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] [thread-next>] [day] [month] [year] [list]
Message-ID: <rmivbuqy3hr.fsf@fnord.ir.bbn.com>
Date:	Thu, 03 Apr 2014 08:57:52 -0400
From:	Greg Troxel <gdt@...bbn.com>
To:	"Michael Kerrisk \(man-pages\)" <mtk.manpages@...il.com>
Cc:	Richard Hansen <rhansen@....com>,
	Steven Whitehouse <swhiteho@...hat.com>,
	Christoph Hellwig <hch@...radead.org>,
	"linux-mm\@kvack.org" <linux-mm@...ck.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Linux API <linux-api@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH] mm: msync: require either MS_ASYNC or MS_SYNC


"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com> writes:

> I think the only reasonable solution is to better document existing
> behavior and what the programmer should do. With that in mind, I've
> drafted the following text for the msync(2) man page:
>
>     NOTES
>        According to POSIX, exactly one of MS_SYNC and MS_ASYNC  must  be
>        specified  in  flags.   However,  Linux permits a call to msync()
>        that specifies neither of these flags, with  semantics  that  are
>        (currently)  equivalent  to  specifying  MS_ASYNC.   (Since Linux
>        2.6.19, MS_ASYNC is in fact a no-op, since  the  kernel  properly
>        tracks  dirty  pages  and  flushes them to storage as necessary.)
>        Notwithstanding the Linux behavior, portable, future-proof appliā€
>        cations  should  ensure  that they specify exactly one of MS_SYNC
>        and MS_ASYNC in flags.
>
> Comments on this draft welcome.

I think it's a step backwards to document unspecified behavior.  If
anything, the man page should make it clear that providing neither flag
results in undefined behavior and will lead to failure on systems on
than Linux.  While I can see the point of not changing the previous
behavior to protect buggy code, there's no need to document it in the
man page and further enshrine it.

There's a larger point, which is that people write code for Linux when
they should be writing code for POSIX.  Therefore, Linux has an
obligation to the larger free software community to avoid encouraging
non-portable code.  This is somewhat similar (except for the key point
that it's unintentional) to bash's allowing "==" in test, which is a
gratuitous extension to the standard that has led to large amounts of
nonportable code.  To mitigate this, it would be reasonable to syslog a
warning the first time a process makes a call with flags that POSIX says
leads to undefined behavior.  That would meet the
portability-citizenzhip goals and not break existing systems.

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ