On Tue, Dec 1, 2020 at 6:38 PM Jakub Kicinski <k...@kernel.org> wrote: > > On Tue, 1 Dec 2020 12:24:38 -0800 Mahesh Bandewar (महेश बंडेवार) wrote: > > On Thu, Nov 19, 2020 at 8:56 PM Jakub Kicinski <k...@kernel.org> wrote: > > > Do you have more details on what the use cases are that expect no > > > networking? > > > > > > TBH I don't get the utility of this knob. If you want to write vaguely > > > portable software you have to assume the knob won't be useful, because > > > either (a) kernel may be old, or (b) you shouldn't assume to own the > > > sysctls and this is a global one (what if an application spawns that > > > expects legacy behavior?) > > > > > > And if you have to check for those two things you're gonna write more > > > code than just ifuping lo would be. > > > > > > Maybe you can shed some more light on how it makes life at Google > > > easier for you? Or someone else can enlighten me? > > > > > > I don't have much practical experience with namespaces, but the more > > > I think about it the more pointless it seems. > > > > Thanks for the input. > > > > Sorry, I was on vacation and couldn't process this response earlier. > > > > There are two things that this patch is providing and let me understand the > > objections well. > > > > (a) Bring up lo by default > > (b) sysctl to protect the legacy behavior > > > > Frankly we really dont have any legacy-behavior use case and one can > > bring it back to life by just doing 'ifdown lo' if necessary. > > If use cases depending on legacy behavior exist we are just trading the > ifup in one case for an ifdown in another. > Yes, I would agree with this if the use-cases are 50/50 but I would say it's more like 99/1 distribution (99% of the time if not higher times lo is required to be UP and probably 1% of the time or less it's down)
> Unless we can dispel the notion that sand-boxing by lo down is a > legitimate use case IMO we're just adding complexity and growing > a sysctl for something that can be trivially handled from user space. > OK, I can remove the sysctl and just have the 3 line patch. > > Most of > > the use cases involve using networking anyways. My belief was that we > > need to protect legacy behavior and hence went lengths to add sysctl > > to protect it. If we are OK not to have it, I'm more than happy to > > remove the sysctl and just have the 3 line patch to bring loopback up. > > > > If legacy-behavior is a concern (which I thought generally is), then > > either we can have the sysctl to have it around to protect it (the > > current implementation) but if we prefer to have kernel-command-line > > instead of sysctl that defaults to legacy behavior but if provided, we > > can set it UP by default during boot (or the other way around)? > > > > My primary motive is (a) while (b) is just a side-effect which we can > > get away if deemed unnecessary. >
