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  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, 26 Oct 2017 17:06:18 +0900 (KST)
From:   David Miller <>
Subject: Re: [PATCH net-next 0/2] net: dsa: don't unmask port bitmaps

From: Andrew Lunn <>
Date: Tue, 24 Oct 2017 11:22:34 +0200

>> In case of probe deferral, you get the full probe function to exit with
>> an error, and that usually involves freeing the recently allocated
>> dsa_switch instance, and then allocating a new one when probe is
>> re-entered, so that should not be a problem.
> Hi Florian
> That is the simple case. I remember having problems with more complex
> cases, D in DSA. Switches 1 and 2 probe O.K, switch 3 fail with
> EPROBE_DEFER. Switch 3, as you say, releases its dsa_switch instance,
> so will get a freshly zero'ed new instance when it probes
> again. However, switches 1 and 2 only experience the unwind at the DSA
> level. The devices are not removed and later probed again. They have a
> 'dirty' dsa_switch structure the next time they are applied.
> I just think there might be potential for regressions here. But i've
> not yet looked at the details to really know if there actually is.

I realize there is still some trepidation about these patches, but it
seems like the only real way to find out if it causes regressions is
to apply them and watch carefully.

So I've applied this and if anything pops up we can easily revert.


Powered by blists - more mailing lists