On Sun, May 25, 2025 at 09:48:45PM +0100, Matthew Wilcox wrote:
> On Sun, May 25, 2025 at 01:32:33PM -0700, Linus Torvalds wrote:
> > But yeah, maybe the drop-behind case never triggers in practice, and I
> > should just revert commit 974c5e6139db ("xfs: flag as supporting
> > FOP_DONTCACHE") for now.
> >
> > That's kind of sad too, but at least that's new to 6.15 and we
> > wouldn't have a kernel release that triggers this issue.
> >
> > I realize that Vlastimil had a suggested possible fix, but doing
> > _that_ kind of surgery at this point in the release isn't an option,
> > I'm afraid. And delaying 6.15 for this also seems a bit excessive - if
> > it turns out to be easy to fix, we can always just backport the fix
> > and undo the revert.
> >
> > Sounds like a plan?
> >
> > I'm somewhat surprised that this was only noticed now if it triggers
> > so easily for Al with xfstests on xfs. But better late than never, I
> > guess..
>
> I wonder if we shouldn't do ...
>
> +++ b/include/linux/fs.h
> @@ -3725,6 +3725,8 @@ static inline int kiocb_set_rw_flags(struct kiocb *ki, rwf_t flags,
> return -EOPNOTSUPP;
> }
> if (flags & RWF_DONTCACHE) {
> + /* Houston, we have a problem */
> + return -EOPNOTSUPP;
> /* file system must support it */
> if (!(ki->ki_filp->f_op->fop_flags & FOP_DONTCACHE))
> return -EOPNOTSUPP;
>
Perhaps
-#define FOP_DONTCACHE ((__force fop_flags_t)(1 << 7)) when shit gets fixed
+#define FOP_DONTCACHE 0 // ((__force fop_flags_t)(1 << 7)) when shit gets fixed
instead?
