Re: [PATCH 1/2] fs: use memclear_highpage_flush to zero page data

[Andrew Morton]

On Mon, 09 Apr 2007 21:31:37 -0700 Nate Diller <[EMAIL PROTECTED]> wrote:

> It's very common for file systems to need to zero part or all of a page, the
> simplist way is just to use kmap_atomic() and memset().  There's actually a
> library function in include/linux/highmem.h that does exactly that, but it's
> confusingly named memclear_highpage_flush(), which is descriptive of *how*
> it does the work rather than what the *purpose* is.  So this patch renames
> the function to zero_page_data(), and calls it from the various places that
> currently open code it.
> 
> Compile tested in x86_64.
> 
> signed-off-by: Nate Diller <[EMAIL PROTECTED]>
> 
> ---
> 
>  drivers/block/loop.c |6 ---
>  fs/affs/file.c   |6 ---
>  fs/buffer.c  |   53 
> +--
>  fs/direct-io.c   |8 +---
>  fs/ecryptfs/mmap.c   |   14 +---
>  fs/ext3/inode.c  |   12 +--
>  fs/ext4/inode.c  |   12 +--
>  fs/ext4/writeback.c  |   12 +--
>  fs/gfs2/bmap.c   |6 ---
>  fs/mpage.c   |   11 +-
>  fs/nfs/read.c|   10 ++---
>  fs/nfs/write.c   |2 -
>  fs/ntfs/aops.c   |   32 +++---
>  fs/ntfs/file.c   |   47 +--
>  fs/ocfs2/aops.c  |5 --
>  fs/reiser4/plugin/file/cryptcompress.c   |   19 +--
>  fs/reiser4/plugin/file/file.c|6 ---
>  fs/reiser4/plugin/item/ctail.c   |6 ---
>  fs/reiser4/plugin/item/extent_file_ops.c |   19 +++
>  fs/reiser4/plugin/item/tail.c|8 +---
>  fs/reiserfs/file.c   |   39 ++
>  fs/reiserfs/inode.c  |   13 +--
>  fs/xfs/linux-2.6/xfs_lrw.c   |2 -
>  include/linux/highmem.h  |2 -
>  mm/filemap_xip.c |7 
>  mm/truncate.c|2 -
>  26 files changed, 78 insertions(+), 281 deletions(-)
> 

Not sure that I agree with the name zero_page_data().  People might use it
to, err, zero a page's data.  Whereas it is really only for use against
*user* pages.   zero_user_page(), perhaps.

Plus..

This patch as presented causes me surprising amounts of trouble.  I need to
split it up into

  - core plus filesystems which don't have maintainers (for me to merge)

  - filesystems which do have maintainers (one patch per), for
maintainers to merge.

  - another patch for reiser4, to remain in -mm.

And this is actually not possible to do, because my merge and the subsystem
maintainers' merges will happen at different times.  In the intervening
window, the kernel won't compile.

So instead I need to

  - split off the reiser4 bit

  - get acks from fs maintainers on the rest

  - merge the whole thing in one hit (minus reiser4)

And I can do that, but it is the less preferable option.


The better way to do this merge is:

patch #1:

static inline void memclear_highpage_flush(...) __deprecated
{
zero_user_page(...);
}

patch #2..n:  convert filesystems.


then, when all filesystems are converted, we're ready to remove
memclear_highpage_flush().  But we do that six months later - let's not
screw out-of-tree fs maintainers (and their users) unnecessarily.

-
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

[PATCH 1/2] fs: use memclear_highpage_flush to zero page data

[Nate Diller]

It's very common for file systems to need to zero part or all of a page, the
simplist way is just to use kmap_atomic() and memset().  There's actually a
library function in include/linux/highmem.h that does exactly that, but it's
confusingly named memclear_highpage_flush(), which is descriptive of *how*
it does the work rather than what the *purpose* is.  So this patch renames
the function to zero_page_data(), and calls it from the various places that
currently open code it.

Compile tested in x86_64.

signed-off-by: Nate Diller <[EMAIL PROTECTED]>

---

 drivers/block/loop.c |6 ---
 fs/affs/file.c   |6 ---
 fs/buffer.c  |   53 +--
 fs/direct-io.c   |8 +---
 fs/ecryptfs/mmap.c   |   14 +---
 fs/ext3/inode.c  |   12 +--
 fs/ext4/inode.c  |   12 +--
 fs/ext4/writeback.c  |   12 +--
 fs/gfs2/bmap.c   |6 ---
 fs/mpage.c   |   11 +-
 fs/nfs/read.c|   10 ++---
 fs/nfs/write.c   |2 -
 fs/ntfs/aops.c   |   32 +++---
 fs/ntfs/file.c   |   47 +--
 fs/ocfs2/aops.c  |5 --
 fs/reiser4/plugin/file/cryptcompress.c   |   19 +--
 fs/reiser4/plugin/file/file.c|6 ---
 fs/reiser4/plugin/item/ctail.c   |6 ---
 fs/reiser4/plugin/item/extent_file_ops.c |   19 +++
 fs/reiser4/plugin/item/tail.c|8 +---
 fs/reiserfs/file.c   |   39 ++
 fs/reiserfs/inode.c  |   13 +--
 fs/xfs/linux-2.6/xfs_lrw.c   |2 -
 include/linux/highmem.h  |2 -
 mm/filemap_xip.c |7 
 mm/truncate.c|2 -
 26 files changed, 78 insertions(+), 281 deletions(-)

---

diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/drivers/block/loop.c 
linux-2.6.21-rc6-mm1-test/drivers/block/loop.c
--- linux-2.6.21-rc6-mm1/drivers/block/loop.c   2007-04-09 17:24:00.0 
-0700
+++ linux-2.6.21-rc6-mm1-test/drivers/block/loop.c  2007-04-09 
18:18:23.0 -0700
@@ -244,17 +244,13 @@ static int do_lo_send_aops(struct loop_d
transfer_result = lo_do_transfer(lo, WRITE, page, offset,
bvec->bv_page, bv_offs, size, IV);
if (unlikely(transfer_result)) {
-   char *kaddr;
-
/*
 * The transfer failed, but we still write the data to
 * keep prepare/commit calls balanced.
 */
printk(KERN_ERR "loop: transfer error block %llu\n",
   (unsigned long long)index);
-   kaddr = kmap_atomic(page, KM_USER0);
-   memset(kaddr + offset, 0, size);
-   kunmap_atomic(kaddr, KM_USER0);
+   zero_page_data(page, offset, size);
}
flush_dcache_page(page);
ret = aops->commit_write(file, page, offset,
diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/fs/affs/file.c 
linux-2.6.21-rc6-mm1-test/fs/affs/file.c
--- linux-2.6.21-rc6-mm1/fs/affs/file.c 2007-04-09 17:23:48.0 -0700
+++ linux-2.6.21-rc6-mm1-test/fs/affs/file.c2007-04-09 18:18:23.0 
-0700
@@ -628,11 +628,7 @@ static int affs_prepare_write_ofs(struct
return err;
}
if (to < PAGE_CACHE_SIZE) {
-   char *kaddr = kmap_atomic(page, KM_USER0);
-
-   memset(kaddr + to, 0, PAGE_CACHE_SIZE - to);
-   flush_dcache_page(page);
-   kunmap_atomic(kaddr, KM_USER0);
+   zero_page_data(page, to, PAGE_CACHE_SIZE - to);
if (size > offset + to) {
if (size < offset + PAGE_CACHE_SIZE)
tmp = size & ~PAGE_CACHE_MASK;
diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/fs/buffer.c 
linux-2.6.21-rc6-mm1-test/fs/buffer.c
--- linux-2.6.21-rc6-mm1/fs/buffer.c2007-04-09 17:24:03.0 -0700
+++ linux-2.6.21-rc6-mm1-test/fs/buffer.c   2007-04-09 18:18:23.0 
-0700
@@ -1862,13 +1862,8 @@ static int __block_prepare_write(struct 
if (block_start >= to)
break;
if (buffer_new(bh)) {
-   void *kaddr;
-
clear_buffer_new(bh);
-   kaddr = kmap_atomic(page, KM_USER0);
-   memset(kaddr+block_start, 0, bh->b_size);
-   flush_dcache_page(page);
-   kunmap_atomic(kaddr, KM_USER0);
+   

[PATCH 2/2] fs: use simple_prepare_write to zero page data

[Nate Diller]

It's common for file systems to need to zero data on either side of a write,
if a page is not Uptodate during prepare_write.  It just so happens that
simple_prepare_write() in libfs.c does exactly that, so we can avoid
duplication and just call that function to zero page data.

Compile tested on x86_64.

signed-off-by: Nate Diller <[EMAIL PROTECTED]>

---

 cifs/file.c   |9 +
 ext4/writeback.c  |   17 +
 reiser4/plugin/item/extent_file_ops.c |   13 +++--
 3 files changed, 5 insertions(+), 34 deletions(-)

---

diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/fs/cifs/file.c 
linux-2.6.21-rc6-mm1-test/fs/cifs/file.c
--- linux-2.6.21-rc6-mm1/fs/cifs/file.c 2007-04-09 18:25:37.0 -0700
+++ linux-2.6.21-rc6-mm1-test/fs/cifs/file.c2007-04-09 18:23:16.0 
-0700
@@ -1955,14 +1955,7 @@ static int cifs_prepare_write(struct fil
 * We don't need to read data beyond the end of the file.
 * zero it, and set the page uptodate
 */
-   void *kaddr = kmap_atomic(page, KM_USER0);
-
-   if (from)
-   memset(kaddr, 0, from);
-   if (to < PAGE_CACHE_SIZE)
-   memset(kaddr + to, 0, PAGE_CACHE_SIZE - to);
-   flush_dcache_page(page);
-   kunmap_atomic(kaddr, KM_USER0);
+   simple_prepare_write(file, page, from, to);
SetPageUptodate(page);
} else if ((file->f_flags & O_ACCMODE) != O_WRONLY) {
/* might as well read a page, it is fast enough */
diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/fs/ext4/writeback.c 
linux-2.6.21-rc6-mm1-test/fs/ext4/writeback.c
--- linux-2.6.21-rc6-mm1/fs/ext4/writeback.c2007-04-09 18:32:52.0 
-0700
+++ linux-2.6.21-rc6-mm1-test/fs/ext4/writeback.c   2007-04-09 
18:23:16.0 -0700
@@ -819,21 +819,6 @@ int ext4_wb_writepages(struct address_sp
return 0;
 }
 
-static void ext4_wb_clear_page(struct page *page, int from, int to)
-{
-   void *kaddr;
-
-   if (to < PAGE_CACHE_SIZE || from > 0) {
-   kaddr = kmap_atomic(page, KM_USER0);
-   if (PAGE_CACHE_SIZE > to)
-   memset(kaddr + to, 0, PAGE_CACHE_SIZE - to);
-   if (0 < from)
-   memset(kaddr, 0, from);
-   flush_dcache_page(page);
-   kunmap_atomic(kaddr, KM_USER0);
-   }
-}
-
 int ext4_wb_prepare_write(struct file *file, struct page *page,
  unsigned from, unsigned to)
 {
@@ -863,7 +848,7 @@ int ext4_wb_prepare_write(struct file *f
/* this block isn't allocated yet, reserve space */
wb_debug("reserve space for new block\n");
page->private = 1;
-   ext4_wb_clear_page(page, from, to);
+   simple_prepare_write(file, page, from, to);
ClearPageMappedToDisk(page);
} else { 
/* block is already mapped, so no need to reserve */
diff -urpN -X dontdiff 
linux-2.6.21-rc6-mm1/fs/reiser4/plugin/item/extent_file_ops.c 
linux-2.6.21-rc6-mm1-test/fs/reiser4/plugin/item/extent_file_ops.c
--- linux-2.6.21-rc6-mm1/fs/reiser4/plugin/item/extent_file_ops.c   
2007-04-09 18:32:52.0 -0700
+++ linux-2.6.21-rc6-mm1-test/fs/reiser4/plugin/item/extent_file_ops.c  
2007-04-09 18:31:34.0 -0700
@@ -1040,16 +1040,9 @@ ssize_t reiser4_write_extent(struct file
BUG_ON(get_current_context()->trans->atom != NULL);
 
lock_page(page);
-   if (!PageUptodate(page) && to_page != PAGE_CACHE_SIZE) {
-   void *kaddr;
-
-   kaddr = kmap_atomic(page, KM_USER0);
-   memset(kaddr, 0, page_off);
-   memset(kaddr + page_off + to_page, 0,
-  PAGE_CACHE_SIZE - (page_off + to_page));
-   flush_dcache_page(page);
-   kunmap_atomic(kaddr, KM_USER0);
-   }
+   if (!PageUptodate(page) && to_page != PAGE_CACHE_SIZE)
+   simple_prepare_write(file, page, page_off,
+page_off + to_page);
 
written = filemap_copy_from_user(page, page_off, buf, to_page);
flush_dcache_page(page);
-
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: [GIT PULL -mm] Unionfs branch management code

[Josef Sipek]

On Mon, Apr 09, 2007 at 10:49:48AM -0700, Andrew Morton wrote:
> On Mon,  9 Apr 2007 10:53:51 -0400 "Josef 'Jeff' Sipek" <[EMAIL PROTECTED]> 
> wrote:
> 
> > The following patches introduce new branch-management code into Unionfs as
> > well as fix a number of stability issues and resource leaks.

First, a quick note...Unionfs used to have branch management code, but the
code was so crufty that we decided to spare the eyes (and brains) of kernel
developers at large by ripping it out. This series of patches just
reintroduces the functionality in a sane way. With that said...

> I have a mental note that unionfs is in the "stuck" state, due to general
> agreement that we should implement this functionality at the VFS level, one
> reason for which is unionfs's upper-vs-lower coherency problems.

Right. The upper-vs-lower coherency problem is indeed a problem, but it is
not a _Unionfs_ problem, but rather a _stackable filesystems_ problem
(eCrypfs suffers from the same issue people are just less likely to trip
over it as no one in their right mind modifies encrypted data by hand). If
we hope to have Linux do stacking (which, I think makes sense), we need to
make few changes to the kernel to allow stackable filesystems to work
better, and safer. We're working on an OLS paper which discusses some of
these ideas (some of which we got at LSF back in February) - for example, do
we want to have strong or weak cache coherency? (When the lower pages
change, do we want to have the VM enforce coherency, or can we use more of
an NFS-like coherency model - checking {a,c,m}time.)

Josef "Jeff" Sipek.

-- 
Intellectuals solve problems; geniuses prevent them
- Albert Einstein
-
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 0/8] unprivileged mount syscall

[Serge E. Hallyn]

Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> This patchset adds support for keeping mount ownership information in
> the kernel, and allow unprivileged mount(2) and umount(2) in certain
> cases.

Well, I'd like to feel all smart and point out some bugs, but the code
all reads very nicely, seems to work as advertised, and while I won't
have ltp results until tomorrow, boot test results in so far are all
successful.

Looks good.

-serge

> This can be useful for the following reasons:
> 
> - mount(8) can store ownership ("user=XY" option) in the kernel
>   instead, or in addition to storing it in /etc/mtab.  For example if
>   private namespaces are used with mount propagations /etc/mtab
>   becomes unworkable, but using /proc/mounts works fine
> 
> - fuse won't need a special suid-root mount/umount utility.  Plain
>   umount(8) can easily be made to work with unprivileged fuse mounts
> 
> - users can use bind mounts without having to pre-configure them in
>   /etc/fstab
> 
> All this is done in a secure way, and unprivileged bind and fuse
> mounts are disabled by default and can be enabled through sysctl or
> /proc/sys.
> 
> One thing that is missing from this series is the ability to restrict
> user mounts to private namespaces.  The reason is that private
> namespaces have still not gained the momentum and support needed for
> painless user experience.  So such a feature would not yet get enough
> attention and testing.  However adding such an optional restriction
> can be done with minimal changes in the future, once private
> namespaces have matured.
> 
> An earlier version of these patches have been discussed here:
> 
>   http://lkml.org/lkml/2005/5/3/64
> 
> --
> -
> 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
-
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 0/8] unprivileged mount syscall

[Serge E. Hallyn]

Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > One thing that is missing from this series is the ability to restrict
> > > user mounts to private namespaces.  The reason is that private
> > > namespaces have still not gained the momentum and support needed for
> > > painless user experience.  So such a feature would not yet get enough
> > > attention and testing.  However adding such an optional restriction
> > > can be done with minimal changes in the future, once private
> > > namespaces have matured.
> > 
> > What is the main reason for that feature?  Would it be to prevent things
> > like login from being tricked by user mounts?  Isn't it sufficient, in
> > fact, better, to require that the target of the mount be owned by the
> > user doing the mount?
> 
> It's been discussed later in that thread.  Basically you can fool a

I see now, sorry.

> lot of system programs (like backup) with mounting/binding in the
> global namespace.  Restricting the destination doesn't always help.
> 
> Miklos

It would be nice in general if we could avoid any sort of checks for
(mnt->mnt_ns == init_nsproxy.mnt_ns).  Maybe that won't be possible,
but, taking the two listed examples:

1. mount --bind / ~/bindns;  (later) userdel hallyn

I assume userdel does a simple stupid rm -rf without first umounting,
then?  So (1) it seems wise to have userdel umount anything under ~user
first anyway, and (2) if $USER does a mount --bind from a source he
doesn't own, should we make the resulting mount read-only?  (realizing
the read-only bind mount patches are still under development :)  Or is
that overly restrictive somehow for fuse?

2. backups

Is this just a 'he's going to fill up the whole disk' issue?  Frankly,
it seems wise to have cron or whatever is spawning the backup start in
it's own namespace right at boot.  Generally when I think back on sites
where I've dealt with backup, backups were done on a separate server
which didn't allow userlogins anyway, so it wouldn't be a problem.  But
I'm sure that's a limited (==erroneous) POV.

I do realize that the whole problem about corner cases isn't addressing
two little ones, but the fact that there are more we haven't thought of.
So are there any currently known use cases where requiring a CLONE_NEWNS
before user mounts is unacceptable?

thanks,
-serge
-
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 0/8] unprivileged mount syscall

[Miklos Szeredi]

> > One thing that is missing from this series is the ability to restrict
> > user mounts to private namespaces.  The reason is that private
> > namespaces have still not gained the momentum and support needed for
> > painless user experience.  So such a feature would not yet get enough
> > attention and testing.  However adding such an optional restriction
> > can be done with minimal changes in the future, once private
> > namespaces have matured.
> 
> What is the main reason for that feature?  Would it be to prevent things
> like login from being tricked by user mounts?  Isn't it sufficient, in
> fact, better, to require that the target of the mount be owned by the
> user doing the mount?

It's been discussed later in that thread.  Basically you can fool a
lot of system programs (like backup) with mounting/binding in the
global namespace.  Restricting the destination doesn't always help.

Miklos
-
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 0/8] unprivileged mount syscall

[Miklos Szeredi]

> > The one in pam-0.99.6.3-29.1 in opensuse-10.2 is totally broken.  Are
> > you interested in the details?  I can reproduce it, but forgot to note
> > down the details of the brokenness.
> 
> I don't know how far removed that is from the one being used by redhat,
> but assuming it's the same, then redhat-lspp@redhat.com will be
> very interested.

OK.

> >  - user namespace setup: what if user has multiple sessions?
> > 
> >1) namespaces are shared?  That's tricky because the session needs to
> >be a child of a namespace server, not of login.  I'm not sure PAM
> >can handle this
> > 
> >2) or mounts are copied on login?  That's not possible currently,
> >as there's no way to send a mount between namespaces.  Also it's
> >tricky to make sure that new mounts are also shared
> 
> See toward the end of the 'shared subtrees' OLS paper from last year for
> a suggestion on how to let users effectively 'log in to' an existing
> private mounts ns.

This?

  1. create a new namespace
  2. bind /share/$USER to /share
  3. for each pair ($who, $what) such that
 /share/$USER/$who/$what exists, look
 in /share/$who/allowed for "peer $what
 $USER" or "slave $what $USER". If the
 former is found, rbind /share/$who/$what
 on /share/$USER/$who/$what; if the
 latter is found, do the same and
 follow with marking subtree under
 /share/$USER/$who/$what as slave.
  4. rbind /share/$USER to /share
  5. mark subtree under /share as private.
  6. umount -l /share

Well, someone please explain using short words, because I don't
understand at all.

Thanks,
Miklos
-
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: [GIT PULL -mm] Unionfs branch management code

[Jan Engelhardt]

On Apr 9 2007 10:53, Josef 'Jeff' Sipek wrote:
>
>The following patches introduce new branch-management code into Unionfs as
>well as fix a number of stability issues and resource leaks.  For detailed
>announcement, see end of this email.

I have to seriously ask: why don't we consider aufs? Without
readvertising its simple codebase, unionfs was (version 1.5pre) not
able to be used as a root filesystem when one of its branches is nfs.
(I figure I should build a testcase for that know that I had
a way to reproduce it for some time.)


Jan
-- 
-
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: REISER4 FOR INCLUSION IN THE LINUX KERNEL.

[Bill Davidsen]

[EMAIL PROTECTED] wrote:

I actually beleive that Hans made a reasonable case that 
Reiser4 had gone about as far as it could reasonably go with regard 
to testing, robustness, ... without the broader base of use that 
even an experimental filesystem in distribution tree would get.


Of course, this is an entirely reasonable request of Reiser's.
One meet with an array of unreasonable actions, but mainly STALLING 
which has led to REISER4 never becoming part of the main kernel.


It has also lead to many false claims about REISER4. Claims that are
never backed up with solid statistics, but used to keep REISER4 out of
the kernel and tar its reputation.


Keep that last sentence in mind for four lines...


I for one would at least play with it if it were in the distribution
tree.


I AM SURE THERE ARE A HUGE NUMBER OF PEOPLE WHO WOULD GIVE IT A TRY.
 

"Claims that are never backed up with solid statistics, ..."

As far as I could tell Hans pretty much everything else that 
was demanded. Hans eventually caved and provided - albeit with much 
pissing and moaning, and holy than thou rhetoric.


It was not his pissing and moaning, etc,... these were just excuses to
keep REISER4 from succeeding. The truth is, that any excuse would do.

The real reasons are financial and backed by big money (sometimes, big
egos).

Yes all of the people who make millions on the other filesystems! 
Wait... identify who makes a penny more or less with or without Reiser4.


[ snip ]

Until Namesys is stable there's no support team. It's not my impression 
that there's much support otherwise.


--
Bill Davidsen <[EMAIL PROTECTED]>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
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 0/8] unprivileged mount syscall

[Serge E. Hallyn]

Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> This patchset adds support for keeping mount ownership information in
> the kernel, and allow unprivileged mount(2) and umount(2) in certain
> cases.
> 
> This can be useful for the following reasons:
> 
> - mount(8) can store ownership ("user=XY" option) in the kernel
>   instead, or in addition to storing it in /etc/mtab.  For example if
>   private namespaces are used with mount propagations /etc/mtab
>   becomes unworkable, but using /proc/mounts works fine
> 
> - fuse won't need a special suid-root mount/umount utility.  Plain
>   umount(8) can easily be made to work with unprivileged fuse mounts
> 
> - users can use bind mounts without having to pre-configure them in
>   /etc/fstab
> 
> All this is done in a secure way, and unprivileged bind and fuse
> mounts are disabled by default and can be enabled through sysctl or
> /proc/sys.
> 
> One thing that is missing from this series is the ability to restrict
> user mounts to private namespaces.  The reason is that private
> namespaces have still not gained the momentum and support needed for
> painless user experience.  So such a feature would not yet get enough
> attention and testing.  However adding such an optional restriction
> can be done with minimal changes in the future, once private
> namespaces have matured.

What is the main reason for that feature?  Would it be to prevent things
like login from being tricked by user mounts?  Isn't it sufficient, in
fact, better, to require that the target of the mount be owned by the
user doing the mount?

-serge   (who's pretty sure he's missing something)

> An earlier version of these patches have been discussed here:
> 
>   http://lkml.org/lkml/2005/5/3/64
> 
> --
> -
> 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
-
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 12/17] lockd: handle fl_notify callbacks

[Christoph Hellwig]

On Thu, Apr 05, 2007 at 07:41:02PM -0400, J. Bruce Fields wrote:
> + if (block->b_fl)
> + kfree(block->b_fl);

kfree(NULL) is fine.

> +static void
> +nlmsvc_update_deferred_block(struct nlm_block *block, struct file_lock *conf,
> +  int result)
> +{
> + block->b_flags |= B_GOT_CALLBACK;
> + if (result == 0)
> + block->b_granted = 1;
> + else
> + block->b_flags |= B_TOO_LATE;
> + if (conf) {
> + block->b_fl = kzalloc(sizeof(struct file_lock), GFP_KERNEL);
> + if (block->b_fl)
> + locks_copy_lock(block->b_fl, conf);
> + }
> +}

Shouldn't there be a way to propagate errors back to the caller when
the kzalloc fails?

-
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 8/17] locks: add fl_notify arguments for asynchronous lock return

[Christoph Hellwig]

On Thu, Apr 05, 2007 at 07:40:58PM -0400, J. Bruce Fields wrote:
> From: Marc Eshel <[EMAIL PROTECTED]> - unquoted
> 
> Acquiring a lock on a cluster filesystem may require communication with remote
> hosts, and to avoid blocking lockd or nfsd threads during such communication,
> we allow the results to be returned asynchronously.
> 
> When a ->lock() call needs to block, the file system will return -EINPROGRESS,
> and then later return the results with a call to the routine in the fl_notify
> field of the lock_manager_operations struct.
> 
> Note that this is different from the ->lock() call discovering that there is a
> conflict which would cause the caller to block; this is still handled in the
> same way as before.  In fact, we don't currently handle "blocking" locks at
> all; those are less urgent, because the filesystem can always just return an
> immediate -EAGAIN without denying the lock.
> 
> So this asynchronous interface is only used in the case of a non-blocking 
> lock,
> where we must know whether to allow or deny the lock now.
> 
> We're using fl_notify to asynchronously return the result of a lock
> request.  So we want fl_notify to be able to return a status and, if
> appropriate, a conflicting lock.
> 
> This only current caller of fl_notify is in the blocked case, in which case
> we don't use these extra arguments.
> 
> We also allow fl_notify to return an error.  (Also ignored for now.)

I don't really like the overload of fl_notify.  What the reason not
to use a separate callback?

-
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 9/17] locks: add lock cancel command

[Christoph Hellwig]

On Thu, Apr 05, 2007 at 07:40:59PM -0400, J. Bruce Fields wrote:
> From: Marc Eshel <[EMAIL PROTECTED]> - unquoted
> 
> Lock managers need to be able to cancel pending lock requests.  In the case
> where the exported filesystem manages its own locks, it's not sufficient just
> to call posix_unblock_lock(); we need to let the filesystem know what's
> happening too.
> 
> We do this by adding a new fcntl lock command: FL_CANCELLK.  Some day this
> might also be made available to userspace applications that could benefit from
> an asynchronous locking api.

Should we really add more and more subcases to ->lock that probably don't
share implementation code?  I'd much prefer adding different operations.

-
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

mount options atime/diratime on cifs

[Shirish Pargaonkar]

mount command does not support passing on mount options such as atime and
diratime to the mounting filesystems.  So it is OK if one wants to mount
a filesytem with options such as noatime and nodiratime but mount options
such as atime and diratime get filtered out.

Today cifs client does not support behaviour for the mount options atime and
diratime.  A command such as touch on a file on a mounted filesystem will
update the access time of that file on client as well as server.
But if a file is loaded and cached on the client, access times will get
updated only on the client inode but not on the server inode.
So we can say that default behaviour of cifs client is such that it is
mounted with options noatime and nodiratime.
Because of the mount command behaviour, if one wants to mount a
filesysetem using cifs client with options atime and diratime, it is not
possible.

So, it appears that for cifs, an equivalent mount option of atime and
diratime would be needed.


Thoughts, suggestions on the name of the option and behaviour under
this option?

Regards,

Shirish S. Pargaonkar
-
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: Reiser4. BEST FILESYSTEM EVER.

[Nate Diller]

On 08 Apr 2007 06:32:26 +0200, Christer Weinigel <[EMAIL PROTECTED]> wrote:

[EMAIL PROTECTED] writes:

> Lennart. Tell me again that these results from
>
> http://linuxhelp.150m.com/resources/fs-benchmarks.htm and
> http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm
>
> are not of interest to you. I still don't understand why you have your
> head in the sand.

Oh, for fucks sake, stop sounding like a broken record.  You have
repeated the same totally meaningless statistics more times than I
care to count.  Please shut the fuck up.


wow, it's really amazing how reiser4 can still inspire flamewars so
easily when Hans isn't even around to antagonize people and escalate
things


As you discovered yourself (even though you seem to fail to understand
the significance of your discovery), bonnie writes files that consist
of mostly zeroes.  If your normal use cases consist of creating a
bunch of files containing zeroes, reiser4 with compression will do
great.  Just lovely.  Except that nobody sane would store a lot of
files containing zeroes, except an an excercize in mental
masturbation.  So the two bonnie benchmarks with lzo and gzip are
totally meaningless for any real life usages.


yeah, i sure wish Grev was still around running the benchmarks and
regression testing, cause I thought she came up with a good, QA
oriented mix of real benchmarks.  aside from a number of streaming
video benchmarks i did, those were the only results i actually trusted
to compare reiser4 with other systems.  I know Ted doesn't like the
Mongo suite, cause it focuses on small files and shows the common
weakness of block-aligned storage ... personally i thought it was
great for its primary purpose, making sure reiser4 was optimized for
its target workload.  i also recall that the distribution of small
files to large ones in mongo was pulled from some paper out of CMU,
but i can't find the reference to that study right now.


As for the amount of disk needed to store three kernel trees, the
figures you quote show that Reiser4 does tail combining where the tail
of multiple files are stored in one disk block.  A nice trick that
seems save you about 15% disk space compared to ext3.  Now you have to
realise what that means, it means that if the disk block containing
those tails (or any metadata pointing at that block) gets corrupted,
instead of just losing one disk block for one file, you will have lost
the tail for all the files sharing that disk block.  Depending on your
personal prioritites, saving 15% of the space may be worth the risk to
you, or maybe not.  Personally, for the only disk I'm short on space
on, I mostly store flac encoded images of my CD collection, and saving
2kByte out of every 300MByte disk simply doesn't make any difference,
and I much prefer a stable file system that I can trust not to lose my
data.  You might make different choices.


well, it turns out that reiser4 does things a little differently,
since tail packing has bad performance effects (i always turn it off
on my reiserfs partitions).  Reiser4 guarantees a file will be stored
contiguously if it is below a certain size (20K?), and instead stores
the whole file unaligned, so that many files can be packed together
without slack space.  this gives the best of both worlds
performance-wise, at the expense of some complicated flush code to
pack everything together in the tree before it gets written.  that
combined with the fine-grained locking scheme (per-node -- reiserfs
just has a global lock) is the primary reason the code is so
convoluted ... not poor coding.


The same goes for just about every feature that you tout, it has its
advantages, and it has its disadvantages.  Doing compression on data
is great if the data you store is compressible, and sucks if it isn't.
Doing compression on each disk block and then packing multiple
compressed blocks into each physical disk block will probably save
some space if the data is compressible, but at the same time it means
that you will spend a lot of CPU (and cache footprint) compressing and
uncompressing that data.  On a single user system where the CPU is
mostly idle it might not make much of a difference, on a heavily
loaded multiuser system it might do.


my understanding of the code is that it uses a heuristic to decide if
a file is already compressed, so that the system doesn't waste time on
them and simply writes them out directly.  there may also be a way to
turn it off for certain classes of files, this would be most useful
for executables and the like that are frequently mmap()ed and we care
more about page-alignment than read bandwidth or data density.
edward?


Logs can be compressed quite well using a block based compression
scheme, but the logs can be compressed even better by doing
compression on the whole file with gzip.  So what's the best choice,
to do transparent compression on the fly giving ok compression or
teaching the userspace tools to do compression of old logs and get
really good

Re: [patch 0/8] unprivileged mount syscall

[H. Peter Anvin]

Ram Pai wrote:


It is in FC6. I dont know the status off upstream util-linux. I did
submit the patch many times to Adrian Bunk (the then util-linux
maintainer) and got no response. I have not pushed the patches to the
new maintainer(Karel Zak?) though.



Well, do that, then :)

Seriously.  The whole point of util-linux-ng is to make forward progress.

-hpa
-
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: [GIT PULL -mm] Unionfs branch management code

[Andrew Morton]

On Mon,  9 Apr 2007 10:53:51 -0400 "Josef 'Jeff' Sipek" <[EMAIL PROTECTED]> 
wrote:

> The following patches introduce new branch-management code into Unionfs as
> well as fix a number of stability issues and resource leaks.

I have a mental note that unionfs is in the "stuck" state, due to general
agreement that we should implement this functionality at the VFS level, one
reason for which is unionfs's upper-vs-lower coherency problems.

Am I wrong?
-
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 0/8] unprivileged mount syscall

[Ram Pai]

On Mon, 2007-04-09 at 12:07 -0500, Serge E. Hallyn wrote:
> Quoting Miklos Szeredi ([EMAIL PROTECTED]):

> >  - need to set up mount propagation from global namespace to private
> >ones, mount(8) does not yet have options to configure propagation
> 
> Hmm, I guess I get lost using my own little systems, and just assumed
> that shared subtree functionality was making its way up into mount(8).
> Ram, have you been working on that?

It is in FC6. I dont know the status off upstream util-linux. I did
submit the patch many times to Adrian Bunk (the then util-linux
maintainer) and got no response. I have not pushed the patches to the
new maintainer(Karel Zak?) though.

RP

-
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: Troll Of The Year

[Valdis . Kletnieks]

On Mon, 09 Apr 2007 18:41:08 +0200, Jan Engelhardt said:
> On Apr 9 2007 12:55, Ronni Nielsen wrote:
> > 
> > And the award as Troll Of The Year goes to: johnrobertbanks.
> > 
> 
> The year is not even over and you already picked your favorite -
> who bribed you? :-)

The vast right-wing anti-Reiser4 conspiracy, of course. :)


pgpxTpNcirpHD.pgp
Description: PGP signature

Re: [patch 0/8] unprivileged mount syscall

[Serge E. Hallyn]

Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > > > One thing that is missing from this series is the ability to restrict
> > > > > user mounts to private namespaces.  The reason is that private
> > > > > namespaces have still not gained the momentum and support needed for
> > > > > painless user experience.  So such a feature would not yet get enough
> > > > > attention and testing.  However adding such an optional restriction
> > > > > can be done with minimal changes in the future, once private
> > > > > namespaces have matured.
> > > > 
> > > > I suspect the people who developed and maintain nsproxy would disagree 
> > > > ;)
> > > 
> > > Well, they better show me some working and simple-to-use userspace
> > > code, because I've not seen anything like that related to mount
> > > namespaces.
> > 
> > If you mean to test/exploit them, see
> > http://lxc.sourceforge.net/patches/2.6.20/2.6.20-lxc8/broken-out/tests/
> > 
> > Compile the ns_exec.c program and do
> > 
> > ns_exec -m /bin/sh
> > 
> > to get a shell in a new mounts namespace.
> 
> Cool, thanks.  This is a very nice utility for testing, but for the
> end user rather useless:

Well that depends on which end-user.  Those wanting to create a vserver
or checkpoint-restart job will want this, but clearly we have a long way
to go for that upstream anyway.

>   - user starts up a private namespace in a shell, mounts something
> 
>   - then opens app from menu, tries to access mount, but the mount is
> not there
> 
>   - user unhappy
> 
> BTW, looking at -mm unshare() on namespace is not privileged any more.
> Why is that?  Or rather, what's the reason, that clone() is privileged
> and unshare() is not?

The check is still there - see kernel/nsproxy.c:unshare_nsproxy_namespaces().

> > > pam_namespace.so is one example of a non-working, but probably-not-too-
> > > hard-to-fix one.
> > 
> > Non-working?  I sure hope the one used for LSPP certification is
> > working...  As is the ugly version I wrote 18 mounts ago and use on my
> > laptop.
> 
> The one in pam-0.99.6.3-29.1 in opensuse-10.2 is totally broken.  Are
> you interested in the details?  I can reproduce it, but forgot to note
> down the details of the brokenness.

I don't know how far removed that is from the one being used by redhat,
but assuming it's the same, then redhat-lspp@redhat.com will be
very interested.

> > > I'm just saying this is not yet something that Joe Blow would just
> > > enable by ticking a box in their desktop setup wizard, and it would
> > > all work flawlessly thereafter.  There's still a _long_ way towards
> > > that, and mostly in userspace.
> > 
> > I'm not sure there's a that long a way to go, but clearly we need to be
> > showing users what they can do, or they'll never work their way towards
> > there.
> 
> There _is_ a long way to go.  Random things that spring to my mind:
> 
>  - using /etc/mtab is broken with private namespaces, using
>/proc/mounts is missing various functionality, that /etc/mtab has,
>for example the "user" option, which this patchset adds

Agreed those need fixing.

>  - need to set up mount propagation from global namespace to private
>ones, mount(8) does not yet have options to configure propagation

Hmm, I guess I get lost using my own little systems, and just assumed
that shared subtree functionality was making its way up into mount(8).
Ram, have you been working on that?

>  - user namespace setup: what if user has multiple sessions?
> 
>1) namespaces are shared?  That's tricky because the session needs to
>be a child of a namespace server, not of login.  I'm not sure PAM
>can handle this
> 
>2) or mounts are copied on login?  That's not possible currently,
>as there's no way to send a mount between namespaces.  Also it's
>tricky to make sure that new mounts are also shared

See toward the end of the 'shared subtrees' OLS paper from last year for
a suggestion on how to let users effectively 'log in to' an existing
private mounts ns.

> > For instance, as you say, a user admin gui with a checkmark and text
> > boxes saying 'enter new namespace on login', 'create private /tmp',
> > and 'create private dmcrypted /home' would be trivial right now.
> 
> Trivial modulo the above slightly non-trivial exemptions ;)

Ok, so it can use some very non-trivial fine-tuning...

But I've been using the above - minus the trivial gui - for over a year
without ever worrying about any of these short-comings.

> Miklos

-serge
-
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: Troll Of The Year

[Jan Engelhardt]

On Apr 9 2007 12:55, Ronni Nielsen wrote:
>
> [EMAIL PROTECTED] wrote:
> [snip arguments FUBAR]
>
> 
> And the award as Troll Of The Year goes to: johnrobertbanks.
> 

The year is not even over and you already picked your favorite -
who bribed you? :-)


Jan
-- 
-
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: Interface for the new fallocate() system call

[Jörn Engel]

On Mon, 9 April 2007 23:01:42 +1000, Paul Mackerras wrote:
> Jörn Engel writes:
> 
> > Wouldn't that work be confined to fallocate()?  If I understand Heiko
> > correctly, the alternative would slow s390 down for every syscall,
> > including more performance-critical ones.
> 
> The alternative that Jakub suggested wouldn't slow s390 down.

True.  And it appears to be one of the least offensive options we have.

Jörn

-- 
My second remark is that our intellectual powers are rather geared to
master static relations and that our powers to visualize processes
evolving in time are relatively poorly developed.
-- Edsger W. Dijkstra
-
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 0/8] unprivileged mount syscall

[Miklos Szeredi]

> > > > One thing that is missing from this series is the ability to restrict
> > > > user mounts to private namespaces.  The reason is that private
> > > > namespaces have still not gained the momentum and support needed for
> > > > painless user experience.  So such a feature would not yet get enough
> > > > attention and testing.  However adding such an optional restriction
> > > > can be done with minimal changes in the future, once private
> > > > namespaces have matured.
> > > 
> > > I suspect the people who developed and maintain nsproxy would disagree ;)
> > 
> > Well, they better show me some working and simple-to-use userspace
> > code, because I've not seen anything like that related to mount
> > namespaces.
> 
> If you mean to test/exploit them, see
> http://lxc.sourceforge.net/patches/2.6.20/2.6.20-lxc8/broken-out/tests/
> 
> Compile the ns_exec.c program and do
> 
>   ns_exec -m /bin/sh
> 
> to get a shell in a new mounts namespace.

Cool, thanks.  This is a very nice utility for testing, but for the
end user rather useless:

  - user starts up a private namespace in a shell, mounts something

  - then opens app from menu, tries to access mount, but the mount is
not there

  - user unhappy

BTW, looking at -mm unshare() on namespace is not privileged any more.
Why is that?  Or rather, what's the reason, that clone() is privileged
and unshare() is not?

> > pam_namespace.so is one example of a non-working, but probably-not-too-
> > hard-to-fix one.
> 
> Non-working?  I sure hope the one used for LSPP certification is
> working...  As is the ugly version I wrote 18 mounts ago and use on my
> laptop.

The one in pam-0.99.6.3-29.1 in opensuse-10.2 is totally broken.  Are
you interested in the details?  I can reproduce it, but forgot to note
down the details of the brokenness.

> > I'm just saying this is not yet something that Joe Blow would just
> > enable by ticking a box in their desktop setup wizard, and it would
> > all work flawlessly thereafter.  There's still a _long_ way towards
> > that, and mostly in userspace.
> 
> I'm not sure there's a that long a way to go, but clearly we need to be
> showing users what they can do, or they'll never work their way towards
> there.

There _is_ a long way to go.  Random things that spring to my mind:

 - using /etc/mtab is broken with private namespaces, using
   /proc/mounts is missing various functionality, that /etc/mtab has,
   for example the "user" option, which this patchset adds

 - need to set up mount propagation from global namespace to private
   ones, mount(8) does not yet have options to configure propagation

 - user namespace setup: what if user has multiple sessions?

   1) namespaces are shared?  That's tricky because the session needs to
   be a child of a namespace server, not of login.  I'm not sure PAM
   can handle this

   2) or mounts are copied on login?  That's not possible currently,
   as there's no way to send a mount between namespaces.  Also it's
   tricky to make sure that new mounts are also shared

> For instance, as you say, a user admin gui with a checkmark and text
> boxes saying 'enter new namespace on login', 'create private /tmp',
> and 'create private dmcrypted /home' would be trivial right now.

Trivial modulo the above slightly non-trivial exemptions ;)

Miklos
-
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: Reiser4. BEST FILESYSTEM EVER - Christer Weinigel

[Richard Knutsson]

[EMAIL PROTECTED] wrote:

On Mon, 09 Apr 2007 00:58:53 +0200, "Richard Knutsson"
<[EMAIL PROTECTED]> said:
  
Wow, I'm impressed. Think you got the record on how many mails you 
referenced to in a reply... 



TWO actually. I guess you are easily impressed.
  

Oh, took it to be from 5-6 sources...
+ you have repeated the same statement several times, that is 
not the best way of convincing people.



I know you DON'T believe that, as you are about the tenth person to
repeat that "repeating stuff has no effect."
  
Why should we change our response to the same error? The only solution 
to this loop is when people stops answering you and you "lose".
I believe you picked up the "anti-Reiser religion"-phrase from previous 
rant-wars (otherwise, why does that "religion"-phrase always come up, 
and (almost) only when dealing with Reiser-fs), and yes, there has been 
some clashes caused by both sides, so please be careful when dealing 
with this matter.



NO. You people simply come across as zealots who work together, against
Reiser4.

Hence the term "anti-Reiser religion."
  

Please, don't address someone you meet for the first time as "you people"!
Yes, we do _work_ together, it is a community and as a community you 
have to follow the social rules agreed upon. Without all those 
pro-Reiser peoples who knew how to work with the rest, there would not 
be a ResierFS/Reiser3 in the kernel. Unfortunately, Hans is in this case 
his own worst enemy and has ruffed quite a few feathers over the time. I 
don't think you would like someone who tells you "if you do it my way, 
then you are doing it wrong"...


But personally, even if I find Hans a bit too strong-headed, he got some 
interesting design-ideas and the Reiser-filesystem is something I think 
many find interesting as a concept but not yet trust-worthy for their 
own machines.
Would you be willing to benchmark Reiser4 with some compressed 
binary-blob and show the time as well as the CPU-usage? 



I might be. I don't really know how to set it all up.

Perhaps if you guided me through it.
  
Am not sure how much help I would be but from the responses to your 
benchmark-list, there seems to be many who could help you. But first I 
think you should set up a system to test on, and then after some tests 
and made the result public, there will (most likely) be people who ask 
you to test it in some specific way.
I may have missed something, but if my room-mate took my harddrive, 
screwed it open, wrote a love-letter on the disk with a pencil and then 
returned it (ok, there may be some more plausible reasons for 
corruption), is the OS really suppose to handle it? 



Yeah, I can't see how the OS could read the love-letter either.

But one thing is for sure. The FS ain't responsible for reading it.
  
And no-one has asked the file-system to _read_ the disk, but to be 
designed to help restore the file-structure. This I have found to be the 
main-point people complains about.
It is like arguing against air-bags in a car. Of course the car should 
not be responsible for preventing accidents, but they are designed so 
_if_ it happens, you should not be totally screwed.
Yes, it should not 
assign any new data to those blocks but should it not also fall into the 
file-systems domain to be able to restore some/all data?



It's a tough ask of any FS. 


Microsoft's filesystem checker totally roasted all my data on an XP-box
last night. 
  

Sorry to hear that, but two wrongs does not make it right.

Richard Knutsson

-
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: Troll Of The Year (Was: REISER4 FOR INCLUSION IN THE LINUX KERNEL.)

[Phillip Susi]

I second that award.  Three threads in as many days, all idiotic 
trolling.  Can this idiot be banned from the list?  Sheesh!


Ronni Nielsen wrote:

[EMAIL PROTECTED] wrote:
[snip arguments FUBAR]


And the award as Troll Of The Year goes to: johnrobertbanks.


/ronni

+--+
|  PLEASE  |
|  DO NOT  |
| FEED THE |
|  TROLLS  |
+--+
   |  |   |  | .\|.||/..


-
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: Interface for the new fallocate() system call

[Paul Mackerras]

Jörn Engel writes:

> Wouldn't that work be confined to fallocate()?  If I understand Heiko
> correctly, the alternative would slow s390 down for every syscall,
> including more performance-critical ones.

The alternative that Jakub suggested wouldn't slow s390 down.

Paul.
-
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

[PATCH 14/21] Unionfs: Document unionfs_d_release locking

[Josef 'Jeff' Sipek]

Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
 fs/unionfs/dentry.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/fs/unionfs/dentry.c b/fs/unionfs/dentry.c
index c841f08..4756b78 100644
--- a/fs/unionfs/dentry.c
+++ b/fs/unionfs/dentry.c
@@ -286,6 +286,10 @@ static int unionfs_d_revalidate(struct dentry *dentry, 
struct nameidata *nd)
return err;
 }
 
+/*
+ * At this point no one can reference this dentry, so we don't have to be
+ * careful about concurrent access.
+ */
 static void unionfs_d_release(struct dentry *dentry)
 {
int bindex, bstart, bend;
-- 
1.5.0.3.268.g3dda

-
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

[PATCH 13/21] Unionfs: Remove the older incgen ioctl

[Josef 'Jeff' Sipek]

The new remount code now has the "incgen" functionality.

Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
 fs/unionfs/branchman.c  |   21 -
 fs/unionfs/commonfops.c |6 ++
 2 files changed, 2 insertions(+), 25 deletions(-)

diff --git a/fs/unionfs/branchman.c b/fs/unionfs/branchman.c
index 83d443a..6912be9 100644
--- a/fs/unionfs/branchman.c
+++ b/fs/unionfs/branchman.c
@@ -18,27 +18,6 @@
 
 #include "union.h"
 
-/* increase the superblock generation count; effectively invalidating every
- * upper inode, dentry and file object */
-int unionfs_ioctl_incgen(struct file *file, unsigned int cmd, unsigned long 
arg)
-{
-   struct super_block *sb;
-   int gen;
-
-   sb = file->f_dentry->d_sb;
-
-   unionfs_write_lock(sb);
-
-   gen = atomic_inc_return(&UNIONFS_SB(sb)->generation);
-
-   atomic_set(&UNIONFS_D(sb->s_root)->generation, gen);
-   atomic_set(&UNIONFS_I(sb->s_root->d_inode)->generation, gen);
-
-   unionfs_write_unlock(sb);
-
-   return gen;
-}
-
 /* return to userspace the branch indices containing the file in question
  *
  * We use fd_set and therefore we are limited to the number of the branches
diff --git a/fs/unionfs/commonfops.c b/fs/unionfs/commonfops.c
index 6606cba..8453f2d 100644
--- a/fs/unionfs/commonfops.c
+++ b/fs/unionfs/commonfops.c
@@ -623,10 +623,8 @@ long unionfs_ioctl(struct file *file, unsigned int cmd, 
unsigned long arg)
switch (cmd) {
case UNIONFS_IOCTL_INCGEN:
/* Increment the superblock generation count */
-   err = -EACCES;
-   if (!capable(CAP_SYS_ADMIN))
-   goto out;
-   err = unionfs_ioctl_incgen(file, cmd, arg);
+   printk("unionfs: incgen ioctl deprecated; use \"-o 
remount,incgen\"\n");
+   err = -ENOSYS;
break;
 
case UNIONFS_IOCTL_QUERYFILE:
-- 
1.5.0.3.268.g3dda

-
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

[PATCH 01/21] fs: Introduce path{get,put}

[Josef 'Jeff' Sipek]

From: Erez Zadok 

Export drop_pagecache_sb symbol (for branch-management).

Signed-off-by: Erez Zadok 
Signed-off-by: Josef 'Jeff' Sipek 
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
 include/linux/namei.h |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/include/linux/namei.h b/include/linux/namei.h
index 941be96..92b422b 100644
--- a/include/linux/namei.h
+++ b/include/linux/namei.h
@@ -3,6 +3,7 @@
 
 #include 
 #include 
+#include 
 
 struct vfsmount;
 
@@ -107,4 +108,16 @@ static inline char *nd_get_link(struct nameidata *nd)
return nd->saved_names[nd->depth];
 }
 
+static inline void pathget(struct path *path)
+{
+   mntget(path->mnt);
+   dget(path->dentry);
+}
+
+static inline void pathput(struct path *path)
+{
+   dput(path->dentry);
+   mntput(path->mnt);
+}
+
 #endif /* _LINUX_NAMEI_H */
-- 
1.5.0.3.268.g3dda

-
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

[PATCH 08/21] Unionfs: Introduce branch-id code

[Josef 'Jeff' Sipek]

From: Erez Zadok <[EMAIL PROTECTED]>

Each branch gets a unique ID, which helps during branch additions,
deletions, and changes, to locate where branches were moved to, and perform
proper reference-counting.  This is useful even if the same directory was
added more than once to union.

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
 fs/unionfs/commonfops.c |   62 +-
 fs/unionfs/fanout.h |   22 -
 fs/unionfs/main.c   |1 +
 fs/unionfs/union.h  |4 ++-
 4 files changed, 85 insertions(+), 4 deletions(-)

diff --git a/fs/unionfs/commonfops.c b/fs/unionfs/commonfops.c
index aa7c75d..8d0f8d1 100644
--- a/fs/unionfs/commonfops.c
+++ b/fs/unionfs/commonfops.c
@@ -86,6 +86,31 @@ out:
return err;
 }
 
+/*
+ * Find new index of matching branch with an open file, since branches could
+ * have been added/deleted causing the one with open files to shift.
+ *
+ * @file: current file whose branches may have changed
+ * @bindex: index of branch within current file (could be old branch)
+ * @new_sb: the new superblock which may have new branch IDs
+ * Returns index of newly found branch (0 or greater), -1 otherwise.
+ */
+static int find_new_branch_index(struct file *file, int bindex,
+struct super_block *new_sb)
+{
+   int old_branch_id = UNIONFS_F(file)->saved_branch_ids[bindex];
+   int i;
+
+   for (i = 0; i < sbmax(new_sb); i++)
+   if (old_branch_id == branch_id(new_sb, i))
+   return i;
+   /*
+* XXX: maybe we should BUG_ON if not found new branch index?
+* (really that should never happen).
+*/
+   return -1;
+}
+
 /* put all references held by upper struct file and free lower file pointer
  * array
  */
@@ -93,6 +118,7 @@ static void cleanup_file(struct file *file)
 {
int bindex, bstart, bend;
struct file **lf;
+   struct super_block *sb = file->f_dentry->d_sb;
 
lf = UNIONFS_F(file)->lower_files;
bstart = fbstart(file);
@@ -100,13 +126,29 @@ static void cleanup_file(struct file *file)
 
for (bindex = bstart; bindex <= bend; bindex++) {
if (unionfs_lower_file_idx(file, bindex)) {
-   branchput(file->f_dentry->d_sb, bindex);
+   int i;  /* holds (possibly) updated branch index */
+   i = find_new_branch_index(file, bindex, sb);
+   if (i < 0)
+   printk(KERN_ERR "unionfs: no supberlock for 
file %p\n",
+  file);
+   else {
+   unionfs_read_lock(sb);
+   branchput(sb, i);
+   unionfs_read_unlock(sb);
+   /* XXX: is it correct to use sb->s_root here? */
+   unionfs_mntput(sb->s_root, i);
+   /* XXX: mntget b/c fput below will call mntput 
*/
+   unionfs_mntget(sb->s_root, bindex);
+   }
fput(unionfs_lower_file_idx(file, bindex));
}
}
 
UNIONFS_F(file)->lower_files = NULL;
kfree(lf);
+   kfree(UNIONFS_F(file)->saved_branch_ids);
+   /* set to NULL because caller needs to know if to kfree on error */
+   UNIONFS_F(file)->saved_branch_ids = NULL;
 }
 
 /* open all lower files for a given file */
@@ -270,6 +312,12 @@ int unionfs_file_revalidate(struct file *file, int 
willwrite)
err = -ENOMEM;
goto out;
}
+   size = sizeof(int) * sbmax(sb);
+   UNIONFS_F(file)->saved_branch_ids = kzalloc(size, GFP_KERNEL);
+   if (!UNIONFS_F(file)->saved_branch_ids) {
+   err = -ENOMEM;
+   goto out;
+   }
 
if (S_ISDIR(dentry->d_inode->i_mode)) {
/* We need to open all the files. */
@@ -297,8 +345,10 @@ int unionfs_file_revalidate(struct file *file, int 
willwrite)
}
 
 out:
-   if (err)
+   if (err) {
kfree(UNIONFS_F(file)->lower_files);
+   kfree(UNIONFS_F(file)->saved_branch_ids);
+   }
 out_nofree:
unionfs_unlock_dentry(dentry);
unionfs_read_unlock(dentry->d_sb);
@@ -418,6 +468,12 @@ int unionfs_open(struct inode *inode, struct file *file)
err = -ENOMEM;
goto out;
}
+   size = sizeof(int) * sbmax(inode->i_sb);
+   UNIONFS_F(file)->saved_branch_ids = kzalloc(size, GFP_KERNEL);
+   if (!UNIONFS_F(file)->saved_branch_ids) {
+   err = -ENOMEM;
+   goto out;
+   }
 
dentry = file->f_dentry;
unionfs_lock_dentry(dentry);
@@ -456,6 +512,7 @@ in

[PATCH 03/21] Unionfs: Documentation updates for branch-management

[Josef 'Jeff' Sipek]

From: Erez Zadok <[EMAIL PROTECTED]>

Describe dynamic branch-management introduced by subsequent patches.

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
 Documentation/filesystems/unionfs/concepts.txt |5 ++
 Documentation/filesystems/unionfs/issues.txt   |   22 +++-
 Documentation/filesystems/unionfs/usage.txt|   61 +++-
 3 files changed, 84 insertions(+), 4 deletions(-)

diff --git a/Documentation/filesystems/unionfs/concepts.txt 
b/Documentation/filesystems/unionfs/concepts.txt
index d417576..83d45b9 100644
--- a/Documentation/filesystems/unionfs/concepts.txt
+++ b/Documentation/filesystems/unionfs/concepts.txt
@@ -1,3 +1,6 @@
+Unionfs 2.0 CONCEPTS:
+=
+
 This file describes the concepts needed by a namespace unification file
 system.
 
@@ -68,3 +71,5 @@ though to this copy. The copy must be made on a higher 
priority branch so
 that lookup and readdir return this newer "version" of the file rather than
 the original (see duplicate elimination).
 
+
+For more information, see .
diff --git a/Documentation/filesystems/unionfs/issues.txt 
b/Documentation/filesystems/unionfs/issues.txt
index b070175..a434fee 100644
--- a/Documentation/filesystems/unionfs/issues.txt
+++ b/Documentation/filesystems/unionfs/issues.txt
@@ -1,5 +1,5 @@
-KNOWN Unionfs ISSUES:
-=
+KNOWN Unionfs 2.0 ISSUES:
+=
 
 1. The NFS server returns -EACCES for read-only exports, instead of -EROFS.
This means we can't reliably detect a read-only NFS export.
@@ -14,10 +14,26 @@ KNOWN Unionfs ISSUES:
introducing small VFS/MM changes that would allow a file system to handle
cache coherency correctly.
 
+   Unionfs 2.0 has a temporary workaround for this.  You can force Unionfs
+   to increase the superblock generation number, and hence purge all cached
+   Unionfs objects, which would then  be re-gotten from the lower branches.
+   This should ensure cache consistency.  To increase the generation number,
+   executed the command:
+
+   mount -t unionfs -o remount,incgen none MOUNTPOINT
+
+   Note that the older way of incrementing the generation number using an
+   ioctl, is no longer supported in Unionfs 2.0.  Ioctls in general are not
+   encouraged.  Plus, an ioctl is per-file concept, whereas the generation
+   number is a per-file-system concept.  Worse, such an ioctl requires an
+   open file, which then has to be invalidated by the very nature of the
+   generation number increase (read: the old generation increase ioctl was
+   pretty racy).
+
 3. Unionfs should not use lookup_one_len() on the underlying f/s as it
confuses NFS.  Currently, unionfs_lookup() passes lookup intents to the
lower file-system, this eliminates part of the problem.  The remaining
calls to lookup_one_len may need to be changed to pass an intent.
 
 
-For more information, see .
+For more information, see .
diff --git a/Documentation/filesystems/unionfs/usage.txt 
b/Documentation/filesystems/unionfs/usage.txt
index 14e0856..13fbcea 100644
--- a/Documentation/filesystems/unionfs/usage.txt
+++ b/Documentation/filesystems/unionfs/usage.txt
@@ -28,4 +28,63 @@ Example:
dirs=/writable_branch=rw:/read-only_branch=ro
 
 
-For more information, see unionfs.filesystems.org.
+DYNAMIC BRANCH MANAGEMENT AND REMOUNTS
+==
+
+You can remount a union and change its overall mode, or reconfigure the
+branches, as follows.
+
+To downgrade a union from read-write to read-only:
+
+# mount -t unionfs -o remount,ro none MOUNTPOINT
+
+To upgrade a union from read-only to read-write:
+
+# mount -t unionfs -o remount,rw none MOUNTPOINT
+
+To delete a branch /foo, regardless where it is in the current union:
+
+# mount -t unionfs -o del=/foo none MOUNTPOINT
+
+To insert (add) a branch /foo before /bar:
+
+# mount -t unionfs -o remount,add=/bar:/foo none MOUNTPOINT
+
+To insert (add) a branch /foo (with the "rw" mode flag) before /bar:
+
+# mount -t unionfs -o remount,add=/bar:/foo=rw none MOUNTPOINT
+
+To insert (add) a branch /foo (in "rw" mode) at the very beginning (i.e., a
+new highest-priority branch), you can use the above syntax, or use a short
+hand version as follows:
+
+# mount -t unionfs -o remount,add=/foo none MOUNTPOINT
+
+To append a branch to the very end (new lowest-priority branch):
+
+# mount -t unionfs -o remount,add=:/foo none MOUNTPOINT
+
+To append a branch to the very end (new lowest-priority branch), in
+read-only mode:
+
+# mount -t unionfs -o remount,add=:/foo:ro none MOUNTPOINT
+
+Finally, to change the mode of one existing branch, say /foo, from read-only
+to read-write, and change /bar from read-write to read-only:
+
+# mount -t unionfs -o remount,mode=/foo=rw,mode=/bar=ro none MOUNTPOINT
+
+
+CACHE CONSISTENCY
+=
+
+If you modify any file on any of the lower b

[PATCH 04/21] Unionfs: Proper comment on rwsem field

[Josef 'Jeff' Sipek]

Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
 fs/unionfs/union.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/unionfs/union.h b/fs/unionfs/union.h
index bae3c76..5676394 100644
--- a/fs/unionfs/union.h
+++ b/fs/unionfs/union.h
@@ -130,7 +130,7 @@ struct unionfs_sb_info {
int bend;
 
atomic_t generation;
-   struct rw_semaphore rwsem;
+   struct rw_semaphore rwsem; /* protects access to data+id fields */
 
struct unionfs_data *data;
 };
-- 
1.5.0.3.268.g3dda

-
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

[PATCH 05/21] Unionfs: Rename unionfs_data sbcount field to more appropriate open_files

[Josef 'Jeff' Sipek]

From: Erez Zadok <[EMAIL PROTECTED]>

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
 fs/unionfs/fanout.h |8 
 fs/unionfs/union.h  |2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/fs/unionfs/fanout.h b/fs/unionfs/fanout.h
index e2acb75..3d1dd4c 100644
--- a/fs/unionfs/fanout.h
+++ b/fs/unionfs/fanout.h
@@ -106,22 +106,22 @@ static inline void unionfs_set_lower_super(struct 
super_block *sb, struct super_
 /* Branch count macros. */
 static inline int branch_count(const struct super_block *sb, int index)
 {
-   return atomic_read(&UNIONFS_SB(sb)->data[index].sbcount);
+   return atomic_read(&UNIONFS_SB(sb)->data[index].open_files);
 }
 
 static inline void set_branch_count(struct super_block *sb, int index, int val)
 {
-   atomic_set(&UNIONFS_SB(sb)->data[index].sbcount, val);
+   atomic_set(&UNIONFS_SB(sb)->data[index].open_files, val);
 }
 
 static inline void branchget(struct super_block *sb, int index)
 {
-   atomic_inc(&UNIONFS_SB(sb)->data[index].sbcount);
+   atomic_inc(&UNIONFS_SB(sb)->data[index].open_files);
 }
 
 static inline void branchput(struct super_block *sb, int index)
 {
-   atomic_dec(&UNIONFS_SB(sb)->data[index].sbcount);
+   atomic_dec(&UNIONFS_SB(sb)->data[index].open_files);
 }
 
 /* Dentry macros */
diff --git a/fs/unionfs/union.h b/fs/unionfs/union.h
index 5676394..df9b8c0 100644
--- a/fs/unionfs/union.h
+++ b/fs/unionfs/union.h
@@ -121,7 +121,7 @@ struct unionfs_dentry_info {
 /* These are the pointers to our various objects. */
 struct unionfs_data {
struct super_block *sb;
-   atomic_t sbcount;
+   atomic_t open_files;/* number of open files on branch */
int branchperms;
 };
 
-- 
1.5.0.3.268.g3dda

-
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

[PATCH 18/21] Unionfs: Pass lowernd to lower ->revalidate function

[Josef 'Jeff' Sipek]

From: Erez Zadok <[EMAIL PROTECTED]>

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
 fs/unionfs/dentry.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/fs/unionfs/dentry.c b/fs/unionfs/dentry.c
index b08842f..9eb143d 100644
--- a/fs/unionfs/dentry.c
+++ b/fs/unionfs/dentry.c
@@ -150,8 +150,7 @@ static int __unionfs_d_revalidate_one(struct dentry 
*dentry, struct nameidata *n
if (!hidden_dentry || !hidden_dentry->d_op
|| !hidden_dentry->d_op->d_revalidate)
continue;
-
-   if (!hidden_dentry->d_op->d_revalidate(hidden_dentry, nd))
+   if (!hidden_dentry->d_op->d_revalidate(hidden_dentry, &lowernd))
valid = 0;
}
 
-- 
1.5.0.3.268.g3dda

-
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

[PATCH 19/21] Unionfs: Properly handle stale inodes passed to unionfs_permission

[Josef 'Jeff' Sipek]

From: Erez Zadok <[EMAIL PROTECTED]>

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
 fs/unionfs/inode.c |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/fs/unionfs/inode.c b/fs/unionfs/inode.c
index edd226f..5c452b6 100644
--- a/fs/unionfs/inode.c
+++ b/fs/unionfs/inode.c
@@ -843,8 +843,21 @@ static int unionfs_permission(struct inode *inode, int 
mask,
const int is_file = !S_ISDIR(inode->i_mode);
const int write_mask = (mask & MAY_WRITE) && !(mask & MAY_READ);
 
+   unionfs_read_lock(inode->i_sb);
+
bstart = ibstart(inode);
bend = ibend(inode);
+   if (bstart < 0 || bend < 0) {
+   /*
+* With branch-management, we can get a stale inode here.
+* If so, we return ESTALE back to link_path_walk, which
+* would discard the dcache entry and re-lookup the
+* dentry+inode.  This should be equivalent to issuing
+* __unionfs_d_revalidate_chain on nd.dentry here.
+*/
+   err = -ESTALE;  /* force revalidate */
+   goto out;
+   }
 
for (bindex = bstart; bindex <= bend; bindex++) {
hidden_inode = unionfs_lower_inode_idx(inode, bindex);
@@ -881,6 +894,7 @@ static int unionfs_permission(struct inode *inode, int mask,
}
 
 out:
+   unionfs_read_unlock(inode->i_sb);
return err;
 }
 
-- 
1.5.0.3.268.g3dda

-
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

[PATCH 09/21] Unionfs: Bulk of branch-management remount code

[Josef 'Jeff' Sipek]

From: Erez Zadok <[EMAIL PROTECTED]>

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
 fs/unionfs/main.c  |   52 +++--
 fs/unionfs/super.c |  612 +++-
 fs/unionfs/union.h |6 +
 3 files changed, 646 insertions(+), 24 deletions(-)

diff --git a/fs/unionfs/main.c b/fs/unionfs/main.c
index ed264c7..1c93b13 100644
--- a/fs/unionfs/main.c
+++ b/fs/unionfs/main.c
@@ -181,7 +181,7 @@ void unionfs_reinterpose(struct dentry *dentry)
  * 2) it exists
  * 3) is a directory
  */
-static int check_branch(struct nameidata *nd)
+int check_branch(struct nameidata *nd)
 {
if (!strcmp(nd->dentry->d_sb->s_type->name, "unionfs"))
return -EINVAL;
@@ -211,20 +211,29 @@ static int is_branch_overlap(struct dentry *dent1, struct 
dentry *dent2)
return (dent == dent1);
 }
 
-/* parse branch mode */
-static int parse_branch_mode(char *name)
+/*
+ * Parse branch mode helper function
+ */
+int __parse_branch_mode(const char *name)
 {
-   int perms;
-   int l = strlen(name);
-   if (!strcmp(name + l - 3, "=ro")) {
-   perms = MAY_READ;
-   name[l - 3] = '\0';
-   } else if (!strcmp(name + l - 3, "=rw")) {
-   perms = MAY_READ | MAY_WRITE;
-   name[l - 3] = '\0';
-   } else
-   perms = MAY_READ | MAY_WRITE;
+   if (!name)
+   return 0;
+   if (!strcmp(name, "ro"))
+   return MAY_READ;
+   if (!strcmp(name, "rw"))
+   return (MAY_READ | MAY_WRITE);
+   return 0;
+}
 
+/*
+ * Parse "ro" or "rw" options, but default to "rw" of no mode options
+ * was specified.
+ */
+int parse_branch_mode(const char *name)
+{
+   int perms =  __parse_branch_mode(name);
+   if (perms == 0)
+   perms = MAY_READ | MAY_WRITE;
return perms;
 }
 
@@ -271,18 +280,22 @@ static int parse_dirs_option(struct super_block *sb, 
struct unionfs_dentry_info
goto out;
}
 
-   /* now parsing the string b1:b2=rw:b3=ro:b4 */
+   /* now parsing a string such as "b1:b2=rw:b3=ro:b4" */
branches = 0;
while ((name = strsep(&options, ":")) != NULL) {
int perms;
+   char *mode = strchr(name, '=');
 
-   if (!*name)
+   if (!name || !*name)
continue;
 
branches++;
 
-   /* strip off =rw or =ro if it is specified. */
-   perms = parse_branch_mode(name);
+   /* strip off '=' if any */
+   if (mode)
+   *mode++ = '\0';
+
+   perms = parse_branch_mode(mode);
if (!bindex && !(perms & MAY_WRITE)) {
err = -EINVAL;
goto out;
@@ -305,8 +318,11 @@ static int parse_dirs_option(struct super_block *sb, 
struct unionfs_dentry_info
hidden_root_info->lower_paths[bindex].dentry = nd.dentry;
hidden_root_info->lower_paths[bindex].mnt = nd.mnt;
 
+   unionfs_write_lock(sb);
set_branchperms(sb, bindex, perms);
set_branch_count(sb, bindex, 0);
+   new_branch_id(sb, bindex);
+   unionfs_write_unlock(sb);
 
if (hidden_root_info->bstart < 0)
hidden_root_info->bstart = bindex;
@@ -387,7 +403,7 @@ static struct unionfs_dentry_info 
*unionfs_parse_options(struct super_block *sb,
char *endptr;
int intval;
 
-   if (!*optname)
+   if (!optname || !*optname)
continue;
 
optarg = strchr(optname, '=');
diff --git a/fs/unionfs/super.c b/fs/unionfs/super.c
index 037c47d..7f0d174 100644
--- a/fs/unionfs/super.c
+++ b/fs/unionfs/super.c
@@ -143,14 +143,614 @@ static int unionfs_statfs(struct dentry *dentry, struct 
kstatfs *buf)
return err;
 }
 
-/* We don't support a standard text remount. Eventually it would be nice to
- * support a full-on remount, so that you can have all of the directories
- * change at once, but that would require some pretty complicated matching
- * code.
+/* handle mode changing during remount */
+static int do_remount_mode_option(char *optarg, int cur_branches,
+ struct unionfs_data *new_data,
+ struct path *new_lower_paths)
+{
+   int err = -EINVAL;
+   int perms, idx;
+   char *modename = strchr(optarg, '=');
+   struct nameidata nd;
+
+   /* by now, optarg contains the branch name */
+   if (!*optarg) {
+   printk("unionfs: no branch specified for mode change.\n");
+   goto out;
+   }
+   if (!modename) {
+   printk("unionfs: branch \"%s\" requires a mode.\n", optarg);
+   goto out;
+   }
+   *modename++ = '\0';
+   perms = __p

[PATCH 17/21] Unionfs: vfsmount reference counting fixes

[Josef 'Jeff' Sipek]

From: Erez Zadok <[EMAIL PROTECTED]>

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
 fs/unionfs/dentry.c |8 +++-
 1 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/fs/unionfs/dentry.c b/fs/unionfs/dentry.c
index 4756b78..b08842f 100644
--- a/fs/unionfs/dentry.c
+++ b/fs/unionfs/dentry.c
@@ -235,8 +235,8 @@ int __unionfs_d_revalidate_chain(struct dentry *dentry, 
struct nameidata *nd)
valid = __unionfs_d_revalidate_one(chain[i], nd);
/* XXX: is this the correct mntput condition?! */
if (valid && chain_len > 0 &&
-   sbgen != dgen && dentry->d_inode &&
-   S_ISDIR(dentry->d_inode->i_mode)) {
+   sbgen != dgen && chain[i]->d_inode &&
+   S_ISDIR(chain[i]->d_inode->i_mode)) {
for (bindex = saved_bstart; bindex <= saved_bend; 
bindex++)
unionfs_mntput(chain[i], bindex);
}
@@ -256,9 +256,7 @@ int __unionfs_d_revalidate_chain(struct dentry *dentry, 
struct nameidata *nd)
saved_bend = dbend(dentry);
valid = __unionfs_d_revalidate_one(dentry, nd);
 
-   if (valid && chain_len > 0 &&
-   sbgen != dgen && dentry->d_inode &&
-   S_ISDIR(dentry->d_inode->i_mode)) {
+   if (valid && chain_len > 0 && sbgen != dgen) {
for (bindex = saved_bstart; bindex <= saved_bend; bindex++)
unionfs_mntput(dentry, bindex);
}
-- 
1.5.0.3.268.g3dda

-
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

[PATCH 11/21] Unionfs: Rewrite unionfs_d_revalidate

[Josef 'Jeff' Sipek]

From: Erez Zadok <[EMAIL PROTECTED]>

Rewrite unionfs_d_revalidate code to avoid stack-unfriendly recursion: split
into a call to revalidate just one dentry, and an interative driver function
to revalidate an entire dentry-parent chain.

Fix vfsmount ref leaks which prevented lower f/s from being unmounted after
generation increment, esp. during heavy loads.

Fix one deadlock between revalidation code and VFS.

Better documentation of what the code does.

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
[jsipek: compile & whitespace fixes]
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
 fs/unionfs/commonfops.c |   12 +++-
 fs/unionfs/dentry.c |  153 +++
 fs/unionfs/union.h  |1 +
 3 files changed, 136 insertions(+), 30 deletions(-)

diff --git a/fs/unionfs/commonfops.c b/fs/unionfs/commonfops.c
index c20dd6f..9b6128c 100644
--- a/fs/unionfs/commonfops.c
+++ b/fs/unionfs/commonfops.c
@@ -266,7 +266,11 @@ static int do_delayed_copyup(struct file *file, struct 
dentry *dentry)
return err;
 }
 
-/* revalidate the stuct file */
+/*
+ * Revalidate the struct file
+ * @file: file to revalidate
+ * @willwrite: 1 if caller may cause changes to the file; 0 otherwise.
+ */
 int unionfs_file_revalidate(struct file *file, int willwrite)
 {
struct super_block *sb;
@@ -280,8 +284,9 @@ int unionfs_file_revalidate(struct file *file, int 
willwrite)
dentry = file->f_dentry;
unionfs_lock_dentry(dentry);
sb = dentry->d_sb;
-   unionfs_read_lock(sb);
-   if (!__unionfs_d_revalidate(dentry, NULL) && !d_deleted(dentry)) {
+
+   /* first revalidate the dentry inside struct file */
+   if (!__unionfs_d_revalidate_chain(dentry, NULL) && !d_deleted(dentry)) {
err = -ESTALE;
goto out_nofree;
}
@@ -351,7 +356,6 @@ out:
}
 out_nofree:
unionfs_unlock_dentry(dentry);
-   unionfs_read_unlock(dentry->d_sb);
return err;
 }
 
diff --git a/fs/unionfs/dentry.c b/fs/unionfs/dentry.c
index 5ee1451..c841f08 100644
--- a/fs/unionfs/dentry.c
+++ b/fs/unionfs/dentry.c
@@ -18,10 +18,15 @@
 
 #include "union.h"
 
+
 /*
- * returns 1 if valid, 0 otherwise.
+ * Revalidate a single dentry.
+ * Assume that dentry's info node is locked.
+ * Assume that parent(s) are all valid already, but
+ * the child may not yet be valid.
+ * Returns 1 if valid, 0 otherwise.
  */
-int __unionfs_d_revalidate(struct dentry *dentry, struct nameidata *nd)
+static int __unionfs_d_revalidate_one(struct dentry *dentry, struct nameidata 
*nd)
 {
int valid = 1;  /* default is valid (1); invalid is 0. */
struct dentry *hidden_dentry;
@@ -29,7 +34,6 @@ int __unionfs_d_revalidate(struct dentry *dentry, struct 
nameidata *nd)
int sbgen, dgen;
int positive = 0;
int locked = 0;
-   int restart = 0;
int interpose_flag;
 
struct nameidata lowernd; /* TODO: be gentler to the stack */
@@ -39,7 +43,6 @@ int __unionfs_d_revalidate(struct dentry *dentry, struct 
nameidata *nd)
else
memset(&lowernd, 0, sizeof(struct nameidata));
 
-restart:
verify_locked(dentry);
 
/* if the dentry is unhashed, do NOT revalidate */
@@ -62,28 +65,12 @@ restart:
struct dentry *result;
int pdgen;
 
-   unionfs_read_lock(dentry->d_sb);
-   locked = 1;
-
/* The root entry should always be valid */
BUG_ON(IS_ROOT(dentry));
 
/* We can't work correctly if our parent isn't valid. */
pdgen = atomic_read(&UNIONFS_D(dentry->d_parent)->generation);
-   if (!restart && (pdgen != sbgen)) {
-   unionfs_read_unlock(dentry->d_sb);
-   locked = 0;
-   /* We must be locked before our parent. */
-   if (!
-   (dentry->d_parent->d_op->
-d_revalidate(dentry->d_parent, nd))) {
-   valid = 0;
-   goto out;
-   }
-   restart = 1;
-   goto restart;
-   }
-   BUG_ON(pdgen != sbgen);
+   BUG_ON(pdgen != sbgen); /* should never happen here */
 
/* Free the pointers for our inodes and this dentry. */
bstart = dbstart(dentry);
@@ -102,7 +89,17 @@ restart:
interpose_flag = INTERPOSE_REVAL_NEG;
if (positive) {
interpose_flag = INTERPOSE_REVAL;
-   mutex_lock(&dentry->d_inode->i_mutex);
+   /*
+* During BRM, the VFS could already hold a lock on
+* a file being read, so don't lock it again
+* (deadlock), but if you lock it in this function,
+ 

[PATCH 07/21] Unionfs: Actually verify if dentry's info node is locked

[Josef 'Jeff' Sipek]

From: Erez Zadok <[EMAIL PROTECTED]>

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
 fs/unionfs/fanout.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/fs/unionfs/fanout.h b/fs/unionfs/fanout.h
index 3d1dd4c..e8c0fee 100644
--- a/fs/unionfs/fanout.h
+++ b/fs/unionfs/fanout.h
@@ -205,6 +205,7 @@ static inline void unionfs_unlock_dentry(struct dentry *d)
 
 static inline void verify_locked(struct dentry *d)
 {
+   BUG_ON(!mutex_is_locked(&UNIONFS_D(d)->lock));
 }
 
 #endif /* _FANOUT_H */
-- 
1.5.0.3.268.g3dda

-
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

[PATCH 16/21] Unionfs: unionfs_create needs to revalidate the dentry

[Josef 'Jeff' Sipek]

From: Erez Zadok <[EMAIL PROTECTED]>

We have to read-lock the superblock rwsem, and we have to revalidate the
parent dentry and this one.  A branch-management operation could have taken
place, mid-way through a VFS operation that eventually reaches
unionfs_create().  So we have to ensure consistency, just as we do with the
file operations.

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
 fs/unionfs/inode.c |   29 -
 1 files changed, 28 insertions(+), 1 deletions(-)

diff --git a/fs/unionfs/inode.c b/fs/unionfs/inode.c
index 6dfc16f..edd226f 100644
--- a/fs/unionfs/inode.c
+++ b/fs/unionfs/inode.c
@@ -28,9 +28,35 @@ static int unionfs_create(struct inode *parent, struct 
dentry *dentry,
struct dentry *hidden_parent_dentry = NULL;
int bindex = 0, bstart;
char *name = NULL;
-
+   int valid = 0;
+
+   /*
+* We have to read-lock the superblock rwsem, and we have to
+* revalidate the parent dentry and this one.  A branch-management
+* operation could have taken place, mid-way through a VFS operation
+* that eventually reaches here.  So we have to ensure consistency,
+* just as we do with the file operations.
+*
+* XXX: we may need to do this for all other inode ops that take a
+* dentry.
+*/
+   unionfs_read_lock(dentry->d_sb);
unionfs_lock_dentry(dentry);
 
+   unionfs_lock_dentry(dentry->d_parent);
+   valid = __unionfs_d_revalidate_chain(dentry->d_parent, nd);
+   unionfs_unlock_dentry(dentry->d_parent);
+   if (!valid) {
+   err = -ENOENT;  /* same as what real_lookup does */
+   goto out;
+   }
+   valid = __unionfs_d_revalidate_chain(dentry, nd);
+   /*
+* It's only a bug if this dentry was not negative and couldn't be
+* revalidated (shouldn't happen).
+*/
+   BUG_ON(!valid && dentry->d_inode);
+
/* We start out in the leftmost branch. */
bstart = dbstart(dentry);
hidden_dentry = unionfs_lower_dentry(dentry);
@@ -184,6 +210,7 @@ out:
kfree(name);
 
unionfs_unlock_dentry(dentry);
+   unionfs_read_unlock(dentry->d_sb);
return err;
 }
 
-- 
1.5.0.3.268.g3dda

-
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

[PATCH 15/21] Unionfs: Decrement totalopens counter on error in unionfs_open

[Josef 'Jeff' Sipek]

From: Erez Zadok <[EMAIL PROTECTED]>

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
 fs/unionfs/commonfops.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/fs/unionfs/commonfops.c b/fs/unionfs/commonfops.c
index 8453f2d..c9df99d 100644
--- a/fs/unionfs/commonfops.c
+++ b/fs/unionfs/commonfops.c
@@ -509,6 +509,7 @@ int unionfs_open(struct inode *inode, struct file *file)
 
/* freeing the allocated resources, and fput the opened files */
if (err) {
+   atomic_dec(&UNIONFS_I(dentry->d_inode)->totalopens);
for (bindex = bstart; bindex <= bend; bindex++) {
hidden_file = unionfs_lower_file_idx(file, bindex);
if (!hidden_file)
-- 
1.5.0.3.268.g3dda

-
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

[PATCH 21/21] Unionfs: Don't inline do_remount_{add,del,mode}_option

[Josef 'Jeff' Sipek]

From: Erez Zadok <[EMAIL PROTECTED]>

gcc4 decided to inline do_remount_{add,del,mode}_option creating an 600 byte
stack abuser on a x86_64 test box.

Reported by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
 fs/unionfs/lookup.c |2 +-
 fs/unionfs/super.c  |   20 ++--
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/fs/unionfs/lookup.c b/fs/unionfs/lookup.c
index 0572247..0fc5993 100644
--- a/fs/unionfs/lookup.c
+++ b/fs/unionfs/lookup.c
@@ -30,7 +30,7 @@ static int is_validname(const char *name)
 }
 
 /* The rest of these are utility functions for lookup. */
-static int is_opaque_dir(struct dentry *dentry, int bindex)
+static noinline int is_opaque_dir(struct dentry *dentry, int bindex)
 {
int err = 0;
struct dentry *hidden_dentry;
diff --git a/fs/unionfs/super.c b/fs/unionfs/super.c
index ec5706b..e6a6cc1 100644
--- a/fs/unionfs/super.c
+++ b/fs/unionfs/super.c
@@ -148,9 +148,9 @@ static int unionfs_statfs(struct dentry *dentry, struct 
kstatfs *buf)
 }
 
 /* handle mode changing during remount */
-static int do_remount_mode_option(char *optarg, int cur_branches,
- struct unionfs_data *new_data,
- struct path *new_lower_paths)
+static noinline int do_remount_mode_option(char *optarg, int cur_branches,
+  struct unionfs_data *new_data,
+  struct path *new_lower_paths)
 {
int err = -EINVAL;
int perms, idx;
@@ -207,9 +207,9 @@ out:
 }
 
 /* handle branch deletion during remount */
-static int do_remount_del_option(char *optarg, int cur_branches,
-struct unionfs_data *new_data,
-struct path *new_lower_paths)
+static noinline int do_remount_del_option(char *optarg, int cur_branches,
+ struct unionfs_data *new_data,
+ struct path *new_lower_paths)
 {
int err = -EINVAL;
int idx;
@@ -268,10 +268,10 @@ out:
 }
 
 /* handle branch insertion during remount */
-static int do_remount_add_option(char *optarg, int cur_branches,
-struct unionfs_data *new_data,
-struct path *new_lower_paths,
-int *high_branch_id)
+static noinline int do_remount_add_option(char *optarg, int cur_branches,
+ struct unionfs_data *new_data,
+ struct path *new_lower_paths,
+ int *high_branch_id)
 {
int err = -EINVAL;
int perms;
-- 
1.5.0.3.268.g3dda

-
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

[PATCH 06/21] Unionfs: Provide more helpful info on branch leaks during unmount

[Josef 'Jeff' Sipek]

From: Erez Zadok <[EMAIL PROTECTED]>

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
[jsipek: no need to take a read lock on the superblock private data]
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
 fs/unionfs/super.c |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/fs/unionfs/super.c b/fs/unionfs/super.c
index 571b589..037c47d 100644
--- a/fs/unionfs/super.c
+++ b/fs/unionfs/super.c
@@ -97,6 +97,7 @@ static void unionfs_put_super(struct super_block *sb)
 {
int bindex, bstart, bend;
struct unionfs_sb_info *spd;
+   int leaks = 0;
 
spd = UNIONFS_SB(sb);
if (!spd)
@@ -107,7 +108,12 @@ static void unionfs_put_super(struct super_block *sb)
 
/* Make sure we have no leaks of branchget/branchput. */
for (bindex = bstart; bindex <= bend; bindex++)
-   BUG_ON(branch_count(sb, bindex) != 0);
+   if (branch_count(sb, bindex) != 0) {
+   printk("unionfs: branch %d has %d references left!\n",
+  bindex, branch_count(sb,bindex));
+   leaks = 1;
+   }
+   BUG_ON(leaks != 0);
 
kfree(spd->data);
kfree(spd);
-- 
1.5.0.3.268.g3dda

-
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

[PATCH 12/21] Unionfs: Grab the unionfs sb private data lock around branch info users

[Josef 'Jeff' Sipek]

From: Erez Zadok <[EMAIL PROTECTED]>

Locking/concurrency/race fixes.  Use the unionfs superblock rwsem, and grab
the read lock around every op that uses branch-related information, such as
branch counters.  Grab the write rwsem lock in operations which attempt to
change branch information, such as when adding/deleting branches.  This
will, for example, cause branch-management remount commands (which are
infrequent) to block a bit until all in-progress file operations on open
files are done.

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
[jsipek: whitespace fixes & more locks/unlocks]
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
 fs/unionfs/commonfops.c |   25 ++---
 fs/unionfs/copyup.c |   14 ++
 fs/unionfs/dirfops.c|4 
 fs/unionfs/dirhelper.c  |6 ++
 fs/unionfs/file.c   |   14 ++
 fs/unionfs/inode.c  |   10 +++---
 fs/unionfs/main.c   |4 
 fs/unionfs/super.c  |6 ++
 fs/unionfs/union.h  |   10 +++---
 9 files changed, 80 insertions(+), 13 deletions(-)

diff --git a/fs/unionfs/commonfops.c b/fs/unionfs/commonfops.c
index 9b6128c..6606cba 100644
--- a/fs/unionfs/commonfops.c
+++ b/fs/unionfs/commonfops.c
@@ -170,7 +170,9 @@ static int open_all_files(struct file *file)
 
dget(hidden_dentry);
unionfs_mntget(dentry, bindex);
+   unionfs_read_lock(sb);
branchget(sb, bindex);
+   unionfs_read_unlock(sb);
 
hidden_file = dentry_open(hidden_dentry,
unionfs_lower_mnt_idx(dentry, bindex),
@@ -215,7 +217,9 @@ static int open_highest_file(struct file *file, int 
willwrite)
 
dget(hidden_dentry);
unionfs_mntget(dentry, bstart);
+   unionfs_read_lock(sb);
branchget(sb, bstart);
+   unionfs_read_unlock(sb);
hidden_file = dentry_open(hidden_dentry,
unionfs_lower_mnt_idx(dentry, bstart), file->f_flags);
if (IS_ERR(hidden_file)) {
@@ -256,7 +260,9 @@ static int do_delayed_copyup(struct file *file, struct 
dentry *dentry)
bend = fbend(file);
for (bindex = bstart; bindex <= bend; bindex++) {
if (unionfs_lower_file_idx(file, bindex)) {
+   unionfs_read_lock(dentry->d_sb);
branchput(dentry->d_sb, bindex);
+   unionfs_read_unlock(dentry->d_sb);
fput(unionfs_lower_file_idx(file, bindex));
unionfs_set_lower_file_idx(file, bindex, NULL);
}
@@ -387,7 +393,9 @@ static int __open_dir(struct inode *inode, struct file 
*file)
/* The branchget goes after the open, because otherwise
 * we would miss the reference on release.
 */
+   unionfs_read_lock(inode->i_sb);
branchget(inode->i_sb, bindex);
+   unionfs_read_unlock(inode->i_sb);
}
 
return 0;
@@ -443,7 +451,9 @@ static int __open_file(struct inode *inode, struct file 
*file)
return PTR_ERR(hidden_file);
 
unionfs_set_lower_file(file, hidden_file);
+   unionfs_read_lock(inode->i_sb);
branchget(inode->i_sb, bstart);
+   unionfs_read_unlock(inode->i_sb);
 
return 0;
 }
@@ -456,6 +466,7 @@ int unionfs_open(struct inode *inode, struct file *file)
int bindex = 0, bstart = 0, bend = 0;
int size;
 
+   unionfs_read_lock(inode->i_sb);
file->private_data = kzalloc(sizeof(struct unionfs_file_info), 
GFP_KERNEL);
if (!UNIONFS_F(file)) {
err = -ENOMEM;
@@ -481,7 +492,6 @@ int unionfs_open(struct inode *inode, struct file *file)
 
dentry = file->f_dentry;
unionfs_lock_dentry(dentry);
-   unionfs_read_lock(inode->i_sb);
 
bstart = fbstart(file) = dbstart(dentry);
bend = fbend(file) = dbend(dentry);
@@ -504,14 +514,15 @@ int unionfs_open(struct inode *inode, struct file *file)
if (!hidden_file)
continue;
 
+   unionfs_read_lock(file->f_dentry->d_sb);
branchput(file->f_dentry->d_sb, bindex);
+   unionfs_read_unlock(file->f_dentry->d_sb);
/* fput calls dput for hidden_dentry */
fput(hidden_file);
}
}
 
unionfs_unlock_dentry(dentry);
-   unionfs_read_unlock(inode->i_sb);
 
 out:
if (err) {
@@ -520,6 +531,7 @@ out:
kfree(UNIONFS_F(file));
}
 out_nofree:
+   unionfs_read_unlock(inode->i_sb);
return err;
 }
 
@@ -532,6 +544,7 @@ int unionfs_file_release(struct inode *inode, struct file 
*file)
int bindex, bstart, bend;
int fgen;
 
+   unionfs_read_lock(inode->i_sb);
   

[PATCH 20/21] Unionfs: Added several BUG_ONs to assert dentry validity

[Josef 'Jeff' Sipek]

From: Erez Zadok <[EMAIL PROTECTED]>

This should help catch races between the VFS and the branch-management code.

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
 fs/unionfs/inode.c  |   15 +++
 fs/unionfs/rename.c |3 +++
 fs/unionfs/super.c  |2 ++
 fs/unionfs/union.h  |   13 +
 fs/unionfs/unlink.c |4 
 fs/unionfs/xattr.c  |8 
 6 files changed, 45 insertions(+), 0 deletions(-)

diff --git a/fs/unionfs/inode.c b/fs/unionfs/inode.c
index 5c452b6..97dad8c 100644
--- a/fs/unionfs/inode.c
+++ b/fs/unionfs/inode.c
@@ -249,6 +249,9 @@ static int unionfs_link(struct dentry *old_dentry, struct 
inode *dir,
struct dentry *whiteout_dentry;
char *name = NULL;
 
+   BUG_ON(!is_valid_dentry(new_dentry));
+   BUG_ON(!is_valid_dentry(old_dentry));
+
double_lock_dentry(new_dentry, old_dentry);
 
hidden_new_dentry = unionfs_lower_dentry(new_dentry);
@@ -373,6 +376,8 @@ static int unionfs_symlink(struct inode *dir, struct dentry 
*dentry,
int bindex = 0, bstart;
char *name = NULL;
 
+   BUG_ON(!is_valid_dentry(dentry));
+
unionfs_lock_dentry(dentry);
 
/* We start out in the leftmost branch. */
@@ -495,6 +500,8 @@ static int unionfs_mkdir(struct inode *parent, struct 
dentry *dentry, int mode)
int whiteout_unlinked = 0;
struct sioq_args args;
 
+   BUG_ON(!is_valid_dentry(dentry));
+
unionfs_lock_dentry(dentry);
bstart = dbstart(dentry);
 
@@ -622,6 +629,8 @@ static int unionfs_mknod(struct inode *dir, struct dentry 
*dentry, int mode,
char *name = NULL;
int whiteout_unlinked = 0;
 
+   BUG_ON(!is_valid_dentry(dentry));
+
unionfs_lock_dentry(dentry);
bstart = dbstart(dentry);
 
@@ -724,6 +733,8 @@ static int unionfs_readlink(struct dentry *dentry, char 
__user * buf,
int err;
struct dentry *hidden_dentry;
 
+   BUG_ON(!is_valid_dentry(dentry));
+
unionfs_lock_dentry(dentry);
hidden_dentry = unionfs_lower_dentry(dentry);
 
@@ -749,6 +760,8 @@ static void *unionfs_follow_link(struct dentry *dentry, 
struct nameidata *nd)
int len = PAGE_SIZE, err;
mm_segment_t old_fs;
 
+   BUG_ON(!is_valid_dentry(dentry));
+
/* This is freed by the put_link method assuming a successful call. */
buf = kmalloc(len, GFP_KERNEL);
if (!buf) {
@@ -908,6 +921,8 @@ static int unionfs_setattr(struct dentry *dentry, struct 
iattr *ia)
int i;
int copyup = 0;
 
+   BUG_ON(!is_valid_dentry(dentry));
+
unionfs_lock_dentry(dentry);
bstart = dbstart(dentry);
bend = dbend(dentry);
diff --git a/fs/unionfs/rename.c b/fs/unionfs/rename.c
index c9aa040..0044492 100644
--- a/fs/unionfs/rename.c
+++ b/fs/unionfs/rename.c
@@ -379,6 +379,9 @@ int unionfs_rename(struct inode *old_dir, struct dentry 
*old_dentry,
int err = 0;
struct dentry *wh_dentry;
 
+   BUG_ON(!is_valid_dentry(old_dentry));
+   BUG_ON(!is_valid_dentry(new_dentry));
+
double_lock_dentry(old_dentry, new_dentry);
 
if (!S_ISDIR(old_dentry->d_inode->i_mode))
diff --git a/fs/unionfs/super.c b/fs/unionfs/super.c
index 5d11908..ec5706b 100644
--- a/fs/unionfs/super.c
+++ b/fs/unionfs/super.c
@@ -129,6 +129,8 @@ static int unionfs_statfs(struct dentry *dentry, struct 
kstatfs *buf)
int err = 0;
struct super_block *sb, *hidden_sb;
 
+   BUG_ON(!is_valid_dentry(dentry));
+
sb = dentry->d_sb;
 
unionfs_read_lock(sb);
diff --git a/fs/unionfs/union.h b/fs/unionfs/union.h
index faaa87e..b6fa0a2 100644
--- a/fs/unionfs/union.h
+++ b/fs/unionfs/union.h
@@ -399,6 +399,19 @@ static inline int is_robranch(const struct dentry *dentry)
return is_robranch_idx(dentry, index);
 }
 
+/*
+ * Check if dentry is valid or not, as per our generation numbers.
+ * @dentry: dentry to check.
+ * Returns 1 (valid) or 0 (invalid/stale).
+ */
+static inline int is_valid_dentry(struct dentry *dentry)
+{
+   BUG_ON(!UNIONFS_D(dentry));
+   BUG_ON(!UNIONFS_SB(dentry->d_sb));
+   return (atomic_read(&UNIONFS_D(dentry)->generation) ==
+   atomic_read(&UNIONFS_SB(dentry->d_sb)->generation));
+}
+
 /* What do we use for whiteouts. */
 #define UNIONFS_WHPFX ".wh."
 #define UNIONFS_WHLEN 4
diff --git a/fs/unionfs/unlink.c b/fs/unionfs/unlink.c
index f5b250a..dd1dd9c 100644
--- a/fs/unionfs/unlink.c
+++ b/fs/unionfs/unlink.c
@@ -74,6 +74,8 @@ int unionfs_unlink(struct inode *dir, struct dentry *dentry)
 {
int err = 0;
 
+   BUG_ON(!is_valid_dentry(dentry));
+
unionfs_lock_dentry(dentry);
 
err = unionfs_unlink_whiteout(dir, dentry);
@@ -122,6 +124,8 @@ int unionfs_rmdir(struct inode *dir, struct dentry *dentry)
int err = 0;
struct unionfs_dir_state *namelist = NULL;
 
+   BUG_ON(!is_valid_dentry(dentry));
+
un

[PATCH 02/21] fs: Export drop_pagecache_sb symbol

[Josef 'Jeff' Sipek]

From: Erez Zadok 

Signed-off-by: Erez Zadok 
Signed-off-by: Josef 'Jeff' Sipek 
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
 fs/drop_caches.c   |4 +++-
 include/linux/mm.h |1 +
 2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/fs/drop_caches.c b/fs/drop_caches.c
index 03ea769..6a7aa05 100644
--- a/fs/drop_caches.c
+++ b/fs/drop_caches.c
@@ -3,6 +3,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -12,7 +13,7 @@
 /* A global variable is a bit ugly, but it keeps the code simple */
 int sysctl_drop_caches;
 
-static void drop_pagecache_sb(struct super_block *sb)
+void drop_pagecache_sb(struct super_block *sb)
 {
struct inode *inode;
 
@@ -24,6 +25,7 @@ static void drop_pagecache_sb(struct super_block *sb)
}
spin_unlock(&inode_lock);
 }
+EXPORT_SYMBOL(drop_pagecache_sb);
 
 void drop_pagecache(void)
 {
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 60e0e4a..c680669 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1157,6 +1157,7 @@ int drop_caches_sysctl_handler(struct ctl_table *, int, 
struct file *,
void __user *, size_t *, loff_t *);
 unsigned long shrink_slab(unsigned long scanned, gfp_t gfp_mask,
unsigned long lru_pages);
+extern void drop_pagecache_sb(struct super_block *);
 void drop_pagecache(void);
 void drop_slab(void);
 
-- 
1.5.0.3.268.g3dda

-
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

[GIT PULL -mm] Unionfs branch management code

[Josef 'Jeff' Sipek]

The following patches introduce new branch-management code into Unionfs as
well as fix a number of stability issues and resource leaks.  For detailed
announcement, see end of this email.

As before, there is a git repo at:

git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/unionfs.git

(master.kernel.org:/pub/scm/linux/kernel/git/jsipek/unionfs.git)

There are 21 new commits:

Unionfs: Don't inline do_remount_{add,del,mode}_option
Unionfs: Added several BUG_ONs to assert dentry validity
Unionfs: Properly handle stale inodes passed to unionfs_permission
Unionfs: Pass lowernd to lower ->revalidate function
Unionfs: vfsmount reference counting fixes
Unionfs: unionfs_create needs to revalidate the dentry
Unionfs: Decrement totalopens counter on error in unionfs_open
Unionfs: Document unionfs_d_release locking
Unionfs: Remove the older incgen ioctl
Unionfs: Grab the unionfs sb private data lock around branch info users
Unionfs: Rewrite unionfs_d_revalidate
Unionfs: Introduce unionfs_mnt{get,put}
Unionfs: Bulk of branch-management remount code
Unionfs: Introduce branch-id code
Unionfs: Actually verify if dentry's info node is locked
Unionfs: Provide more helpful info on branch leaks during unmount
Unionfs: Rename unionfs_data sbcount field to more appropriate 
open_files
Unionfs: Proper comment on rwsem field
Unionfs: Documentation updates for branch-management
fs: Export drop_pagecache_sb symbol
fs: Introduce path{get,put}

Thanks,

Josef 'Jeff' Sipek <[EMAIL PROTECTED]>

---

Announcement:

We're pleased to announce that we merged new branch-management code into
Unionfs 2.0.  Using this code, you can add, remove, and/or change the mode
of branches.  We allow multiple branch-management operations at the same
time and they are applied atomically.

The new branch-management interface uses the remount functionality.  It is
NOT compatible with the older Unionfs 1.x branch-management interface, which
used ioctl()s.  The older interface was not atomic for multiple operations,
and had a fundamental consistency problem with open files being revalidated.
The new remount-based branch-management interface fixes all of that, and
also saves users from having to use another utility (unionctl) to control
their branches: you can now use plain /sbin/mount for all your
branch-management commands.  Additionally, we now allow the entire union to
be remounted read-only or read-write.  Here are a few examples of how to use
the new interface:

To delete a branch /foo, regardless where it is in the current union:

# mount -t unionfs -o remount,del=/foo none MOUNTPOINT

To insert (add) a branch /foo before /bar:

# mount -t unionfs -o remount,add=/bar:/foo none MOUNTPOINT

To insert (add) a branch /foo (in "rw" mode) at the very beginning (i.e., a
new highest-priority branch), you can use the above syntax, or use a short
hand version as follows:

# mount -t unionfs -o remount,add=/foo none MOUNTPOINT

To change the mode of one existing branch, say /foo, from read-only to
read-write, and change /bar from read-write to read-only:

# mount -t unionfs -o remount,mode=/foo=rw,mode=/bar=ro none MOUNTPOINT


The above are just a few examples.  You can mix and match the branch
management commands.  For more documentation and examples, see the following
file in the latest patch:

Documentation/filesystems/unionfs/usage.txt

Finally, the patch below includes bug fixes to a number of bugs we've
discovered during our thorough testing of the branch-management code.  One
of the challenges in branch management is that it can change the composition
of a live, running file system *while* it has open files and cached objects.
We tested the code as much as possible to ensure that even under intense
multi-threaded workloads, generation number and stale cache entries are
handled properly.

-
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

[PATCH 10/21] Unionfs: Introduce unionfs_mnt{get,put}

[Josef 'Jeff' Sipek]

From: Erez Zadok <[EMAIL PROTECTED]>

Helper inline functions to perform Unionfs's mntget/put ops on lower
branches.

Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
[jsipek: cleanup branching in unionfs_mnt{get,put} and compile fixes]
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
 fs/unionfs/commonfops.c |8 
 fs/unionfs/copyup.c |6 +++---
 fs/unionfs/dentry.c |2 +-
 fs/unionfs/dirhelper.c  |2 +-
 fs/unionfs/lookup.c |   25 +
 fs/unionfs/main.c   |7 ---
 fs/unionfs/union.h  |   35 ++-
 7 files changed, 60 insertions(+), 25 deletions(-)

diff --git a/fs/unionfs/commonfops.c b/fs/unionfs/commonfops.c
index 8d0f8d1..c20dd6f 100644
--- a/fs/unionfs/commonfops.c
+++ b/fs/unionfs/commonfops.c
@@ -169,7 +169,7 @@ static int open_all_files(struct file *file)
continue;
 
dget(hidden_dentry);
-   mntget(unionfs_lower_mnt_idx(dentry, bindex));
+   unionfs_mntget(dentry, bindex);
branchget(sb, bindex);
 
hidden_file = dentry_open(hidden_dentry,
@@ -214,7 +214,7 @@ static int open_highest_file(struct file *file, int 
willwrite)
}
 
dget(hidden_dentry);
-   mntget(unionfs_lower_mnt_idx(dentry, bstart));
+   unionfs_mntget(dentry, bstart);
branchget(sb, bstart);
hidden_file = dentry_open(hidden_dentry,
unionfs_lower_mnt_idx(dentry, bstart), file->f_flags);
@@ -371,7 +371,7 @@ static int __open_dir(struct inode *inode, struct file 
*file)
continue;
 
dget(hidden_dentry);
-   mntget(unionfs_lower_mnt_idx(file->f_dentry, bindex));
+   unionfs_mntget(file->f_dentry, bindex);
hidden_file = dentry_open(hidden_dentry,
unionfs_lower_mnt_idx(file->f_dentry, bindex),
file->f_flags);
@@ -431,7 +431,7 @@ static int __open_file(struct inode *inode, struct file 
*file)
/* dentry_open will decrement mnt refcnt if err.
 * otherwise fput() will do an mntput() for us upon file close.
 */
-   mntget(unionfs_lower_mnt_idx(file->f_dentry, bstart));
+   unionfs_mntget(file->f_dentry, bstart);
hidden_file = dentry_open(hidden_dentry,
  unionfs_lower_mnt_idx(file->f_dentry, bstart),
  hidden_flags);
diff --git a/fs/unionfs/copyup.c b/fs/unionfs/copyup.c
index e24d940..4ccef81 100644
--- a/fs/unionfs/copyup.c
+++ b/fs/unionfs/copyup.c
@@ -206,7 +206,7 @@ static int __copyup_reg_data(struct dentry *dentry,
int err = 0;
 
/* open old file */
-   mntget(unionfs_lower_mnt_idx(dentry, old_bindex));
+   unionfs_mntget(dentry, old_bindex);
branchget(sb, old_bindex);
input_file = dentry_open(old_hidden_dentry,
unionfs_lower_mnt_idx(dentry, old_bindex),
@@ -223,7 +223,7 @@ static int __copyup_reg_data(struct dentry *dentry,
 
/* open new file */
dget(new_hidden_dentry);
-   mntget(unionfs_lower_mnt_idx(dentry, new_bindex));
+   unionfs_mntget(dentry, new_bindex);
branchget(sb, new_bindex);
output_file = dentry_open(new_hidden_dentry,
unionfs_lower_mnt_idx(dentry, new_bindex),
@@ -555,7 +555,7 @@ static void __cleanup_dentry(struct dentry * dentry, int 
bindex,
dput(unionfs_lower_dentry_idx(dentry, i));
unionfs_set_lower_dentry_idx(dentry, i, NULL);
 
-   mntput(unionfs_lower_mnt_idx(dentry, i));
+   unionfs_mntput(dentry, i);
unionfs_set_lower_mnt_idx(dentry, i, NULL);
} else {
if (new_bstart < 0)
diff --git a/fs/unionfs/dentry.c b/fs/unionfs/dentry.c
index cae4897..5ee1451 100644
--- a/fs/unionfs/dentry.c
+++ b/fs/unionfs/dentry.c
@@ -206,7 +206,7 @@ static void unionfs_d_release(struct dentry *dentry)
bend = dbend(dentry);
for (bindex = bstart; bindex <= bend; bindex++) {
dput(unionfs_lower_dentry_idx(dentry, bindex));
-   mntput(unionfs_lower_mnt_idx(dentry, bindex));
+   unionfs_mntput(dentry, bindex);
 
unionfs_set_lower_dentry_idx(dentry, bindex, NULL);
unionfs_set_lower_mnt_idx(dentry, bindex, NULL);
diff --git a/fs/unionfs/dirhelper.c b/fs/unionfs/dirhelper.c
index 0da8a8e..bb5f7bc 100644
--- a/fs/unionfs/dirhelper.c
+++ b/fs/unionfs/dirhelper.c
@@ -225,7 +225,7 @@ int check_empty(struct dentry *dentry, struct 
unionfs_dir_state **namelist)
continue;
 
dget(hidden_dentry);
-   mntget(unionfs_lower_mnt_idx(dentry, bindex));
+   unionfs_mntget(dentry, bindex);
branchget(sb, bin

Re: [patch 0/8] unprivileged mount syscall

[Serge E. Hallyn]

Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > This patchset adds support for keeping mount ownership information in
> > > the kernel, and allow unprivileged mount(2) and umount(2) in certain
> > > cases.
> > 
> > No replies, huh?
> 
> All we need is a comment from Andrew, and the replies come flooding in ;)
> 
> > My knowledge of the code which you're touching is not strong, and my spare
> > reviewing capacity is not high.  And this work does need close review by
> > people who are familar with the code which you're changing.
> > 
> > So could I suggest that you go for a dig through the git history, identify
> > some individuals who look like they know this code, then do a resend,
> > cc'ing those people?  Please also cc linux-kernel on that resend.
> 
> OK.
> 
> > > One thing that is missing from this series is the ability to restrict
> > > user mounts to private namespaces.  The reason is that private
> > > namespaces have still not gained the momentum and support needed for
> > > painless user experience.  So such a feature would not yet get enough
> > > attention and testing.  However adding such an optional restriction
> > > can be done with minimal changes in the future, once private
> > > namespaces have matured.
> > 
> > I suspect the people who developed and maintain nsproxy would disagree ;)
> 
> Well, they better show me some working and simple-to-use userspace
> code, because I've not seen anything like that related to mount
> namespaces.

If you mean to test/exploit them, see
http://lxc.sourceforge.net/patches/2.6.20/2.6.20-lxc8/broken-out/tests/

Compile the ns_exec.c program and do

ns_exec -m /bin/sh

to get a shell in a new mounts namespace.

> pam_namespace.so is one example of a non-working, but probably-not-too-
> hard-to-fix one.

Non-working?  I sure hope the one used for LSPP certification is
working...  As is the ugly version I wrote 18 mounts ago and use on my
laptop.

> I'm just saying this is not yet something that Joe Blow would just
> enable by ticking a box in their desktop setup wizard, and it would
> all work flawlessly thereafter.  There's still a _long_ way towards
> that, and mostly in userspace.

I'm not sure there's a that long a way to go, but clearly we need to be
showing users what they can do, or they'll never work their way towards
there.

For instance, as you say, a user admin gui with a checkmark and text
boxes saying 'enter new namespace on login', 'create private /tmp',
and 'create private dmcrypted /home' would be trivial right now.

-serge
-
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: REISER4 FOR INCLUSION IN THE LINUX KERNEL.

[Matthew Wilcox]

On Sun, Apr 08, 2007 at 09:16:59PM -0700, [EMAIL PROTECTED] wrote:
> REISER4 FOR INCLUSION IN THE LINUX KERNEL.

Fuck off.  Cheerleading like this only hurts your cause.
-
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: REISER4 FOR INCLUSION IN THE LINUX KERNEL.

[Valdis . Kletnieks]

On Sun, 08 Apr 2007 21:39:12 PDT, [EMAIL PROTECTED] said:
> YOU GUYS WILL LAUGH ABOUT THIS:
> 
> I forgot the all the statistics that might support the sase for REISER4
> inclusion.
> 
> Well, here it all is:

*plonk* - The sound of a sender address entering a procmail /dev/null filter.

Come back when you're done doing the "nyah-nyeh I can't hear you" routine and
start paying attention when people point out crucial facts - like the fact
that Bonnie benchmarks that rely on compressing large files full of zeros
aren't relevant unless you're in the exceedingly small minority of users who
are interested in compressing large files full of zeros. Heck, I've had
systems where compression was interesting - but I'm willing to admit that 
it's somewhat a corner case.


pgpiXEoDYXLYk.pgp
Description: PGP signature

Re: REISER4 FOR INCLUSION IN THE LINUX KERNEL.

[Valdis . Kletnieks]

On Sun, 08 Apr 2007 21:16:59 PDT, [EMAIL PROTECTED] said:

> > I am not looking to defend Hans - he is likely to be in jail and no
> > longer a factor for a long time. Nor am I looking to make or support
> > claims for Reiser4.
> 
> Why not defend Hans? He is in jail on what appear to be trumped-up
> charges, just like the trumped-up complainants about his filesystem.

The charges certainly appear to be a lot more serious than "trumped-up".
All the same, I hope that Hans is accorded a fair trial and given a chance
to clear his name.

However, whether he's innocent or guilty, he *is* "out of play" for the
foreseeable future.  And "Where is the maintainer?" *is* a legitimate
question when contemplating including a large chunk of code in the kernel.
Hans is out of play, Namesys may or may not survive the loss of Hans, and
there isn't any signs of support outside Namesys.  So if it merges, who will
get stuck with supporting it?

(I won't bother replying to the rest of your conspiracy theories...)




pgpnelGbhMvHw.pgp
Description: PGP signature

Troll Of The Year (Was: REISER4 FOR INCLUSION IN THE LINUX KERNEL.)

[Ronni Nielsen]

[EMAIL PROTECTED] wrote:
[snip arguments FUBAR]


And the award as Troll Of The Year goes to: johnrobertbanks.


/ronni

+--+
|  PLEASE  |
|  DO NOT  |
| FEED THE |
|  TROLLS  |
+--+
   |  |
   |  |
 .\|.||/.. 




-
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: REISER4 FOR INCLUSION IN THE LINUX KERNEL.

[Pekka Enberg]

On 4/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

YOU GUYS WILL LAUGH ABOUT THIS:


No, I am crying actually. Dear post-masters, can we have this thread
shit-canned, please?
-
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: Reiser4. BEST FILESYSTEM EVER - Christer Weinigel

[Willy Tarreau]

On Sun, Apr 08, 2007 at 10:14:18PM -0700, [EMAIL PROTECTED] wrote:
> NO. You people simply come across as zealots who work together, against
> Reiser4.

Poor guy ! People are not against Reiser4, they are against the stupid and
irritating person who pollutes the lists always sending the same results
without any comment because he doesn't even understand the results. Just
like the kid on the beach "Look Ma, I found a soft shell!". "Leave it
overthere, it's a jellyfish !".  "I don't know what a jellyfish is, I will
take all those soft shells with me".

You keep saying people do not want to read you, but there is nothing to read.
In fact, you hope that people will comment on your results so that you will
finally understand them, but people keep saying there is nothing to read there.

When will you stop annoying people with your noisy toys ?

Oh, and please send your conspiracy claims somewhere else.

Willy

-
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