Re: [PATCH v1 0/7] Remove in-tree usage of MAP_DENYWRITE

On Thu, 19 Aug 2021, J. Bruce Fields wrote:

On Fri, Aug 13, 2021 at 05:49:19PM -0700, Andy Lutomirski wrote:

quoted

I’ll bite.  How about we attack this in the opposite direction: remove
the deny write mechanism entirely.

For what it's worth, Windows has open flags that allow denying read or
write opens.  They also made their way into the NFSv4 protocol, but
knfsd enforces them only against other NFSv4 clients.  Last I checked,
Samba attempted to emulate them using flock (and there's a comment to
that effect on the flock syscall in fs/locks.c).  I don't know what Wine
does.

Pavel Shilovsky posted flags adding O_DENY* flags years ago:

	https://lwn.net/Articles/581005/

I keep thinking I should look back at those some day but will probably
never get to it.

O_DENYREAD is an insane flag.  If a process reads a file that some other
process is working on, then the only which could be hurt is the reader.
So allowing a process to ask for the open to fail if someone is writing
might make sense.  Insisting that all opens fail does not.
Any code wanting O_DENYREAD *should* use advisory locking, and any code
wanting to know about read denial should too.

O_DENYWRITE can make sense.  When combined with a O_RDONLY open it is
effectively what happens when you exec a program.  You can no longer
open that file for write - you get ETXTBSY.

It would be nice to be able to combine O_DENYWRITE with O_RDWR.  This
combination is exactly what the kernel *should* do for swap files.
Unfortunately it doesn't.  The "i_writecount" field that is used to
trigger ETXTBSY for executables doesn't work for the single-writer
model.

I'm not sure about O_DENYDELETE.  It is a lock on the name.  Unix has
traditionally used lock-files to lock a name.  The functionality makes
sense for processes with write-access to the directory...

NeilBrown