linux-kernel - Re: [PATCH] 9p: Avoid creating multiple slab caches with the same name

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8d09dcdc-b8bc-4d25-9afb-5eec8fb11a27@suse.cz>
Date: Mon, 21 Oct 2024 22:18:25 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Omar Sandoval <osandov@...ndov.com>
Cc: Dominique Martinet <asmadeus@...ewreck.org>,
 Thorsten Leemhuis <regressions@...mhuis.info>,
 Linus Torvalds <torvalds@...ux-foundation.org>,
 Eric Van Hensbergen <ericvh@...nel.org>,
 Christian Schoenebeck <linux_oss@...debyte.com>, v9fs@...ts.linux.dev,
 linux-kernel@...r.kernel.org, regressions@...ts.linux.dev,
 Jason Gunthorpe <jgg@...dia.com>, Pedro Falcato <pedro.falcato@...il.com>
Subject: Re: [PATCH] 9p: Avoid creating multiple slab caches with the same
 name

On 10/21/24 20:37, Omar Sandoval wrote:
> On Mon, Oct 21, 2024 at 10:42:02AM +0200, Vlastimil Babka wrote:
> 
> FYI, drgn's CI started getting EIO errors from
> getdents("/sys/kernel/slab") that I bisected to this patch. The problem
> is that dev_name can be an arbitrary string. In my case, it is
> "/dev/root". This trips verify_dirent_name(), which fails if a filename
> contains a slash.
> 
> This needs to use a different unique identifier. Maybe clnt->msize? But
> then the kmem_caches will need to be shared between different mounts
> using the same msize.

Yep, Dominique mentioned that here too:

https://lore.kernel.org/all/ZvBIl8b9RRK9jgtJ@codewreck.org/

And yes, slab has internal merging of compatible caches enabled by default.
But since it can be disabled, that would indeed result in duplicate names
again if 9p mounts didn't track and reuse caches with same msize accross
mounts on its own.

Linus's suggestion seems like the easiest fix for now.

> In any case, can this be reverted for now?
> 
> Thanks,
> Omar