Re: RFC: [PATCH] staging/lustre/llite: fix O_TMPFILE/O_LOV_DELAY_CREATE conflict

[Al Viro <viro@ZenIV.linux.org.uk>]

On Mon, Feb 10, 2014 at 09:29:29PM +0000, Al Viro wrote:
> On Mon, Feb 10, 2014 at 08:16:52PM +0000, Dilger, Andreas wrote:
> 
> > >>Instead of trying to find a non-conflicting O_LOV_DELAY_CREATE flag
> > >>or define a Lustre-specific flag that isn't of use to most/any other
> > >>filesystems, use (O_NOCTTY|FASYNC) as the new value.  These flag
> > >>are not meaningful for newly-created regular files and should be
> > >>OK since O_LOV_DELAY_CREATE is only meaningful for new files.
> 
> *shrug*
> 
> I can live with that; it's a kludge, but it's less broken than that
> explicit constant - that one is a non-starter, since O_... flag
> values are arch-dependent.
> 
> 	I have another question about what you are doing there - the games
> you are playing with crw_pos.  Is there any reason not to have ->ki_pos
> updated immediately in lustre_generic_file_read()/lustre_generic_file_write()?
> 
> 	These two are the only places in the entire tree where
> generic_file_aio_{read,write}() does *not* have ppos argument
> equal to &iocb->ki_pos and I would very much prefer to kill the
> sucker off.

Ugh...  Sorry, I misread that code.  Why the devil do you have the
pos argument passed to lustre_generic_file_{read,write}() by address,
when both proceed to dereference it and pass the value on?