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;
Subject: Re: [PATCH] printk: Fix unnecessary returning broken pipe error from
 devkmsg_read
To:     Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
CC:     <pmladek@suse.com>, <sergey.senozhatsky@gmail.com>,
        <rostedt@goodmis.org>, <linux-kernel@vger.kernel.org>
References: <1568813503-420025-1-git-send-email-zhe.he@windriver.com>
 <20190923100513.GA51932@jagdpanzerIV>
From:   He Zhe <zhe.he@windriver.com>
Message-ID: <027b2f0d-b7dc-4e76-22a7-ce80c9a0aade@windriver.com>
Date:   Mon, 23 Sep 2019 18:45:18 +0800
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: <20190923100513.GA51932@jagdpanzerIV>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 9/23/19 6:05 PM, Sergey Senozhatsky wrote:
> On (09/18/19 21:31), zhe.he@windriver.com wrote:
>> When users read the buffer from start, there is no need to return -EPIPE
>> since the possible overflows will not affect the output.
>>
> [..]
>> -	if (user->seq < log_first_seq) {
>> +	if (user->seq == 0) {
>> +		user->seq = log_first_seq;
>> +	} else if (user->seq < log_first_seq) {
>>  		/* our last seen message is gone, return error and reset */
>>  		user->idx = log_first_idx;
>>  		user->seq = log_first_seq;
> A tough call.
>
> User-space wants to read messages which are gone: log_first_seq > user->seq.
>
> I think returning EPIPE is sort of appropriate; user-space, possibly,
> can printf(stderr, "Some /dev/kmsg messages are gone\n"); or something
> like that.

Yes, a tough call. I was looking at the similar part of RT kernel and thought
that handling was better.
https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/tree/kernel/printk/printk.c?h=linux-5.2.y-rt#n706

IMHO, the EPIPE is used to inform user-space when the buffer has overflown and
there is a inconsistency/break between what has been read and what has not.

When user-space just wants to read the buffer from sequence 0, there would not
be the inconsistency.

I think it is NOT necessary to inform user-space, when it just wants to read
from the beginning of the buffer, that the buffer has changed since the time
point when it issues the action of reading. But if that IS what we want, the RT
kernel needs to be changed so that mainline and RT kernel act in the same way.


Zhe

>
> 	-ss
>