From: Simon Horman <horms@verge•net.au>
To: David Miller <davem@davemloft•net>
Cc: simon.horman@netronome•com, sfeldma@gmail•com,
netdev@vger•kernel.org, jiri@resnulli•us,
makita.toshiaki@lab•ntt.co.jp
Subject: Re: [PATCH net-next v2] rocker: move netevent neigh update to processes context
Date: Thu, 4 Jun 2015 18:07:52 +0900 [thread overview]
Message-ID: <20150604090749.GA18460@verge.net.au> (raw)
In-Reply-To: <20150604.013409.228829580818256337.davem@davemloft.net>
Hi Dave,
On Thu, Jun 04, 2015 at 01:34:09AM -0700, David Miller wrote:
> From: Simon Horman <simon.horman@netronome•com>
> Date: Thu, 4 Jun 2015 17:20:48 +0900
>
> > What I was seeing is as follows:
> >
> > 1. rocker_port_ipv4_nh() is called via switchdev_port_obj_add()
> > with trans = SWITCHDEV_TRANS_PREPARE
> >
> > 2. rocker_port_ipv4_neigh() is called by rocker_neigh_update()
> > with trans = SWITCHDEV_TRANS_NONE.
> >
> > The call chain goes up to arp_process() via neigh_update().
> >
> > 3. rocker_port_ipv4_nh() is called via switchdev_port_obj_add()
> > with trans = SWITCHDEV_TRANS_COMMIT
> >
> > #1 and #2 are guarded by rtl across those calls but
> > #2 is not guarded by rtnl.
> >
> > Inside both rocker_port_ipv4_nh() and rocker_port_ipv4_neigh()
> > neigh_tbl_lock lock is taken but it is not held across the
> > two calls to rocker_port_ipv4_nh within a single prepare->commit transaction.
> >
> > I can double check that the above still occurs, but I'm not aware of any
> > recent changes that would cause it not to occur any more.
>
> Ok, thanks for explaining.
>
> I still don't want this to be moved asynchronosly from the ARP neigh
> update event code path.
>
> And therefore I'd like folks to look into another mechanism to fix
> this.
>
> If that means the prepare/commit engine is given a spinlock by the
> driver to be held across the two calls, so be it.
I'm not opposed to such a scheme. But I'd like to note that it seems to me
that for it to resolve the problem above the lock would be need be held
both for "none" and "prepare->commit" transactions. I think the former may
be a little tricky as it may occur in IRQ context but perhaps I am missing
something obvious.
next prev parent reply other threads:[~2015-06-04 9:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-03 3:43 [PATCH net-next v2] rocker: move netevent neigh update to processes context sfeldma
2015-06-04 6:38 ` David Miller
2015-06-04 8:20 ` Simon Horman
2015-06-04 8:34 ` David Miller
2015-06-04 9:07 ` Simon Horman [this message]
2015-06-04 15:34 ` Toshiaki Makita
2015-06-04 18:48 ` David Miller
2015-06-04 16:12 ` Scott Feldman
2015-06-04 22:54 ` Simon Horman
2015-06-05 1:33 ` Scott Feldman
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=20150604090749.GA18460@verge.net.au \
--to=horms@verge$(echo .)net.au \
--cc=davem@davemloft$(echo .)net \
--cc=jiri@resnulli$(echo .)us \
--cc=makita.toshiaki@lab$(echo .)ntt.co.jp \
--cc=netdev@vger$(echo .)kernel.org \
--cc=sfeldma@gmail$(echo .)com \
--cc=simon.horman@netronome$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox