All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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.