headers
Ben Hutchings | 1 May 2012 01:31
Picon

Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

On Mon, 2012-04-30 at 16:30 -0400, J. Bruce Fields wrote:
> On Mon, Apr 30, 2012 at 09:15:56PM +0100, David Howells wrote:
> > Ben Hutchings <ben <at> decadent.org.uk> wrote:
> > 
> > > Try 86,400 seconds - the actual granularity of atime on VFAT.
> > 
> > 24 hours?  Really?  I guess it makes the updating of atime on the media
> > something you can be lazy about.
> > 
> > > (For mtime it's 2 seconds, and for ctime 0.01 seconds.)
> 
> Does it actually support ctime, or is there some confusion here between
> unix ctime and file creation time?

I think there is some confusion, yes.  The Linux implementation stores
ctime, but the documentation I can find refers to creation time.

> > Sigh.  Okay.  Ugh.  I guess I need separate granularities after all...  Not
> > only that, but a 32-bit integer isn't sufficiently capacious to hold the full
> > range I now know about (1nS up to 1 day).
> > 
> > I wonder if granularity should be left to a statfsxat() syscall?
> > 
> > And I know Linus didn't like it, but I wonder if I can pack it in to a 32-bit
> > word either by doing an x * 10^y thing.
> 
> Does it matter if we don't get vfat's atime granularity exactly right?
> Is anyone ever going to use it for anything?

I thought the point of this extension was to let callers know what
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Moyer | 1 May 2012 15:46
Picon
Favicon

[patch|rfc] block: don't mark buffers beyond end of disk as mapped

Hi,

We have a bug report open where a squashfs image mounted on ppc64 would
exhibit errors due to trying to read beyond the end of the disk.  It can
easily be reproduced by doing the following:

[root <at> ibm-p750e-02-lp3 ~]# ls -l install.img
-rw-r--r-- 1 root root 142032896 Apr 30 16:46 install.img
[root <at> ibm-p750e-02-lp3 ~]# mount -o loop ./install.img /mnt/test
[root <at> ibm-p750e-02-lp3 ~]# dd if=/dev/loop0 of=/dev/null 
dd: reading `/dev/loop0': Input/output error
277376+0 records in
277376+0 records out
142016512 bytes (142 MB) copied, 0.9465 s, 150 MB/s

In dmesg, you'll find the following:

squashfs: version 4.0 (2009/01/31) Phillip Lougher
[   43.106012] attempt to access beyond end of device
[   43.106029] loop0: rw=0, want=277410, limit=277408
[   43.106039] Buffer I/O error on device loop0, logical block 138704
[   43.106053] attempt to access beyond end of device
[   43.106057] loop0: rw=0, want=277412, limit=277408
[   43.106061] Buffer I/O error on device loop0, logical block 138705
[   43.106066] attempt to access beyond end of device
[   43.106070] loop0: rw=0, want=277414, limit=277408
[   43.106073] Buffer I/O error on device loop0, logical block 138706
[   43.106078] attempt to access beyond end of device
[   43.106081] loop0: rw=0, want=277416, limit=277408
[   43.106085] Buffer I/O error on device loop0, logical block 138707
(Continue reading)

Permalink | Reply | 7 comments |
headers
Nick Piggin | 1 May 2012 16:01
Picon

Re: [patch|rfc] block: don't mark buffers beyond end of disk as mapped

On 1 May 2012 23:46, Jeff Moyer <jmoyer <at> redhat.com> wrote:
> Hi,
>
> We have a bug report open where a squashfs image mounted on ppc64 would
> exhibit errors due to trying to read beyond the end of the disk.  It can
> easily be reproduced by doing the following:
>
> [root <at> ibm-p750e-02-lp3 ~]# ls -l install.img
> -rw-r--r-- 1 root root 142032896 Apr 30 16:46 install.img
> [root <at> ibm-p750e-02-lp3 ~]# mount -o loop ./install.img /mnt/test
> [root <at> ibm-p750e-02-lp3 ~]# dd if=/dev/loop0 of=/dev/null
> dd: reading `/dev/loop0': Input/output error
> 277376+0 records in
> 277376+0 records out
> 142016512 bytes (142 MB) copied, 0.9465 s, 150 MB/s
>
> In dmesg, you'll find the following:
>
> squashfs: version 4.0 (2009/01/31) Phillip Lougher
> [   43.106012] attempt to access beyond end of device
> [   43.106029] loop0: rw=0, want=277410, limit=277408
> [   43.106039] Buffer I/O error on device loop0, logical block 138704
> [   43.106053] attempt to access beyond end of device
> [   43.106057] loop0: rw=0, want=277412, limit=277408
> [   43.106061] Buffer I/O error on device loop0, logical block 138705
> [   43.106066] attempt to access beyond end of device
> [   43.106070] loop0: rw=0, want=277414, limit=277408
> [   43.106073] Buffer I/O error on device loop0, logical block 138706
> [   43.106078] attempt to access beyond end of device
> [   43.106081] loop0: rw=0, want=277416, limit=277408
(Continue reading)

Permalink | Reply | 6 comments |
headers
Jeff Moyer | 1 May 2012 16:08
Picon
Favicon

Re: [patch|rfc] block: don't mark buffers beyond end of disk as mapped

Nick Piggin <npiggin <at> gmail.com> writes:

> Not a bad fix. But it's kind of sad to have i_size checking logic also in
> block_read_full_page, that does not cope with this.
>
> I have found there are parts of the kernel (readahead) that try to read
> beyond EOF and seem to get angry if we return an error (by not
> marking uptodate in readpage) in that case though :(
>
> But, either way, I think it's very reasonable to not mark buffers beyond
> end of device as mapped. So I think your patch is fine.
>
> I guess for ext[234], it does not read metadata close to the end of the
> device or you were using 4K sized blocks?

Well, the test case just reads directly from the loop device, bypassing
the file system, and I did use 1KB blocks when making the file system, so
it is quite puzzling.

Thanks for taking a look, Nick.

Cheers,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 5 comments |
headers
Andy Whitcroft | 1 May 2012 17:17
Favicon

[PATCH 2/5] overlayfs: switch to use inode_only_permissions

When checking permissions on an overlayfs inode we do not take into
account either device cgroup restrictions nor security permissions.
This allows a user to mount an overlayfs layer over a restricted device
directory and by pass those permissions to open otherwise restricted
files.

Switch over to the newly introduced inode_only_permissions.

Signed-off-by: Andy Whitcroft <apw <at> canonical.com>
---
 fs/overlayfs/inode.c |   12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c
index ba1a777..bc9178c 100644
--- a/fs/overlayfs/inode.c
+++ b/fs/overlayfs/inode.c
 <at>  <at>  -105,19 +105,9  <at>  <at>  int ovl_permission(struct inode *inode, int mask)
 		if (is_upper && !IS_RDONLY(inode) && IS_RDONLY(realinode) &&
 		    (S_ISREG(mode) || S_ISDIR(mode) || S_ISLNK(mode)))
 			goto out_dput;
-
-		/*
-		 * Nobody gets write access to an immutable file.
-		 */
-		err = -EACCES;
-		if (IS_IMMUTABLE(realinode))
-			goto out_dput;
 	}
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Moyer | 1 May 2012 22:37
Picon
Favicon

Re: [patch|rfc] block: don't mark buffers beyond end of disk as mapped

Nick Piggin <npiggin <at> gmail.com> writes:

> On 2 May 2012 00:08, Jeff Moyer <jmoyer <at> redhat.com> wrote:
>> Nick Piggin <npiggin <at> gmail.com> writes:
>>
>>> Not a bad fix. But it's kind of sad to have i_size checking logic also in
>>> block_read_full_page, that does not cope with this.
>>>
>>> I have found there are parts of the kernel (readahead) that try to read
>>> beyond EOF and seem to get angry if we return an error (by not
>>> marking uptodate in readpage) in that case though :(
>>>
>>> But, either way, I think it's very reasonable to not mark buffers beyond
>>> end of device as mapped. So I think your patch is fine.
>>>
>>> I guess for ext[234], it does not read metadata close to the end of the
>>> device or you were using 4K sized blocks?
>>
>> Well, the test case just reads directly from the loop device, bypassing
>> the file system, and I did use 1KB blocks when making the file system, so
>> it is quite puzzling.
>
> It's because buffer_head creation does not go through the same paths
> for bdev file access versus getblk APIs.
>
> blkdev_get_block does the right thing there
>
> In fact, it's probably good to unify the checks here, i.e., use max_blocks()

You really think it's worth it?  I mean, it's just an i_size_read and a
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jeff Moyer | 1 May 2012 23:40
Picon
Favicon

Re: [patch|rfc] block: don't mark buffers beyond end of disk as mapped

Jeff Moyer <jmoyer <at> redhat.com> writes:

> Nick Piggin <npiggin <at> gmail.com> writes:
>
>> On 2 May 2012 00:08, Jeff Moyer <jmoyer <at> redhat.com> wrote:
>>> Nick Piggin <npiggin <at> gmail.com> writes:
>>>
>>>> Not a bad fix. But it's kind of sad to have i_size checking logic also in
>>>> block_read_full_page, that does not cope with this.
>>>>
>>>> I have found there are parts of the kernel (readahead) that try to read
>>>> beyond EOF and seem to get angry if we return an error (by not
>>>> marking uptodate in readpage) in that case though :(
>>>>
>>>> But, either way, I think it's very reasonable to not mark buffers beyond
>>>> end of device as mapped. So I think your patch is fine.
>>>>
>>>> I guess for ext[234], it does not read metadata close to the end of the
>>>> device or you were using 4K sized blocks?
>>>
>>> Well, the test case just reads directly from the loop device, bypassing
>>> the file system, and I did use 1KB blocks when making the file system, so
>>> it is quite puzzling.
>>
>> It's because buffer_head creation does not go through the same paths
>> for bdev file access versus getblk APIs.
>>
>> blkdev_get_block does the right thing there
>>
>> In fact, it's probably good to unify the checks here, i.e., use max_blocks()
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nick Piggin | 2 May 2012 01:23
Picon

Re: [patch|rfc] block: don't mark buffers beyond end of disk as mapped

On 2 May 2012 07:40, Jeff Moyer <jmoyer <at> redhat.com> wrote:
> Jeff Moyer <jmoyer <at> redhat.com> writes:
>
>> Nick Piggin <npiggin <at> gmail.com> writes:
>>
>>> On 2 May 2012 00:08, Jeff Moyer <jmoyer <at> redhat.com> wrote:
>>>> Nick Piggin <npiggin <at> gmail.com> writes:
>>>>
>>>>> Not a bad fix. But it's kind of sad to have i_size checking logic also in
>>>>> block_read_full_page, that does not cope with this.
>>>>>
>>>>> I have found there are parts of the kernel (readahead) that try to read
>>>>> beyond EOF and seem to get angry if we return an error (by not
>>>>> marking uptodate in readpage) in that case though :(
>>>>>
>>>>> But, either way, I think it's very reasonable to not mark buffers beyond
>>>>> end of device as mapped. So I think your patch is fine.
>>>>>
>>>>> I guess for ext[234], it does not read metadata close to the end of the
>>>>> device or you were using 4K sized blocks?
>>>>
>>>> Well, the test case just reads directly from the loop device, bypassing
>>>> the file system, and I did use 1KB blocks when making the file system, so
>>>> it is quite puzzling.
>>>
>>> It's because buffer_head creation does not go through the same paths
>>> for bdev file access versus getblk APIs.
>>>
>>> blkdev_get_block does the right thing there
>>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonson Chong, | 1 May 2012 16:45
Picon
Favicon

Mutual Benefit


62A-1 Jalan PJU 5/21,
The Strand Kota Damansara,
47801 Petaling Jaya, Malaysia.

I am Jonson Chong,an attorney at law and i would love to share with you a very important business 
proposition that will be of mutual benefit to both of us.
 A deceased client of mine,that shares the same last name as yours,who after shall be referred to as 
my late client,died as the result of a heart-related condition on March 12th 2009.
His heart condition was due to the death of all the members of his family in the tsunami disaster on the 26th
 December 2004 in Sumatra Indonesia .

http://en.wikipedia.org/wiki/2004_Indian_Ocean_earthquake
My late Client has a deposit of ( US$17.5 Million Dollars) left behind.
I can be reached on (jclegalfirm001 <at> gmail.com) for more information.

Email: jclegalfirm001 <at> gmail.com
Best regards,
Jonson Chong
Attorney at Law
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Tetsuo Handa | 2 May 2012 15:40
Picon

/proc/pid/fd/ shows strange mode when executed via sudo.

I noticed a strange difference in /proc/pid/fd/ directory
when a command is executed via /usr/bin/sudo.

Say, there are three files in some directory.
(In my environment, /tmp/ is a plain ext4 partition.)

# touch /tmp/1
# touch /tmp/2
# touch /tmp/3
# ls -l /tmp/?
-rw-r--r-- 1 root root 0 May  2 21:48 /tmp/1
-rw-r--r-- 1 root root 0 May  2 21:48 /tmp/2
-rw-r--r-- 1 root root 0 May  2 21:48 /tmp/3

Try to read one of them using "tail -f" from one terminal.

# tail -f /tmp/1

Show /proc/pid/fd/ from another terminal.

# ls -l /proc/`pidof tail`/fd/
total 0
lrwx------ 1 root root 64 May  2 21:54 0 -> /dev/pts/0
lrwx------ 1 root root 64 May  2 21:54 1 -> /dev/pts/0
lrwx------ 1 root root 64 May  2 21:54 2 -> /dev/pts/0
lr-x------ 1 root root 64 May  2 21:54 3 -> /tmp/1
lr-x------ 1 root root 64 May  2 21:54 4 -> anon_inode:inotify

Quit the "tail -f". Try to read two of them using "tail -f".
(Continue reading)

Permalink | Reply | 19 comments |

Gmane