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]
Date:   Thu, 8 Mar 2018 22:57:57 +0300
From:   Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
To:     Brad Mouring <brad.mouring@...com>, Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: phy: Move interrupt check from phy_check to
 phy_interrupt

On 03/08/2018 10:41 PM, Sergei Shtylyov wrote:

>> If multiple phys share the same interrupt (e.g. a multi-phy chip),
>> the first device registered is the only one checked as phy_interrupt
>> will always return IRQ_HANDLED if the first phydev is not halted.
>> Move the interrupt check into phy_interrupt and, if it was not this
>> phydev, return IRQ_NONE to allow other devices on this irq a chance
>> to check if it was their interrupt.
> 
>    Hm, looking at kernel/irq/handle.c, all registered IRQ handlers are always
> called regardless of their results. Care to explain?
> 
>> Signed-off-by: Brad Mouring <brad.mouring@...com>
>> ---
>>  drivers/net/phy/phy.c | 16 ++++++----------
>>  1 file changed, 6 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
>> index e3e29c2b028b..ff1aa815568f 100644
>> --- a/drivers/net/phy/phy.c
>> +++ b/drivers/net/phy/phy.c
>> @@ -632,6 +632,12 @@ static irqreturn_t phy_interrupt(int irq, void *phy_dat)
>>  	if (PHY_HALTED == phydev->state)
>>  		return IRQ_NONE;		/* It can't be ours.  */
>>  
>> +	if (phy_interrupt_is_valid(phydev)) {
> 
>   Always true in this context, no?
> 
>> +		if (phydev->drv->did_interrupt &&
>> +			!phydev->drv->did_interrupt(phydev))
> 
>    I don't think we can do this in the interrupt context as this function *will*
> read from MDIO... I think that was the reason why IRQ handling is done in the
> thread context...

   Ah, we're already in a thread context here! Forgot about it...
 
> [...]

MBR, Sergei

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ