linux-kernel - Re: [PATCH] fsync.2: ERRORS: add EIO and ENOSPC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20f8c520-49e2-142b-df75-4980a76f3c38@gmail.com>
Date:   Thu, 17 Sep 2020 09:01:09 +0200
From:   "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:     NeilBrown <neilb@...e.de>, Jeff Layton <jlayton@...nel.org>,
        Jan Kara <jack@...e.cz>
Cc:     mtk.manpages@...il.com, milan.opensource@...il.com,
        lkml <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH] fsync.2: ERRORS: add EIO and ENOSPC

On 9/17/20 1:25 AM, NeilBrown wrote:
> On Thu, Sep 10 2020, Jeff Layton wrote:
>>
>>> Regarding your "NOTES" addition, I don't feel comfortable with the
>>> "clean" language.  I would prefer something like:
>>>
>>>  When fsync() reports a failure (EIO, ENOSPC, EDQUOT) it must be assumed
>>>  that any write requests initiated since the previous successful fsync
>>>  was initiated may have failed, and that any cached data may have been
>>>  lost.  A future fsync() will not attempt to write out the same data
>>>  again.  If recovery is possible and desired, the application must
>>>  repeat all the writes that may have failed.
>>>
>>>  If the regions of a file that were written to prior to a failed fsync()
>>>  are read, the content reported may not reflect the stored content, and
>>>  subsequent reads may revert to the stored content at any time.
>>>
>>
>> Much nicer.
> 
> I guess someone should turn it into a patch....

That woud be great.

>> Should we make a distinction between usage and functional classes of
>> errors in this? The "usage" errors will probably not result in the pages
>> being tossed out, but the functional ones almost certainly will...
> 
> Maybe.  I think it is a useful distinction, but to be consistent it
> would be best to make it in all (section 2) man pages.  Maybe not all at
> once though.  It is really up to Michael if that is a direction he is
> interesting in following.

I think it's useful, and I'd accept patches that make such
distinctions. Of course, if we said *everything* should get fixed
at the same time, nothing would get fixed :-). So, I think
I'd just take individual patches that made such changes on an
ad hoc basis.

Thanks,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/