[LU-3044] LSeek SEEK_CUR gives incorrect value after write when file is open with O_APPEND

• Type: Bug
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.4.0, Lustre 2.1.6
• Affects Version/s: Lustre 2.3.0
• Labels: patch
• Environment: SLES11SP1/SP2. Lustre 2.x.
• Severity: 3
• Assignee: Emoly Liu
• Reporter: Patrick Farrell (Inactive)

Description

When a file is opened with O_APPEND set, and data is written, the resulting value of the file pointer is incorrect. This is observed when using lseek with SEEK_CUR set.

This does not result in corruption on subsequent writes because with O_APPEND set, the file pointer is reset to EOF before each write. (See ULK3 on VFS)

I'm attaching a trivial reproducer for this problem.

A bit of debugging showed me that a correct value of the file pointer is available at the same point where it is set to the incorrect value in ll_file_io_generic.

Here's the sample (this is from 2.3, but the code is effectively the same in all 2.x releases) with my debug code in it to make clear exactly what I'm talking about:

ppos_out = (unsigned long) *ppos;
printk(KERN_NOTICE "ll_file_io_generic (before if) ppos: %lu\n",ppos_out);
if (io->ci_nob > 0) { 
    result = io->ci_nob; 
    *ppos = io->u.ci_wr.wr.crw_pos; 
    ppos_out = (unsigned long) *ppos;
    printk(KERN_NOTICE "ll_file_io_generic io->u.ci_wr.wr.crw_pos ppos:     %lu\n",ppos_out); 
}

The value of ppos before the *ppos = io->u.ci_wr.wr.crw_pos is correct, but the value in io->u.ci_wr.wr.crw_pos is not. It is greater than expected by approximately the number of bytes in the write. (See comment for further details.)

An if statement around the assignment checking for O_APPEND corrects the issue and passes acceptance-small sanity:

if(!cl_io_is_append(io)) { 
    *ppos = io->u.ci_wr.wr.crw_pos; 
}

Still, I am concerned this is a band-aid and a deeper fix may be necessary.

I have some more detailed information on exactly how much io->u.ci_wr.wr.crw_pos; that I'll put in a subsequent comment - It's lengthy, and may not be relevant to fixing the issue.

Issue Links

• is related to: LU-11069 ifort lseek returns wrong position on lustre 2.10.3
• is related to: LU-3440 ftello() system call not grok'ing with expected file position location

Comments

[Mark Abraham]

For the record, as reported in LU-3440, this bug can produce problems, including corruption.

If an ftell returns the incorrect file pointer, and the client assumes it is EOF like it should be, further processing based on (for example) a computed current file size will be wrong.

But I'm glad to see it is fixed

[Oleg Drokin]

This is also oalnded into b2_1 for 2.1.6

[Peter Jones]

Landed for 2.4

[Patrick Farrell (Inactive)]

Jinshan,

I am still waiting for review on the mod. Is there anyone else you would suggest to have review it?

Thanks,!

[Patrick Farrell (Inactive)]

Jinshan,

Thank you, I follow now. I've pushed a patch set with an updated commit message with your information.

• Patrick

[Jinshan Xiong (Inactive)]

We used to adjust crw_pos in ll_prepare_write() to survive the sanity check of LASSERT(cl_page_in_io(page, io)) in cl_io_prepare_write(). However, crw_pos is changed again cl_io_rw_advance() therefore append write has the issue of setting ppos wrong.

The adjustment is not needed anymore as we have changed cl_page_in_io() to exclude append write case.