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: <50802F8A.6090205@linaro.org>
Date:	Thu, 18 Oct 2012 18:34:18 +0200
From:	Daniel Lezcano <daniel.lezcano@...aro.org>
To:	Ming Lei <ming.lei@...onical.com>
CC:	Bjørn Mork <bjorn@...k.no>,
	"David S. Miller" <davem@...emloft.net>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Oliver Neukum <oneukum@...e.de>,
	Alan Stern <stern@...land.harvard.edu>, netdev@...r.kernel.org,
	linux-pm@...r.kernel.org
Subject: Re: [PATCH v1] net/core: support runtime PM on net_device

On 10/18/2012 02:55 PM, Ming Lei wrote:
> On Thu, Oct 18, 2012 at 7:40 PM, Bjørn Mork <bjorn@...k.no> wrote:
>>
>> Because bugs are supposed to be fixed and not hidden?
> 
> OK, now let's discuss solution for the problem which should be
> clear and be solved.
> 
> The 1st one is to do it by this patch, or rule out some ioctl cmd
> which needn't wakeup device.
> 
> The second one is to fix ioctl one by one in each driver.
> 
> Any other solution?
> 
>>
>> Note that I am not claiming this is a bug.  That is still an open
>> question as far as I can see.

Hi Ming,

IIUC, the pm_runtime is related to the device drivers, so at the first
glance, we should see invocation of the runtime's functions in drivers/*
and arch/*. Adding these calls in the net core, which makes sense at a
certain point, is a bit weird for me.

>From my POV, if the drivers have been modified to support the pm_runtime
and this new functionality brought a regression with the ioctl, that
should be fixed in the drivers and not in the core code.

What happens with your patch if we use ethtool on a virtual device like
veth, macvlan, bridge, ... ?

Shouldn't handle the mac address, mtu, ... changes with the rtnetlink also ?

Thanks
  -- Daniel

-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ