[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080114125939.GP27894@ZenIV.linux.org.uk>
Date: Mon, 14 Jan 2008 12:59:39 +0000
From: Al Viro <viro@...IV.linux.org.uk>
To: Neil Brown <neilb@...e.de>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-raid@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 002 of 6] md: Fix use-after-free bug when dropping an rdev from an md array.
On Mon, Jan 14, 2008 at 05:28:44PM +1100, Neil Brown wrote:
> On Monday January 14, neilb@...e.de 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 is not NULL, we know it will stay that way as it only
> gets cleared under the same lock.
>
> While in the rdev show/store routines, we know that the mddev cannot
> get freed, do to the kobject relationships.
>
> rdev_size_store is awkward because it has to drop the lock. So we
> take a copy of rdev->mddev before the drop, and we are safe...
>
> Comments?
*cringe*
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 sysfs will (rightfully) refuse to add another entry with
the same name and parent while the old one is still there and for all
sysfs knows is going to stay there...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists