Messages in this thread | | | From | Dmitry Vyukov <> | Date | Fri, 29 Jul 2022 14:31:01 +0200 | Subject | Re: [syzbot] WARNING in p9_client_destroy |
| |
On Tue, 26 Jul 2022 at 14:10, Christian Schoenebeck <linux_oss@crudebyte.com> wrote: > > On Montag, 25. Juli 2022 14:45:08 CEST Dmitry Vyukov wrote: > > On Mon, 25 Jul 2022 at 13:51, <asmadeus@codewreck.org> 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@google.com> > > > > > 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.
Yes, I meant providing allocation stacks for leaked objects. Filed https://bugzilla.kernel.org/show_bug.cgi?id=216306 for this feature.
| |