linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Reuben Hawkins <reubenhwk@gmail.com>,
	kernel test robot <oliver.sang@intel.com>,
	brauner@kernel.org, Cyril Hrubis <chrubis@suse.cz>,
	mszeredi@redhat.com, lkp@intel.com,
	linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk,
	oe-lkp@lists.linux.dev, ltp@lists.linux.it,
	Jan Kara <jack@suse.cz>
Subject: Re: [LTP] [PATCH] vfs: fix readahead(2) on block devices
Date: Mon, 25 Sep 2023 12:43:42 +0300	[thread overview]
Message-ID: <CAOQ4uxgUC2KxO2fD-rSgVo3RyrrWbP-UHH+crG57uwXVn_sf2Q@mail.gmail.com> (raw)
In-Reply-To: <ZREr3M32aIPfdem7@casper.infradead.org>

On Mon, Sep 25, 2023 at 9:42 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Sun, Sep 24, 2023 at 11:35:48PM -0500, Reuben Hawkins wrote:
> > The v2 patch does NOT return ESPIPE on a socket.  It succeeds.
> >
> > readahead01.c:54: TINFO: test_invalid_fd pipe
> > readahead01.c:56: TFAIL: readahead(fd[0], 0, getpagesize()) expected
> > EINVAL: ESPIPE (29)
> > readahead01.c:60: TINFO: test_invalid_fd socket
> > readahead01.c:62: TFAIL: readahead(fd[0], 0, getpagesize()) succeeded
> > <-------here
>
> Thanks!  I am of the view that this is wrong (although probably
> harmless).  I suspect what happens is that we take the
> 'bdi == &noop_backing_dev_info' condition in generic_fadvise()
> (since I don't see anywhere in net/ setting f_op->fadvise) and so
> return 0 without doing any work.
>
> The correct solution is probably your v2, combined with:
>
>         inode = file_inode(file);
> -       if (S_ISFIFO(inode->i_mode))
> +       if (S_ISFIFO(inode->i_mode) || S_ISSOCK(inode->i_mode))
>                 return -ESPIPE;
>
> in generic_fadvise(), but that then changes the return value from
> posix_fadvise(), as I outlined in my previous email.  And I'm OK with
> that, because I think it's what POSIX intended.  Amir may well disagree
> ;-)

I really have no problem with that change to posix_fadvise().
I only meant to say that we are not going to ask Reuben to talk to
the standard committee, but that's obvious ;-)
A patch to man-pages, that I would recommend as a follow up.

FWIW, I checked and there is currently no test for
posix_fadvise() on socket in LTP AFAIK.
Maybe Cyril will follow your suggestion and this will add test
coverage for socket in posix_fadvise().

Reuben,

The actionable item, if all agree with Matthew's proposal, is
not to change the v2 patch to readahead(), but to send a new
patch for generic_fadvise().

When you send the patch to Christian, you should specify
the dependency - it needs to be applied before the readahead
patch.

If the readahead patch was not already in the vfs tree, you
would have needed to send a patch series with a cover letter,
where you would leave the Reviewed-by on the unchanged
[2/2] readahead patch.

Sending a patch series is a good thing to practice, but it is
not strictly needed in this case, so I'll leave it up to you to decide.

Thanks,
Amir.

  reply	other threads:[~2023-09-25  9:43 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-09  4:38 [PATCH] vfs: fix readahead(2) on block devices Reuben Hawkins
2023-09-09  6:36 ` Amir Goldstein
2023-09-10 10:02   ` Christian Brauner
2023-09-11  8:15     ` Amir Goldstein
2023-09-19  2:47 ` kernel test robot
2023-09-19  8:43   ` Amir Goldstein
     [not found]     ` <CAD_8n+TpZF2GoE1HUeBLs0vmpSna0yR9b+hsd-VC1ZurTe41LQ@mail.gmail.com>
2023-09-21 14:44       ` Amir Goldstein
2023-09-22  9:10       ` [LTP] " Cyril Hrubis
     [not found]         ` <CAD_8n+ShV=HJuk5v-JeYU1f+MAq1nDz9GqVmbfK9NpNThRjzSg@mail.gmail.com>
2023-09-23  5:56           ` Amir Goldstein
2023-09-23 14:41             ` Matthew Wilcox
2023-09-23 15:48               ` Amir Goldstein
     [not found]                 ` <CAD_8n+SNKww4VwLRsBdOg+aBc7pNzZhmW9TPcj9472_MjGhWyg@mail.gmail.com>
2023-09-24  6:46                   ` Amir Goldstein
2023-09-24 11:47                     ` Amir Goldstein
2023-09-24 14:27                       ` Matthew Wilcox
2023-09-24 15:32                         ` Amir Goldstein
2023-09-24 21:56                           ` Matthew Wilcox
     [not found]                             ` <CAD_8n+SBo4EaU4-u+DaEFq3Bgii+vX0JobsqJV-4m+JjY9wq8w@mail.gmail.com>
2023-09-25  6:42                               ` Matthew Wilcox
2023-09-25  9:43                                 ` Amir Goldstein [this message]
2023-09-25 12:39                                   ` Christian Brauner
     [not found]                                   ` <CAD_8n+QeGwf+CGNW_WnyRNQMu9G2_HJ4RSwJGq-b4CERpaA4uQ@mail.gmail.com>
2023-09-25 16:51                                     ` Amir Goldstein
2023-09-26 10:08                                       ` Christian Brauner
2023-09-26  1:56                           ` Oliver Sang
2023-09-26  5:34                             ` Amir Goldstein

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=CAOQ4uxgUC2KxO2fD-rSgVo3RyrrWbP-UHH+crG57uwXVn_sf2Q@mail.gmail.com \
    --to=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=chrubis@suse.cz \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=ltp@lists.linux.it \
    --cc=mszeredi@redhat.com \
    --cc=oe-lkp@lists.linux.dev \
    --cc=oliver.sang@intel.com \
    --cc=reubenhwk@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).