On Fri, May 29, 2026 at 12:11 PM Stephen Smalley <[email protected]> wrote: > On Fri, May 29, 2026 at 11:39 AM Paul Moore <[email protected]> wrote: > > On Fri, May 29, 2026 at 11:19 AM Stephen Smalley > > <[email protected]> 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/[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. > > 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
