On 11/2/20 12:27 PM, Eric W. Biederman wrote: > Jens Axboe <axboe@xxxxxxxxx> writes: > >> On 10/30/20 4:22 PM, Al Viro wrote: >>> On Fri, Oct 30, 2020 at 02:33:11PM -0600, Jens Axboe wrote: >>>> On 10/30/20 12:49 PM, Al Viro wrote: >>>>> On Fri, Oct 30, 2020 at 12:46:26PM -0600, Jens Axboe wrote: >>>>> >>>>>> See other reply, it's being posted soon, just haven't gotten there yet >>>>>> and it wasn't ready. >>>>>> >>>>>> It's a prep patch so we can call do_renameat2 and pass in a filename >>>>>> instead. The intent is not to have any functional changes in that prep >>>>>> patch. But once we can pass in filenames instead of user pointers, it's >>>>>> usable from io_uring. >>>>> >>>>> You do realize that pathname resolution is *NOT* offloadable to helper >>>>> threads, I hope... >>>> >>>> How so? If we have all the necessary context assigned, what's preventing >>>> it from working? >>> >>> Semantics of /proc/self/..., for starters (and things like /proc/mounts, etc. >>> *do* pass through that, /dev/stdin included) >> >> Don't we just need ->thread_pid for that to work? > > No. You need ->signal. > > You need ->signal->pids[PIDTYPE_TGID]. It is only for /proc/thread-self > that ->thread_pid is needed. > > Even more so than ->thread_pid, it is a kernel invariant that ->signal > does not change. I don't care about the pid itself, my suggestion was to assign ->thread_pid over the lookup operation to ensure that /proc/self/ worked the way that you'd expect. -- Jens Axboe
