Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp252575pxb; Thu, 14 Jan 2021 05:13:55 -0800 (PST) X-Google-Smtp-Source: ABdhPJz7YchZhgu1X/NOi6RrE9k6UEjL7dOhX5+kAeqqd1SHapeIb4c6V3QYF2z6wjVIVIceHvv3 X-Received: by 2002:a50:9ea4:: with SMTP id a33mr5564396edf.70.1610630034932; Thu, 14 Jan 2021 05:13:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610630034; cv=none; d=google.com; s=arc-20160816; b=McSUXUrcfud2Uw0F84YQFQaH9tG541J0IlAlwVo5bsYhP7fB+70s8NCfS41CZ1UeZr YoNWiNyrLS3Ww8tNQ0jmX+TPWajc5xsS1SMDIrN8MgqPfzFB6k6wHNRb2J4sBuxyIWm6 RqrmCmyUbCd71FxoOKrgRk/ypvp0l1sPE+eFYsIffYzIXqF3RNawxWk4uVz7Ns+UkEax IQuDWdtYNSHCYQfB+h/vaAnz4GPqSX+YKQRZtP2FVZevJO+cLVhSTHbxZTb4QsEyCg2y KLrY0/yGJ2UD8j/PPmUs51HixQw9QnibkRqgul5cRHaDggBuAJmYPEi6g6qF6W6BD/rh 729w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=NmtcablsKSbfT/kPFSeW/UwkLbr0hcu7CM8rAe854EM=; b=Zkim8l22OKkR2rZ8tSEpmPM1SCPRsgWYS0k1TxWDqLCNz7wS/ghvnbEXCL5A1la8gZ Yym0XrUc9jclSMa2hNIxDb5/wb7GC4vB8d2js5YNnOIDjk7dwDELHYqBvkyRxQ4mIP+N FfPtj2JGig6GJ2lz06khLtXhM7V230H9t/67/dqfI0ud0OJntyd2ZrJdPqzuqlJaQ/Yl XG+OtaCD+HsIjCdHdUAsz/iyM4mzxSHGH0Ep5TF0Le8k8HmPWMzOuW055r8ylROjMmsE dEtGytomRCAnpjpZmZklu1/rVyM5MTCmpfRDkFl+a6Rwub50ENNsvxNysk56dLBoffLm F1Ng== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=s2Z0T0YT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=suse.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lh17si2354778ejb.328.2021.01.14.05.13.30; Thu, 14 Jan 2021 05:13:54 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=s2Z0T0YT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727264AbhANNMQ (ORCPT + 99 others); Thu, 14 Jan 2021 08:12:16 -0500 Received: from mx2.suse.de ([195.135.220.15]:35852 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725991AbhANNMQ (ORCPT ); Thu, 14 Jan 2021 08:12:16 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1610629889; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=NmtcablsKSbfT/kPFSeW/UwkLbr0hcu7CM8rAe854EM=; b=s2Z0T0YTG3S6gGDghmbDdbWwhK/d1psqMmti18bbuWWjtl1yOxcnqIG/3g/GOeZh2D6TQn a820kQgQB8vXQUDJM68bFcS6EfE4NjmLeTWBZlpsAJs0iRX9Iiokk3eTVFx5v+JhDTTSMk 2C9i6nYnBOmaC5rw/zb+MiowW4TbRJE= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 2BE8CB775; Thu, 14 Jan 2021 13:11:29 +0000 (UTC) Date: Thu, 14 Jan 2021 14:11:28 +0100 From: Petr Mladek To: John Ogness Cc: Sergey Senozhatsky , Sergey Senozhatsky , Steven Rostedt , linux-kernel@vger.kernel.org Subject: Re: [PATCH] printk: ringbuffer: fix line counting Message-ID: References: <20210113144234.6545-1-john.ogness@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210113144234.6545-1-john.ogness@linutronix.de> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 2021-01-13 15:48:34, John Ogness wrote: > Counting text lines in a record simply involves counting the number > of newline characters (+1). However, it is searching the full data > block for newline characters, even though the text data can be (and > often is) a subset of that area. Since the extra area in the data > block was never initialized, the result is that extra newlines may > be seen and counted. Great catch! > Restrict newline searching to the text data length. > > Fixes: b6cf8b3f3312 ("printk: add lockless ringbuffer") > Signed-off-by: John Ogness Reviewed-by: Petr Mladek There is a note below. > --- > kernel/printk/printk_ringbuffer.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/printk/printk_ringbuffer.c b/kernel/printk/printk_ringbuffer.c > index 6704f06e0417..8a7b7362c0dd 100644 > --- a/kernel/printk/printk_ringbuffer.c > +++ b/kernel/printk/printk_ringbuffer.c > @@ -1718,7 +1718,7 @@ static bool copy_data(struct prb_data_ring *data_ring, > > /* Caller interested in the line count? */ > if (line_count) > - *line_count = count_lines(data, data_size); > + *line_count = count_lines(data, len); > > /* Caller interested in the data content? */ > if (!buf || !buf_size) Another question is what line count should be returned when the data are copied into the buffer. In this case, the text might get shrunken even more. Well, this case is not supported by the API at the moment. @line_count is defined only in prb_read_valid_info() where the buffer is always NULL. But we might add a WARN_ONCE() or a comment there to prevent similar mistakes in the future. Best Regards, Petr