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 h...@infradead.org: 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. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2041670 Title: tmpfs: O_DIRECT | O_CREATE open reports open failure but actually creates a file. Status in Linux: Unknown Status in linux package in Ubuntu: New Bug description: creating a file on tmpfs with open(filename, O_RDWR | O_DIRECT | O_CREAT, 0666) reports an open failure error EINVAL, but still creates the file. The file should not be created if we hit such an error. Tested and fails on: mantic amd64: 6.5.0-10-generic lunar amd64: 6.2.0-35-generic jammie amd64: 5.15.0-generic focal: 5.4.0-165-generic bionic: 4.15.0-213-generic trusty: 4.4.0-148-generic sudo mkdir /mnt/tmpfs sudo mount -t tmpfs -o size=1G,nr_inodes=10k,mode=777 tmpfs /mnt/tmpfs sudo chmod 666 /mnt/tmpfs gcc reproducer.c -o reproducer sudo ./reproducer Run the attached program. It reports an open failure (errno 22, EINVAL) but still manages to create the file. Note this was original discovered by running stress-ng on tmpfs with the open stressor: stress-ng --open 1 To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/2041670/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
