linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gao Xiang <gaoxiang25@huawei.com>
To: Sergei Turchanov <turchanov@farpost.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
	<linux-fsdevel@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [BUG] lseek on /proc/meminfo is broken in 4.19.59
Date: Thu, 1 Aug 2019 15:11:02 +0800	[thread overview]
Message-ID: <5c4c0648-2a96-4132-9d22-91c22e7c7d4d@huawei.com> (raw)
In-Reply-To: <3bd775ab-9e31-c6b3-374e-7a9982a9a8cd@farpost.com>

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;
> }
> 
> 
> 

  reply	other threads:[~2019-08-01  7:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-01  6:16 [BUG] lseek on /proc/meminfo is broken in 4.19.59 Sergei Turchanov
2019-08-01  7:11 ` Gao Xiang [this message]
2019-08-01  7:52   ` Sergei Turchanov
2019-08-01  8:09   ` [BUG] lseek on /proc/meminfo is broken in 4.19.59 maybe due to commit 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface") Sergei Turchanov
2019-08-01  9:14     ` NeilBrown
2019-08-02  1:40       ` Sergei Turchanov
2019-08-05  4:26         ` [PATCH] seq_file: fix problem when seeking mid-record NeilBrown
2019-08-05  9:15           ` Markus Elfring
2019-08-05 10:08             ` NeilBrown
2019-08-06 22:42           ` [PATCH] " Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2019-07-18  3:26 [BUG] lseek on /proc/meminfo is broken in 4.19.59 Sergei Turchanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5c4c0648-2a96-4132-9d22-91c22e7c7d4d@huawei.com \
    --to=gaoxiang25@huawei.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=turchanov@farpost.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).