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. -- Jens Axboe
