From: Hans Montero <hjm2133@columbia.edu>
To: linux-fsdevel@vger.kernel.org
Cc: Tal Zussman <tz2294@columbia.edu>,
Xijiao Li <xl2950@columbia.edu>,
OS-TA <cucs4118-tas@googlegroups.com>
Subject: Question about `generic_write_checks()` FIXME comment
Date: Thu, 30 Dec 2021 03:07:25 -0500 [thread overview]
Message-ID: <CAMqPytVSCD+6ER+uXa-SrXQCpY-U-34G1jWmprR1Zgag+wBqTA@mail.gmail.com> (raw)
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
next reply other threads:[~2021-12-30 9:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-30 8:07 Hans Montero [this message]
2021-12-30 13:59 ` Question about `generic_write_checks()` FIXME comment Al Viro
2021-12-30 19:04 ` Theodore Ts'o
2021-12-30 20:06 ` Al Viro
2021-12-31 7:23 ` Tal Zussman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMqPytVSCD+6ER+uXa-SrXQCpY-U-34G1jWmprR1Zgag+wBqTA@mail.gmail.com \
--to=hjm2133@columbia.edu \
--cc=cucs4118-tas@googlegroups.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=tz2294@columbia.edu \
--cc=xl2950@columbia.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.