Hi,
On Wed, 2005-08-24 at 22:03, Glauber de Oliveira Costa wrote:
> This simple patch provides a fix for a locking issue found in the online
> resizing code. The problem actually happened while trying to resize the
> filesystem trough the resize=xxx option in a remount.
NAK, this is wrong:
> + lock_super(sb);
> err = ext3_group_extend(sb, EXT3_SB(sb)->s_es, n_blocks_count);
> + unlock_super(sb);
This basically reverses the order of locking between lock_super() and
journal_start() (the latter acts like a lock because it can block on a
resource if the journal is too full for the new transaction.) That's
the opposite order to normal, and will result in a potential deadlock.
> + {Opt_resize, "resize=%u"},
> {Opt_err, NULL},
> - {Opt_resize, "resize"},
Right, that's disabled for now. I guess the easy fix here is just to
remove the code entirely, given that we have locking problems with
trying to fix it!
But the _right_ fix, if you really want to keep that code, is probably
to move all the resize locking to a separate lock that ranks outside the
journal_start. The easy workaround is to drop the superblock lock and
reaquire it around the journal_start(); it would be pretty easy to make
that work robustly as far as ext3 is concerned, but I suspect there may
be VFS-layer problems if we start dropping the superblock lock in the
middle of the s_ops->remount() call --- Al?
--Stephen
-
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/
