Summary: | dprintf fails when file descriptor is connected to /dev/kmsg | ||
---|---|---|---|
Product: | glibc | Reporter: | Mike Crowe <mac> |
Component: | stdio | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | bugdal |
Priority: | P2 | Flags: | fweimer:
security-
|
Version: | 2.19 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: |
Description
Mike Crowe
2015-01-12 12:33:16 UTC
I think this is a bug in the /dev/kmsg driver. It should return ESPIPE instead of EBADF. The problem appears to be that devkmsg_open returns without allocating a devkmsg_user struct if opened with O_WRONLY, which causes devkmsg_llseek to return EBADF, even though the file is properly opened. Please report that to the kernel devs. (In reply to Andreas Schwab from comment #2) > The problem appears to be that devkmsg_open returns without allocating a > devkmsg_user struct if opened with O_WRONLY, which causes devkmsg_llseek to > return EBADF, even though the file is properly opened. Please report that > to the kernel devs. I think that's intentional. A write-only /dev/kmsg is intended to be lighter-weight than a readable one. What seems to be wrong is unconditionally returning EBADF in that situation. ESPIPE would presumably be better. Even if the device were opened for reading too and we got past that point I think dprintf would still get upset since SEEK_CUR isn't handled so devkmsg_llseek would yield EINVAL. I think both cases need fixing. I'll try posting a kernel patch. Thanks for your help. (In reply to Mike Crowe from comment #3) > Even if the device were opened for reading too and we got past that point I > think dprintf would still get upset since SEEK_CUR isn't handled so > devkmsg_llseek would yield EINVAL. This case can be reproduced with "./a.out 1<>/dev/kmsg" which yields: Result: -1 Invalid argument (In reply to Andreas Schwab from comment #2) > Please report that to the kernel devs. http://lkml.iu.edu/hypermail/linux/kernel/1501.1/05813.html Isn't it something of a bug (performance, if nothing else) that dprintf is making useless seek attempts on the file descriptor? Are they useless? Yes. Presumably the seek is part of setting up the general-case FILE for glibc's libio stdio ops to know about, but it's completely irrelevant to a single write-only operation on a temporary FILE structure. dprintf should be operating more like the virtual FILEs used for snprintf, fmemopen, fopencookie, etc. rather than using the same ops as fopen so it doesn't pull in all this overhead to every write. |