netdev - Re: [Patch v2] drivers/net/b44: Change to non-atomic bit operations on pwol

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

Date:   Sun, 05 Jan 2020 14:22:12 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     tony.luck@...el.com
Cc:     fenghua.yu@...el.com, michael.chan@...adcom.com,
        netdev@...r.kernel.org, tglx@...utronix.de, luto@...nel.org,
        peterz@...radead.org, David.Laight@...lab.com,
        ravi.v.shankar@...el.com
Subject: Re: [Patch v2] drivers/net/b44: Change to non-atomic bit
 operations on pwol_mask

From: "Luck, Tony" <tony.luck@...el.com>
Date: Thu, 2 Jan 2020 13:27:06 -0800

> From: Fenghua Yu <fenghua.yu@...el.com>
> 
> Atomic operations that span cache lines are super-expensive on x86
> (not just to the current processor, but also to other processes as all
> memory operations are blocked until the operation completes). Upcoming
> x86 processors have a switch to cause such operations to generate a #AC
> trap. It is expected that some real time systems will enable this mode
> in BIOS.
> 
> In preparation for this, it is necessary to fix code that may execute
> atomic instructions with operands that cross cachelines because the #AC
> trap will crash the kernel.
> 
> Since "pwol_mask" is local and never exposed to concurrency, there is
> no need to set bits in pwol_mask using atomic operations.
> 
> Directly operate on the byte which contains the bit instead of using
> __set_bit() to avoid any big endian concern due to type cast to
> unsigned long in __set_bit().
> 
> Suggested-by: Peter Zijlstra <peterz@...radead.org>
> Signed-off-by: Fenghua Yu <fenghua.yu@...el.com>
> Signed-off-by: Tony Luck <tony.luck@...el.com>

Applied, thanks.

I wonder if this is being used in an endian safe way.  Maybe the way
the filter is written into the chip makes it work out, I don't know.