Received: with ECARTIS (v1.0.0; list netdev); Wed, 12 Jan 2005 05:07:54 -0800 (PST) Received: from yue.st-paulia.net (yue.linux-ipv6.org [203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j0CD7l3F017968 for ; Wed, 12 Jan 2005 05:07:48 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id 8368F33CC2; Wed, 12 Jan 2005 22:08:16 +0900 (JST) Date: Wed, 12 Jan 2005 22:08:16 +0900 (JST) Message-Id: <20050112.220816.56650893.yoshfuji@linux-ipv6.org> To: tgraf@suug.ch Cc: buytenh@wantstofly.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: race in net/ipv4/ipip.c ? From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20050112125336.GH26856@postel.suug.ch> References: <20050112122300.GA12155@xi.wantstofly.org> <20050112125336.GH26856@postel.suug.ch> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/650/Sun Jan 2 19:00:02 2005 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Status: Clean X-archive-position: 147 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <20050112125336.GH26856@postel.suug.ch> (at Wed, 12 Jan 2005 13:53:36 +0100), Thomas Graf says: > * Lennert Buytenhek <20050112122300.GA12155@xi.wantstofly.org> 2005-01-12 13:23 : > > static void ipip_tunnel_link(struct ipip_tunnel *t) > > { > > struct ipip_tunnel **tp = ipip_bucket(t); > > > > t->next = *tp; > > write_lock_bh(&ipip_lock); > > *tp = t; > > write_unlock_bh(&ipip_lock); > > } > > > > Shouldn't the "t->next = *tp" be done inside the write lock? > > Why do you think so? linking may only happen on new tunnels > so they can't be found before they're assigned to the bucket. > dev_hold is called correctly so dev->priv usage is safe as > well. How about adding multiple tunnels (with same ipip_bucket(t)) concurrently? :-) --yoshfuji