netdev - Re: [PATCH 1/6] net/rds: Avoid queuing superfluous send and recv work

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: <b3f771fbc3cb987cd2bd476b845fdd1f901c7730.camel@oracle.com>
Date: Wed, 5 Mar 2025 00:38:41 +0000
From: Allison Henderson <allison.henderson@...cle.com>
To: "kuba@...nel.org" <kuba@...nel.org>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH 1/6] net/rds: Avoid queuing superfluous send and recv work

On Fri, 2025-02-28 at 16:19 -0800, Jakub Kicinski wrote:
> On Wed, 26 Feb 2025 21:26:33 -0700 allison.henderson@...cle.com wrote:
> > +	/* clear_bit() does not imply a memory barrier */
> > +	smp_mb__before_atomic();
> > +	clear_bit(RDS_SEND_WORK_QUEUED, &cp->cp_flags);
> > +	/* clear_bit() does not imply a memory barrier */
> > +	smp_mb__after_atomic();
> 
> I'm guessing the comments were added because checkpatch asked for them.
> The comments are supposed to indicate what this barrier pairs with.
> I don't see the purpose of these barriers, please document..

Hi Jakob,

I think the comments meant to refer to the implicit memory barrier in "test_and_set_bit".  It looks like it has assembly
code to set the barrier if CONFIG_SMP is set.  How about we change the comments to: "pairs with implicit memory barrier
in test_and_set_bit()" ?  Let me know what you think.

Thanks!
Allison