On Tue, Dec 12, 2023 at 9:08 PM Andrei Vagin <avagin@xxxxxxxxxx> wrote: > > Hi Amir, > > On Mon, Dec 11, 2023 at 9:51 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > > +fsdevel, +overlayfs, +brauner, +miklos > > > > On Mon, Dec 11, 2023 at 9:30 PM Andrei Vagin <avagin@xxxxxxxxxx> wrote: > > > > > > Device and inode numbers in /proc/pid/maps have to match numbers returned by > > > statx for the same files. > > > > That statement may be true for regular files. > > It is not true for block/char as far as I know. > > > > I think that your fix will break that by displaying the ino/dev > > of the block/char reference inode and not their backing rdev inode. > > I think it doesn't break anything here. /proc/pid/maps shows dev of a > filesystem where the device file resides. > > 7f336b6c3000-7f336b6c4000 rw-p 00000000 00:05 7 > /dev/zero > $ stat /dev/zero > Device: 0,5 Inode: 7 Links: 1 Device type: 1,5 > > I checked that it works with and without my patch. It doesn't matter, look at > the following comments. > > > > > > > > > /proc/pid/maps shows device and inode numbers of vma->vm_file-s. Here is > > > an issue. If a mapped file is on a stackable file system (e.g., > > > overlayfs), vma->vm_file is a backing file whose f_inode is on the > > > underlying filesystem. To show correct numbers, we need to get a user > > > file and shows its numbers. The same trick is used to show file paths in > > > /proc/pid/maps. > > > > For the *same* trick, see my patch below. > > The patch looks good to me. Thanks! Will you send it? > I can send it, if you want. I wouldn't mind if you send it with my Suggested-by though, as you are already testing it and posting the selftest. Thanks, Amir.
