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;
Date:   Fri, 13 Mar 2020 08:02:29 -0300
From:   Bruno Meneguele <bmeneg@redhat.com>
To:     Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc:     linux-kernel@vger.kernel.org, stable@vger.kernel.org,
        pmladek@suse.com, sergey.senozhatsky@gmail.com, rostedt@goodmis.org
Subject: Re: [PATCH] kernel/printk: add kmsg SEEK_CUR handling
Message-ID: <20200313110229.GI13406@glitch>
References: <20200313003533.2203429-1-bmeneg@redhat.com>
 <20200313073425.GA219881@google.com>
MIME-Version: 1.0
In-Reply-To: <20200313073425.GA219881@google.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="KrHCbChajFcK0yQE"
Content-Disposition: inline
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

--KrHCbChajFcK0yQE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 13, 2020 at 04:34:25PM +0900, Sergey Senozhatsky wrote:
> On (20/03/12 21:35), Bruno Meneguele wrote:
> >=20
> > Userspace libraries, e.g. glibc's dprintf(), expect the default return =
value
> > for invalid seek situations: -ESPIPE, but when the IO was over /dev/kms=
g the
> > current state of kernel code was returning the generic case of an -EINV=
AL.
> > Hence, userspace programs were not behaving as expected or documented.
> >=20
>=20
> Hmm. I don't think I see ESPIPE in documentation [0], [1], [2]
>=20
> [0] https://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.ht=
ml
> [1] http://man7.org/linux/man-pages/man3/dprintf.3p.html
> [2] http://man7.org/linux/man-pages/man3/fprintf.3p.html
>=20
> =09-ss
>=20

Ok, I poorly expressed the notion of "documentantion". The userspace
doesn't tell about returning -ESPIPE, but to the functions work properly
they watch for -ESPIPE returning from the syscall. For instance, gblic
dprintf() implementation:

dprintf:
  __vdprintf_internal:
    _IO_new_file_attach:

  if (_IO_SEEKOFF (fp, (off64_t)0, _IO_seek_cur, _IOS_INPUT|_IOS_OUTPUT)
      =3D=3D _IO_pos_BAD && errno !=3D ESPIPE)
    return NULL;

With that, if the seek fails, but return anything other than ESPIPE the
dprintf() will also fail returning -EINVAL to dprintf() caller. While if
ESPIPE is returned, it's "ignored" and the call still works. The way we
have today make kmsg an exception case among the rest of the system
files where you can open with dprintf.

One of the things I could agree with is removing the SEEK call from
dprintf, since fprintf basically follows the same steps, but doesn't
seek anything.  But at the same time, IMO it makes sense to make kmsg
interface complaint with the errno return values.

--=20
bmeneg=20
PGP Key: http://bmeneg.com/pubkey.txt

--KrHCbChajFcK0yQE
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEdWo6nTbnZdbDmXutYdRkFR+RokMFAl5raEUACgkQYdRkFR+R
okPnQAgAoEVvkr9xuWNi7/5UFSFUCzBWggHS62VeY1aVd+yBi04vKD0eeHERUsCV
0z4B/Bz9/6QvmuEMm1+xsOfzimrnhrvdJaf3i8o/4GPEZOiDfv7I/FRMd3eIFUtC
/BWcuRAd53x8zPDbqRrtfc/oHysW6ClTHu+DjIeidwDJ67W75u2hwRDaNf0sonu4
VA0+SyaLTtnFC+gYAh2vFpleQJ8feEEraFjFIhZLK0hP/5UTvCDv76GWG3WXaL1B
2nXGBf16LEe546UbPcSBhaRc+w9aaynfZUgj9GYbP5Mg29egSdhF6AEJ+Kq044pO
G3ZYD4XRaVtbvPTlCQD7yHUiKcSLfg==
=+ptV
-----END PGP SIGNATURE-----

--KrHCbChajFcK0yQE--