Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp6937976ybi; Thu, 1 Aug 2019 00:39:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqx5blQofvnjE37e8p3oeP7Gqq3Wu61dipgrMg2bI8nvwbDY6ZoZVTP6P6gH/mRXUmAt+uQ7 X-Received: by 2002:a62:87c8:: with SMTP id i191mr51860292pfe.133.1564645167417; Thu, 01 Aug 2019 00:39:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564645167; cv=none; d=google.com; s=arc-20160816; b=Cc/ITsirgGIi/dMXcfxr47apd2FZgGWTigPNSea25bE+py+wHP+EC3W7TEFHOeS1Sq 8ofMD0M9O3cRsq9Dw4imPoTbMQKhLKJPTPG4OO3Qydzas9dtg1h0D8+csQJvjlpPkFd9 43j8Uqds3Wuyln7Qzb6KKZ72W0U6tg3wzJ445aUC77N6nkYMMnQkVMFjNuTUuJfV3N5q 7XqXr+ZmNWRgO8JcrdIH6QjnsRLpw2aE1hulAxtd17kdWvhBiox1wRhoEtwJKijoU8Pe LAKPg8UwZJgxOrfKwXn+y8Br26jqnx67HC9YwcJRYO3a+wrnITbLXEh9jWCDdGeeBTzk DZhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=smAh9l8LarFZoBRTNjmDuWMi5c07vOlA3g8NFMkZAaU=; b=AcdK9T57OAc+isH5/P45zbJTmoWxf7jI+dpJAO6AlkcHNmoPqexT13dPFP1Yms5FBR RFKFDstb5xWhuo+OmdYeiZ75FhNfR7Tus6Fymv/8BfbRa8dl0w/F2MCh9e3m1NNSqa1y Msw5M0fiCtLqoGS8KdOvbfDthHDmuN3WIkJ8tYSZb3Z27zNFuxswelX5C6V6Q40EgB4m 1y7lkalyryLNDYKOj8IUSAdvm4IdbOXbn1QIS2ezOkgJaKgw5bOteOFF1fduZcKCp05s WB3yr8dmlYLguUBDElj/IjvDmYBP2WPSEEIlkDxke+KLpZ3D95Foa/FWFGHkJxxoHXTP 5kbQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z72si36394793pgd.34.2019.08.01.00.39.11; Thu, 01 Aug 2019 00:39:27 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729091AbfHAHLW (ORCPT + 99 others); Thu, 1 Aug 2019 03:11:22 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:47434 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725790AbfHAHLW (ORCPT ); Thu, 1 Aug 2019 03:11:22 -0400 Received: from DGGEMS414-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id F3DE384F77E482D42356; Thu, 1 Aug 2019 15:11:19 +0800 (CST) Received: from [10.151.23.176] (10.151.23.176) by smtp.huawei.com (10.3.19.214) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 1 Aug 2019 15:11:18 +0800 Subject: Re: [BUG] lseek on /proc/meminfo is broken in 4.19.59 To: Sergei Turchanov CC: Alexander Viro , , References: <3bd775ab-9e31-c6b3-374e-7a9982a9a8cd@farpost.com> From: Gao Xiang Message-ID: <5c4c0648-2a96-4132-9d22-91c22e7c7d4d@huawei.com> Date: Thu, 1 Aug 2019 15:11:02 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <3bd775ab-9e31-c6b3-374e-7a9982a9a8cd@farpost.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.151.23.176] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 > #include > #include > #include > #include > #include > > #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 []\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; > } > > >