Re: [PATCH 01/26] document nlink function

2007-06-23 Thread Christoph Hellwig
On Fri, Jun 22, 2007 at 01:03:04PM -0700, Dave Hansen wrote: These should have been documented from the beginning. Fix it. Ok. This is a trivial doc fix and should go into the 2.6.22 queue IMHO. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a

Re: [PATCH 03/26] ext4: remove extra IS_RDONLY() check

2007-06-23 Thread Christoph Hellwig
On Fri, Jun 22, 2007 at 01:03:06PM -0700, Dave Hansen wrote: ext4_change_inode_journal_flag() is only called from one location: ext4_ioctl(EXT3_IOC_SETFLAGS). That ioctl case already has a IS_RDONLY() call in it so this one is superfluous. Ditto. - To unsubscribe from this list: send the

Re: [PATCH 04/26] filesystem helpers for custom 'struct file's

2007-06-23 Thread Christoph Hellwig
On Fri, Jun 22, 2007 at 01:03:08PM -0700, Dave Hansen wrote: Christoph H. says this stands on its own and can go in before the rest of the r/o bind mount set. --- Some filesystems forego the vfs and may_open() and create their own 'struct file's. This patch creates a couple of

Re: [PATCH 05/26] r/o bind mounts: stub functions

2007-06-23 Thread Christoph Hellwig
On Fri, Jun 22, 2007 at 01:03:09PM -0700, Dave Hansen wrote: This patch adds two function mnt_want_write() and mnt_drop_write(). These are used like a lock pair around and fs operations that might cause a write to the filesystem. Before these can become useful, we must first cover each

Re: [PATCH 06/26] elevate write count open()'d files

2007-06-23 Thread Christoph Hellwig
On Fri, Jun 22, 2007 at 01:03:10PM -0700, Dave Hansen wrote: This is the first really tricky patch in the series. It elevates the writer count on a mount each time a non-special file is opened for write. This is not completely apparent in the patch because the two if() conditions in

Re: [PATCH 09/26] make access() use mnt check

2007-06-23 Thread Christoph Hellwig
On Fri, Jun 22, 2007 at 01:03:14PM -0700, Dave Hansen wrote: It is OK to let access() go without using a mnt_want/drop_write() pair because it doesn't actually do writes to the filesystem, and it is inherently racy anyway. This is a rare case when it is OK to use __mnt_is_readonly()

Re: [PATCH 10/26] elevate mnt writers for callers of vfs_mkdir()

2007-06-23 Thread Christoph Hellwig
On Fri, Jun 22, 2007 at 01:03:16PM -0700, Dave Hansen wrote: Pretty self-explanatory. Fits in with the rest of the series. Ok for this and similar patch 11-13. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More

Re: [PATCH 14/26] elevate write count for file_update_time()

2007-06-23 Thread Christoph Hellwig
On Fri, Jun 22, 2007 at 01:03:21PM -0700, Dave Hansen wrote: Signed-off-by: Dave Hansen [EMAIL PROTECTED] We really want a guaranteed non-NULL file here, but I don't want to put this on your plate also. Please add a comment about bloody NFS exports for now. - To unsubscribe from this list:

Re: [PATCH 15/26] mount_is_safe(): add comment

2007-06-23 Thread Christoph Hellwig
On Fri, Jun 22, 2007 at 01:03:22PM -0700, Dave Hansen wrote: This area of code is currently #ifdef'd out, so add a comment for the time when it is actually used. Ok. Does this clash with the user mount patches? Even if it does I think we want this patch first in the series and fix the

Re: [PATCH 17/26] elevate write count over calls to vfs_rename()

2007-06-23 Thread Christoph Hellwig
On Fri, Jun 22, 2007 at 01:03:25PM -0700, Dave Hansen wrote: This also creates a little helper in the NFS code to make an if() a little bit less ugly. That should probably be a separate patch. Or better one to just rip out the MSNFS ifdefs completely, they've always been true for about the

Re: [PATCH 18/26] nfs: check mnt instead of superblock directly

2007-06-23 Thread Christoph Hellwig
Ok. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 19/26] elevate writer count for do_sys_truncate()

2007-06-23 Thread Christoph Hellwig
Ok. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 20/26] elevate write count for do_utimes()

2007-06-23 Thread Christoph Hellwig
Ok. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 21/26] elevate write count for do_sys_utime() and touch_atime()

2007-06-23 Thread Christoph Hellwig
Ok. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 22/26] sys_mknodat(): elevate write count for vfs_mknod/create()

2007-06-23 Thread Christoph Hellwig
On Fri, Jun 22, 2007 at 01:03:32PM -0700, Dave Hansen wrote: This takes care of all of the direct callers of vfs_mknod(). Since a few of these cases also handle normal file creation as well, this also covers some calls to vfs_create(). Ok. diff -puN

Re: [PATCH 23/26] elevate mnt writers for vfs_unlink() callers

2007-06-23 Thread Christoph Hellwig
Ok. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 24/26] do_rmdir(): elevate write count

2007-06-23 Thread Christoph Hellwig
Ok. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 07/26] r/o bind mounts: elevate write count for some ioctls

2007-06-23 Thread Christoph Hellwig
On Fri, Jun 22, 2007 at 01:03:12PM -0700, Dave Hansen wrote: Some ioctl()s can cause writes to the filesystem. Take these, and make them use mnt_want/drop_write() instead. We need to pass the filp one layer deeper in XFS, but somebody _just_ pulled it out in February because nobody was

Re: [PATCH 08/26] elevate writer count for chown and friends

2007-06-23 Thread Christoph Hellwig
On Fri, Jun 22, 2007 at 01:03:13PM -0700, Dave Hansen wrote: chown/chmod,etc... don't call permission in the same way that the normal open for write calls do. They still write to the filesystem, so bump the write count during these operations. Looks good. - To unsubscribe from this

Re: [PATCH 26/26] honor r/w changes at do_remount() time

2007-06-23 Thread Christoph Hellwig
On Fri, Jun 22, 2007 at 01:03:37PM -0700, Dave Hansen wrote: Originally from: Herbert Poetzl [EMAIL PROTECTED] This is the core of the read-only bind mount patch set. Note that this does _not_ add a ro option directly to the bind mount operation. If you require such a mount, you must

Re: [PATCH] make iunique use a do/while loop rather than its obscure goto loop

2007-06-23 Thread Christoph Hellwig
On Wed, Apr 11, 2007 at 05:58:56PM -0400, Jeffrey Layton wrote: A while back, Christoph mentioned that he thought that iunique ought to be cleaned up to use a more conventional loop construct. This patch does that, turning the strange goto loop into a do/while. Signed-off-by: Jeff Layton

Re: [PATCH 25/26] r/o bind mounts: scalable writer count

2007-06-23 Thread Miklos Szeredi
This uses a statically-allocated percpu variable. All operations are local to a cpu as long that cpu operates on the same mount, and there are no writer count imbalances. Writer count imbalances happen when a write is taken on one cpu, and released on another, like when an open/close pair

Re: [PATCH 25/26] r/o bind mounts: scalable writer count

2007-06-23 Thread Miklos Szeredi
I'd suggest something along these lines in final mntput: lock_and_coalesce_cpu_mnt_writer_counts(); mnt_unlock_cpus(); BUG_ON(atomic_read(mnt-__mnt_writers)); Or rather a WARN_ON(), since it's not a fatal condition. Miklos - To unsubscribe from this list: send the line

Re: [PATCH 04/26] filesystem helpers for custom 'struct file's

2007-06-23 Thread Andrew Morton
On Fri, 22 Jun 2007 13:03:08 -0700 Dave Hansen [EMAIL PROTECTED] wrote: Christoph H. says this stands on its own and can go in before the rest of the r/o bind mount set. --- Some filesystems forego the vfs and may_open() and create their own 'struct file's. This patch creates a

Re: [PATCH 00/26] Mount writer count and read-only bind mounts

2007-06-23 Thread Andrew Morton
On Fri, 22 Jun 2007 13:03:03 -0700 Dave Hansen [EMAIL PROTECTED] wrote: Why do we need r/o bind mounts? This feature allows a read-only view into a read-write filesystem. In the process of doing that, it also provides infrastructure for keeping track of the number of writers to any given

Re: [PATCH 05/26] r/o bind mounts: stub functions

2007-06-23 Thread Andrew Morton
On Fri, 22 Jun 2007 13:03:09 -0700 Dave Hansen [EMAIL PROTECTED] wrote: This patch adds two function mnt_want_write() and mnt_drop_write() ITYM global, exported-to-modules yet 100% undocumented functions. tsk. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the

Re: [-mm PATCH] ocfs2: -fallocate() support

2007-06-23 Thread Andrew Morton
On Thu, 21 Jun 2007 12:01:43 -0700 Mark Fasheh [EMAIL PROTECTED] wrote: Plug ocfs2 into the -fallocate() callback. We only support FA_ALLOCATE for now - FA_DEALLOCATE will come later. I get a healthy reject when applying this against your own tree. Perhaps because my copy of it is a few days

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

2007-06-23 Thread Toshiharu Harada
This thread is amazing. With so many smart people's precious time, What are the results? What are the issues anyway? Is anyone happy? (I'm not and I assume Chris is not) Yes, waste of time is taking place here, but it's not for pathname-based MAC but for wrongly posted messages, I believe.

Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

2007-06-23 Thread Toshiharu Harada
This thread is amazing. With so many smart people's precious time, What are the results? What are the issues anyway? Is anyone happy? (I'm not and I assume Chris is not) Yes, waste of time is taking place here, but it's not for pathname-based MAC but for wrongly posted messages, I believe. I'm

[RFC] fsblock

2007-06-23 Thread Nick Piggin
I'm announcing fsblock now because it is quite intrusive and so I'd like to get some thoughts about significantly changing this core part of the kernel. fsblock is a rewrite of the buffer layer (ding dong the witch is dead), which I have been working on, on and off and is now at the stage where

[patch 2/3] block_dev: convert to fsblock

2007-06-23 Thread Nick Piggin
Convert block_dev mostly to fsblocks. --- fs/block_dev.c | 204 +++- fs/buffer.c | 113 ++-- fs/super.c |2 include/linux/buffer_head.h |9 - include/linux/fs.h | 29

[patch 3/3] minix: convert to fsblock

2007-06-23 Thread Nick Piggin
Convert minix from buffer head to fsblock. --- fs/minix/bitmap.c | 148 +-- fs/minix/file.c |6 - fs/minix/inode.c| 172 ++-- fs/minix/itree_common.c | 227

Re: [RFC] fsblock

2007-06-23 Thread Nick Piggin
Just clarify a few things. Don't you hate rereading a long work you wrote? (oh, you're supposed to do that *before* you press send?). On Sun, Jun 24, 2007 at 03:45:28AM +0200, Nick Piggin wrote: I'm announcing fsblock now because it is quite intrusive and so I'd like to get some thoughts

Re: [RFC] fsblock

2007-06-23 Thread Jeff Garzik
Nick Piggin wrote: - No deadlocks (hopefully). The buffer layer is technically deadlocky by design, because it can require memory allocations at page writeout-time. It also has one path that cannot tolerate memory allocation failures. No such problems for fsblock, which keeps fsblock

Re: [RFC] fsblock

2007-06-23 Thread Nick Piggin
On Sat, Jun 23, 2007 at 11:07:54PM -0400, Jeff Garzik wrote: Nick Piggin wrote: - No deadlocks (hopefully). The buffer layer is technically deadlocky by design, because it can require memory allocations at page writeout-time. It also has one path that cannot tolerate memory allocation

Re: [RFC] fsblock

2007-06-23 Thread William Lee Irwin III
On Sun, Jun 24, 2007 at 03:45:28AM +0200, Nick Piggin wrote: fsblock is a rewrite of the buffer layer (ding dong the witch is dead), which I have been working on, on and off and is now at the stage where some of the basics are working-ish. This email is going to be long... Long overdue. Thank

vm/fs meetup in september?

2007-06-23 Thread Nick Piggin
I'd just like to take the chance also to ask about a VM/FS meetup some time around kernel summit (maybe take a big of time during UKUUG or so). I was thinking about trying to arrange a proper mini summit thing, but it's a bit difficult and we could talk this year about doing it for subsequent