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: <20230131131408.ceea0a762d45bf94c1387367@linux-foundation.org>
Date:   Tue, 31 Jan 2023 13:14:08 -0800
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Andrey Konovalov <andreyknvl@...il.com>
Cc:     Marco Elver <elver@...gle.com>, andrey.konovalov@...ux.dev,
        Alexander Potapenko <glider@...gle.com>,
        Vlastimil Babka <vbabka@...e.cz>, kasan-dev@...glegroups.com,
        Evgenii Stepanov <eugenis@...gle.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org,
        Andrey Konovalov <andreyknvl@...gle.com>
Subject: Re: [PATCH 16/18] lib/stackdepot: annotate racy slab_index accesses

On Tue, 31 Jan 2023 19:57:58 +0100 Andrey Konovalov <andreyknvl@...il.com> wrote:

> On Tue, Jan 31, 2023 at 9:41 AM Marco Elver <elver@...gle.com> wrote:
> >
> > > diff --git a/lib/stackdepot.c b/lib/stackdepot.c
> > > index f291ad6a4e72..cc2fe8563af4 100644
> > > --- a/lib/stackdepot.c
> > > +++ b/lib/stackdepot.c
> > > @@ -269,8 +269,11 @@ depot_alloc_stack(unsigned long *entries, int size, u32 hash, void **prealloc)
> > >                         return NULL;
> > >                 }
> > >
> > > -               /* Move on to the next slab. */
> > > -               slab_index++;
> > > +               /*
> > > +                * Move on to the next slab.
> > > +                * WRITE_ONCE annotates a race with stack_depot_fetch.
> >
> > "Pairs with potential concurrent read in stack_depot_fetch()." would be clearer.
> >
> > I wouldn't say WRITE_ONCE annotates a race (race = involves 2+
> > accesses, but here's just 1), it just marks this access here which
> > itself is paired with the potential racing read in the other function.
> 
> Will do in v2. Thanks!

Please let's not redo an 18-patch series for a single line comment
change.  If there are more substantial changes then OK.

I queued this as a to-be-squashed fixup against "/stackdepot: annotate
racy slab_index accesses":


From: Andrew Morton <akpm@...ux-foundation.org>
Subject: lib-stackdepot-annotate-racy-slab_index-accesses-fix
Date: Tue Jan 31 01:10:50 PM PST 2023

enhance comment, per Marco

Cc: Alexander Potapenko <glider@...gle.com>
Cc: Andrey Konovalov <andreyknvl@...gle.com>
Cc: Evgenii Stepanov <eugenis@...gle.com>
Cc: Marco Elver <elver@...gle.com>
Cc: Vlastimil Babka <vbabka@...e.cz>
Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
---

 lib/stackdepot.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/lib/stackdepot.c~lib-stackdepot-annotate-racy-slab_index-accesses-fix
+++ a/lib/stackdepot.c
@@ -271,7 +271,8 @@ depot_alloc_stack(unsigned long *entries
 
 		/*
 		 * Move on to the next slab.
-		 * WRITE_ONCE annotates a race with stack_depot_fetch.
+		 * WRITE_ONCE pairs with potential concurrent read in
+		 * stack_depot_fetch().
 		 */
 		WRITE_ONCE(slab_index, slab_index + 1);
 		slab_offset = 0;
_


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ