On Mon, Nov 10, 2025 at 12:52:57PM -0800, Linus Torvalds wrote: > On Mon, 10 Nov 2025 at 11:58, Al Viro <[email protected]> wrote: > > > > If we go that way, do you see any problems with treating > > osf_{ufs,cdfs}_mount() in the same manner? Yes, these are pathnames, > > Hmm. In those cases, the ENAMETOOLONG thing actually does make sense - > exactly because they are pathnames. > > So I think that in those two places using getname() is fairly natural > and gets us the natural error handling too. No?
Seeing that we don't do that for native mount(2)... Hell knows - the thing is, import is done early in syscall, before we know what does that particular filesystem type expect. It's not always a pathname of any sort. Note that empty string for the first argument of mount(2) is perfectly fine - for some values of the 5th (flags) and 3rd (type) ones. So plain getname() is not an option and we do, unfortunately, need the sucker imported before we start parsing the flags, etc. I'd love to take security_sb_mount() - it's an utter shitshow of API, inherently racy, etc., but currently it takes a kernelspace string for the first argument (dev_name) and is called before we'd even started to look at flags (so the instances have to essentially duplicate flags parsing, among other things). But that's a lot of massage and it will require the LSM crowd acceptance ;-/ If earlier attempts are anything to go by, there will be a lot of resistance. BTW, take a look at apparmor_sb_mount() and aa_bind_mount(). Compare the calls of kern_path() in aa_bind_mount() and in do_loopback() and note that the damn thing relies upon both pathwalks resolving to the same location...
