On Feb 10, 2014, at 2:10 PM, Al Viro <adilger@xxxxxxxxx> wrote:
> 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?
Indeed. This patch will fix the problem, please check the attachment for the patch.
Jinshan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Attachment:
0001-staging-lustre-llite-remove-lustre_generic_file_-rea.patch
Description: 0001-staging-lustre-llite-remove-lustre_generic_file_-rea.patch
