gmane.linux.file-systems

Re: v2.6.28-rc1: readlink /proc/*/exe returns uninitialized data to userspace

Andrew Morton — 2008-12-03T20:20:48

On Wed, 3 Dec 2008 09:18:54 -0800 Greg KH kroah.com> wrote: Stuck in -mm. Sent to Al on Dec 1, ignored. As usual. Al, what's going on? Are you thinking that I'm planning on merging these myself? Because if you're on the To: then my intention is that the patch be processed by yourself. -- 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

[PATCH] block_write_begin(): remove useless goto

Franck Bui-Huu — 2008-12-03T20:19:12

From: Franck Bui-Huu gmail.com> Signed-off-by: Franck Bui-Huu gmail.com> --- fs/buffer.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/fs/buffer.c b/fs/buffer.c index 6569fda..a3e2bc8 100644 --- a/fs/buffer.c +++ b/fs/buffer.c < at >< at > -2013,7 +2013,6 < at >< at > int block_write_begin(struct file *file, struct address_space *mapping, if (pos + len > inode->i_size) vmtruncate(inode, inode->i_size); } -goto out; } out:

Re: [PATCH V3 2/3] quota: Add quota claim and release reservedquota

Jan Kara — 2008-12-03T19:06:46

Hmm, I can't find the email with this patch so I've just copied it from some mail archive ;). Sorry if the CC's are wrong. I guess the function should be called like vfs_dq_release_reservation_block(). It's ugly long but we should not omit the "block" part. Maybe we could shorten reservation everywhere in function names to rsv? Please call lowercase variants from ext4 and don't define these functions. Wouldn't a WARN_ON here be more appropriate? It's a filesystem bug to cause this AFAICS. You should use dq_data_lock to protect these operations... It seems a bit silly to try to recover here from filesystem bugs. I'd just make dquot_claim_reserved_space() void and ignore possible failure here. We won't do anything harmful like loosing data. Just counters might become out of sync but given there's a bug in fs anyway it does not matter much. And this should be called from under dq_data_lock from dquot_claim_reserved_space(). BTW: This reminds me that you should also modify dquot_transfer()

[PATCH 3/3] EXPORTFS: Update the documentation and comments andadjust the types used [try #2]

David Howells — 2008-12-03T18:30:44

Update the exportfs documentation and comments to fit the code, and add an extra FID type to be used for error indication (FILEID_ERROR). The following other code changes have been made: (*) The encode_fh() op and exportfs_encode_fh() return enum fid_type rather than int. (*) The exportfs_encode_fh() function has it's acceptable() function pointer typedef'd. (*) The fh_to_dentry() and fh_to_parent() ops and exportfs_decode_fh() take enum fid_type rather than int. (*) The generic_fh_to_dentry() and generic_fh_to_parent() functions now take enum fid_type rather than int. Their get_inode() function pointer has been typedef'd. (*) Returns from encode_fh() implementations of 255 are changed to FILEID_ERROR. (*) FAT has had its fh type #defined (FAT_FILEID). (*) FUSE has had its fh types #defined (FUSE_FILEID, FUSE_FILEID_PARENT). (*) ISOFS has had its fh types #defined (ISOFS_FILEID, ISOFS_FILEID_PARENT). (*) OCFS2 has had its fh types #defined (OCFS2_FILEID, OCFS

[PATCH 2/3] EXPORTFS: Have fh_to_*() return -ESTALE if the filehandle type is unrecognised [try #2]

David Howells — 2008-12-03T18:30:38

Make fh_to_dentry() and fh_to_parent() operations return -ESTALE rather than a negative dentry if the file handle type is unrecognised. Signed-off-by: David Howells redhat.com> --- fs/libfs.c | 4 ++++ fs/xfs/linux-2.6/xfs_export.c | 4 ++++ 2 files changed, 8 insertions(+), 0 deletions(-) diff --git a/fs/libfs.c b/fs/libfs.c index 4fe5b5b..47952f2 100644 --- a/fs/libfs.c +++ b/fs/libfs.c < at >< at > -758,6 +758,8 < at >< at > struct dentry *generic_fh_to_dentry(struct super_block *sb, struct fid *fid, case FILEID_INO32_GEN_PARENT: inode = get_inode(sb, fid->i32.ino, fid->i32.gen); break; +default: +return ERR_PTR(-ESTALE); } return d_obtain_alias(inode); < at >< at > -791,6 +793,8 < at >< at > struct dentry *generic_fh_to_parent(struct super_block *sb, struct fid *fid, inode = get_inode(sb, fid->i32.parent_ino, (fh_len > 3 ? fid->i32.parent_gen : 0)); break; +default: +return ERR_PTR(-ESTALE); } return d_obtain_alias(inode); diff --git a/fs/xfs/linux-2.6/xfs_export.c

[PATCH 1/3] EXPORTFS: Don't return NULL fromfh_to_dentry()/fh_to_parent() [try #2]

David Howells — 2008-12-03T18:30:33

Returning NULL from fh_to_dentry() and fh_to_parent() is not permitted, so return -ESTALE instead. exportfs_decode_fh() does not check for NULL, but will try to dereference it as IS_ERR() does not check for it. The generic_fh_to_dentry() and generic_fh_to_parent() functions also no longer return NULL, but return -ESTALE instead. Signed-off-by: David Howells redhat.com> --- fs/fat/inode.c | 2 +- fs/fuse/inode.c | 4 ++-- fs/gfs2/ops_export.c | 4 ++-- fs/isofs/export.c | 4 ++-- fs/libfs.c | 4 ++-- fs/ocfs2/export.c | 4 ++-- fs/udf/namei.c | 4 ++-- fs/xfs/linux-2.6/xfs_export.c | 2 +- 8 files changed, 14 insertions(+), 14 deletions(-) diff --git a/fs/fat/inode.c b/fs/fat/inode.c index d937aaf..cac84f2 100644 --- a/fs/fat/inode.c +++ b/fs/fat/inode.c < at >< at > -657,7 +657,7 < at >< at > static struct dentry *fat_fh_to_dentry(struct super_block *sb, u32 *fh = fid->raw; if (fh_len <

[PATCH] add a FMODE flag to make XFS invisible I/O less hacky

Christoph Hellwig — 2008-12-03T17:45:27

XFS has a mode called invisble I/O that doesn't update any of the timestamps. It's used for HSM-style applications and exposed through the nasty open by handle ioctl. Instead of doing directly assignment of file operations that set an internal flag for it add a new FMODE_NOCMTIME flag that we can check in the normal file operations. Note that I'd like to get this into 2.6.29 via the XFS tree as there are a lot changes in XFS that would cause conflicts otherwise. For 2.6.30 I'll plan turning it into a proper O_ flag available via open(2), but for now I just want to sort out the XFS issues. Signed-off-by: Christoph Hellwig lst.de> Index: xfs/fs/xfs/linux-2.6/xfs_ioctl32.c =================================================================== --- xfs.orig/fs/xfs/linux-2.6/xfs_ioctl32.c2008-12-03 18:30:14.000000000 +0100 +++

Re: [PATCH] Update the exportfs documentation and comments and fix some exportfs issues

David Howells — 2008-12-03T17:21:31

M-C-q is your friend:-) David -- 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

Re: v2.6.28-rc1: readlink /proc/*/exe returns uninitialized datato userspace

Greg KH — 2008-12-03T17:18:54

What ever happened to this patch? Did it not make it into Linus's tree somehow? thanks, greg k-h (original patch below...) -- 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

Re: [PATCH (mmotm-2008-12-02-17-08)] Introducesecurity_path_set/clear() hooks.

Stephen Smalley — 2008-12-03T14:13:25

Your security_path_set()/security_path_clear() pairs look rather similar to mnt_want_write()/mnt_drop_write() pairs. What if you were to call your hooks from those functions, and then you would only need to add further hook calls in the case of read-only and execute/search checks?

Re: [PATCH] Update the exportfs documentation and comments and fix some exportfs issues

Jörn Engel — 2008-12-03T13:47:13

It is also more susceptible to bitrot, though. :) Jörn

Re: [PATCH] Update the exportfs documentation and comments and fix some exportfs issues

David Howells — 2008-12-03T13:14:03

I can do that, but why not pass a u32* or void* instead in all cases? The operations are under no obligation to use struct fid. It's passed around between a number of functions and it makes the function declarations more readable. Okay. Which isn't used by all exportable filesystems... Should those filesystems have specific entries added to the union in struct fid? Should they be required to use the raw member of struct fid's union? In fact, why struct fid at all: why not union fid? It also seems odd to declare a struct that only has passing acquaintance with reality. struct fid is rarely used to its full extent, and may not even be big enough - something that's decided on a per-use basis. Furthermore, when the decode routines are called, less data may be presented than is required to fill out a struct fid, so overlaying a struct fid on it may include uninitialised data. As I see it, struct fid doesn't gain anything - except perhaps documentary purposes for people looking to build packet snif

Re: [PATCH] Update the exportfs documentation and comments and fixsome exportfs issues

Christoph Hellwig — 2008-12-03T12:50:51

The reason why the IDs for new filesystems go into exportfs.h to make sure they don't clash for different filesystems. While re-using the same ID to mean a different format is technically fine, it's not very nice for people trying to e.g. decipher NFS traffic in wireshark. Somewhere on my TODO list is an item to walk through all the filesystems and make them send out different IDs for new requests that don't overlap while still accepting their legacy IDs for traffic from the time before a server reboot. -- 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

Re: [PATCH] Update the exportfs documentation and comments and fixsome exportfs issues

Christoph Hellwig — 2008-12-03T12:48:50

Once you change the prototype please also pass the struct fid * instead of the current __u32 array, like the fh_to_dentry / fh_to_parent methods. I don't really see the point for that, but I don't care too much. Ok. Ok. Again I don't really see the point of the typede, but hey.. These two should probably be broken out into a smaller patch, before all the cosmetic bits. Ok. Not really true anymore, as we have a real struct for it now. But all the length calculation is still done in number of 4 byte words. Messy.. Why the strange indentation? Two tabs indent for spillover prototypes is pretty much standard.. That cast is completely pointless in C. /* * Persistent file handle encoding and decoding interface -- 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

Re: [PATCH] Update the exportfs documentation and comments and fix some exportfs issues

David Howells — 2008-12-03T10:54:50

I don't know that we want to stick loads of filesystem-specific stuff into a general header file. I believe we used to do that for struct inode (IIRC there used to be a large union with filesystem-specific members). I missed that. Updated. As mentioned above, do we really want to do that? I know. As far as I know, there's no restriction on them reusing types 1 and 2, just an advisory note where these collide with other export types. Perhaps Al or Christoph would care to comment on this. Also, I don't know that changing these types would necessarily be a good idea. wireshark, for example, could multiplex the types by the length as the standard types are lengths 2 and 4, and ISOFS types are 3 and 5. David -- 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

Re: [PATCH] Update the exportfs documentation and comments and fix someexportfs issues

Phillip Lougher — 2008-12-03T08:27:48

You define these in the filesystem c files themselves as #defines. UDF and BTRFS place theirs in the enum fid_type definition itself (in linux/exportfs.h). Is there any reason why you didn't do this? ^^^^ this should be changed to enum fid_type Move to enum fid_type in linux/exportfs.h? Move to enum fid_type in linux/exportfs.h? Type 1 and 2 are also used by the generic fid_types FILEID_INO32_GEN and FILEID_INO32_GEN_PARENT, but (obviously) their formats are different. Phillip -- 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

Re: [PATCH] fs: truncate blocks outside i_size after O_DIRECT write error.

Andrew Morton — 2008-12-02T23:58:37

On Sun, 30 Nov 2008 16:32:46 +0300 Dmitri Monakhov openvz.org> wrote: Only 11? We can do better than that.. Really we should use i_size_read() in both cases (i_mutex might not be held). How does this look? /* * In case of error extending write may have instantiated a few * blocks outside i_size. Trim these off again for DIO_LOCKING. * NOTE: DIO_NO_LOCK/DIO_OWN_LOCK callers have to handle this by * it's own meaner. */ if (unlikely(retval < 0 && (rw & WRITE))) { loff_t isize = i_size_read(inode); if (end > isize && dio_lock_type == DIO_LOCKING) vmtruncate(inode, isize); } -- 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

Re: PROBLEM: hfsplus filesystem allows opendir() on plain files

Brad Boyer — 2008-12-02T22:21:11

Yes, this is a side effect of an intentional behavior. In osx, you can open "file/rsrc" to get the resource fork of "file". This behavior is emulated inside hfsplus on Linux, which means that to some degree every file acts like a directory. There isn't a readdir operation so it's not possible to list these, but it is possible to do a lookup on this specific name. The code path taken by opendir inside the kernel checks inode->i_op->lookup and returns ENOTDIR if this function pointer is not set. We can't fix this without either eliminating this way to open the resource fork or making real changes to the generic Linux code. I'm not sure what would be the appropriate thing to do in this case. Someone on the mailing list is likely to have a strong opinion, so there are likely to be suggestions of one sort or another. Maybe the check in the generic code to decide what is a "directory" should be changed? We could possibly check inode->i_fop->readdir. Brad Boyer flar< at >allandria.com -- To unsubscribe from this

Re: Support for applications which need NFS or CIFS "share_deny" flags on open

Steve French — 2008-12-02T21:26:26

Yes, I think that this is more important for network file systems not local file systems (especially since NFSv4 and CIFS and SMB2 all support these flags in the protocol definition). Since wine (or any subsystem running on a single local linux system) can handle its own locks between application instances, the main problem is that byte range locks can't perfectly emulate the application semantics needed when applications are running on two different "clients" (in this case, one Wine/Linux, and one a Windows client) but mounted to the same server

Re: Support for applications which need NFS or CIFS "share_deny" flags on open

jim owens — 2008-12-02T21:20:18

The title of their proposal was "client"... as in not the local filesystem, but the impression of what wine really wanted is for local linux filesystems to implement these non-posix behaviors so "wine apps can run just like on windows" on the local machine. Thus the strong objection from everyone doing local filesystems. Passing exclusive DENYREAD DENYWRITE DENYDELETE network protocol flags from a linux client to a remote server is an entirely different and IMO acceptible thing. And AFAIK on unix the only local support would be by doing a client-on-server loopback, where the server implements these modes as best it can and you are only protected against wine apps that are also inside the "share drive". jim -- 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

[PATCH] Update the exportfs documentation and comments and fix someexportfs issues

David Howells — 2008-12-02T21:02:33

Update the exportfs documentation and comments to fit the code, and add an extra FID type to be used for error indication (FILEID_ERROR). The following other code changes have been made: (*) The encode_fh() op and exportfs_encode_fh() return enum fid_type rather than int. (*) The exportfs_encode_fh() function has it's acceptable() function pointer typedef'd. (*) The fh_to_dentry() and fh_to_parent() ops and exportfs_decode_fh() take enum fid_type rather than int. (*) The generic_fh_to_dentry() and generic_fh_to_parent() functions now take enum fid_type rather than int. Their get_inode() function pointer has been typedef'd. (*) The generic_fh_to_dentry() and generic_fh_to_parent() functions no longer return NULL, but return -ESTALE instead. exportfs_decode_fh() does not check for NULL, but will try to dereference it as IS_ERR() does not check for it. (*) Returns from encode_fh() implementations of 255 are changed to FILEID_ERROR. (*) FAT has had it