On Wed, May 20, 2015 at 10:05:07PM -0700, sfel...@gmail.com wrote: > From: Scott Feldman <sfel...@gmail.com> > > In review of Simon's patchset "rocker: transaction fixes". it was noted > that rocker->neigh_tbl_next_index was unprotected in the call path below > and could race with other contexts calling rocker_port_ipv4_neigh(): > > arp_process() > neigh_update() > rocker_neigh_update() > rocker_port_ipv4_neigh() > > To fix, move the neigh_update() event processing to process contexts and > hold rtnl_lock to call rocker_port_ipv4_neigh(). This will protect > rocker->neigh_tbl_next_index accesses and is more consistent with the rest > of the driver code where non-I/O processing is done under process context > with rtnl_lock held. > > Signed-off-by: Scott Feldman <sfel...@gmail.com>
Hi Scott, this patch does what it says on the wrapper and in itself looks good. Reviewed-by: Simon Horman <simon.hor...@netronome.com> However, this patch seems to expose another bug. With it applied I see the following: ip addr add 10.0.99.192/24 dev eth0 ip link set up dev eth0 ip route add 10.0.97.0/24 via 10.0.99.135 1. Prepare Phase: rocker_port_ipv4_nh() -> rocker_port_ipv4_resolve() In rocker_port_ipv4_resolve() n->nud_state & NUD_VALID is false and rocker_port_ipv4_neigh() is not called. 2. Commit Phase: rocker_port_ipv4_nh() -> rocker_port_ipv4_resolve() In rocker_port_ipv4_resolve() n->nud_state & NUD_VALID is now true and rocker_port_ipv4_neigh() is called. rocker_port_ipv4_neigh() calls rocker_port_kzalloc() which reports a bug because there was no corresponding call during the prepare phase. In a nutshell the rocker_port_*alloc calls are not symmetric in the two phases because of an external state change (in the neighbour table in the core of the network stack). -- 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
