Comment 13 for bug 2041670

Artem: thanks for the Cc.

Colin: I think you misread the reproducer output for 6.6-rc, that's
precisely the release in which this is (unwittingly) fixed on tmpfs:
not by failing the creat part, but by allowing O_DIRECT open and I/O -
it gives me "open succeeded", "stat succeeded", "unlink succeeded".

(That's if I "sudo ./reproducer", or remove "sudo chmod 666 /mnt/tmpfs"
from its preliminary instructions - maybe that line was a braino? It
gives me "open failed, errno=13 (Permission denied)", "stat" likewise.)

So, nothing to do for tmpfs at all (this is not worth a stable backport).

As for ramfs: yes, I agree with you that it's nicer not to creat anything
when the open is going to fail; and your minix link does indicate that
Christian and Jan have previously accepted that pragmatic solution, of
allowing the O_DIRECT open but then failing at the I/O stage.

So if you want ramfs changed, how about sending a noop_direct_IO patch
to ram_aops in fs/libfs.c? But please do Cc <email address hidden>: he's on
his way to eliminating the direct_IO method entirely. There appears to
be plenty of noop_direct_IO usage elsewhere, so I don't suppose he will
mind one more, but he'd better be kept in the loop.