prb_read_valid() could return a record whose seq number can be
newer than the requested one. In that case, we allow the reading
of the data instead of erroring out.

This commit fixes this by correcting the check.

Fixes: ce6de43a547b6e01a3 ("printk: avoid prb_first_valid_seq() where possible")
Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
---
 kernel/printk/printk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 155229f..53b09b98 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -738,7 +738,7 @@ static ssize_t devkmsg_read(struct file *file, char __user *buf,
 			goto out;
 	}
 
-	if (r->info->seq != atomic64_read(&user->seq)) {
+	if (r->info->seq < atomic64_read(&user->seq)) {
 		/* our last seen message is gone, return error and reset */
 		atomic64_set(&user->seq, r->info->seq);
 		ret = -EPIPE;
-- 
2.7.4

On 2022-01-18, Mukesh Ojha <quic_mojha@quicinc.com> wrote:
> prb_read_valid() could return a record whose seq number can be
> newer than the requested one. In that case, we allow the reading
> of the data instead of erroring out.

The EPIPE error is intentional. It informs the devkmsg reader that a
record was missed.

For simple readers, like cat(1), this means that the kernel messages
cannot be read completely reliably. We talked about this a while back
[0] because initially I wanted to do what your patch does. In the end it
was agreed that readers of /dev/kmsg must implement EPIPE handling for
missed records.

John Ogness

[0] https://lore.kernel.org/all/87pneiyv12.fsf@linutronix.de