All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
To: Florian Westphal <fw@strlen.de>
Cc: Anatoly Pugachev <matorola@gmail.com>,
	Sparc kernel list <sparclinux@vger.kernel.org>,
	netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
	debian-sparc <debian-sparc@lists.debian.org>
Subject: Re: [netfilter-core] [sparc64] possible circular locking / deadlock
Date: Mon, 17 Jun 2019 22:32:26 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1906172223110.31141@blackhole.kfki.hu> (raw)
In-Reply-To: <20190617201104.qv2tm5oezluyg4nv@breakpoint.cc>

Hi Florian,

On Mon, 17 Jun 2019, Florian Westphal wrote:

> Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> wrote:
> > >                -> #0 (&table[i].mutex){+.+.}:
> > > [   11.698157]        lock_acquire+0x1a4/0x1c0
> > > [   11.698165]        __mutex_lock+0x48/0x920
> > > [   11.698173]        mutex_lock_nested+0x1c/0x40
> > > [   11.698181]        nfnl_lock+0x24/0x40 [nfnetlink]
> > > [   11.698196]        ip_set_nfnl_get_byindex+0x19c/0x280 [ip_set]
> > > [   11.698207]        set_match_v1_checkentry+0x14/0xc0 [xt_set]
> > 
> > set_match_v1_checkentry() from ipset always assumed that it's called via 
> > the old xtables/setsockopt interface. Thus it calls 
> > ip_set_nfnl_get_byindex() which is then calls 
> > nfnl_lock(NFNL_SUBSYS_IPSET). Here comes the circular dependency.
> 
> But isnt it a false positive?
> 
> > > [   11.698359]        CPU0                    CPU1
> > > [   11.698366]        ----                    ----
> > > [   11.698372]   lock(&net->nft.commit_mutex);
> > > [   11.698381]                                lock(&table[i].mutex);
> > > [   11.698390]                                lock(&net->nft.commit_mutex);
> > > [   11.698400]   lock(&table[i].mutex);
> > > [   11.698408]
> 
> AFAICS CPU0 takes the ipset subsys mutex after taking the nftables 
> transaction mutex (via checkentry of ipset match), while CPU1 took the 
> nftables subsys mutex and then the nftables transaction mutex.
> 
> The only reason why this splat is generated is because nftables and 
> ipset subset mutexes are currently the same from lockdep pov.
> 
> It looks like we need to extend nfnetlink to place the subsystem mutexes 
> in different lockdep classes.

That would be nicer! 

Otherwise I'd need "struct xt_mtdtor_param" and "struct xt_tgdtor_param" 
be extended with "bool nft_compat" to handle all required calls from the 
ip_set module.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

WARNING: multiple messages have this Message-ID (diff)
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
To: Florian Westphal <fw@strlen.de>
Cc: Anatoly Pugachev <matorola@gmail.com>,
	Sparc kernel list <sparclinux@vger.kernel.org>,
	netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
	debian-sparc <debian-sparc@lists.debian.org>
Subject: Re: [netfilter-core] [sparc64] possible circular locking / deadlock
Date: Mon, 17 Jun 2019 20:32:26 +0000	[thread overview]
Message-ID: <alpine.DEB.2.20.1906172223110.31141@blackhole.kfki.hu> (raw)
In-Reply-To: <20190617201104.qv2tm5oezluyg4nv@breakpoint.cc>

Hi Florian,

On Mon, 17 Jun 2019, Florian Westphal wrote:

> Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> wrote:
> > >                -> #0 (&table[i].mutex){+.+.}:
> > > [   11.698157]        lock_acquire+0x1a4/0x1c0
> > > [   11.698165]        __mutex_lock+0x48/0x920
> > > [   11.698173]        mutex_lock_nested+0x1c/0x40
> > > [   11.698181]        nfnl_lock+0x24/0x40 [nfnetlink]
> > > [   11.698196]        ip_set_nfnl_get_byindex+0x19c/0x280 [ip_set]
> > > [   11.698207]        set_match_v1_checkentry+0x14/0xc0 [xt_set]
> > 
> > set_match_v1_checkentry() from ipset always assumed that it's called via 
> > the old xtables/setsockopt interface. Thus it calls 
> > ip_set_nfnl_get_byindex() which is then calls 
> > nfnl_lock(NFNL_SUBSYS_IPSET). Here comes the circular dependency.
> 
> But isnt it a false positive?
> 
> > > [   11.698359]        CPU0                    CPU1
> > > [   11.698366]        ----                    ----
> > > [   11.698372]   lock(&net->nft.commit_mutex);
> > > [   11.698381]                                lock(&table[i].mutex);
> > > [   11.698390]                                lock(&net->nft.commit_mutex);
> > > [   11.698400]   lock(&table[i].mutex);
> > > [   11.698408]
> 
> AFAICS CPU0 takes the ipset subsys mutex after taking the nftables 
> transaction mutex (via checkentry of ipset match), while CPU1 took the 
> nftables subsys mutex and then the nftables transaction mutex.
> 
> The only reason why this splat is generated is because nftables and 
> ipset subset mutexes are currently the same from lockdep pov.
> 
> It looks like we need to extend nfnetlink to place the subsystem mutexes 
> in different lockdep classes.

That would be nicer! 

Otherwise I'd need "struct xt_mtdtor_param" and "struct xt_tgdtor_param" 
be extended with "bool nft_compat" to handle all required calls from the 
ip_set module.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

  reply	other threads:[~2019-06-17 20:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-17 14:46 [sparc64] possible circular locking / deadlock Anatoly Pugachev
2019-06-17 14:46 ` Anatoly Pugachev
2019-06-17 15:02 ` [netfilter-core] " Jozsef Kadlecsik
2019-06-17 15:02   ` Jozsef Kadlecsik
2019-06-17 15:06   ` Pablo Neira Ayuso
2019-06-17 15:06     ` Pablo Neira Ayuso
2019-06-17 18:17     ` Jozsef Kadlecsik
2019-06-17 18:17       ` Jozsef Kadlecsik
2019-06-17 20:11   ` Florian Westphal
2019-06-17 20:11     ` Florian Westphal
2019-06-17 20:32     ` Jozsef Kadlecsik [this message]
2019-06-17 20:32       ` Jozsef Kadlecsik

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=alpine.DEB.2.20.1906172223110.31141@blackhole.kfki.hu \
    --to=kadlec@blackhole.kfki.hu \
    --cc=coreteam@netfilter.org \
    --cc=debian-sparc@lists.debian.org \
    --cc=fw@strlen.de \
    --cc=matorola@gmail.com \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=sparclinux@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.