On Mon 21-09-20 18:26:00, Dave Chinner wrote: > On Thu, Sep 17, 2020 at 12:47:10AM -0700, Hugh Dickins wrote: > > It's because POSIX demanded that when a file > > is truncated, the user will get SIGBUS on trying to access even the > > COWed pages beyond EOF in a MAP_PRIVATE mapping. Page lock on the > > cache page does not serialize the pages COWed from it very well. > > And there's the "why". I don't find the "page lock doesn't > serialise COW faults very well" particularly reassuring in this > case.... > > > But there's no such SIGBUS requirement in the case of hole-punching, > > and trying to unmap those pages racily instantiated just after the > > punching cursor passed, would probably do more harm than good. > > There isn't a SIGBUS requirement for fallocate operations, just a > "don't expose stale data to userspace" requirement. > > FWIW, how does a COW fault even work with file backed pages? We can > only have a single page attached to the inode address space for a given > offset, so if there's been a COW fault and a new page faulted in for > the write fault in that VMA, doesn't that imply the user data then > written to that page is never going to be written back to storage > because the COW page is not tracked by the inode address space? Correct. Private file mappings work so that on first write fault on some page offset we allocate anonymous page for that offset, copy to it current contents of the corresponding file page, and from that moment on it behaves as an anonymous page. Except that on truncate, we have to unmap these anonymous pages in private file mappings as well... Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
