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: <alpine.NEB.2.20.17.1611081030000.6177@chris.i8u.org>
Date:   Tue, 8 Nov 2016 10:32:10 -0800 (PST)
From:   Hisashi T Fujinaka <htodd@...fifty.com>
To:     Corinna Vinschen <vinschen@...hat.com>
cc:     Cao jin <caoj.fnst@...fujitsu.com>, netdev@...r.kernel.org,
        intel-wired-lan@...ts.osuosl.org, linux-kernel@...r.kernel.org,
        izumi.taku@...fujitsu.com
Subject: Re: [Intel-wired-lan] [PATCH] igb: use igb_adapter->io_addr instead
 of e1000_hw->hw_addr

On Tue, 8 Nov 2016, Hisashi T Fujinaka wrote:

>> Incidentally we're just looking for a solution to that problem too.
>> Do three patches to fix the same problem at rougly the same time already
>> qualify as freak accident?
>> 
>> FTR, I attached my current patch, which I was planning to submit after
>> some external testing.
>> 
>> However, all three patches have one thing in common:  They workaround
>> a somewhat dubious resetting of the hardware address to NULL in case
>> reading from a register failed.
>> 
>> That makes me wonder if setting the hardware address to NULL in
>> rd32/igb_rd32 is really such a good idea.  It's performed in a function
>> which return value is *never* tested for validity in the calling
>> functions and leads to subsequent crashes since no tests for hw_addr ==
>> NULL are performed.
>> 
>> Maybe commit 22a8b2915 should be reconsidered?  Isn't there some more
>> graceful way to handle the "surprise removal"?
>
> Answering this from my home account because, well, work is Outlook.
>
> "Reconsidering" would be great. In fact, revert if if you'd like. I'm
> uncertain that the surprise removal code actually works the way I
> thought previously and I think I took a lot of it out of my local code.
>
> Unfortuantely I don't have any equipment that I can use to reproduce
> surprise removal any longer so that means I wouldn't be able to test
> anything. I have to defer to you or Cao Jin.

Whoops. Never mind. I was just told that I had a bug that Alex Duyck and
Cao Jin just fixed. I'd stick to listening to Alex.

-- 
Hisashi T Fujinaka - htodd@...fifty.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ