Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp159585ybf; Wed, 26 Feb 2020 10:37:45 -0800 (PST) X-Google-Smtp-Source: APXvYqyLo+loMFI6f62KP1h/pOnpVs6cyHlPtGpiPBseHM5NcQSRu0B13x9cuFOhHbMiOpnuK/oT X-Received: by 2002:aca:b703:: with SMTP id h3mr299042oif.148.1582742265145; Wed, 26 Feb 2020 10:37:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582742265; cv=none; d=google.com; s=arc-20160816; b=WQePTFGAJxHxWE63o3TsAiUCu8inTnqJ2WkfuLnODip3OcQOhYXuGAqVd93zw2I+Wv YtRPklkMQFCQL24GL1lR5nUFr3YHxW6AwCzkrlv/SzBuWgLNEAJUhor2Gin+peHbuVBM /+Fc0GsyGolGDnrmR6N4Wv/4A4i4f8E6pSi+vK1w6jpqEHnksubaX1974ZhR4PVv0x1P NuqFOMM9Tpups2UGYHX6S1oJRaXwGvwHbH8RblabxdkT0Hazs/EmQS3qckF8+4uoST6V VUoqJRyjNo8KOAH6jn5nHGjKlvmZ7b5yLfUrhNv0b17DohUVLqD68Kpdhc7hC6qPuMli hxkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=tcZLgNZUBvJl2n2nxeHHbb+zy0PX2FhfitPuErDlntw=; b=0ByZlu91/Ln/NybnaEskVR3km9WBYnZRZ0qzeweWGCmRJ6zyLKiPbDScd2vC3O2WDM kxTop/vdph3Uhd6fkILmpiTQMuQJs1d4DUT633PXv29qaWxoOrDFKT8UvKSwoTYMG2OZ BFzxwf8VLWqPC1me8lfUmbFMth63mOAMIcMFXcYFLCsVYeUJmOcXnNYE1th1gHirlNWB 9N5xzUUP0eY6bZacfPrd00H1ad1y6pnjm7BZGqiU89zJ3NhBzee67yZWOU6+hmp4dI9z T80igiIww6OmeCQwKllMiEp5VRDhuvD8RlOhONE+uzuaGXgo2sSThOG8ChWPc2aS01kz 9nmw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="OIGX/FnQ"; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f14si201533oto.46.2020.02.26.10.37.32; Wed, 26 Feb 2020 10:37:45 -0800 (PST) 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; dkim=pass header.i=@google.com header.s=20161025 header.b="OIGX/FnQ"; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727144AbgBZSg6 (ORCPT + 99 others); Wed, 26 Feb 2020 13:36:58 -0500 Received: from mail-qt1-f193.google.com ([209.85.160.193]:41705 "EHLO mail-qt1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726878AbgBZSg6 (ORCPT ); Wed, 26 Feb 2020 13:36:58 -0500 Received: by mail-qt1-f193.google.com with SMTP id l21so232037qtr.8 for ; Wed, 26 Feb 2020 10:36:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tcZLgNZUBvJl2n2nxeHHbb+zy0PX2FhfitPuErDlntw=; b=OIGX/FnQATi2tGpoayVWr/MjgDklMgief8mHrZMct1gM/Cff+3esZ3lbA/D8QaGFG2 EvqYAVIpa5ljzwSuDYO9GC/L4tItD10N0Li8tSEJZZtOufUV0ehxrJt2OAhK1Nr7iAkr AJMoM9N10eXCTIM8ap7nN+mW+j+9bGJ83XsEieHMdG4H9L15vpesOM2krZzyA7IBc+Kv w1Gg/uYDU9B6akelza7T1E4SfZHuytq7I2z590XpmNMITZW8jYGSk9nJIN53laWv8NCh A0kE1nxMEFch3VOYjVfaUY7Xl/oCPN62/OejFrOCRCFyDpuoyjawB3y4WmGW8sY+xOZV jRDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tcZLgNZUBvJl2n2nxeHHbb+zy0PX2FhfitPuErDlntw=; b=Qw7O5RflQ+rTt2e3beUI23c9dkJIP/vdNv+ilb/8Ed7BeG9BkqYput/OgaJXhlUD5B aoLA8McpEghYgkx0ywJ2L+8+TSl9BTSgS5qgahcT5JXr6knGw+U9lCVf5X+0kUUSh5su NnMtM80Y8lRkHnPo+NYzuCkUoLGESD2Ej7gEum5w6jkpiSu7MQLwLwU3fEE35X4HavRv N78rtySd2V8zmAvGwp3c7s/mNF4MsIB1NV9TUUS82rbMGJvosIfgUBW4Hvb7hB3QxD6F zZ/pEctyS2pR2soa/0Zh54huQEf03rJ4sM4/XQhjhgg813LvmXPPevSb/oKq83w/EAVh dI/g== X-Gm-Message-State: APjAAAWSlaUvX06k1Qgf9okLnTUDUhuGgRkwp2pz2TaXED3IKc3fiDpX OqhCEMMAwB6lZPaWZ3TRva/2A2/TU1lMy+ucYYBusQ== X-Received: by 2002:ac8:67d2:: with SMTP id r18mr198178qtp.34.1582742216565; Wed, 26 Feb 2020 10:36:56 -0800 (PST) MIME-Version: 1.0 References: <4e49830d-4c88-0171-ee24-1ee540028dad@virtuozzo.com> <202002251136.3816A79E@keescook> In-Reply-To: <202002251136.3816A79E@keescook> From: Joel Fernandes Date: Wed, 26 Feb 2020 13:36:45 -0500 Message-ID: Subject: Re: [PATCH v2] pstore: pstore_ftrace_seq_next should increase position index To: Kees Cook Cc: Vasily Averin , LKML , Anton Vorontsov , Colin Cross , Tony Luck Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 25, 2020 at 2:39 PM Kees Cook wrote: > > [merged threads] > > On Tue, Feb 25, 2020 at 11:11:20AM +0300, Vasily Averin wrote: > > In Aug 2018 NeilBrown noticed > > commit 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface") > > "Some ->next functions do not increment *pos when they return NULL... > > Note that such ->next functions are buggy and should be fixed. > > A simple demonstration is > > > > dd if=/proc/swaps bs=1000 skip=1 > > > > Choose any block size larger than the size of /proc/swaps. This will > > always show the whole last line of /proc/swaps" > > > > /proc/swaps output was fixed recently, however there are lot of other > > affected files, and one of them is related to pstore subsystem. > > > > If .next function does not change position index, following .show function > > will repeat output related to current position index. > > > > There are at least 2 related problems: > > - read after lseek beyond end of file, described above by NeilBrown > > "dd if= bs=1000 skip=1" will generate whole last list > > - read after lseek on in middle of last line will output expected rest of > > last line but then repeat whole last line once again. > > > > If .show() function generates multy-line output > > (like pstore_ftrace_seq_show() does ?) > > following bash script cycles endlessly > > > > $ q=;while read -r r;do echo "$((++q)) $r";done < AFFECTED_FILE > > > > Unfortunately I'm not familiar enough to pstore subsystem and was unable to > > find affected pstore-related file on my test node. > > > > If .next function does not change position index, > > following .show function will repeat output related > > to current position index. > > > > Cc: stable@vger.kernel.org > > Fixes: 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code ...") > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=206283 > > Signed-off-by: Vasily Averin > > --- > > fs/pstore/inode.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c > > index 7fbe8f0..ea8799b 100644 > > --- a/fs/pstore/inode.c > > +++ b/fs/pstore/inode.c > > @@ -87,11 +87,11 @@ static void *pstore_ftrace_seq_next(struct seq_file *s, void *v, loff_t *pos) > > struct pstore_private *ps = s->private; > > struct pstore_ftrace_seq_data *data = v; > > > > + (*pos)++; > > data->off += REC_SIZE; > > if (data->off + REC_SIZE > ps->total_size) > > return NULL; > > > > - (*pos)++; > > return data; > > } > > > > -- > > 1.8.3.1 > > > > I think this make sense, but I figured I'd check with Joel first. Does > this look sane for how ftrace will merge records? The merging of the per-cpu records is completed at boot time. The above snip is related to reading the merged records and formatting them. It makes sense. One thing I was not sure about is, if we move "pos" forward but still return NULL from next(), then does show() need to check if data is NULL? As below. Otherwise the suggested patch looks sane to me. diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c index 7fbe8f0582205..e3e7370b1a34d 100644 --- a/fs/pstore/inode.c +++ b/fs/pstore/inode.c @@ -101,6 +101,9 @@ static int pstore_ftrace_seq_show(struct seq_file *s, void *v) struct pstore_ftrace_seq_data *data = v; struct pstore_ftrace_record *rec; + if (!data) + return 0; + rec = (struct pstore_ftrace_record *)(ps->record->buf + data->off); seq_printf(s, "CPU:%d ts:%llu %08lx %08lx %ps <- %pS\n",