All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Reuben Hawkins <reubenhwk@gmail.com>
Cc: mszeredi@redhat.com, brauner@kernel.org, Jan Kara <jack@suse.cz>,
	lkp@intel.com, oe-lkp@lists.linux.dev,
	kernel test robot <oliver.sang@intel.com>,
	viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org,
	ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] vfs: fix readahead(2) on block devices
Date: Mon, 25 Sep 2023 07:42:36 +0100	[thread overview]
Message-ID: <ZREr3M32aIPfdem7@casper.infradead.org> (raw)
In-Reply-To: <CAD_8n+SBo4EaU4-u+DaEFq3Bgii+vX0JobsqJV-4m+JjY9wq8w@mail.gmail.com>

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
;-)

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

WARNING: multiple messages have this Message-ID (diff)
From: Matthew Wilcox <willy@infradead.org>
To: Reuben Hawkins <reubenhwk@gmail.com>
Cc: Amir Goldstein <amir73il@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 07:42:36 +0100	[thread overview]
Message-ID: <ZREr3M32aIPfdem7@casper.infradead.org> (raw)
In-Reply-To: <CAD_8n+SBo4EaU4-u+DaEFq3Bgii+vX0JobsqJV-4m+JjY9wq8w@mail.gmail.com>

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
;-)

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

Thread overview: 49+ 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 ` [LTP] " kernel test robot
2023-09-19  2:47   ` kernel test robot
2023-09-19  8:43   ` [LTP] " Amir Goldstein
2023-09-19  8:43     ` Amir Goldstein
2023-09-21 13:01     ` [LTP] " Reuben Hawkins
2023-09-21 14:44       ` Amir Goldstein
2023-09-21 14:44         ` Amir Goldstein
2023-09-22  9:10       ` [LTP] " Cyril Hrubis
2023-09-22  9:10         ` Cyril Hrubis
2023-09-22 20:29         ` Reuben Hawkins
2023-09-23  5:56           ` Amir Goldstein
2023-09-23  5:56             ` Amir Goldstein
2023-09-23 12:20             ` Reuben Hawkins
2023-09-23 12:28               ` Reuben Hawkins
2023-09-23 14:41             ` Matthew Wilcox
2023-09-23 14:41               ` Matthew Wilcox
2023-09-23 15:48               ` Amir Goldstein
2023-09-23 15:48                 ` Amir Goldstein
2023-09-24  3:48                 ` Reuben Hawkins
2023-09-24  6:46                   ` Amir Goldstein
2023-09-24  6:46                     ` Amir Goldstein
2023-09-24 11:47                     ` Amir Goldstein
2023-09-24 11:47                       ` Amir Goldstein
2023-09-24 14:27                       ` Matthew Wilcox
2023-09-24 14:27                         ` Matthew Wilcox
2023-09-24 15:32                         ` Amir Goldstein
2023-09-24 15:32                           ` Amir Goldstein
2023-09-24 21:56                           ` Matthew Wilcox
2023-09-24 21:56                             ` Matthew Wilcox
2023-09-25  4:35                             ` Reuben Hawkins
2023-09-25  6:42                               ` Matthew Wilcox [this message]
2023-09-25  6:42                                 ` Matthew Wilcox
2023-09-25  9:43                                 ` Amir Goldstein
2023-09-25  9:43                                   ` Amir Goldstein
2023-09-25 12:39                                   ` Christian Brauner
2023-09-25 12:39                                     ` Christian Brauner
2023-09-25 15:36                                   ` Reuben Hawkins
2023-09-25 16:51                                     ` Amir Goldstein
2023-09-25 16:51                                       ` Amir Goldstein
2023-09-26 10:08                                       ` Christian Brauner
2023-09-26 10:08                                         ` Christian Brauner
2023-09-26  1:56                           ` Oliver Sang
2023-09-26  1:56                             ` Oliver Sang
2023-09-26  5:34                             ` Amir Goldstein
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=ZREr3M32aIPfdem7@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=brauner@kernel.org \
    --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 \
    /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.