Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp7057917ybi; Thu, 1 Aug 2019 02:34:26 -0700 (PDT) X-Google-Smtp-Source: APXvYqzMPo+SyiNkjkeYrZrqZ8GoimWkGei2kpLiAKNH4FQjuWLcu3OtdV31aiAULPBMTnst90wY X-Received: by 2002:a17:902:b08a:: with SMTP id p10mr126466571plr.83.1564652066362; Thu, 01 Aug 2019 02:34:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564652066; cv=none; d=google.com; s=arc-20160816; b=WfdrmEIOsf6xYYyTCpfxYGXBGHuW2nR6TUu7lsXKmFpvoLTjFB8CMbIFiorN3SzQar J5Lnm3vowCX/ELQrUwXFmsKpRDLSPg3V+cRWBnsziQR9vvUP4M96vZSjT2PnH54N6J0f 26sx/cjZQ0rNX7ftTu7JOewBA1aHL/WuONjY3l7bCNlKchmJOGpqnmiY4ozSFWmGDdGm HBInCDy7WRoRU3GhMpvFaw+aX/NsXnbtJpMdyHxqIFwoirGq8uHEPaK+F8WWHKMO4bL6 ROvZ/op8OwmmlXw/QoRtO4s/lv1COQtiiJxJQODbYH8LEnbXkngfj4aTuzXBU9+StLtF M5nQ== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject; bh=pvgfeumKxcE97W7BwJGAwvmnocvJTR1NBNUzHnI/z9w=; b=ML/O57vonAQZJqOLXdo5KbsJZgt51KbrlqRD+DychCA3tmDszZVoJ4ZEtNfwDdwoUn lzo40glZEF3uFnjYBdXGPGnT8goKQ3M1u0qg2JlF1uC8jNA6OYSm98HrDI8t9RiKl87x mF5gXNO1csgmCAKaBvdc8QjiZHvqe3uRw2hUayNw93XqJfS/zvPrEeMIH9LFL72eFFDE Y3nCTi8bjZRhLzTAuwBoLbaaHyo4GJ2G5mufRJtQm/2FA72AgqGdpDPQcKPrCqS0Ol2o K1TJG8owtl9M8BfqIubc6EdiPYR+J5DfRp8t6F1/f1HVzgOpk5fHev64+obIO1uZ8JZs kutA== 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 x13si37122827pfr.274.2019.08.01.02.34.07; Thu, 01 Aug 2019 02:34:26 -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 S1730968AbfHAIKB convert rfc822-to-8bit (ORCPT + 99 others); Thu, 1 Aug 2019 04:10:01 -0400 Received: from mx1.mail.vl.ru ([80.92.161.250]:38556 "EHLO mx1.mail.vl.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728987AbfHAIKA (ORCPT ); Thu, 1 Aug 2019 04:10:00 -0400 Received: from localhost (unknown [127.0.0.1]) by mx1.mail.vl.ru (Postfix) with ESMTP id F0D551860D81; Thu, 1 Aug 2019 08:09:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.vl.ru Received: from mx1.mail.vl.ru ([127.0.0.1]) by localhost (smtp1.srv.loc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3msz10VMucFn; Thu, 1 Aug 2019 18:09:54 +1000 (+10) Received: from [10.125.1.12] (unknown [109.126.62.18]) (Authenticated sender: turchanov@vl.ru) by mx1.mail.vl.ru (Postfix) with ESMTPSA id BA09D1860D70; Thu, 1 Aug 2019 18:09:54 +1000 (+10) Subject: [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") To: NeilBrown Cc: Alexander Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org References: <3bd775ab-9e31-c6b3-374e-7a9982a9a8cd@farpost.com> <5c4c0648-2a96-4132-9d22-91c22e7c7d4d@huawei.com> From: Sergei Turchanov Organization: FarPost Message-ID: Date: Thu, 1 Aug 2019 18:09:54 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <5c4c0648-2a96-4132-9d22-91c22e7c7d4d@huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello! [ As suggested in previous discussion this behavior may be caused by your commit 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface") ] Original bug report: 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. > 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 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: $ ./test /proc/meminfo 0        # Works as expected MemTotal:       394907728 kB MemFree:        173738328 kB ... DirectMap2M:    13062144 kB DirectMap1G:    390070272 kB ----------------------------------------------------------------------- $ ./test /proc/meminfo 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; }