Re: [RFC][PATCH] getname_maybe_null() - the third variant of pathname copy-in

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Oct 09, 2024 at 05:03:16AM +0100, Al Viro wrote:
> [
> in #work.getname; if nobody objects, I'm going to make #work.xattr pull that.
> IMO it's saner than hacks around vfs_empty_path() and it does very similar
> logics - with simpler handling on the caller side.
> ]
> 
> Semantics used by statx(2) (and later *xattrat(2)): without AT_EMPTY_PATH
> it's standard getname() (i.e. ERR_PTR(-ENOENT) on empty string,
> ERR_PTR(-EFAULT) on NULL), with AT_EMPTY_PATH both empty string and
> NULL are accepted.
>     
> Calling conventions: getname_maybe_null(user_pointer, flags) returns
> 	* pointer to struct filename when non-empty string had been
> successfully read
> 	* ERR_PTR(...) on error
> 	* NULL if an empty string or NULL pointer had been given
> with AT_EMPTY_FLAGS in the flags argument.
> 
> It tries to avoid allocation in the last case; it's not always
> able to do so, in which case the temporary struct filename instance
> is freed and NULL returned anyway.
> 
> Fast path is inlined.
> 
> Signed-off-by: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
> --- 

Looks good.

Fyi, I'm using your #base.getname as a base for some other work that I'm
currently doing. So please don't rebase #base.getname anymore. ;)

Since you have your #work.xattr and #work.stat using it as base it seems
pretty unlikely anyway but I just thought I mention explicitly that I'm
relying on that #base.getname branch.




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux