I have just applied a patch fixing it. Now depending on which filesystem OSv runs we get same or different major:minor:
./scripts/manifest_from_host.sh -w cat && ./scripts/build -j4 fs=rofs --append-manifest && ./scripts/run.py -e '/cat /proc/self/maps' ... OSv v0.53.0-43-gef0696c5 eth0: 192.168.122.15 Booted up in 137.34 ms 0-0 ---p 00000000 00:00 0 100000000000-100000001000 r--p 00000000 00:00 3 /libvdso.so 100000001000-100000002000 r-xp 00001000 00:00 3 /libvdso.so 100000002000-100000003000 r--p 00002000 00:00 3 /libvdso.so 100000003000-100000004000 r--p 00002000 00:00 3 /libvdso.so 100000004000-100000005000 rw-p 00003000 00:00 3 /libvdso.so 100000005000-100000007000 r--p 00000000 00:00 6 /cat 100000007000-10000000c000 r-xp 00002000 00:00 6 /cat 10000000c000-10000000e000 r--p 00007000 00:00 6 /cat 10000000f000-100000010000 r--p 00009000 00:00 6 /cat 100000010000-100000011000 rw-p 0000a000 00:00 6 /cat 200000000000-200000001000 ---p 00000000 00:00 0 200000001000-200000100000 rw-p 00000000 00:00 0 200000100000-200000101000 ---p 00000000 00:00 0 200000101000-200000200000 rw-p 00000000 00:00 0 800000000000-800000000000 ---p 00000000 00:00 0 ZFS: ./scripts/manifest_from_host.sh -w cat && ./scripts/build -j4 fs=zfs --append-manifest && ./scripts/run.py -e '/cat /proc/self/maps' ... OSv v0.53.0-43-gef0696c5 eth0: 192.168.122.15 Booted up in 425.54 ms 0-0 ---p 00000000 00:00 0 100000062000-100000063000 r--p 00000000 ccdc54:48c1440c 9 /libvdso.so 100000063000-100000064000 r-xp 00001000 ccdc54:48c1440c 9 /libvdso.so 100000064000-100000065000 r--p 00002000 ccdc54:48c1440c 9 /libvdso.so 100000065000-100000066000 r--p 00002000 ccdc54:48c1440c 9 /libvdso.so 100000066000-100000067000 rw-p 00003000 ccdc54:48c1440c 9 /libvdso.so 100000067000-100000069000 r--p 00000000 ccdc54:48c1440c 29 /cat 100000069000-10000006e000 r-xp 00002000 ccdc54:48c1440c 29 /cat 10000006e000-100000070000 r--p 00007000 ccdc54:48c1440c 29 /cat 100000071000-100000072000 r--p 00009000 ccdc54:48c1440c 29 /cat 100000072000-100000073000 rw-p 0000a000 ccdc54:48c1440c 29 /cat 200000000000-200000001000 ---p 00000000 00:00 0 200000001000-200000100000 rw-p 00000000 00:00 0 200000100000-200000101000 ---p 00000000 00:00 0 200000101000-200000200000 rw-p 00000000 00:00 0 800000000000-800000000000 ---p 00000000 00:00 0 I am not 100% our logic to calculate st_dev is correct here - https://github.com/cloudius-systems/osv/blob/master/fs/vfs/vfs_vnode.cc#L351-L359. I do not know what va_fsid represents but it does not seem to encode major:minor for the corresponding device. Waldek On Monday, July 1, 2019 at 12:42:31 PM UTC-4, Nadav Har'El wrote: > > On Mon, Jul 1, 2019 at 7:26 AM Waldek Kozaczuk <jwkoz...@gmail.com > <javascript:>> wrote: > >> Also where would I get the values for this xx:yy pair from? >> >> On Sunday, June 30, 2019 at 7:37:09 AM UTC-4, Waldek Kozaczuk wrote: >>> >>> We could. But that could be a separate patch. For now I do not care >>> about it. >>> >> >>> Do you have strong objections to commit this patch without the >>> device-I’d? It is enough to fix my GraalVM example. >>> >> > No, no strong objection. I committed your patch. I was just curious why > fixing half of these nonsense zeros would help anything. > > The xx:yy pair is the major and minor numbers of the device. The same > stat() which returns the inode number also has > > dev_t st_dev; > > and there are major() and minor() functions to split this single device id > into "major" and "minor" parts. > > The idea is that inode numbers are unique in a single device, but not > necessarily across different devices (e.g., two disk drives), so the inode > number alone is not enough. > > > >>> Sent from my iPhone >>> >>> On Jun 30, 2019, at 04:34, Nadav Har'El <n...@scylladb.com <javascript:>> >>> wrote: >>> >>> Looks good to me, but I wonder, together with the inode, shouldn't we >>> also save the device id, so we can print that too (that is the 00:00 we >>> print now)? >>> >>> -- >>> Nadav Har'El >>> n...@scylladb.com <javascript:> >>> >>> >>> On Sun, Jun 30, 2019 at 7:14 AM Waldemar Kozaczuk <jwkoz...@gmail.com >>> <javascript:>> wrote: >>> >>>> This patch refines the implementation of procfs >>>> to generate maps file that contains correct file i-node >>>> numbers instead of 0s for file VMAs as shown below: >>>> >>>> 0-0 ---p 00000000 00:00 0 >>>> 100000000000-100000001000 r--p 00000000 00:00 3 /libvdso.so >>>> 100000001000-100000002000 r-xp 00001000 00:00 3 /libvdso.so >>>> 100000002000-100000003000 r--p 00002000 00:00 3 /libvdso.so >>>> 100000003000-100000004000 r--p 00002000 00:00 3 /libvdso.so >>>> 100000004000-100000005000 rw-p 00003000 00:00 3 /libvdso.so >>>> 100000005000-100000007000 r--p 00000000 00:00 6 /cat >>>> 100000007000-10000000c000 r-xp 00002000 00:00 6 /cat >>>> 10000000c000-10000000e000 r--p 00007000 00:00 6 /cat >>>> 10000000f000-100000010000 r--p 00009000 00:00 6 /cat >>>> 100000010000-100000011000 rw-p 0000a000 00:00 6 /cat >>>> 200000000000-200000001000 ---p 00000000 00:00 0 >>>> 200000001000-200000100000 rw-p 00000000 00:00 0 >>>> 200000100000-200000101000 ---p 00000000 00:00 0 >>>> 200000101000-200000200000 rw-p 00000000 00:00 0 >>>> 800000000000-800000000000 ---p 00000000 00:00 0 >>>> >>>> It does so by capturing and saving the file i-node number when >>>> constructing file_vma so that it can be used when generating >>>> /proc/self/maps. >>>> >>>> Signed-off-by: Waldemar Kozaczuk <jwkoz...@gmail.com <javascript:>> >>>> --- >>>> core/mmu.cc | 10 +++++++++- >>>> include/osv/mmu.hh | 2 ++ >>>> 2 files changed, 11 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/core/mmu.cc b/core/mmu.cc >>>> index 575834ca..c37cc1a5 100644 >>>> --- a/core/mmu.cc >>>> +++ b/core/mmu.cc >>>> @@ -1679,6 +1679,14 @@ file_vma::file_vma(addr_range range, unsigned >>>> perm, unsigned flags, fileref file >>>> if (err != 0) { >>>> throw make_error(err); >>>> } >>>> + >>>> + struct stat st; >>>> + err = _file->stat(&st); >>>> + if (err != 0) { >>>> + throw make_error(err); >>>> + } >>>> + >>>> + _file_inode = st.st_ino; >>>> } >>>> >>>> void file_vma::fault(uintptr_t addr, exception_frame *ef) >>>> @@ -1910,7 +1918,7 @@ std::string procfs_maps() >>>> osv::fprintf(os, "%x-%x %c%c%c%c ", vma.start(), >>>> vma.end(), read, write, execute, priv); >>>> if (vma.flags() & mmap_file) { >>>> const file_vma &f_vma = static_cast<file_vma&>(vma); >>>> - osv::fprintf(os, "%08x 00:00 0 %s\n", f_vma.offset(), >>>> f_vma.file()->f_dentry->d_path); >>>> + osv::fprintf(os, "%08x 00:00 %ld %s\n", >>>> f_vma.offset(), f_vma.file_inode(), f_vma.file()->f_dentry->d_path); >>>> } else { >>>> osv::fprintf(os, "00000000 00:00 0\n"); >>>> } >>>> diff --git a/include/osv/mmu.hh b/include/osv/mmu.hh >>>> index e6a3f008..54ebf6f1 100644 >>>> --- a/include/osv/mmu.hh >>>> +++ b/include/osv/mmu.hh >>>> @@ -93,10 +93,12 @@ public: >>>> virtual void fault(uintptr_t addr, exception_frame *ef) override; >>>> fileref file() const { return _file; } >>>> f_offset offset() const { return _offset; } >>>> + u64 file_inode() const { return _file_inode; } >>>> private: >>>> f_offset offset(uintptr_t addr); >>>> fileref _file; >>>> f_offset _offset; >>>> + u64 _file_inode; >>>> }; >>>> >>>> ulong map_jvm(unsigned char* addr, size_t size, size_t align, >>>> balloon_ptr b); >>>> -- >>>> 2.20.1 >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "OSv Development" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to osv...@googlegroups.com <javascript:>. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/osv-dev/20190630041405.4350-1-jwkozaczuk%40gmail.com >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "OSv Development" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to osv...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/osv-dev/5684a16f-4f1f-4094-a20b-f5859d19dbef%40googlegroups.com >> >> <https://groups.google.com/d/msgid/osv-dev/5684a16f-4f1f-4094-a20b-f5859d19dbef%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/938882d8-dae0-49d4-9880-f327747a6837%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
