netdev - Re: [RFC 01/11] net: phy: Don't report success if devices weren't found

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: <0eec69af-2099-2fee-f0f1-a83c7e4c2690@arm.com>
Date:   Mon, 25 May 2020 16:59:16 -0500
From:   Jeremy Linton <jeremy.linton@....com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, andrew@...n.ch,
        f.fainelli@...il.com, hkallweit1@...il.com,
        madalin.bucur@....nxp.com, calvin.johnson@....nxp.com,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC 01/11] net: phy: Don't report success if devices weren't
 found

Hi,

On 5/25/20 4:07 PM, Russell King - ARM Linux admin wrote:
> On Mon, May 25, 2020 at 04:02:13PM -0500, Jeremy Linton wrote:
>>> So, I think you're going to have to add a work-around to ignore bit 0,
>>> which brings up the question whether this is worth it or not.
>>
>> It does ignore bit 0, it gets turned into the C22 regs flag, and
>> cleared/ignored in the remainder of the code (do to MMD loop indexes
>> starting at 1).
> 
> However, I've already pointed out that that isn't the case in a
> number of functions that I listed in another email, and I suspect
> was glossed over.
> 

Hmm, right, I might not be understanding, I'm still considering your 
comments in 4/11 and a couple others..

OTOH, the mmd 0 logic could be completely removed, as its actually been 
broken for a year or so in linux (AFAIK) because the code triggering it 
was disabled when the C22 sanitation patch was merged. OTOH, this patch 
is still clearing the C22 flag from devices, so anything dependent 
entirely on that should have the same behavior as before.

So, there is a bug in the is_valid_phy/device macro, because I messed it 
up when I converted it to a function because its using a signed val, 
when it should be unsigned. I don't think that is what you were hinting 
in 4/11 though.

Thanks,