On Tue, 12 Feb 2019, Jan Kara wrote: > > Isn't that already racy? If the mmap user is fast enough can't it > > prevent the page from becoming freed in the first place today? > > No, it cannot. We block page faulting for the file (via a lock), tear down > page tables, free pages and blocks. Then we resume faults and return > SIGBUS (if the page ends up being after the new end of file in case of > truncate) or do new page fault and fresh block allocation (which can end > with SIGBUS if the filesystem cannot allocate new block to back the page). Well that is already pretty inconsistent behavior. Under what conditions is the SIGBUS occurring without the new fault attempt? If a new fault is attempted then we have resource constraints that could have caused a SIGBUS independently of the truncate. So that case is not really something special to be considered for truncation. So the only concern left is to figure out under what conditions SIGBUS occurs with a racing truncate (if at all) if there are sufficient resources to complete the page fault.
