[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181114160600.GD13885@redhat.com>
Date: Wed, 14 Nov 2018 17:06:01 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Ravi Bangoria <ravi.bangoria@...ux.ibm.com>
Cc: srikar@...ux.vnet.ibm.com, rostedt@...dmis.org,
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()
On 11/14, Ravi Bangoria wrote:
>
> syzbot reported a kernel crash with delayed_uprobe_remove():
> https://lkml.org/lkml/2018/11/1/1244
>
> Backtrace mentioned in the link points to a race between process
> exit and uprobe_unregister(). Fix it by locking delayed_uprobe_lock
> before calling delayed_uprobe_remove() from put_uprobe().
The patch looks good to me, but could you update the changelog?
Please explain that the exiting task calls uprobe_clear_state() which
can race with delayed_uprobe_remove(). IIUC this is the only problem
solved by this patch, right?
Oleg.
Powered by blists - more mailing lists