On Wed, Feb 28, 2024 at 11:09:53AM -0800, Linus Torvalds wrote: > On Wed, 28 Feb 2024 at 10:18, Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote: > > > > I think we can keep that guarantee. > > > > The tricky case was -EFAULT from copy_from_user_nofault(), where we have > > to bail out, drop locks, re-fault in the user buffer - and redo the rest > > of the write, this time holding the inode lock. > > > > We can't guarantee that partial writes don't happen, but what we can do > > is restart the write from the beginning, so the partial write gets > > overwritten with a full atomic write. > > I think that's a solution that is actually much worse than the thing > it is trying to solve. > > Now a concurrent reader can actually see the data change twice or > more. Either because there's another writer that came in in between, > or because of threaded modifications to the source buffer in the first > writer. Yeah, that's a wrinkle. But that requires a three way race to observe; a race between a reader and multiple writers, and the reader doing multiple reads. The more concerning sitution to me would be if breaking write atomicity means that we end up with data in the file that doesn't correspond to an total ordering of writes; e.g. part of write a, then write b, then the rest of write a overlaying part of write b. Maybe that can't happen as long as writes are always happening in ascending folio order?
