Re: PowerPC: Random memory corruption causing kernel oops on Power11

[Paul Moore]

On Fri, May 29, 2026 at 12:11 PM Stephen Smalley
<stephen.smalley.work@xxxxxxxxx> wrote:
> On Fri, May 29, 2026 at 11:39 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> > On Fri, May 29, 2026 at 11:19 AM Stephen Smalley
> > <stephen.smalley.work@xxxxxxxxx> wrote:
> > > 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@xxxxxxxxxxxxxx
> >
> > 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