[Bugme-new] [Bug 11014] New: Weird select(2) behaviour with certain files in sysfs

[bugme-daemon at bugzilla.kernel.org]

http://bugzilla.kernel.org/show_bug.cgi?id=11014

           Summary: Weird select(2) behaviour with certain files in sysfs
           Product: File System
           Version: 2.5
     KernelVersion: 2.6.25.4
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: SysFS
        AssignedTo: greg at kroah.com
        ReportedBy: der_julian at web.de


Latest working kernel version: -
Earliest failing kernel version: 2.6.20 (oldest I could find)
Distribution: Gentoo
Hardware Environment: Thinkpad X60s (see
http://thinkwiki.org/wiki/Category:X60s ), but also reproducible on PPC64 box.
Software Environment: Gentoo Linux 2008.0, GCC 4.1.2
Problem Description:

The select man page states that select returns, once one of the file
descriptors it is passed is "ready". Where ready means that the requested I/O
operation can be done without blocking. Files in sysfs seem to violate this
property, specifically in the case where a file descriptor is at the EOF. 

Consider reading a complete file via non-blocking I/O. In pseudo code this
would look like:

fd = open_nonblocking(filename)

do 
 test for data on fd via select
 bytes_read = read(fd)
while bytes_read > 0

In particular, EOF means that select returns immediately and the following read
returns 0 to indicate the EOF condition.

If you try that on files in sysfs (e.g. /sys/class/input/input0/name or
/sys/class/power_supply/AC/type ), select will block permanently (or timeout,
if you set one) instead of returning immediately when the EOF is reached. This
violates the sentence in the man page, since the requested read operation
wouldn't block.

SBCL (Steel Bank Common Lisp, see sbcl.org) does file I/O in more or less this
way and thus cannot read these files in sysfs. 

Steps to reproduce:
Get http://www1.inf.tu-dresden.de/~s1054849/kernbug.c which is a small C
program implementing the pseudo code above. Compile it via cc -o kernbug
kernbug.c. Now you can try it out. First a positive example:

% ./kernbug /proc/cpuinfo 
Read 512 bytes.
Read 512 bytes.
Read 126 bytes.
Read 0 bytes.
EOF

Now a negative one:

% ./kernbug /sys/class/input/input0/name 
Read 18 bytes.
Timeout...
^C

and another one:

% ./kernbug /sys/class/power_supply/AC/type 
Read 6 bytes.
Timeout...
^C


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.