netdev - Re: [PATCH net-next 3/3] eth: bnxt: handle invalid Tx completions more gracefully

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] [day] [month] [year] [list]

Message-ID: <20230712135032.28011bc4@kernel.org>
Date: Wed, 12 Jul 2023 13:50:32 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Paolo Abeni <pabeni@...hat.com>
Cc: davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
 michael.chan@...adcom.com
Subject: Re: [PATCH net-next 3/3] eth: bnxt: handle invalid Tx completions
 more gracefully

On Wed, 12 Jul 2023 22:31:45 +0200 Paolo Abeni wrote:
> > Is there really any difference whether one changes a byte or ors
> > in a bit? Either way it's a partial update of a word.  
> 
> Really not a big deal, but 'or' fetches memory and then store it, while
> move [immediate] is a single store. In case of a cache miss, 'or'
> should stall, while 'mov' should not. In general with 'mov' there
> should be less pressure on the cache and/or bus.

You're right, if the store buffer can buffer 1B stores then we won't
stall the instruction pile line. But we most likely will for the bit
op. The setting is an extremely rare path, tho, so given your
"not a big deal" disclaimer I'm intending to keep the bitfield :)