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 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 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
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 cal
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 o
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 reference.
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. Consequently, we need to
explicitly hold a reference to ensure that t
8 matches
Mail list logo
