On Mon, Jan 14, 2008 at 12:59:39PM +, Al Viro wrote:
> I really don't like the entire scheme, to be honest. BTW, what happens
> if you try to add the same device to the same array after having it kicked
> out? If that comes before your delayed kobject_del(), the things will
> get nasty
On Mon, Jan 14, 2008 at 05:28:44PM +1100, Neil Brown wrote:
> On Monday January 14, [EMAIL PROTECTED] wrote:
> >
> > Thanks. I'll see what I can some up with.
>
> How about this, against current -mm
>
> On both the read and write path for an rdev attribute, we
> call mddev_lock, first checking
On Mon, Jan 14, 2008 at 05:28:44PM +1100, Neil Brown wrote:
On Monday January 14, [EMAIL PROTECTED] wrote:
Thanks. I'll see what I can some up with.
How about this, against current -mm
On both the read and write path for an rdev attribute, we
call mddev_lock, first checking that
On Mon, Jan 14, 2008 at 12:59:39PM +, Al Viro wrote:
I really don't like the entire scheme, to be honest. BTW, what happens
if you try to add the same device to the same array after having it kicked
out? If that comes before your delayed kobject_del(), the things will
get nasty since
On Monday January 14, [EMAIL PROTECTED] wrote:
>
> Thanks. I'll see what I can some up with.
How about this, against current -mm
On both the read and write path for an rdev attribute, we
call mddev_lock, first checking that mddev is not NULL.
Once we get the lock, we check again.
If
On Monday January 14, [EMAIL PROTECTED] wrote:
> On Mon, Jan 14, 2008 at 02:21:45PM +1100, Neil Brown wrote:
>
> > Maybe it isn't there any more
> >
> > Once upon a time, when I
> >echo remove > /sys/block/mdX/md/dev-YYY/state
>
> Egads. And just what will protect you from parallel
On Mon, Jan 14, 2008 at 02:21:45PM +1100, Neil Brown wrote:
> Maybe it isn't there any more
>
> Once upon a time, when I
>echo remove > /sys/block/mdX/md/dev-YYY/state
Egads. And just what will protect you from parallel callers
of state_store()? buffer->mutex does *not* do that - it
On Monday January 14, [EMAIL PROTECTED] wrote:
> On Mon, Jan 14, 2008 at 12:45:31PM +1100, NeilBrown wrote:
> >
> > Due to possible deadlock issues we need to use a schedule work to
> > kobject_del an 'rdev' object from a different thread.
> >
> > A recent change means that kobject_add no longer
On Mon, Jan 14, 2008 at 12:45:31PM +1100, NeilBrown wrote:
>
> Due to possible deadlock issues we need to use a schedule work to
> kobject_del an 'rdev' object from a different thread.
>
> A recent change means that kobject_add no longer gets a refernce, and
> kobject_del doesn't put a
On Mon, Jan 14, 2008 at 12:45:31PM +1100, NeilBrown wrote:
Due to possible deadlock issues we need to use a schedule work to
kobject_del an 'rdev' object from a different thread.
A recent change means that kobject_add no longer gets a refernce, and
kobject_del doesn't put a reference.
On Monday January 14, [EMAIL PROTECTED] wrote:
On Mon, Jan 14, 2008 at 12:45:31PM +1100, NeilBrown wrote:
Due to possible deadlock issues we need to use a schedule work to
kobject_del an 'rdev' object from a different thread.
A recent change means that kobject_add no longer gets a
On Mon, Jan 14, 2008 at 02:21:45PM +1100, Neil Brown wrote:
Maybe it isn't there any more
Once upon a time, when I
echo remove /sys/block/mdX/md/dev-YYY/state
Egads. And just what will protect you from parallel callers
of state_store()? buffer-mutex does *not* do that - it only
On Monday January 14, [EMAIL PROTECTED] wrote:
On Mon, Jan 14, 2008 at 02:21:45PM +1100, Neil Brown wrote:
Maybe it isn't there any more
Once upon a time, when I
echo remove /sys/block/mdX/md/dev-YYY/state
Egads. And just what will protect you from parallel callers
of
On Monday January 14, [EMAIL PROTECTED] wrote:
Thanks. I'll see what I can some up with.
How about this, against current -mm
On both the read and write path for an rdev attribute, we
call mddev_lock, first checking that mddev is not NULL.
Once we get the lock, we check again.
If rdev-mddev
14 matches
Mail list logo
