Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp726329ybt; Fri, 10 Jul 2020 10:45:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyZAX7tXz1Xn5dv/aE8d8jbisjAst4SaDhYEW5nhMqUwqDYA9ktqA0VTYqAmrGR1SPt8i2w X-Received: by 2002:a17:906:7709:: with SMTP id q9mr5096552ejm.123.1594403108235; Fri, 10 Jul 2020 10:45:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594403108; cv=none; d=google.com; s=arc-20160816; b=MGlTdRl+muXJQqOXnYSslfPTKqHuRrBZiPhymRR3u2L+S9NBuJo/NGdzbq1gOpRhlI h4iaFIR/odDzD/d4TTKpj9Fr7GBWbWG0PrV93i7jGHzINQohlMYLscIumHIGY0ILfHnd pAaNptgJyXSkz7v6P5TrmHFQ2vqlpnqnPFiGq1sx260wucA3mkOaezckc+65ENAEKs5c EGEaDJdZK3+pUnYTdCZ9w3VeoF0FtwbltTQ1wKRHAmxhVf9K7Zj40rY7SLW1iGYLZDZQ wsrOqOur+bkKyuZzWYCoSOSTUObo3MsVexuo9OcdTCiqF2P69qjnzxVTCOneC3PsaLCS mfkg== 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:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=qc023nhny6w6wkYHyPdwfmXQH84TOjG2Gsy5/9ekYpU=; b=oKTpozzk4WjlJrmpwT9ViQ0Hlrkul3YXVLLRQFgFuuA8aaV+5uNnhd6wfH6tgGNfI5 Jwanslo/3L3+fcuvdemC4j7ARYwv+9MloX32RqZ+K/5I2Ia8/dj8oYxl5x2BOpO3JWcP aNtQh8q18Lal0JVxiItfMSBadUJnLRB+CYdAsCHsTyDSPvaWVNeU7KeahlmM+J11uRAT clBbQFGEcAY927x78qzdZZ3DPc+pJrVEMaBPGc6egndhoj7dTdpmSAPOKgR1pRae8QFC Ip5eduA187qfB36wIkxwFXInP93RLqo8JLjVi12QDNzhuBEWCYOP73Ez7jECuf6UMsic DDVQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=WiBDVzlU; 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=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bg25si4180637ejb.230.2020.07.10.10.44.43; Fri, 10 Jul 2020 10:45:08 -0700 (PDT) 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=@redhat.com header.s=mimecast20190719 header.b=WiBDVzlU; 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=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728022AbgGJRod (ORCPT + 99 others); Fri, 10 Jul 2020 13:44:33 -0400 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:27832 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726977AbgGJRod (ORCPT ); Fri, 10 Jul 2020 13:44:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1594403072; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=qc023nhny6w6wkYHyPdwfmXQH84TOjG2Gsy5/9ekYpU=; b=WiBDVzlU3yxiEk6cwF0/3LUSfQsDjxnE7jGb7Z3pCcsBlrHYvHzFfx72Tn1QWjVKx/DGdr fnNgqg6UwzKadlhAA6EF2tTztrq08dSgaSq4WiuOaHXbr6/KLqp2l4Nmd3wWphA5BlRj71 m75hK9k8gQVuFy0hocC7qt0HZvpDR/Q= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-131-HcDM24aXMsKzcTD7-6iUIg-1; Fri, 10 Jul 2020 13:44:30 -0400 X-MC-Unique: HcDM24aXMsKzcTD7-6iUIg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4CB68800FEB; Fri, 10 Jul 2020 17:44:29 +0000 (UTC) Received: from localhost (ovpn-116-13.gru2.redhat.com [10.97.116.13]) by smtp.corp.redhat.com (Postfix) with ESMTP id D68766FEF8; Fri, 10 Jul 2020 17:44:25 +0000 (UTC) From: Bruno Meneguele To: linux-kernel@vger.kernel.org Cc: pmladek@suse.com, sergey.senozhatsky@gmail.com, torvalds@linux-foundation.org, Jason@zx2c4.com, Bruno Meneguele Subject: [PATCH v2] doc:kmsg: explictly state the return value in case of SEEK_CUR Date: Fri, 10 Jul 2020 14:44:23 -0300 Message-Id: <20200710174423.10480-1-bmeneg@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The commit 625d3449788f ("Revert "kernel/printk: add kmsg SEEK_CUR handling"") reverted a change done to the return value in case a SEEK_CUR operation was performed for kmsg buffer based on the fact that different userspace apps were handling the new return value (-ESPIPE) in different ways, breaking them. At the same time -ESPIPE was the wrong decision because kmsg /does support/ seek() but doesn't follow the "normal" behavior userspace is used to. Because of that and also considering the time -EINVAL has been used, it was decided to keep this way to avoid more userspace breakage. This patch adds an official statement to the kmsg documentation pointing to the current return value for SEEK_CUR, -EINVAL, thus userspace libraries and apps can refer to it for a definitive guide on what to expect. Signed-off-by: Bruno Meneguele --- Changelog: v2: - Changed wording to Documentation/ file and also added some doc directly to the code (suggested by Petr) Documentation/ABI/testing/dev-kmsg | 11 +++++++++++ kernel/printk/printk.c | 8 ++++++++ 2 files changed, 19 insertions(+) diff --git a/Documentation/ABI/testing/dev-kmsg b/Documentation/ABI/testing/dev-kmsg index f307506eb54c..79f007cdcd41 100644 --- a/Documentation/ABI/testing/dev-kmsg +++ b/Documentation/ABI/testing/dev-kmsg @@ -56,6 +56,17 @@ Description: The /dev/kmsg character device node provides userspace access seek after the last record available at the time the last SYSLOG_ACTION_CLEAR was issued. + Other seek operations or offsets are not supported because of + the special behavior this device has. The device allows to read + or write only whole variable lenght messages (records) that are + stored in a ring buffer. + + Because of the non-standard behavior also the error values are + non-standard. -ESPIPE is returned for non-zero offset. -EINVAL + is returned for other operations, e.g. SEEK_CUR. This behavior + and values are historical and could not be modified without the + risk of breaking userspace. + The output format consists of a prefix carrying the syslog prefix including priority and facility, the 64 bit message sequence number and the monotonic timestamp in microseconds, diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index b71eaf5f5a86..4c3a0822b705 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -943,6 +943,14 @@ static ssize_t devkmsg_read(struct file *file, char __user *buf, return ret; } +/* + * Be careful when modifying this function!!! + * + * Only few operations are supported because the device works only with the + * entire variable length messages (records). Non-standard values are + * returned in the other cases and has been this way for quite some time. + * User space applications might depend on this behavior. + */ static loff_t devkmsg_llseek(struct file *file, loff_t offset, int whence) { struct devkmsg_user *user = file->private_data; -- 2.26.2