Hey there,
We're the teaching staff for Columbia University's graduate-level operating
systems course and something came up as we were improving our filesystem
assignment.
For context, we have students develop a very simple filesystem that implements
the `read()`/`write()` `struct file_operations` functions as opposed to
`read_iter()`/`write_iter()`.
We noticed that the following bash redirection didn't work as expected in our
filesystem: `echo test >> foo.txt`. The write would occur at the beginning of
the file because the `ppos` argument to `write()` was set to 0. Through
`strace`, we verified that bash opens the file with `O_APPEND` so we assumed
that VFS would handle setting `ppos` to the file size for us, yet it did not.
We dug through kernel code to see if other filesystems explicitly account for
this case and surely enough, they do! Most of the filesystems we saw
directly/indirectly call `generic_write_checks()` which is implemented for
`write_iter()` usage. We were able to solve our bug by simply porting the
following logic for our version of `write()`:
/* FIXME: this is for backwards compatibility with 2.4 */
if (iocb->ki_flags & IOCB_APPEND)
iocb->ki_pos = i_size_read(inode);
We noticed the FIXME comment and we weren't sure exactly what it meant so we
kept tracing through older versions of `generic_write_checks()`, going as far as
Linux 2.5.75, before it was implemented for `write_iter()` usage:
if (!isblk) {
/* FIXME: this is for backwards compatibility with 2.4 */
if (file->f_flags & O_APPEND)
*pos = inode->i_size;
...
}
Can someone explain what this comment is referring to? And why does `!isblk`
matter?
Furthermore, why doesn't VFS do the `O_APPEND` check itself instead of
delegating the task to the filesystems? It seems like a universal check,
especially given the following snippet on `O_APPEND` from the man page for
open(2):
APPEND
The file is opened in append mode. Before each write(2), the file offset
is positioned at the end of the file, as if with lseek(2).
Best,
Hans
