From: Christian Brauner <brauner@kernel.org>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Reuben Hawkins <reubenhwk@gmail.com>,
Matthew Wilcox <willy@infradead.org>,
kernel test robot <oliver.sang@intel.com>,
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: Tue, 26 Sep 2023 12:08:43 +0200 [thread overview]
Message-ID: <20230926-leinen-kaltlassen-b5cef5a1e877@brauner> (raw)
In-Reply-To: <CAOQ4uxh7+avP=m8DW_u14Ea4Hrk1xhyuT--t2XX868CBquOCaA@mail.gmail.com>
> What you are saying makes sense.
> And if we are being honest, I think that the right thing to do from the
> beginning was to separate the bug fix commit from the UAPI change.
>
> The minimal bug fix is S_ISREG || S_ISBLK, which
> mentions the Fixes commit and will be picked for stable kernels.
>
> Following up with another one or two patches that change
> the behavior of posix_fadvise on socket and readahead on
> socket and pipe.
>
> The UAPI change is not something that has to go to stable
> and it should be easily revertable independently of the bug fix.
> Doing it otherwise would make our lives much harder if regressions
> turn up from the UAPI change.
>
> Christian, Matthew,
>
> Do you agree?
Fine by me.
next prev parent reply other threads:[~2023-09-26 10:08 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
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 [this message]
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=20230926-leinen-kaltlassen-b5cef5a1e877@brauner \
--to=brauner@kernel.org \
--cc=amir73il@gmail.com \
--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