All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tejun Heo <tj@kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RESEND] fs: sysfs: return EFBIG on write if offset is larger than binary file size
Date: Thu, 23 Oct 2014 15:56:33 +0300	[thread overview]
Message-ID: <5448FB01.1090108@mentor.com> (raw)
In-Reply-To: <20141009184631.GA17554@mtj.dyndns.org>

Hello Greg,

On 09.10.2014 21:46, Tejun Heo wrote:
> 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 <vladimir_zapolskiy@mentor.com>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Cc: Tejun Heo <tj@kernel.org>
> 
> 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 <tj@kernel.org>
> 
> Please also cc stable.
> 
> Thanks.

have you had time to look at the problem? Understanding the risk of the
change, should the inconsistency with POSIX be documented in
Documentation/ABI/stable/syscalls instead?

With best wishes,
Vladimir

      reply	other threads:[~2014-10-23 12:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-09 17:41 [PATCH RESEND] fs: sysfs: return EFBIG on write if offset is larger than binary file size Vladimir Zapolskiy
2014-10-09 18:46 ` Tejun Heo
2014-10-23 12:56   ` Vladimir Zapolskiy [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5448FB01.1090108@mentor.com \
    --to=vladimir_zapolskiy@mentor.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.