Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp527941ybt; Fri, 10 Jul 2020 06:11:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx0z9h2LQVP2EtqzfR2X4xvQw5wHTRrq2U8SWBwprrO1RnKiEUxotj104mHyaKm6uytOYHl X-Received: by 2002:aa7:c341:: with SMTP id j1mr80601743edr.197.1594386713394; Fri, 10 Jul 2020 06:11:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594386713; cv=none; d=google.com; s=arc-20160816; b=iOPFRiwjuUcarFaCf0Um7hi3Rujf3sg6//iB9zXb6yLOhv3yAXsCGD6bfJz7isVVSU Q/0Ju5hLc0maxnEzUHHmhvboKvhadv1uSzKLoYOjZ+UcBIW/y5bfshw90aZdGxDFyKUT YNCbafd728EfOVUC0sBqewrq2qihTiyxUu69TA4JItj03xloqOEcNePvQl3LXj3uIPD5 z0z781krZF75/5zcWg8qmF8T7wS/M/1a0AiTSwsqpaXHqqxrQQd8cUsM0HaqmZC2ea8S hwoT6nDA26rMMvy5dYvRReBmuQNzkMGkAbwbiRFWqRl8G+j9k5jFFbF4/O3AhTJiTHiR aQMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-disposition:in-reply-to :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=gljGcFi9pvin4NSQiUvypzy124N0N1e+L+bUaxisI78=; b=D2ywmZ/TTm0ZdA0KY2puqqPV3FFvZ+vmzrrjr2DAN9ld66aki0CdvUTYSqAc4iz6Yi AiVUo3orpjtJepu5IZ92VJpBCscZ0qI76Uxu+CeILBWnlh0k8M06KYSYrKlMvTIU9L4Z zYILMmeq5uMeK2jrKlJQMx9hR4AEXATel5dJg10mcauAb3v3rD+z0LcASghMrgXuZbrr 2pGcoDe5lYF3mAbSZQr1vJ2vGOfSBjDwd0wiX1IwA8n7tNblKc+ehTJ5vgmcGUDCDtYg A67qU8CPvicrV8j+kZBerh2f4ZQGyUTmVx9fdeqs3tDPPyinjoR7AZayWxB+WPYOFEte FgsA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="NLYr/WFs"; 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 h1si3873096ejk.3.2020.07.10.06.11.27; Fri, 10 Jul 2020 06:11:53 -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="NLYr/WFs"; 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 S1727768AbgGJNLF (ORCPT + 99 others); Fri, 10 Jul 2020 09:11:05 -0400 Received: from us-smtp-1.mimecast.com ([205.139.110.61]:43476 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726828AbgGJNLD (ORCPT ); Fri, 10 Jul 2020 09:11:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1594386661; h=from:from:reply-to:subject:subject: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=gljGcFi9pvin4NSQiUvypzy124N0N1e+L+bUaxisI78=; b=NLYr/WFs9PUq7+riju8SHucVTCRQYfPlUBFMuS+HrfOvLSppcXq/P83yA1BRuLy9Yk9as8 XXF1NyQwd5snDan5VsRXcGz4ibwu3hkih0vSeH1oE61Hw3ii35Lbc0+fEvngcp1Jr28XLA o6dnMOJk56C5kJkc3wwbSknoNYhzV1o= 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-114-GiF5lbolM3a8gU8Y5x4NQQ-1; Fri, 10 Jul 2020 09:10:57 -0400 X-MC-Unique: GiF5lbolM3a8gU8Y5x4NQQ-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 B54D2E928; Fri, 10 Jul 2020 13:10:55 +0000 (UTC) Received: from localhost (ovpn-116-117.gru2.redhat.com [10.97.116.117]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3BE50724A9; Fri, 10 Jul 2020 13:10:53 +0000 (UTC) Date: Fri, 10 Jul 2020 10:10:52 -0300 From: Bruno Meneguele To: Petr Mladek Cc: linux-kernel@vger.kernel.org, sergey.senozhatsky@gmail.com, torvalds@linux-foundation.org, Jason@zx2c4.com Subject: Re: [PATCH] doc:kmsg: explictly state the return value in case of SEEK_CUR Message-ID: <20200710131052.GA9078@glitch> References: <20200709155415.41207-1-bmeneg@redhat.com> <20200710121923.GO4751@alley> MIME-Version: 1.0 In-Reply-To: <20200710121923.GO4751@alley> X-PGP-Key: http://keys.gnupg.net/pks/lookup?op=get&search=0x3823031E4660608D X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=bmeneg@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 10, 2020 at 02:19:23PM +0200, Petr Mladek wrote: > On Thu 2020-07-09 12:54:15, Bruno Meneguele wrote: > > The commit 625d3449788f ("Revert "kernel/printk: add kmsg SEEK_CUR > > handling"") reverted a change done to the return value in case a SEEK_C= UR > > operation was performed for kmsg buffer based on the fact that differen= t > > userspace apps were handling the new return value (-ESPIPE) in differen= t > > ways, breaking them. > >=20 > > At the same time -ESPIPE was the wrong decision because kmsg /does supp= ort/ > > 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. > >=20 > > This patch adds an official statement to the kmsg documentation pointin= g to > > the current return value for SEEK_CUR, -EINVAL, thus userspace librarie= s and > > apps can refer to it for a definitive guide on what to expected. > >=20 > > --- a/Documentation/ABI/testing/dev-kmsg > > +++ b/Documentation/ABI/testing/dev-kmsg > > @@ -56,6 +56,11 @@ Description:=09The /dev/kmsg character device node p= rovides userspace access > > =09=09 seek after the last record available at the time > > =09=09 the last SYSLOG_ACTION_CLEAR was issued. > > =20 > > +=09=09Considering that the seek operation is supported but has=20 > > +=09=09special meaning to the device, any attempt to seek specific > > +=09=09positions on the buffer (i.e. using SEEK_CUR) results in an > > +=09=09-EINVAL error returned to userspace. >=20 > Sigh, I see that devkmsg_llseek() returns -ESPIPE when offset is not > zero. This is a real mess. >=20 > I wonder if we could afford to switch this one to -EINVAL and reduce > the mess. >=20 That's a really good question for which I think the answer is something close to: "that's impossible to predict". I could try some in-house (at redhat) automated tests to see if something break, but I doubt it is enough to catch any breakage. > Anyway, for a random reader, it might be pretty unclear what is > exactly special about /dev/kmsg. I wonder if the following might > be more explanatory and strightforward: >=20 > =09=09Other seek operations or offsets are not supported because of > =09=09the special behavior. The device allows to read or write > =09=09only whole variable lenght messages that are stored in > =09=09a ring buffer. >=20 > =09=09Because of the non-standard behavior also the error values > =09=09are non-standardand. -ESPIPE is returned for non-zero offset. > =09=09-EINVAL is returned for other operations, e.g. SEEK_CUR. > =09=09This behavior is historical and could not be modified > =09=09wihtout the risk of breaking userspace. >=20 Yes, no doubt it's better! >=20 > Finally, only few people read documentation. We should add some > warning also to the code. I think about a something like: >=20 > /* > * Be careful when modifying this function!!! > * > * Only few operations are supported because the device works only with > * the entire variable length messages. Non-standard error values are > * returned in the other cases. User space applications might depend > * on this behavior. > */ >=20 Agreed. I'm going to prepare a v2 of the patch adding the comments. Thanks Petr! --=20 bmeneg=20 PGP Key: http://bmeneg.com/pubkey.txt --AqsLC8rIMeq19msA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEdWo6nTbnZdbDmXutYdRkFR+RokMFAl8IaNwACgkQYdRkFR+R okPtSgf/RrbH0ofSXM+xsuCCXzWeCEsT590daxzzoFEMaGjZz1Bji9zW39bR3X7p jp+Pfx1N8W71xNgkdG1Nh++Yrq89/hBaDC1KZ7RRWVB3gCZSPQDl5rieDIEwyen1 M3j5skAjuR9Wpgbf3DeO5VyYYx2ek7Wj2HsWZN5TRfj6pqdMd7C65mklJ7+0h8Nu YzzJqJVeJgOqAg2PWJA5f3F+O1gXEfIk1Qq11ObAuUPqUbCzr0muYd/0DMO19IqB 7Vc/Ou/o6ynHFQ4h2x43FP1iD96eIhLR2Sl8/J8fKqMRa+18mpypXjSGa2tDMRLn GYB8m/zU8VUP3WFeUkHeUqpVWrOgTg== =voHf -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA--