[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <9f73b926-b3a5-2519-3a9e-91de35899a6e@linux.ibm.com>
Date: Mon, 3 Dec 2018 11:52:41 +0530
From: Ravi Bangoria <ravi.bangoria@...ux.ibm.com>
To: rostedt@...dmis.org
Cc: Oleg Nesterov <oleg@...hat.com>, srikar@...ux.vnet.ibm.com,
mhiramat@...nel.org, liu.song.a23@...il.com, peterz@...radead.org,
mingo@...hat.com, acme@...nel.org,
alexander.shishkin@...ux.intel.com, jolsa@...hat.com,
namhyung@...nel.org, linux-kernel@...r.kernel.org,
ananth@...ux.vnet.ibm.com, alexis.berlemont@...il.com,
naveen.n.rao@...ux.vnet.ibm.com,
linux-arm-kernel@...ts.infradead.org, linux-mips@...ux-mips.org,
linux@...linux.org.uk, ralf@...ux-mips.org, paul.burton@...s.com
Subject: Re: [PATCH] Uprobes: Fix kernel oops with delayed_uprobe_remove()
Hi Steve,
Please pull this patch.
Thanks.
On 11/15/18 6:13 PM, Oleg Nesterov wrote:
> On 11/15, Ravi Bangoria wrote:
>>
>> There could be a race between task exit and probe unregister:
>>
>> exit_mm()
>> mmput()
>> __mmput() uprobe_unregister()
>> uprobe_clear_state() put_uprobe()
>> delayed_uprobe_remove() delayed_uprobe_remove()
>>
>> put_uprobe() is calling delayed_uprobe_remove() without taking
>> delayed_uprobe_lock and thus the race sometimes results in a
>> kernel crash. Fix this by taking delayed_uprobe_lock before
>> calling delayed_uprobe_remove() from put_uprobe().
>>
>> Detailed crash log can be found at:
>> https://lkml.org/lkml/2018/11/1/1244
>
> Thanks, looks good,
>
> Oleg.
>
Powered by blists - more mailing lists