Re: PowerPC: Random memory corruption causing kernel oops on Power11
From: Paul Moore <paul@paul-moore.com>
Date: 2026-05-29 18:25:01
Also in:
lkml, selinux
On Fri, May 29, 2026 at 12:11 PM Stephen Smalley [off-list ref] wrote:
On Fri, May 29, 2026 at 11:39 AM Paul Moore [off-list ref] wrote:quoted
On Fri, May 29, 2026 at 11:19 AM Stephen Smalley [off-list ref] wrote:quoted
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/20260529153608.30853-2-paul@paul-moore.com (local) 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.IIUC, __getname()/__putname() were originally internal helpers for getname()/putname() and allocated from names_cachep for struct filename. commit c3a3577cdb35 ("struct filename: use names_cachep only for getname() and friends") switched __getname()/__putname() over to just generic kmalloc/kfree so that other users of those helpers would stop allocating from names_cachep and noted that those lingering users could be converted to explicit kmalloc() over time. So I don't think vfs folks want new users of __getname()/__putname() but I could be wrong.
Whoever wants to submit a patch to do the conversion again should chase that down. -- paul-moore.com