[Top] [All Lists]

[PATCH][2.6.0-test1] redesign - stack corruption in devfs_lookup

To: Andrew Morton <akpm@xxxxxxxx>
Subject: [PATCH][2.6.0-test1] redesign - stack corruption in devfs_lookup
From: Andrey Borzenkov <arvidjaar@xxxxxxx>
Date: Sat, 26 Jul 2003 18:58:24 +0400
Cc: linux-kernel@xxxxxxxxxxxxxxx, devfs@xxxxxxxxxxx
In-reply-to: <20030706120315.261732bb.akpm@xxxxxxxx>
References: <E198K0q-000Am8-00.arvidjaar-mail-ru@xxxxxxxxxxx> <200307062058.40797.arvidjaar@xxxxxxx> <20030706120315.261732bb.akpm@xxxxxxxx>
Sender: devfs-bounce@xxxxxxxxxxx
User-agent: KMail/1.5
On Sunday 06 July 2003 23:03, Andrew Morton wrote:
> Andrey Borzenkov <arvidjaar@xxxxxxx> wrote:
> > When devfs_lookup needs to call devfsd it arranges for other lookups for
> > the same name to wait. It is using local variable as wait queue head.
> > After devfsd returns devfs_lookup wakes up all waiters and returns.
> > Unfortunately there is no garantee all waiters will actually get chance
> > to run and clean up before devfs_lookup returns. so some of them attempt
> > to access already freed storage on stack.
> OK, but I think there is a simpler fix.  We can rely on the side-effects of
> prepare_to_wait() and finish_wait().

and here is even more simple fix. there is no need to ever bother about wait 
queue because it dies soon without our intervention. This is exactly what 
code in 2.4 does - somebody "improved" code in 2.5 (again) :(

the patch against 2.6.0-test1 removes my previous patch and adds comment in 
revalidate_wait to prevent it from hapenning again. It is basically 2.4 code 
except one spinlock acquisition has been moved a bit earlier (probably does 
not matter just looks better). This probably should use wake_up_all instead 
of wake_up to make intention more clear.

It is tested using the same test case. Also 2.4 never had this problem as 


Attachment: 2.6.0-test1-devfs_stack_corruption-3.patch
Description: Text Data

<Prev in Thread] Current Thread [Next in Thread>