All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Black <daniel@mariadb.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: fcntl(fd, F_SETFL, O_DIRECT) succeeds followed by EINVAL in write
Date: Thu, 27 Jan 2022 13:38:58 +1100	[thread overview]
Message-ID: <CABVffEM4KhSNywBVg06XN5JpsDaONKf7wQiKvrTvqGXosssXLg@mail.gmail.com> (raw)
In-Reply-To: <YfC5vuwQyxoMfWLP@casper.infradead.org>

On Wed, Jan 26, 2022 at 2:02 PM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Wed, Jan 26, 2022 at 09:05:48AM +1100, Daniel Black wrote:
> > The kernel code in setfl seems to want to return EINVAL for
> > filesystems without a direct_IO structure member assigned,
> >
> > A noop_direct_IO seems to be used frequently to just return EINVAL
> > (like cifs_direct_io).
>
> Sorry for the confusion.  You've caught us mid-transition.  Eventually,
> ->direct_IO will be deleted, but for now it signifies whether or not the
> filesystem supports O_DIRECT, even though it's not used (except in some
> scenarios you don't care about).

diff --git a/fs/fcntl.c b/fs/fcntl.c
index 9c6c6a3e2de5..ff55a904bb4e 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -58,7 +58,8 @@ static int setfl(int fd, struct file * filp,
unsigned long arg)
        /* Pipe packetized mode is controlled by O_DIRECT flag */
        if (!S_ISFIFO(inode->i_mode) && (arg & O_DIRECT)) {
                if (!filp->f_mapping || !filp->f_mapping->a_ops ||
-                       !filp->f_mapping->a_ops->direct_IO)
+                       !filp->f_mapping->a_ops->direct_IO ||
+                       filp->f_mapping->a_ops->direct_IO == noop_direct_IO)
                                return -EINVAL;
        }

The above patch prevents:

  filp->f_flags = (arg & SETFL_MASK) | (filp->f_flags & ~SETFL_MASK);

being executed at the bottom of setfl which keeps the file descriptor
out of O_DIRECT mode when
the filesystem (like CIFS doesn't support it). In the original strace

So while you are mid-transition, the relatively simple flag of
direct_IO is good enough a protection
for a file descriptor entering a mode that isn't supported.

Is this an acceptable stop gap concept and/or stable backport?

>.., but I'm not quite sure what limitations cifs imposes.

Given cifs_direct_io is equivalent to the noop_direct_IO return
-EINVAL now, there's no direct io
there as I discovered testing the bug report
https://jira.mariadb.org/browse/MDEV-26970.

My patch two of the series would be to replace cifs_direct_io with
noop_direct_IO.

  parent reply	other threads:[~2022-01-27  2:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-25 22:05 fcntl(fd, F_SETFL, O_DIRECT) succeeds followed by EINVAL in write Daniel Black
2022-01-26  3:02 ` Matthew Wilcox
2022-01-26 22:03   ` Daniel Black
2022-01-26 22:15     ` Matthew Wilcox
2022-01-26 23:16       ` Daniel Black
2022-01-27  2:38   ` Daniel Black [this message]
2022-01-27  4:37     ` Matthew Wilcox

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=CABVffEM4KhSNywBVg06XN5JpsDaONKf7wQiKvrTvqGXosssXLg@mail.gmail.com \
    --to=daniel@mariadb.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=willy@infradead.org \
    /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.