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.
