On Fri, May 29, 2026 at 11:19 AM Stephen Smalley <[email protected]> wrote: > On Fri, May 29, 2026 at 11:02 AM Stephen Smalley > <[email protected]> wrote: > > On Fri, May 29, 2026 at 9:40 AM Venkat Rao Bagalkote > > <[email protected]> wrote: > > > > > > > > > On 29/05/26 12:20 pm, Venkat Rao Bagalkote wrote: > > > > Greetings!!! > > > > > > > > Kernel 7.1.0-rc5-next-20260528 crashes randomly on IBM Power11 > > > > hardware. Attached is the config file. > > > > > > > > **System:** > > > > - Hardware: IBM 9080-HEX Power11, pSeries > > > > - Broken: 7.1.0-rc5-next-20260528 > > > > - Config: 64K pages, Radix MMU > > > > > > > > > > > > **Problem:** > > > > Different crash at each reboot. > > > > > > > > > > > > **Example Crash 1:** > > > > > > > > [ 4.678016] BUG: Unable to handle kernel data access at > > > > 0xbffffffefec10628 > > > > [ 4.678112] NIP [c008000004e3c74c] > > > > xfs_dir2_block_lookup_int+0xd4/0x300 [xfs] > > > > [ 4.678281] [c000000005eaf7d0] [c008000004e3c6d4] > > > > xfs_dir2_block_lookup_int+0x5c/0x300 [xfs] > > > > [ 4.678363] [c000000005eaf850] [c008000004e3d56c] > > > > xfs_dir2_block_lookup+0x44/0x1e0 [xfs] > > > > > > > > > > > > **Example Crash 2:** > > > > > > > > [ 6.327116] BUG: Unable to handle kernel data access at > > > > 0x762f736563697695 > > > > [ 6.327242] NIP [c00000000073cf34] __refill_obj_stock+0x74/0x2c0 > > > > [ 6.327261] [c0000013ffdbfd10] [c0000000007418b8] > > > > obj_cgroup_uncharge+0x48/0x70 > > > > [ 6.327271] [c0000013ffdbfd50] [c00000000062fffc] > > > > free_percpu.part.0+0x12c/0x630 > > > > > > > > > > > > > > Git bisect is pointing to 54067bacb49c selinux: hooks: use __getname() > > > to allocate path buffer as the first bad commit. > > > > > > > > > # git bisect good > > > 54067bacb49caeada82b20b6bd706dca0cb99ffc is the first bad commit > > > commit 54067bacb49caeada82b20b6bd706dca0cb99ffc > > > Author: Mike Rapoport (Microsoft) <[email protected]> > > > Date: Wed May 20 11:18:56 2026 +0300 > > > > > > selinux: hooks: use __getname() to allocate path buffer > > > > > > selinux_genfs_get_sid() allocates memory for a path with > > > __get_free_page() > > > although there is a dedicated helper for allocation of file paths: > > > __getname(). > > > > > > Replace __get_free_page() for allocation of a path buffer with > > > __getname(). > > > > > > Signed-off-by: Mike Rapoport (Microsoft) <[email protected]> > > > Signed-off-by: Paul Moore <[email protected]> > > > > > > security/selinux/hooks.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-)
... > > > > If you happen to fix this, please add below tag. > > > > > > > > Reported-by: Venkat Rao Bagalkote <[email protected]> > > > > IMHO that commit should be reverted: > > __getname()/__putname() exist for a different purpose IIUC. > > __getname() does a kmalloc(PATH_MAX...), whereas we are then calling > > dentry_path_raw(..., PAGE_SIZE) immediately afterward. > > This assumes that PATH_MAX == PAGE_SIZE. > > Alternatively, I suppose we could just update the dentry_path_raw() > call to also pass PATH_MAX, but > I don't see why we want to use __getname/__putname() instead of just > direct kmalloc/kfree here so > the size of the buffer is immediately evident to the reader. It's reverted, see the posting below: https://lore.kernel.org/selinux/[email protected] I think there is still value in using __getname()/__putname() here as opposed to a simple kmalloc()/kfree() pairing, but either way we need to adjust the buffer length in selinux_genfs_get_sid() accordingly to use PATH_MAX instead of PAGE_SIZE. -- paul-moore.com
