Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > On Wed, Apr 28, 2021 at 11:40 PM Rasmus Villemoes > <linux@xxxxxxxxxxxxxxxxxx> wrote: >> >> > That also does explain the arguably odd %pD defaults: %pd came first, >> > and then %pD came afterwards. >> >> Eh? 4b6ccca701ef5977d0ffbc2c932430dea88b38b6 added them both at the same >> time. > > Ahh, I looked at "git blame", and saw that file_dentry_name() was > added later. But that turns out to have been an additional fix on top, > not actually "later support". > > Looking more at that code, I am starting to think that > "file_dentry_name()" simply shouldn't use "dentry_name()" at all. > Despite that shared code origin, and despite that similar letter > choice (lower-vs-upper case), a dentry and a file really are very very > different from a name standpoint. > > And it's not the "a filename is the whale pathname, and a dentry has > its own private dentry name" issue. It's really that the 'struct file' > contains a _path_ - which is not just the dentry pointer, but the > 'struct vfsmount' pointer too. > > So '%pD' really *could* get the real path right (because it has all > the required information) in ways that '%pd' fundamentally cannot. > > At the same time, I really don't like printk specifiers to take any > real locks (ie mount_lock or rename_lock), so I wouldn't want them to > use the full d_path() logic. Well prepend_path the core of d_path, which is essentially the logic I think you are suggesting to use does: read_seqbegin_or_lock(&mount_lock, ...); read_seqbegin_or_lock(&rename_lock, ...); A printk specific variant could easily be modified to always restart or to simply ignore renames and changes to the mount tree. There are always the corner cases when there is no sensible full path to display. A rename or a mount namespace operation could be handled like one of those. Eric
