netdev - Re: [net PATCH] xdp: obtain the mem_id mutex before trying to remove an entry.

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]

Date:   Wed, 04 Dec 2019 09:30:18 -0800
From:   "Jonathan Lemon" <jonathan.lemon@...il.com>
To:     "Jesper Dangaard Brouer" <brouer@...hat.com>
Cc:     "Grygorii Strashko" <grygorii.strashko@...com>,
        netdev@...r.kernel.org, davem@...emloft.net, kernel-team@...com,
        "Ilias Apalodimas" <ilias.apalodimas@...aro.org>
Subject: Re: [net PATCH] xdp: obtain the mem_id mutex before trying to remove
 an entry.

On 4 Dec 2019, at 3:38, Jesper Dangaard Brouer wrote:

> On Wed, 4 Dec 2019 12:07:22 +0200
> Grygorii Strashko <grygorii.strashko@...com> wrote:
>
>> On 04/12/2019 10:32, Jesper Dangaard Brouer wrote:
>>> On Tue, 3 Dec 2019 14:01:14 -0800
>>> Jonathan Lemon <jonathan.lemon@...il.com> wrote:
>>>
>>>> A lockdep splat was observed when trying to remove an xdp memory
>>>> model from the table since the mutex was obtained when trying to
>>>> remove the entry, but not before the table walk started:
>>>>
>>>> Fix the splat by obtaining the lock before starting the table walk.
>>>>
>>>> Fixes: c3f812cea0d7 ("page_pool: do not release pool until inflight 
>>>> == 0.")
>>>> Reported-by: Grygorii Strashko <grygorii.strashko@...com>
>>>> Signed-off-by: Jonathan Lemon <jonathan.lemon@...il.com>
>>>
>>> Have you tested if this patch fix the problem reported by Grygorii?

Yes, I reproduced the problem locally, and confirmed that the patch
resolves the issue.
--
Jonathan


>>>
>>> Link: 
>>> https://lore.kernel.org/netdev/c2de8927-7bca-612f-cdfd-e9112fee412a@ti.com
>>>
>>> Grygorii can you test this?
>>
>> Thanks.
>> I do not see this trace any more and networking is working after if 
>> down/up
>>
>> Tested-by: Grygorii Strashko <grygorii.strashko@...com>
>>
>
> Well if it fixes you issue, then I guess its okay.
>
> Acked-by: Jesper Dangaard Brouer <brouer@...hat.com>
>
> I just though it was related to the rcu_read_lock() around the
> page_pool_destroy() call. Guess, I was wrong.
>
> -- 
> Best regards,
>   Jesper Dangaard Brouer
>   MSc.CS, Principal Kernel Engineer at Red Hat
>   LinkedIn: http://www.linkedin.com/in/brouer