From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752551AbbLMUUx (ORCPT ); Sun, 13 Dec 2015 15:20:53 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:53828 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752036AbbLMUUv (ORCPT ); Sun, 13 Dec 2015 15:20:51 -0500 Message-ID: <1450038035.3944.2.camel@decadent.org.uk> Subject: Re: [PATCH 3.16.y-ckt 009/126] sit: fix sit0 percpu double allocations From: Ben Hutchings To: Luis Henriques Cc: Eric Dumazet , Steffen Klassert , "David S. Miller" , linux-kernel@vger.kernel.org, stable@vger.kernel.org, kernel-team@lists.ubuntu.com Date: Sun, 13 Dec 2015 20:20:35 +0000 In-Reply-To: <20151213185429.GA31826@charon> References: <1449653896-5236-1-git-send-email-luis.henriques@canonical.com> <1449653896-5236-10-git-send-email-luis.henriques@canonical.com> <1449893906.3836.5.camel@decadent.org.uk> <20151213185429.GA31826@charon> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-1eahSQea04jL4uqnhSdq" X-Mailer: Evolution 3.18.2-1 Mime-Version: 1.0 X-SA-Exim-Connect-IP: 192.168.4.247 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-1eahSQea04jL4uqnhSdq Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 2015-12-13 at 18:54 +0000, Luis Henriques wrote: > On Sat, Dec 12, 2015 at 04:18:26AM +0000, Ben Hutchings wrote: > > On Wed, 2015-12-09 at 09:36 +0000, Luis Henriques wrote: > > > 3.16.7-ckt21 -stable review patch.=C2=A0=C2=A0If anyone has any objec= tions, > > > please let me know. > > >=20 > > > ------------------ > > >=20 > > > From: Eric Dumazet > > >=20 > > > commit 4ece9009774596ee3df0acba65a324b7ea79387c upstream. > > >=20 > > > sit0 device allocates its percpu storage twice : > > > - One time in ipip6_tunnel_init() > > > - One time in ipip6_fb_tunnel_init() > > >=20 > > > Thus we leak 48 bytes per possible cpu per network namespace > > > dismantle. > > >=20 > > > ipip6_fb_tunnel_init() can be much simpler and does not > > > return an error, and should be called after register_netdev() > > [...] > >=20 > > Doesn't this introduce a race condition when sit is a module? =C2=A0The= re > > seems to be nothing to prevent access to the partially initialised > > device after calling register_netdev(), if sit_init_net() is called > > during module loading rather than during namespace creation. > >=20 >=20 > This seems to be an upstream issue, not specific to the 3.16.y-ckt > stable kernel.=C2=A0=C2=A0If that is the case, I guess I'll just keep thi= s patch > and later apply the fix.=C2=A0=C2=A0Or do you think this race is really l= ikely > to be a worst problem than then issue the patch is trying to fix? It seems worse than the problem being fixed. Ben. --=20 Ben Hutchings Life would be so much easier if we could look at the source code. --=-1eahSQea04jL4uqnhSdq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUAVm3TE+e/yOyVhhEJAQqVlQ//Sib11nzEBsP85uT0utrE6B3AFQKeR9IQ te5z/OGBfVfdbzVGFKN5XkekxdqkFFbZn8XL+qgUHzjaKPdDrge7MUxi9nrpo5Dm /UgYvWwbeqmQaKlWzXAV16jjObQe1jzjke7Eo4PdgqDV3JYYm8962VjPU8wBXxmm jZMo8WB/L89XiSZOnjK2Kz6fmrg4EyDNl3LmqPdVpzSe4MszyYmhfOkoHwMgi9J+ /SjDardoEf4tT/NcDeZlOsH8OZ22UBik2V7eH57zt6agSLXZo/TpyS1TPCqC6qtN I1i8Hg4bFsHK6cvGGu5OXxN5nqt5+YXiTYh2QMeyVmzywSPYGbYfc+HieBN2Tr+N Nwdc8bQvLqwGYR9+JwgqMCqlXACxXGANfqXcMyFzs+LfX3DT0y5rpL/e9wbK60ql cWJVc0S0hlxxWel3G8i8mqwjRA1Z3CYKF6uPsg6VHEjzcfcnr0OEAVt3SeMOvdRs r1jM/0JefGZ/N3qbN8TPwbHOd3UOw0GmEKijuFxwvAfJB7djRvg6jEiahe2PKHmk VBWiEvEeA/OBt+lUZUZJj4i8JNZ99CZCaYkaE3i5EFsj81PykmQy0AjRiLqXEtQp HRAlR1aySYFrtJ/bln4am6XhjDchsQTNZFlmKojEoJwPeIpMSrT+W59JnbZ7PAXe 3S57G2qSkVU= =q6fS -----END PGP SIGNATURE----- --=-1eahSQea04jL4uqnhSdq--