Re: [RFC] Re: broken userland ABI in configfs binary attributes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 26, 2019 at 09:34:37PM +0300, "Kai Mäkisara (Kolumbus)" wrote:
> 
> 
> > On 26 Aug 2019, at 19.29, Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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.



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux