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]

Message-ID: <20191204123829.2af45813@carbon>
Date:   Wed, 4 Dec 2019 12:38:29 +0100
From:   Jesper Dangaard Brouer <brouer@...hat.com>
To:     Grygorii Strashko <grygorii.strashko@...com>
Cc:     Jonathan Lemon <jonathan.lemon@...il.com>,
        <netdev@...r.kernel.org>, <davem@...emloft.net>,
        <kernel-team@...com>,
        Ilias Apalodimas <ilias.apalodimas@...aro.org>,
        brouer@...hat.com
Subject: Re: [net PATCH] xdp: obtain the mem_id mutex before trying to
 remove an entry.

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?
> > 
> > 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