From: Steve Rago <sar@nec-labs.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] Allow O_SYNC to be set by fcntl(F_SETFL)
Date: Fri, 08 Apr 2011 13:39:16 -0400 [thread overview]
Message-ID: <4D9F4844.7090908@nec-labs.com> (raw)
In-Reply-To: <20110407143719.4044c00d.akpm@linux-foundation.org>
On 04/07/2011 05:37 PM, Andrew Morton wrote:
> (did I ever reply to this? I meant to ;))
>
> On Fri, 25 Feb 2011 16:52:36 -0500
> Steve Rago<sar@nec-labs.com> wrote:
>
>> This has probably been a problem since day 1 (I ran into this running the 2.4 kernel years ago; finally got around to
>> fixing it). The problem is that fcntl(fd, F_SETFL, flags|O_SYNC) appears to work, but silently ignores the O_SYNC flag.
>> Opening the file with O_SYNC works okay, but setting it later on via fcntl doesn't work.
>>
>>
>> Signed-off-by: Steve Rago<sar@nec-labs.com>
>> ---
>> fs/fcntl.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/fs/fcntl.c b/fs/fcntl.c
>> index cb10261..afd233a 100644
>> --- a/fs/fcntl.c
>> +++ b/fs/fcntl.c
>> @@ -143,7 +143,7 @@ SYSCALL_DEFINE1(dup, unsigned int, fildes)
>> return ret;
>> }
>>
>> -#define SETFL_MASK (O_APPEND | O_NONBLOCK | O_NDELAY | O_DIRECT | O_NOATIME)
>> +#define SETFL_MASK (O_APPEND | O_NONBLOCK | O_NDELAY | O_DIRECT | O_NOATIME | O_SYNC)
>
> Does any standard say that we should do this?
> http://pubs.opengroup.org/onlinepubs/007908799/xsh/fcntl.html does, I
> guess.
It's required by the Single UNIX Specification (POSIX.1). All other major platforms allow it to be set via fcntl. See
bugzilla.kernel.org bug ID #5994.
>
> I worry a bit that this change will surprise people. For example, this
> person:
> http://koders.com/c/fidA34D8D5EE9AA5D0AB0F3C604678E2E935E5B0246.aspx?s=dupa
> is going to wonder why his app suddenly got a lot slower!
>
> Sadly, the kernel silently ignores invalid set bits in `arg', so we
> have no reliable way of signaling to the user that our behaviour here
> changed.
>
> I wonder if we should sync the file when someone sets O_SYNC this way.
> If we don't then there is a period during which we have an fd which has
> O_SYNC set, but it has pending unwritten data. An O_SYNC fd should
> never be in such a state!
Why not? If I write something in non-synchronous mode, then change the file descriptor to synchronous mode, I should
not make any assumptions about what was written prior to this point. If I care that much, I'll call fsync. All that
matters is that the operating system honors the contract as specified by the system call API.
>
> Ho hum. yes, I guess we should apply the patch. But it would have
> been better to not have screwed this up in the first place!
>
>
Agreed. Thanks for not letting this fall through the cracks.
Steve
next prev parent reply other threads:[~2011-04-08 17:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-25 21:52 [PATCH] Allow O_SYNC to be set by fcntl(F_SETFL) Steve Rago
2011-04-07 21:37 ` Andrew Morton
2011-04-08 15:14 ` Christoph Hellwig
2011-04-08 17:39 ` Steve Rago [this message]
2011-04-08 17:56 ` Andrew Morton
2011-04-08 21:08 ` Christoph Hellwig
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=4D9F4844.7090908@nec-labs.com \
--to=sar@nec-labs.com \
--cc=akpm@linux-foundation.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.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.