Re: [syzbot] WARNING in p9_client_destroy
From: Christian Schoenebeck
Date: Tue Jul 26 2022 - 08:10:08 EST
On Montag, 25. Juli 2022 14:45:08 CEST Dmitry Vyukov wrote:
> On Mon, 25 Jul 2022 at 13:51, <asmadeus@xxxxxxxxxxxxx> wrote:
> > Vlastimil Babka wrote on Mon, Jul 25, 2022 at 12:15:24PM +0200:
> > > On 7/24/22 15:17, syzbot wrote:
> > > > syzbot has bisected this issue to:
> > > >
> > > > commit 7302e91f39a81a9c2efcf4bc5749d18128366945
> > > > Author: Marco Elver <elver@xxxxxxxxxx>
> > > > Date: Fri Jan 14 22:03:58 2022 +0000
> > > >
> > > > mm/slab_common: use WARN() if cache still has objects on destroy
> > >
> > > Just to state the obvious, bisection pointed to a commit that added the
> > > warning, but the reason for the warning would be that p9 is destroying a
> > > kmem_cache without freeing all the objects there first, and that would
> > > be
> > > true even before the commit.
> >
> > Probably true from the moment that cache/idr was introduced... I've got
> > a couple of fixes in next but given syzcaller claims that's the tree it
> > was produced on I guess there can be more such leaks.
> > (well, the lines it sent in the backtrace yesterday don't match next,
> > but I wouldn't count on it)
> >
> > If someone wants to have a look please feel free, I would bet the
> > problem is just that p9_fd_close() doesn't call or does something
> > equivalent to p9_conn_cancel() and there just are some requests that
> > haven't been sent yet when the mount is closed..
> > But I don't have/can/want to take the time to check right now as I
> > consider such a leak harmless enough, someone has to be root or
> > equivalent to do 9p mounts in most cases.
>
> FWIW with KASAN we have allocation stacks for each heap object. So
> when KASAN is enabled that warning could list all live object
> allocation stacks.
With allocation stack you mean the backtrace/call stack at the point in time
when the memory originally was acquired?
If the answer is yes, then sure, if someone had a chance to post those
backtraces, then that would help us to take a closer look at where this leak
might happen. Otherwise I fear it will end up among those other "lack of
priority" issues.
Best regards,
Christian Schoenebeck