netdev - Re: [PATCH 1/3] net: phylib: add adjust

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] [day] [month] [year] [list]

Message-ID: <5390E383.50805@zonque.org>
Date:	Thu, 05 Jun 2014 23:39:15 +0200
From:	Daniel Mack <daniel@...que.org>
To:	Florian Fainelli <f.fainelli@...il.com>
CC:	netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	"marek.belisko" <marek.belisko@...il.com>,
	Matus Ujhelyi <ujhelyi.m@...il.com>
Subject: Re: [PATCH 1/3] net: phylib: add adjust_state callback to phy device

Hi Florian,

On 06/05/2014 08:12 PM, Florian Fainelli wrote:
> 2014-06-05 0:14 GMT-07:00 Daniel Mack <daniel@...que.org>:

>>> This sounds potentially dangerous if misused, PHY drivers would
>>> basically be allowed to do arbitrary link state changes based on their
>>> custom needs.
>>
>> Yes, and this is basically what my quirk handler does. It takes action
>> when the link goes down (PHY_NOLINK), as we unfortunately need to reset
>> the chip every time this happens.
> 
> In fact, the callback name is sort of a misnomer here, as you are not
> really adjusting the PHY device state here, you are reading from it to
> do something about the PHY device based on this state.
> 
> Could you rename it to "state_notify" for instance to make it clear
> that this must absolutely be a read-only operation and the PHY driver
> is by no means allow to mess with the PHY device structure at all?
> Constifying the phy_device argument here would not really help
> unfortunately, and providing you with just the 'state' as a RO
> argument would not help either since you need to access the PHY
> device...

Sure, I can rename it, no problem.

> I was thinking about having a notifier callchain here that would
> execute synchronously and in the same context as your proposed
> adjust_link() callback, although that might be be too heavy weighted
> for basically just one notified callback.

Plus, it wouldn't really solve the issue you described above, right?


I'll resend after -rc1 is out, with the changed name for the callback.


Again, thanks!
Daniel

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