Hi Al
> -----Original Message-----
> From: Al Viro <viro@xxxxxxxxxxxxxxxx> On Behalf Of Al Viro
> Sent: Saturday, June 26, 2021 1:59 AM
> To: Justin He <Justin.He@xxxxxxx>
> Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>; Petr Mladek
> <pmladek@xxxxxxxx>; Steven Rostedt <rostedt@xxxxxxxxxxx>; Sergey
> Senozhatsky <senozhatsky@xxxxxxxxxxxx>; Andy Shevchenko
> <andriy.shevchenko@xxxxxxxxxxxxxxx>; Rasmus Villemoes
> <linux@xxxxxxxxxxxxxxxxxx>; Jonathan Corbet <corbet@xxxxxxx>; Heiko
> Carstens <hca@xxxxxxxxxxxxx>; Vasily Gorbik <gor@xxxxxxxxxxxxx>; Christian
> Borntraeger <borntraeger@xxxxxxxxxx>; Eric W . Biederman
> <ebiederm@xxxxxxxxxxxx>; Darrick J. Wong <darrick.wong@xxxxxxxxxx>; Peter
> Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>; Ira Weiny <ira.weiny@xxxxxxxxx>;
> Eric Biggers <ebiggers@xxxxxxxxxx>; Ahmed S. Darwish
> <a.darwish@xxxxxxxxxxxxx>; open list:DOCUMENTATION <linux-
> doc@xxxxxxxxxxxxxxx>; Linux Kernel Mailing List <linux-
> kernel@xxxxxxxxxxxxxxx>; linux-s390 <linux-s390@xxxxxxxxxxxxxxx>; linux-
> fsdevel <linux-fsdevel@xxxxxxxxxxxxxxx>
> 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:
> > --- 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);
> > + 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.
