[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200709031842.l83Ig719014512@agora.fsl.cs.sunysb.edu>
Date: Mon, 3 Sep 2007 14:42:07 -0400
From: Erez Zadok <ezk@...sunysb.edu>
To: Al Boldi <a1426z@...ab.com>
Cc: Erez Zadok <ezk@...sunysb.edu>,
"Josef 'Jeff' Sipek" <jsipek@...sunysb.edu>,
akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, hch@...radead.org,
viro@....linux.org.uk, bharata@...ux.vnet.ibm.com,
j.blunck@...harburg.de
Subject: Re: [GIT PULL -mm] Unionfs/fsstack/eCryptfs updates/cleanups/fixes
In message <200709032126.47232.a1426z@...ab.com>, Al Boldi writes:
> Erez Zadok wrote:
> > Al, we have back-ports of the latest Unionfs to 2.6.{22,21,20,19,18,9},
> > all in http://unionfs.filesystems.org/. Before we release any change, we
> > test it on all back-ports as well as the latest -rc/-mm code base (takes
> > over 24 hours straight to get through all of our regressions :-)
>
> I am impressed, thanks!
You're welcome.
> It's probably a good idea to always point these backports out, whenever
> submitting patches against -mm. Otherwise, people might forget.
Good idea.
> > So we'd be happy to submit those patches to the latest stable kernel.
> > But, are you talking about VFS/ecryptfs patches (which are in the stable
> > kernel), or are you talking about Unionfs (which is not)?
>
> I'm talking about Unionfs, which seems like a rather critical feature to
> miss-out on.
Hmmm, we'll have to discuss this among the unionfs developers first.
> BTW, did you ever get that oops-on-umount worked out?
Which bug? Is that something anyone submitted to our
https://bugzilla.filesystems.org? I don't recall such a bug in a while, so
if it got fixed, it must've been a while back. If it's still there and
reproducible, please let me know asap so I can work on it.
It is possible that the bug is in the -mm code. That's why we just posted
the long series of Unionfs patches: those patches represent more than four
months of intense hardening and testing. Some of the bugs we've fixed had
to do with improper refcounting (esp. mnt refcounting, which, if not
perfect, either causes an EBUSY on unmount or an oops on unmount :-)
> Thanks!
>
> --
> Al
Erez.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists