On 12/30/21 2:24 PM, Al Viro wrote:
> On Thu, Dec 30, 2021 at 11:09:12AM -0800, Jens Axboe wrote:
>
>> For each command, there are two steps:
>>
>> - The prep of it, this happens inline from the system call where the
>> request, or requests, are submitted. The prep phase should ensure that
>> argument structs are stable. Hence a caller can prep a request and
>> have memory on stack, as long as it submits before it becomes invalid.
>> An example of that are iovecs for readv/writev. The caller does not
>> need to have them stable for the duration of the request, just across
>> submit. That's the io_${cmd}_prep() helpers.
>>
>> - The execution of it. May be separate from prep and from an async
>> worker. Where the lower layers don't support a nonblocking attempt,
>> they are always done async. The statx stuff is an example of that.
>>
>> Hence prep needs to copy from userland on the prep side always for the
>> statx family, as execution will happen out-of-line from the submission.
>>
>> Does that explain it?
>
> The actual call chain leading to filename_lookup() is, AFAICS, this:
> io_statx()
> do_statx()
> vfs_statx()
> user_path_at()
> user_path_at_empty()
> filename_lookup()
>
> If you are providing such warranties for the contents of pathname
> arguments, you have a bug in statx in the mainline. If you are not,
> there's no point in doing getname() in getxattr prep.
Not for the filename lookup, as I said it's for data passed in. There
are no guarantees on filename lookup, that happens when it gets
executed. See mentioned example on iovec and readv/writev.
--
Jens Axboe
