On Fri, Nov 22, 2019 at 09:19:21PM -0800, Alexei Starovoitov wrote: > hard to tell. It will be run out of bpf prog that attaches to kprobe or > tracepoint. What is the concern about locking? > d_path() doesn't take any locks and doesn't depend on any locks. Above 'if' > checks that plain d_path() is used and not some specilized callback with > unknown logic. It sure as hell does. It might end up taking rename_lock and/or mount_lock spinlock components. It'll try not to, but if the first pass ends up with seqlock mismatch, it will just grab the spinlock the second time around. > > with this number; quite possibly never before that function had been called > > _and_ not once after it has returned. > > Right. TOCTOU is not a concern here. It's tracing. It's ok for full path to be > 'one time deal'. It might very well be a full path of something completely unrelated to what the syscall ends up operating upon. It's not that the file might've been moved; it might be a different file. IOW, results of that tracing might be misleading.
