Hi Dave, On Thu, Jun 04, 2015 at 01:34:09AM -0700, David Miller wrote: > From: Simon Horman <simon.hor...@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. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
