[PATCH] procfs: populate maps file with i-node numbers
6 views
Skip to first unread message
Waldemar Kozaczuk
Jun 30, 2019, 12:14:12 AM6/30/19
to osv...@googlegroups.com, Waldemar Kozaczuk
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>
---
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
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>
---
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
Nadav Har'El
Jun 30, 2019, 4:34:31 AM6/30/19
to Waldemar Kozaczuk, Osv Dev
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
--
Nadav Har'El
--
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+u...@googlegroups.com.
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.
Waldek Kozaczuk
Jun 30, 2019, 7:37:09 AM6/30/19
to Nadav Har'El, Osv Dev
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.
Sent from my iPhone
Waldek Kozaczuk
Jul 1, 2019, 12:26:18 AM7/1/19
to OSv Development
Also where would I get the values for this xx:yy pair from?
To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscribe@googlegroups.com.
Commit Bot
Jul 1, 2019, 12:39:17 PM7/1/19
to osv...@googlegroups.com, Waldemar Kozaczuk
From: Waldemar Kozaczuk <jwkoz...@gmail.com>
Committer: Nadav Har'El <n...@scylladb.com>
Branch: master
procfs: populate maps file with i-node numbers
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>
Message-Id: <20190630041405.4...@gmail.com>
---
diff --git a/core/mmu.cc b/core/mmu.cc
Committer: Nadav Har'El <n...@scylladb.com>
Branch: master
procfs: populate maps file with i-node numbers
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>
---
diff --git a/core/mmu.cc b/core/mmu.cc
Nadav Har'El
Jul 1, 2019, 12:42:31 PM7/1/19
to Waldek Kozaczuk, OSv Development
On Mon, Jul 1, 2019 at 7:26 AM Waldek Kozaczuk <jwkoz...@gmail.com> 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.
To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+u...@googlegroups.com.
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-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/5684a16f-4f1f-4094-a20b-f5859d19dbef%40googlegroups.com.
Waldek Kozaczuk
Jul 1, 2019, 10:39:43 PM7/1/19
to OSv Development
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-gef0696c5eth0: 192.168.122.15Booted up in 137.34 ms0-0 ---p 00000000 00:00 0100000000000-100000001000 r--p 00000000 00:00 3 /libvdso.so100000001000-100000002000 r-xp 00001000 00:00 3 /libvdso.so100000002000-100000003000 r--p 00002000 00:00 3 /libvdso.so100000003000-100000004000 r--p 00002000 00:00 3 /libvdso.so100000004000-100000005000 rw-p 00003000 00:00 3 /libvdso.so100000005000-100000007000 r--p 00000000 00:00 6 /cat100000007000-10000000c000 r-xp 00002000 00:00 6 /cat10000000c000-10000000e000 r--p 00007000 00:00 6 /cat10000000f000-100000010000 r--p 00009000 00:00 6 /cat100000010000-100000011000 rw-p 0000a000 00:00 6 /cat200000000000-200000001000 ---p 00000000 00:00 0200000001000-200000100000 rw-p 00000000 00:00 0200000100000-200000101000 ---p 00000000 00:00 0200000101000-200000200000 rw-p 00000000 00:00 0800000000000-800000000000 ---p 00000000 00:00 0ZFS:
./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-gef0696c5eth0: 192.168.122.15Booted up in 425.54 ms0-0 ---p 00000000 00:00 0100000062000-100000063000 r--p 00000000 ccdc54:48c1440c 9 /libvdso.so100000063000-100000064000 r-xp 00001000 ccdc54:48c1440c 9 /libvdso.so100000064000-100000065000 r--p 00002000 ccdc54:48c1440c 9 /libvdso.so100000065000-100000066000 r--p 00002000 ccdc54:48c1440c 9 /libvdso.so100000066000-100000067000 rw-p 00003000 ccdc54:48c1440c 9 /libvdso.so100000067000-100000069000 r--p 00000000 ccdc54:48c1440c 29 /cat100000069000-10000006e000 r-xp 00002000 ccdc54:48c1440c 29 /cat10000006e000-100000070000 r--p 00007000 ccdc54:48c1440c 29 /cat100000071000-100000072000 r--p 00009000 ccdc54:48c1440c 29 /cat100000072000-100000073000 rw-p 0000a000 ccdc54:48c1440c 29 /cat200000000000-200000001000 ---p 00000000 00:00 0200000001000-200000100000 rw-p 00000000 00:00 0200000100000-200000101000 ---p 00000000 00:00 0200000101000-200000200000 rw-p 00000000 00:00 0800000000000-800000000000 ---p 00000000 00:00 0Waldek
To unsubscribe from this group and stop receiving emails from it, send an email to osv...@googlegroups.com.
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.
Waldek Kozaczuk
Jul 1, 2019, 10:39:53 PM7/1/19
to OSv Development
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-gef0696c5eth0: 192.168.122.15Booted up in 137.34 ms0-0 ---p 00000000 00:00 0100000000000-100000001000 r--p 00000000 00:00 3 /libvdso.so100000001000-100000002000 r-xp 00001000 00:00 3 /libvdso.so100000002000-100000003000 r--p 00002000 00:00 3 /libvdso.so100000003000-100000004000 r--p 00002000 00:00 3 /libvdso.so100000004000-100000005000 rw-p 00003000 00:00 3 /libvdso.so100000005000-100000007000 r--p 00000000 00:00 6 /cat100000007000-10000000c000 r-xp 00002000 00:00 6 /cat10000000c000-10000000e000 r--p 00007000 00:00 6 /cat10000000f000-100000010000 r--p 00009000 00:00 6 /cat100000010000-100000011000 rw-p 0000a000 00:00 6 /cat200000000000-200000001000 ---p 00000000 00:00 0200000001000-200000100000 rw-p 00000000 00:00 0200000100000-200000101000 ---p 00000000 00:00 0200000101000-200000200000 rw-p 00000000 00:00 0800000000000-800000000000 ---p 00000000 00:00 0ZFS:
./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-gef0696c5eth0: 192.168.122.15Booted up in 425.54 ms0-0 ---p 00000000 00:00 0100000062000-100000063000 r--p 00000000 ccdc54:48c1440c 9 /libvdso.so100000063000-100000064000 r-xp 00001000 ccdc54:48c1440c 9 /libvdso.so100000064000-100000065000 r--p 00002000 ccdc54:48c1440c 9 /libvdso.so100000065000-100000066000 r--p 00002000 ccdc54:48c1440c 9 /libvdso.so100000066000-100000067000 rw-p 00003000 ccdc54:48c1440c 9 /libvdso.so100000067000-100000069000 r--p 00000000 ccdc54:48c1440c 29 /cat100000069000-10000006e000 r-xp 00002000 ccdc54:48c1440c 29 /cat10000006e000-100000070000 r--p 00007000 ccdc54:48c1440c 29 /cat100000071000-100000072000 r--p 00009000 ccdc54:48c1440c 29 /cat100000072000-100000073000 rw-p 0000a000 ccdc54:48c1440c 29 /cat200000000000-200000001000 ---p 00000000 00:00 0200000001000-200000100000 rw-p 00000000 00:00 0200000100000-200000101000 ---p 00000000 00:00 0200000101000-200000200000 rw-p 00000000 00:00 0800000000000-800000000000 ---p 00000000 00:00 0I 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 Monday, July 1, 2019 at 12:42:31 PM UTC-4, Nadav Har'El wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to osv...@googlegroups.com.
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.
Nadav Har'El
Jul 2, 2019, 3:55:54 AM7/2/19
to Waldek Kozaczuk, OSv Development
Good question.... zfs_vfsops.c has the following comment:
/*
* The fsid is 64 bits, composed of an 8-bit fs type, which
* separates our fsid from any other filesystem types, and a
* 56-bit objset unique ID. The objset unique ID is unique to
* all objsets open on this system, provided by unique_create().
* The 8-bit fs type must be put in the low bits of fsid[1]
* because that's where other Solaris filesystems put it.
*/
* The fsid is 64 bits, composed of an 8-bit fs type, which
* separates our fsid from any other filesystem types, and a
* 56-bit objset unique ID. The objset unique ID is unique to
* all objsets open on this system, provided by unique_create().
* The 8-bit fs type must be put in the low bits of fsid[1]
* because that's where other Solaris filesystems put it.
*/
I'm not sure how any of this is supposed to correspond to major and minor numbers.
I'm not sure it even matters, really, as long as the st_dev (and its representation as major:minor) is unique.
If anyone ever cares about this issue, we can fix it then.
To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/7cdbebe7-e4ec-410d-b3ef-d2ea912e55ae%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages