Hi,
On Wed, 2005-08-31 at 12:35, Glauber de Oliveira Costa wrote:
> At a first look, i thought about locking gdt-related data. But in a
> closer one, it seemed to me that we're in fact modifying a little bit
> more than that in the resize code. But all these modifications seem to
> be somehow rel
>
> The two different uses of the superblock lock are really quite
> different; I don't see any particular problem with using two different
> locks for the two different things. Mount and the namespace code are
> not locking the same thing --- the fact that the resize code uses the
> superblock l
Hi,
On Thu, 2005-08-25 at 21:43, Glauber de Oliveira Costa wrote:
> Just a question here. With s_lock held by the remount code, we're
> altering the struct super_block, and believing we're safe. We try to
> acquire it inside the resize functions, because we're trying to modify
> this same data.
> 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 beca
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:
> +
5 matches
Mail list logo
