* [BUG] lseek on /proc/meminfo is broken in 4.19.59
@ 2019-07-18 3:26 Sergei Turchanov
0 siblings, 0 replies; 4+ messages in thread
From: Sergei Turchanov @ 2019-07-18 3:26 UTC (permalink / raw)
To: Alexander Viro, linux-fsdevel; +Cc: linux-kernel
Hello!
Seeking (to an offset within file size) in /proc/meminfo is broken in
4.19.59. It does seek to a desired position, but reading from that
position returns the remainder of file and then a whole copy of file.
This doesn't happen with /proc/vmstat or /proc/self/maps for example.
Seeking did work correctly in kernel 4.14.47. So it seems something
broke in the way.
Background: this kind of access pattern (seeking to /proc/meminfo) is
used by libvirt-lxc fuse driver for virtualized view of /proc/meminfo.
$ ./test /proc/meminfo 0 # Works as expected
MemTotal: 394907728 kB
MemFree: 173738328 kB
...
DirectMap2M: 13062144 kB
DirectMap1G: 390070272 kB
-----------------------------------------------------------------------
$ ./test 1024 # returns a copy of file after the remainder
Will seek to 1024
Data read at offset 1024
gePages: 0 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
Hugetlb: 0 kB
DirectMap4k: 245204 kB
DirectMap2M: 13062144 kB
DirectMap1G: 390070272 kB
MemTotal: 394907728 kB
MemFree: 173738328 kB
MemAvailable: 379989680 kB
Buffers: 355812 kB
Cached: 207216224 kB
...
DirectMap2M: 13062144 kB
DirectMap1G: 390070272 kB
As you see, after "DirectMap1G:" line, a whole copy of /proc/meminfo
returned by "read".
Test program:
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#define SIZE 1024
char buf[SIZE + 1];
int main(int argc, char *argv[]) {
int fd;
ssize_t rd;
off_t ofs = 0;
if (argc < 2) {
printf("Usage: test <file> [<offset>]\n");
exit(1);
}
if (-1 == (fd = open(argv[1], O_RDONLY))) {
perror("open failed");
exit(1);
}
if (argc > 2) {
ofs = atol(argv[2]);
}
printf("Will seek to %ld\n", ofs);
if (-1 == (lseek(fd, ofs, SEEK_SET))) {
perror("lseek failed");
exit(1);
}
for (;; ofs += rd) {
printf("\n\nData read at offset %ld\n", ofs);
if (-1 == (rd = read(fd, buf, SIZE))) {
perror("read failed");
exit(1);
}
buf[rd] = '\0';
printf(buf);
if (rd < SIZE) {
break;
}
}
return 0;
}
^ permalink raw reply [flat|nested] 4+ messages in thread
* [BUG] lseek on /proc/meminfo is broken in 4.19.59
@ 2019-08-01 6:16 Sergei Turchanov
2019-08-01 7:11 ` Gao Xiang
0 siblings, 1 reply; 4+ messages in thread
From: Sergei Turchanov @ 2019-08-01 6:16 UTC (permalink / raw)
To: Alexander Viro, linux-fsdevel; +Cc: linux-kernel
Hello!
(I sent this e-mail two weeks ago with no feedback. Does anyone care?
Wrong mailing list? Anything....?)
Seeking (to an offset within file size) in /proc/meminfo is broken in
4.19.59. It does seek to a desired position, but reading from that
position returns the remainder of file and then a whole copy of file.
This doesn't happen with /proc/vmstat or /proc/self/maps for example.
Seeking did work correctly in kernel 4.14.47. So it seems something
broke in the way.
Background: this kind of access pattern (seeking to /proc/meminfo) is
used by libvirt-lxc fuse driver for virtualized view of /proc/meminfo.
So that /proc/meminfo is broken in guests when running kernel 4.19.x.
$ ./test /proc/meminfo 0 # Works as expected
MemTotal: 394907728 kB
MemFree: 173738328 kB
...
DirectMap2M: 13062144 kB
DirectMap1G: 390070272 kB
-----------------------------------------------------------------------
$ ./test 1024 # returns a copy of file after the remainder
Will seek to 1024
Data read at offset 1024
gePages: 0 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
Hugetlb: 0 kB
DirectMap4k: 245204 kB
DirectMap2M: 13062144 kB
DirectMap1G: 390070272 kB
MemTotal: 394907728 kB
MemFree: 173738328 kB
MemAvailable: 379989680 kB
Buffers: 355812 kB
Cached: 207216224 kB
...
DirectMap2M: 13062144 kB
DirectMap1G: 390070272 kB
As you see, after "DirectMap1G:" line, a whole copy of /proc/meminfo
returned by "read".
Test program:
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#define SIZE 1024
char buf[SIZE + 1];
int main(int argc, char *argv[]) {
int fd;
ssize_t rd;
off_t ofs = 0;
if (argc < 2) {
printf("Usage: test <file> [<offset>]\n");
exit(1);
}
if (-1 == (fd = open(argv[1], O_RDONLY))) {
perror("open failed");
exit(1);
}
if (argc > 2) {
ofs = atol(argv[2]);
}
printf("Will seek to %ld\n", ofs);
if (-1 == (lseek(fd, ofs, SEEK_SET))) {
perror("lseek failed");
exit(1);
}
for (;; ofs += rd) {
printf("\n\nData read at offset %ld\n", ofs);
if (-1 == (rd = read(fd, buf, SIZE))) {
perror("read failed");
exit(1);
}
buf[rd] = '\0';
printf(buf);
if (rd < SIZE) {
break;
}
}
return 0;
}
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [BUG] lseek on /proc/meminfo is broken in 4.19.59
2019-08-01 6:16 Sergei Turchanov
@ 2019-08-01 7:11 ` Gao Xiang
2019-08-01 7:52 ` Sergei Turchanov
0 siblings, 1 reply; 4+ messages in thread
From: Gao Xiang @ 2019-08-01 7:11 UTC (permalink / raw)
To: Sergei Turchanov; +Cc: Alexander Viro, linux-fsdevel, linux-kernel
Hi,
I just took a glance, maybe due to
commit 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface")
I simply reverted it just now and it seems fine... but I haven't digged into this commit.
Maybe you could Cc NeilBrown <neilb@suse.com> for some more advice and
I have no idea whether it's an expected behavior or not...
Thanks,
Gao Xiang
On 2019/8/1 14:16, Sergei Turchanov wrote:
> Hello!
>
> (I sent this e-mail two weeks ago with no feedback. Does anyone care? Wrong mailing list? Anything....?)
>
> Seeking (to an offset within file size) in /proc/meminfo is broken in 4.19.59. It does seek to a desired position, but reading from that position returns the remainder of file and then a whole copy of file. This doesn't happen with /proc/vmstat or /proc/self/maps for example.
>
> Seeking did work correctly in kernel 4.14.47. So it seems something broke in the way.
>
> Background: this kind of access pattern (seeking to /proc/meminfo) is used by libvirt-lxc fuse driver for virtualized view of /proc/meminfo. So that /proc/meminfo is broken in guests when running kernel 4.19.x.
>
> $ ./test /proc/meminfo 0 # Works as expected
>
> MemTotal: 394907728 kB
> MemFree: 173738328 kB
> ...
> DirectMap2M: 13062144 kB
> DirectMap1G: 390070272 kB
>
> -----------------------------------------------------------------------
>
> $ ./test 1024 # returns a copy of file after the remainder
>
> Will seek to 1024
>
>
> Data read at offset 1024
> gePages: 0 kB
> ShmemHugePages: 0 kB
> ShmemPmdMapped: 0 kB
> HugePages_Total: 0
> HugePages_Free: 0
> HugePages_Rsvd: 0
> HugePages_Surp: 0
> Hugepagesize: 2048 kB
> Hugetlb: 0 kB
> DirectMap4k: 245204 kB
> DirectMap2M: 13062144 kB
> DirectMap1G: 390070272 kB
> MemTotal: 394907728 kB
> MemFree: 173738328 kB
> MemAvailable: 379989680 kB
> Buffers: 355812 kB
> Cached: 207216224 kB
> ...
> DirectMap2M: 13062144 kB
> DirectMap1G: 390070272 kB
>
> As you see, after "DirectMap1G:" line, a whole copy of /proc/meminfo returned by "read".
>
> Test program:
>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <unistd.h>
> #include <fcntl.h>
> #include <stdio.h>
> #include <stdlib.h>
>
> #define SIZE 1024
> char buf[SIZE + 1];
>
> int main(int argc, char *argv[]) {
> int fd;
> ssize_t rd;
> off_t ofs = 0;
>
> if (argc < 2) {
> printf("Usage: test <file> [<offset>]\n");
> exit(1);
> }
>
> if (-1 == (fd = open(argv[1], O_RDONLY))) {
> perror("open failed");
> exit(1);
> }
>
> if (argc > 2) {
> ofs = atol(argv[2]);
> }
> printf("Will seek to %ld\n", ofs);
>
> if (-1 == (lseek(fd, ofs, SEEK_SET))) {
> perror("lseek failed");
> exit(1);
> }
>
> for (;; ofs += rd) {
> printf("\n\nData read at offset %ld\n", ofs);
> if (-1 == (rd = read(fd, buf, SIZE))) {
> perror("read failed");
> exit(1);
> }
> buf[rd] = '\0';
> printf(buf);
> if (rd < SIZE) {
> break;
> }
> }
>
> return 0;
> }
>
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [BUG] lseek on /proc/meminfo is broken in 4.19.59
2019-08-01 7:11 ` Gao Xiang
@ 2019-08-01 7:52 ` Sergei Turchanov
0 siblings, 0 replies; 4+ messages in thread
From: Sergei Turchanov @ 2019-08-01 7:52 UTC (permalink / raw)
To: Gao Xiang; +Cc: Alexander Viro, linux-fsdevel, linux-kernel
Hi,
Thank you very much for your suggestion. Will certainly do that.
With best regards,
Sergei.
On 01.08.2019 17:11, Gao Xiang wrote:
> Hi,
>
> I just took a glance, maybe due to
> commit 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface")
>
> I simply reverted it just now and it seems fine... but I haven't digged into this commit.
>
> Maybe you could Cc NeilBrown <neilb@suse.com> for some more advice and
> I have no idea whether it's an expected behavior or not...
>
> Thanks,
> Gao Xiang
>
> On 2019/8/1 14:16, Sergei Turchanov wrote:
>> Hello!
>>
>> (I sent this e-mail two weeks ago with no feedback. Does anyone care? Wrong mailing list? Anything....?)
>>
>> Seeking (to an offset within file size) in /proc/meminfo is broken in 4.19.59. It does seek to a desired position, but reading from that position returns the remainder of file and then a whole copy of file. This doesn't happen with /proc/vmstat or /proc/self/maps for example.
>>
>> Seeking did work correctly in kernel 4.14.47. So it seems something broke in the way.
>>
>> Background: this kind of access pattern (seeking to /proc/meminfo) is used by libvirt-lxc fuse driver for virtualized view of /proc/meminfo. So that /proc/meminfo is broken in guests when running kernel 4.19.x.
>>
>> $ ./test /proc/meminfo 0 # Works as expected
>>
>> MemTotal: 394907728 kB
>> MemFree: 173738328 kB
>> ...
>> DirectMap2M: 13062144 kB
>> DirectMap1G: 390070272 kB
>>
>> -----------------------------------------------------------------------
>>
>> $ ./test 1024 # returns a copy of file after the remainder
>>
>> Will seek to 1024
>>
>>
>> Data read at offset 1024
>> gePages: 0 kB
>> ShmemHugePages: 0 kB
>> ShmemPmdMapped: 0 kB
>> HugePages_Total: 0
>> HugePages_Free: 0
>> HugePages_Rsvd: 0
>> HugePages_Surp: 0
>> Hugepagesize: 2048 kB
>> Hugetlb: 0 kB
>> DirectMap4k: 245204 kB
>> DirectMap2M: 13062144 kB
>> DirectMap1G: 390070272 kB
>> MemTotal: 394907728 kB
>> MemFree: 173738328 kB
>> MemAvailable: 379989680 kB
>> Buffers: 355812 kB
>> Cached: 207216224 kB
>> ...
>> DirectMap2M: 13062144 kB
>> DirectMap1G: 390070272 kB
>>
>> As you see, after "DirectMap1G:" line, a whole copy of /proc/meminfo returned by "read".
>>
>> Test program:
>>
>> #include <sys/types.h>
>> #include <sys/stat.h>
>> #include <unistd.h>
>> #include <fcntl.h>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> #define SIZE 1024
>> char buf[SIZE + 1];
>>
>> int main(int argc, char *argv[]) {
>> int fd;
>> ssize_t rd;
>> off_t ofs = 0;
>>
>> if (argc < 2) {
>> printf("Usage: test <file> [<offset>]\n");
>> exit(1);
>> }
>>
>> if (-1 == (fd = open(argv[1], O_RDONLY))) {
>> perror("open failed");
>> exit(1);
>> }
>>
>> if (argc > 2) {
>> ofs = atol(argv[2]);
>> }
>> printf("Will seek to %ld\n", ofs);
>>
>> if (-1 == (lseek(fd, ofs, SEEK_SET))) {
>> perror("lseek failed");
>> exit(1);
>> }
>>
>> for (;; ofs += rd) {
>> printf("\n\nData read at offset %ld\n", ofs);
>> if (-1 == (rd = read(fd, buf, SIZE))) {
>> perror("read failed");
>> exit(1);
>> }
>> buf[rd] = '\0';
>> printf(buf);
>> if (rd < SIZE) {
>> break;
>> }
>> }
>>
>> return 0;
>> }
>>
>>
>>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-08-01 7:52 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-18 3:26 [BUG] lseek on /proc/meminfo is broken in 4.19.59 Sergei Turchanov
2019-08-01 6:16 Sergei Turchanov
2019-08-01 7:11 ` Gao Xiang
2019-08-01 7:52 ` Sergei Turchanov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).