On Fri, Mar 13, 2020 at 04:34:25PM +0900, Sergey Senozhatsky wrote: > On (20/03/12 21:35), Bruno Meneguele wrote: > > > > Userspace libraries, e.g. glibc's dprintf(), expect the default return value > > for invalid seek situations: -ESPIPE, but when the IO was over /dev/kmsg the > > current state of kernel code was returning the generic case of an -EINVAL. > > Hence, userspace programs were not behaving as expected or documented. > > > > Hmm. I don't think I see ESPIPE in documentation [0], [1], [2] > > [0] https://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html > [1] http://man7.org/linux/man-pages/man3/dprintf.3p.html > [2] http://man7.org/linux/man-pages/man3/fprintf.3p.html > > -ss > 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) == _IO_pos_BAD && errno != 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. -- bmeneg PGP Key: http://bmeneg.com/pubkey.txt
Attachment:
signature.asc
Description: PGP signature
