On Mon, Aug 26, 2019 at 09:34:37PM +0300, "Kai Mäkisara (Kolumbus)" wrote: > > > > On 26 Aug 2019, at 19.29, Al Viro <v...@zeniv.linux.org.uk> wrote: > > > > On Mon, Aug 26, 2019 at 03:48:38AM +0100, Al Viro wrote: > > > >> We might be able to paper over that mess by doing what /dev/st does - > >> checking that file_count(file) == 1 in ->flush() instance and doing commit > >> there in such case. It's not entirely reliable, though, and it's > >> definitely > >> not something I'd like to see spreading. > > > > This "not entirely reliable" turns out to be an understatement. > > If you have /proc/*/fdinfo/* being read from at the time of final close(2), > > you'll get file_count(file) > 1 the last time ->flush() is called. In other > > words, we'd get the data not committed at all. > > > ... > > PS: just dropping the check in st_flush() is probably a bad idea - > > as it is, it can't overlap with st_write() and after such change it > > will… > Yes, don’t just drop it. The tape semantics require that a file mark is > written when the last opener closes this sequential device. This is why the > check is there. Of course, it is good if someone finds a better solution for > this.
D'oh... OK, that settles it; exclusion with st_write() would've been painful, but playing with the next st_write() on the same struct file rewinding the damn thing to overwrite what st_flush() had spewed is an obvious no-go.
