From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932617AbVISUOt (ORCPT ); Mon, 19 Sep 2005 16:14:49 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932620AbVISUOs (ORCPT ); Mon, 19 Sep 2005 16:14:48 -0400 Received: from gold.veritas.com ([143.127.12.110]:43168 "EHLO gold.veritas.com") by vger.kernel.org with ESMTP id S932617AbVISUOs (ORCPT ); Mon, 19 Sep 2005 16:14:48 -0400 Date: Mon, 19 Sep 2005 21:14:10 +0100 (BST) From: Hugh Dickins X-X-Sender: hugh@goblin.wat.veritas.com To: Linus Torvalds cc: Smarduch Mario-CMS063 , linux-kernel@vger.kernel.org Subject: Re: Multi-Threaded fork() correctness on Linux 2.4 & 2.6 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 19 Sep 2005 20:14:41.0907 (UTC) FILETIME=[C4F3B430:01C5BD56] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 19 Sep 2005, Linus Torvalds wrote: > > We hold the page_table_lock when doing the fork(), so T2 can't actually be > copying the page until we've done the TLB flush, no? And once the TLB > flush is done, all the writes by T3 should be in the page, so we copy the > right thing at that point, and there is no consistency problems? I was totally overlooking the page_table_lock during the fork. But no matter, it's not good enough: src_mm->page_table_lock is acquired and dropped at the inner level, in copy_pte_range (looking at latest 2.6): it cannot be held across allocating page tables for dst_mm. So each time T1 drops it, there's a window for the T2 vs. T3 problem. Yet we don't much want to flush TLB each time we leave copy_pte_range. Hugh