Hello, Vladimir. On Thu, Oct 09, 2014 at 08:41:55PM +0300, Vladimir Zapolskiy wrote: > According to the user expectations common utilities like dd or sh > redirection operator '>' should work correctly over binary files from > sysfs. At the moment doing excessive write can not be ever completed > (no error is returned), e.g. for 4-byte file: > > write(1, "\0\0\0\0\0\0\0\0", 8) = 4 > write(1, "\0\0\0\0", 4) = 0 > write(1, "\0\0\0\0", 4) = 0 > write(1, "\0\0\0\0", 4) = 0 > write(1, "\0\0\0\0", 4) = 0 > write(1, "\0\0\0\0", 4) = 0 > ....... > > This is not a successful completion of write(2), so fix the problem by > returning EFBIG as described in POSIX.1-2001: > > [EFBIG] > The file is a regular file, nbyte is greater than 0, and the > starting position is greater than or equal to the offset maximum > established in the open file description associated with fildes. > > Note, the write(2) ABI is changed, however > 1) write(2) behaviour is corrected in conformance to POSIX, the > existing userspace applications must be aware of possible errors on > a syscall, > 2) the return value is changed on error path, so it is an exceptional > situation, > 3) the change is related only to binary sysfs files, which is a very > small class of files, mainly representing non-volatile registers or > ram, eeproms etc, many of such files are read-only. > > Presumably it is safe to apply the change, the described problem is > definitely in the kernel and userspace utilities can not be changed to > process 0 return value as an error, because it is just not an error > according to POSIX. > > Signed-off-by: Vladimir Zapolskiy <[email protected]> > Cc: Greg Kroah-Hartman <[email protected]> > Cc: Tejun Heo <[email protected]>
This is a bit risky but the current behavior is problematic and as you pointed out the danger of actual breakge is relatively low. We might as well give it a shot. Cautiously-acked-by: Tejun Heo <[email protected]> Please also cc stable. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
