Re: [PATCH 1/2] fs: remove kiocb.ki_hint

Keith Busch
2022-03-22T02:57:29Z

On Mon, Mar 21, 2022 at 08:50:10PM -0600, Jens Axboe wrote:
> On 3/21/22 8:45 PM, Matthew Wilcox wrote:
> > On Mon, Mar 21, 2022 at 08:13:10PM -0600, Jens Axboe wrote:
> >> On 3/8/22 5:55 PM, Jens Axboe wrote:
> >>> On Tue, 8 Mar 2022 07:05:28 +0100, Christoph Hellwig wrote:
> >>>> This field is entirely unused now except for a tracepoint in f2fs, so
> >>>> remove it.
> >>>>
> >>>>
> >>>
> >>> Applied, thanks!
> >>>
> >>> [1/2] fs: remove kiocb.ki_hint
> >>> commit: 41d36a9f3e5336f5b48c3adba0777b8e217020d7
> >>> [2/2] fs: remove fs.f_write_hint
> >>> commit: 7b12e49669c99f63bc12351c57e581f1f14d4adf
> >>
> >> Upon thinking about the EINVAL solution a bit more, I do have a one
> >> worry - if you're currently using write_hints in your application,
> >> nobody should expect upgrading the kernel to break it. It's a fine
> >> solution for anything else, but that particular point does annoy me.
> >
> > But if your application is run on an earlier kernel, it'll get
> > -EINVAL. So it must already be prepared to deal with that?
>
> Since support wasn't there, it's not unreasonable to expect that an
> application was written on a newer kernel. Might just be an in-house or
> application thing, who knows? But the point is that upgrading from 5.x
> to 5.x+1, nobody should expect their application to break. And it will
> with this change. If you downgrade a kernel and a feature didn't exist
> back then, it's reasonable to expect that things may break.
>
> Maybe this is being overly cautious, but... As a matter of principle,
> it's unquestionably wrong.
>
> We can just let Linus make the decision here, arming him with the info
> he needs to make it in terms of hardware support. I'll write that up in
> the pull request.

It's really just an advisory hint at the hardware level anyway, so
returning success without actually doing anything with it technically
satisfies the requirement.