All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steffen Klassert <steffen.klassert@secunet.com>
To: Jianbo Liu <jianbol@nvidia.com>
Cc: Leon Romanovsky <leonro@nvidia.com>,
	"edumazet@google.com" <edumazet@google.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"fw@strlen.de" <fw@strlen.de>
Subject: Re: [PATCH net] net: drop secpath extension before skb deferral free
Date: Tue, 28 May 2024 11:26:00 +0200	[thread overview]
Message-ID: <ZlWjKHseiI+cfHiR@gauss3.secunet.de> (raw)
In-Reply-To: <e6f70384717d85fb1604566530afd02a594f427f.camel@nvidia.com>

On Tue, May 28, 2024 at 09:02:49AM +0000, Jianbo Liu wrote:
> On Tue, 2024-05-28 at 10:44 +0200, Steffen Klassert wrote:
> > On Mon, May 27, 2024 at 09:40:23AM +0200, Steffen Klassert wrote:
> > > On Thu, May 23, 2024 at 03:26:22PM +0000, Jianbo Liu wrote:
> > > > On Thu, 2024-05-23 at 12:00 +0200, Steffen Klassert wrote:
> > > > > 
> > > > > Hm, interesting.
> > > > > 
> > > > > Can you check if xfrm_dev_state_free() is triggered in that
> > > > > codepath
> > > > > and if it actually removes the device from the states?
> > > > > 
> > > > 
> > > > xfrm_dev_state_free is not triggered. I think it's because I did
> > > > "ip x
> > > > s delall" before unregister netdev.
> > > 
> > > Yes, likely. So we can't defer the device removal to the state free
> > > functions, we always need to do that on state delete.
> > 
> > The only (not too complicated) solution I see so far is to
> > free the device early, along with the state delete function:
> > 
> > diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
> > index 649bb739df0d..bfc71d2daa6a 100644
> > --- a/net/xfrm/xfrm_state.c
> > +++ b/net/xfrm/xfrm_state.c
> > @@ -721,6 +721,7 @@ int __xfrm_state_delete(struct xfrm_state *x)
> >                         sock_put(rcu_dereference_raw(x->encap_sk));
> >  
> >                 xfrm_dev_state_delete(x);
> > +               xfrm_dev_state_free(x);
> >  
> 
> Still hit "scheduling while atomic" issue because __xfrm_state_delete
> is called in state's spin lock. 

Grmpf. Yes, apparently.

Unfortunately I don't have a NIC to test installed currently.


  reply	other threads:[~2024-05-28  9:26 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-13 10:02 [PATCH net] net: drop secpath extension before skb deferral free Jianbo Liu
2024-05-13 10:29 ` Eric Dumazet
2024-05-14  7:37   ` Jianbo Liu
2024-05-14  8:51     ` Eric Dumazet
2024-05-15  3:10       ` Jianbo Liu
2024-05-20 10:06       ` Jianbo Liu
2024-05-21 10:15         ` Steffen Klassert
2024-05-22  9:34         ` Steffen Klassert
2024-05-22 11:06           ` Eric Dumazet
2024-05-23  2:22           ` Jianbo Liu
2024-05-23  6:44             ` Steffen Klassert
2024-05-23  6:57               ` Jianbo Liu
2024-05-23 10:00                 ` Steffen Klassert
2024-05-23 15:26                   ` Jianbo Liu
2024-05-27  7:40                     ` Steffen Klassert
2024-05-28  8:44                       ` Steffen Klassert
2024-05-28  9:02                         ` Jianbo Liu
2024-05-28  9:26                           ` Steffen Klassert [this message]
2024-05-26 10:57               ` Leon Romanovsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZlWjKHseiI+cfHiR@gauss3.secunet.de \
    --to=steffen.klassert@secunet.com \
    --cc=edumazet@google.com \
    --cc=fw@strlen.de \
    --cc=jianbol@nvidia.com \
    --cc=leonro@nvidia.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.