Messages in this thread | | | Date | Thu, 15 May 2003 10:50:23 +0200 | From | Andrea Arcangeli <> | Subject | Re: Race between vmtruncate and mapped areas? |
| |
On Wed, May 14, 2003 at 11:53:19AM -0700, Andrew Morton wrote: > converting i_sem to an rwsem and taking it in the pagefault would certainly > stitch it up. Unpopular, very messy.
and very slow, down_read on every page fault wouldn't scale
> Could "truncate file" return some code to say pages were left behind, so > truncate re-runs zap_page_range()? Sounds unpleasant. > > > Yes, re-checking the page against i_size from do_no_page() would fix it up.
think if there are two truncates, one zapping the entere file, and another restoring the previous i_size, in such case the new_page will be wrong, as it won't be zeroed out. I mean if we do anything about it, we should close all races and make it 100% correct.
My fix has no scalability cost, no indirect calls, touches mostly just hot cachelines anyways, and addresses the multiple truncate case too.
> But damn, that's another indirect call, 64-bit math, etc on _every_ > file-backed pagefault. > > > Remind me again what problem this whole thing is currently causing?
the only thing I can imagine is an app trapping SIGBUS to garbage collect the end of a file. So for example you truncate the file and you wait the SIGBUS to know you've to re-extend it. it would be a legitimate use, and this is a bug, it's not read against write that has no way to synchronize anyways, however I doubt any application is being bitten by this race.
Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |