From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757914AbcBXFRJ (ORCPT ); Wed, 24 Feb 2016 00:17:09 -0500 Received: from mail-wm0-f53.google.com ([74.125.82.53]:32812 "EHLO mail-wm0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757686AbcBXFRB (ORCPT ); Wed, 24 Feb 2016 00:17:01 -0500 MIME-Version: 1.0 In-Reply-To: <20160223.182121.2101846699151527296.davem@davemloft.net> References: <20160221071102.9686.63148.stgit@buzz> <20160223.182121.2101846699151527296.davem@davemloft.net> Date: Wed, 24 Feb 2016 08:16:59 +0300 Message-ID: Subject: Re: [PATCH] ipv4: in new netns initialize sysctls in net.ipv4.conf.* with defaults From: Konstantin Khlebnikov To: David Miller Cc: =?UTF-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0KXQu9C10LHQvdC40LrQvtCy?= , Linux Kernel Network Developers , Linux Containers , Vasily Averin , Linux Kernel Mailing List , "Eric W. Biederman" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 24, 2016 at 2:21 AM, David Miller wrote: > From: Konstantin Khlebnikov > Date: Sun, 21 Feb 2016 10:11:02 +0300 > >> Currently initial net.ipv4.conf.all.* and net.ipv4.conf.default.* are >> copied from init network namespace because static structures are used >> for init_net. This makes no sense because new netns might be created >> from any netns. This patch makes private copy also for init netns if >> network namespaces are enabled. Other sysctls in net.ipv4 and net.ipv6 >> already initialized with default values at namespace creation. >> >> Signed-off-by: Konstantin Khlebnikov >> Fixes: 752d14dc6aa9 ("[IPV4]: Move the devinet pointers on the struct net") > > The horse has long left the stable on this. We cannot change this now > without breaking things. > > Imagine someone who intentionally sets up init_net with a certain set > of settings and expects them to propagate into every created namespace. > > We'll break things for them and given the behavior existed for so long > what the administrator is doing is very reasonable. > > I'm not applying this sorry, we are stuck with the current behavior > whether we like it or not. Major kernel upgrades always break something in weird setups. This shouldn't block bug fixing. This kludge works only for several ipv4 sysctls. If software or man ever have tried to setup ipv6 or tune tcp and want some non-default setup then it/he already knows that sysctls must be configured inside.