netdev - RE: [PATCH] Hyperv: Trigger DHCP renew after host hibernation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <EE124450C0AAF944A40DD71E61F878C9921095@SINEX14MBXC417.southpacific.corp.microsoft.com>
Date:	Tue, 12 Aug 2014 07:48:56 +0000
From:	Dexuan Cui <decui@...rosoft.com>
To:	Florian Fainelli <f.fainelli@...il.com>,
	Greg KH <gregkh@...uxfoundation.org>
CC:	"olaf@...fle.de" <olaf@...fle.de>,
	Richard Weinberger <richard.weinberger@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"jasowang@...hat.com" <jasowang@...hat.com>,
	"driverdev-devel@...uxdriverproject.org" 
	<driverdev-devel@...uxdriverproject.org>,
	Haiyang Zhang <haiyangz@...rosoft.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Thomas Shao <huishao@...rosoft.com>,
	"Yue Zhang (OSTC DEV)" <yuezha@...rosoft.com>,
	"David Miller" <davem@...emloft.net>,
	Stephen Hemminger <stephen@...workplumber.org>
Subject: RE: [PATCH] Hyperv: Trigger DHCP renew after host hibernation

> -----Original Message-----
> From: Florian Fainelli [mailto:f.fainelli@...il.com]
> Sent: Monday, August 11, 2014 11:52 AM
> > I suppose you meant the below logic:
> > if (refresh) {
> >          rtnl_lock();
> >          netif_carrier_off(net);
> >          netif_carrier_on(net);
> >          rtnl_unlock();
> > }
> >
> > We have discussed this in the previous mails of this thread itself:
> > e.g., http://marc.info/?l=linux-driver-devel&m=140593811715975&w=2
> >
> > Unluckily this logic doesn't work because the user-space daemons
> > like ifplugd, usually don't renew the DHCP immediately as long as they
> > receive a link-down message: they usually wait for some seconds and if
> > they find the link becomes up soon, they won't trigger renew operations.
> > (I guess this behavior can be somewhat reasonable: maybe the daemons
> > try to not trigger DHCP renew on temporary link instability)
> 
> Is that such a big deal? If you know you spend much of your time in
> ifplugd, why not use something different that triggers a DHCP renewal
> faster, or fix ifplugd?
 
Hi Florian,
Thanks for the comment!
Yes, we can fix ifplugd and ALL other equivalent daemons, but that would
need much more efforts, so I was trying to add a workaround in the kernel
driver -- now I've realized this is not a good solution. :-)

> > If we use this logic in the kernel space, we'll have to "fix" the user-space
> > daemons, like ifplugd, systemd-networkd...,etc.
> 
> You mean the opposite here don't you? If you put that logic in kernel
> space you don't have to fix the userland.

I think we'll have to fix the userland or customize the userland by passing
proper parameters(if there is any) to the userland daemons(when they run
in a hyper-v guest) if we use the below logic in the driver:
if (refresh) {
          rtnl_lock();
          netif_carrier_off(net);
          netif_carrier_on(net);
          rtnl_unlock();
}
e.g., as Bill told in another mail, ifplugd has --delay-down.

> > I'm not sure our attempt to "fix" the daemons can be easily accepted.
> > BTW, by CPUID, an application has a reliable way to determine  if it's
> > running on hyper-v on not. Maybe we can "fix" the behavior of the
> > daemons when they run on hyper-v?
> 
> That is not acceptable as well, why would an user-space application
> would have to care that much whether it runs on hyper-v or a physical
> host? Not to mention that anytime someone develops a similar but new
> application they would have to become aware of such platform and its
> "specicities".
Ok, I understood.

> > BTW2, according to my limited experience, I doubt other VMMs can
> > handle this auto-DHCP-renew-in-guest issue properly.
> >
> > That was why Yue's patch wanted to add a SLEEP(10s) between the
> > link-down and link-up events and hoped this could be an acceptable
> > fix(while it turned out not, obviously), though we admit it's not so good
> > to add such a magic number "10s" in a kernel driver.
> >
> > Please point it out if I missed or misunderstand something.
> 
> I think this is just an integration issue that you are having, and I
> would not be focusing on any particular user-space implementation, but
> rather put something in the driver that is sensible, just like what was
> suggested before: toggling the carrier state.
OK, let me send a netif_carrier_off()/on() patch after I verify the daemons
can work with proper parameters specified.

Thanks,
-- Dexuan
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html