On Mon, 2007-01-08 at 19:51 -0800, Andrew Morton wrote: > On Mon, 08 Jan 2007 21:38:05 -0600 > Eric Sandeen <[EMAIL PROTECTED]> wrote: > > > Andrew Morton wrote: > > > On Mon, 08 Jan 2007 21:12:40 -0600 > > > Eric Sandeen <[EMAIL PROTECTED]> wrote: > > > > > >> Andrew Morton wrote: > > >>> On Tue, 9 Jan 2007 10:47:28 +1100 > > >>> David Chinner <[EMAIL PROTECTED]> wrote: > > >>> > > >>>> On Mon, Jan 08, 2007 at 10:40:54AM -0600, Eric Sandeen wrote: > > >>>>> Sami Farin wrote: > > >>>>>> On Mon, Jan 08, 2007 at 08:37:34 +1100, David Chinner wrote: > > >>>>>> ... > > >>>>>>>> fstab was there just fine after -u. > > >>>>>>> Oh, that still hasn't been fixed? > > >>>>>> Looked like it =) > > >>>>> Hm, it was proposed upstream a while ago: > > >>>>> > > >>>>> http://lkml.org/lkml/2006/9/27/137 > > >>>>> > > >>>>> I guess it got lost? > > >>>> Seems like it. Andrew, did this ever get queued for merge? > > >>> Seems not. I think people were hoping that various nasties in there > > >>> would go away. We return to userspace with a kernel lock held?? > > >> Is a semaphore any worse than the current mutex in this respect? At > > >> least unlocking from another thread doesn't violate semaphore rules. :) > > > > > > I assume that if we weren't returning to userspace with a lock held, this > > > mutex problem would simply go away. > > > > > > > Well nobody's asserting that the filesystem must always be locked & > > unlocked by the same thread, are they? That'd be a strange rule to > > enforce upon the userspace doing the filesystem management wouldn't it? > > Or am I thinking about this wrong... > > I don't even know what code we're talking about here... > > I'm under the impression that XFS will return to userspace with a > filesystem lock held, under the expectation (ie: requirement) that > userspace will later come in and release that lock.
Its not really XFS, its more the generic device freezing code (freeze_bdev) which is called by both XFS and the device mapper suspend interface (both of which are exposed to userspace via ioctls). These interfaces are used when doing block level snapshots which are "filesystem coherent". > If that's not true, then what _is_ happening in there? This particular case was a device mapper stack trace, hence the confusion, I think. Both XFS and DM are making the same generic block layer call here though (freeze_bdev). > If that _is_ true then, well, that sucks a bit. Indeed, its a fairly ordinary interface, but thats too late to go fix now I guess (since its exposed to userspace already). A remount flag along the lines of readonly may have been a better way to go... perhaps. *shrug*... not clear - I guess the problem the original authors had there (whoever they were, I dunno), was that the block layer wants to call up to the filesystem to quiesce itself, and at some later user-defined point to unquiesce itself... which is a bit of a layering violation. >From a quick look, there seems to be a bug in the original patch - it is passing -EAGAIN back without wrapping it up in ERR_PTR(), which it needs to since freeze_bdev returns a struct super_block pointer. cheers. -- Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
