Hi Al

-----Original Message-----
From: Al Viro <redacted> On Behalf Of Al Viro
Sent: Saturday, June 26, 2021 1:59 AM
To: Justin He <redacted>
Cc: Linus Torvalds <torvalds@linux-foundation.org>; Petr Mladek
[off-list ref]; Steven Rostedt [off-list ref]; Sergey
Senozhatsky [off-list ref]; Andy Shevchenko
[off-list ref]; Rasmus Villemoes
[off-list ref]; Jonathan Corbet [off-list ref]; Heiko
Carstens [off-list ref]; Vasily Gorbik [off-list ref]; Christian
Borntraeger [off-list ref]; Eric W . Biederman
[off-list ref]; Darrick J. Wong [off-list ref]; Peter
Zijlstra (Intel) [off-list ref]; Ira Weiny [off-list ref];
Eric Biggers [off-list ref]; Ahmed S. Darwish
[off-list ref]; open list:DOCUMENTATION <linux-
doc@vger.kernel.org>; Linux Kernel Mailing List <linux-
kernel@vger.kernel.org>; linux-s390 [off-list ref]; linux-
fsdevel [off-list ref]
Subject: Re: [PATCH 13/14] d_path: prepend_path() is unlikely to return
non-zero

On Fri, Jun 25, 2021 at 08:00:49AM +0000, Justin He wrote:

quoted

--- a/fs/d_path.c
+++ b/fs/d_path.c

@@ -210,6 +210,7 @@ static int prepend_path(const struct path *path,
        b = *p;
        read_seqbegin_or_lock(&rename_lock, &seq);
        error = __prepend_path(path->dentry, real_mount(path->mnt), root,

&b);

quoted

+       printk("prepend=%d",error);
        if (!(seq & 1))
                rcu_read_unlock();
        if (need_seqretry(&rename_lock, seq)) {

Then the result seems a little different:
root@entos-ampere-02:~# dmesg |grep prepend=1 |wc -l
7417
root@entos-ampere-02:~# dmesg |grep prepend=0 |wc -l
772

The kernel is 5.13.0-rc2+ + this series + my '%pD' series

Any thoughts?

On which loads?  1 here is "mount/dentry pair is in somebody
else's namespace or outside of the subtree we are chrooted
into".  IOW, what's calling d_path() on your setup?

No special loads, merely collecting the results after kernel boots up.

To narrow down, I tested your branch [1] *without* my '%pD' series:
[1] https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git/log/?h=work.d_path

The result is the same after kernel boots up.

The call trace are as follows:
The prepend_path returns 1:
  Call trace:
   prepend_path+0x144/0x340
   d_absolute_path+0x6c/0xb8
   aa_path_name+0x1c0/0x3d8
   profile_transition+0x90/0x908
   apparmor_bprm_creds_for_exec+0x914/0xaf0
   security_bprm_creds_for_exec+0x34/0x50
   bprm_execve+0x178/0x668
   do_execveat_common.isra.47+0x1b4/0x1c8
   __arm64_sys_execve+0x44/0x58
   invoke_syscall+0x54/0x110
   el0_svc_common.constprop.2+0x5c/0xe0
   do_el0_svc+0x34/0xa0
   el0_svc+0x20/0x30
   el0_sync_handler+0x88/0xb0
   el0_sync+0x148/0x180

The prepend_path returns 0:
  Call trace:
   prepend_path+0x144/0x340
   d_path+0x110/0x158
   proc_pid_readlink+0xbc/0x1b8
   vfs_readlink+0x14c/0x170
   do_readlinkat+0x134/0x168
   __arm64_sys_readlinkat+0x28/0x38
   invoke_syscall+0x54/0x110
   el0_svc_common.constprop.2+0x5c/0xe0
   do_el0_svc+0x34/0xa0
   el0_svc+0x20/0x30
   el0_sync_handler+0x88/0xb0
   el0_sync+0x148/0x180


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.