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
>
> 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
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 lock
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
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.
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
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:
>
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:
+
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
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.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
diff -up
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.
Signed-off-by: Glauber de Oliveira Costa [EMAIL PROTECTED]
diff -up
12 matches
Mail list logo
