lkml.org 
[lkml]   [2005]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: UDF madness
On Thu, Jan 27, 2005 at 09:30:04AM +0000, Stephen C. Tweedie wrote:
> Hi,
>
> On Thu, 2005-01-27 at 07:57, Al Viro wrote:
>
> > Note that fs users of file_fsync() are definitely not going to be
> > involved into contention here - they need opened file => held active
> > reference to superblock.
>
> > So we are left only with fs-internal asynchronous callers of
> > lock_super(). UDF, UFS, sysv, hpfs and ext2 are out of question - they
> > don't have async callers of that sort. ext3... maybe, I'm not familiar
> > with resize code in there. In any case, that'd better be fixed in
> > ext3 if such abuse exists.
>
> ext3 resize is like file_fsync() --- it's an ioctl, so there's a
> guaranteed open file at that point.
>
> But while the resize code originally used lock_super() to protect from
> races against allocation/deallocation, the ordering fixes in it means
> that that's all safe anyway now. The lock_super() is currently only
> really used to guard against two threads doing resize at the same time,
> and if it's a problem, it would be trivial to use a different lock.

That's fine - it does make sense to move to separate lock, but in any
case we are safe against generic_shutdown_super(). And it means that
at least there (which is the source of UDF problems) lock_super() can die.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:09    [W:0.039 / U:0.744 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site