[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAADnVQKNNcj_2U_E=3NPgbO76JB4MPZ131zd4ykE4jOt6TAVkg@mail.gmail.com>
Date: Mon, 30 Aug 2021 09:39:07 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Etienne Martineau <etmartin101@...il.com>, yonch@...ch.com
Cc: Alexei Starovoitov <ast@...com>,
Daniel Borkmann <daniel@...earbox.net>,
Chenbo Feng <fengc@...gle.com>, sashal@...nel.org,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: Question related to ( commit 9f691549f76d "bpf: fix struct
htab_elem layout" )
On Mon, Aug 30, 2021 at 7:17 AM Etienne Martineau <etmartin101@...il.com> wrote:
>
> Hi,
>
> I've been staring at this commit for some time and I wonder what were the
> symptoms when the issue was reproduced?
> "The bug was discovered by manual code analysis and reproducible
> only with explicit udelay() in lookup_elem_raw()."
>
> I tried various stress test + timing combinations in lookup_elem_raw() but no
> luck.
That fix was a long time ago :)
afair the issue will not look like a crash, but rather an element
will not be found.
That's what lookup_nulls_elem_raw() is fixing.
> I believe that one of our production boxes ran into that issue lately with a GPF
> in the area of htab_map_lookup_elem(). The crash was seen on an outdated
> 4.9 stable.
Would be great if you can reproduce it on the latest kernel.
Powered by blists - more mailing lists