From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Horman Subject: Re: [PATCH v3 net-next 3/4] rocker: do not make neighbour entry changes when preparing transactions Date: Wed, 20 May 2015 16:48:13 +0900 Message-ID: <20150520074810.GA21934@vergenet.net> References: <1432100902-10187-1-git-send-email-simon.horman@netronome.com> <1432100902-10187-4-git-send-email-simon.horman@netronome.com> <555C267B.9070807@lab.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Scott Feldman , Jiri Pirko , David Miller , netdev@vger.kernel.org To: Toshiaki Makita Return-path: Received: from mail-pa0-f47.google.com ([209.85.220.47]:34090 "EHLO mail-pa0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751967AbbETHsY (ORCPT ); Wed, 20 May 2015 03:48:24 -0400 Received: by pabru16 with SMTP id ru16so57774325pab.1 for ; Wed, 20 May 2015 00:48:23 -0700 (PDT) Content-Disposition: inline In-Reply-To: <555C267B.9070807@lab.ntt.co.jp> Sender: netdev-owner@vger.kernel.org List-ID: On Wed, May 20, 2015 at 03:15:23PM +0900, Toshiaki Makita wrote: > On 2015/05/20 14:48, Simon Horman wrote: > > rocker_port_ipv4_nh() and in turn rocker_port_ipv4_neigh() may be > > be called with trans == SWITCHDEV_TRANS_PREPARE and then > > trans == SWITCHDEV_TRANS_COMMIT from switchdev_port_obj_set() via > > fib_table_insert(). > > > > The first time that rocker_port_ipv4_nh() is called, with > > trans == SWITCHDEV_TRANS_PREPARE, _rocker_neigh_add() adds a new entry to > > the neigh table. > > > > And the second time rocker_port_ipv4_nh() is called, with > > trans == SWITCHDEV_TRANS_COMMIT, that entry is found. This causes > > rocker_port_ipv4_nh() to believe it is not adding an entry and thus it > > frees "entry", which is still present in rocker driver's neigh table. > > > > This problem does not appear to affect deletion as my analysis is that > > deletion is always performed with trans == SWITCHDEV_TRANS_NONE. > > > > For completeness _rocker_neigh_{add,del,prepare} are updated not to > > manipulate fib table entries if trans == SWITCHDEV_TRANS_PREPARE. > > > > Fixes: c4f20321d968 ("rocker: support prepare-commit transaction model") > > Reported-by: oshiaki Makita > > 'T' is missing from my first name Sorry about that. > > Acked-by: Scott Feldman > > Signed-off-by: Simon Horman > > > ... > > static void _rocker_neigh_add(struct rocker *rocker, > > + enum switchdev_trans trans, > > struct rocker_neigh_tbl_entry *entry) > > { > > + if (trans == SWITCHDEV_TRANS_PREPARE) > > + return; > > entry->index = rocker->neigh_tbl_next_index++; > > Isn't index needed here? It looks to be used in later function call and > logging. Thanks, that does not follow the usual model of setting values during the PREPARE (and all other) transaction phase(s). > How about setting index like this? > > entry->index = rocker->neigh_tbl_next_index; > if (trans == PREPARE) > return; > rocker->neigh_tbl_next_index++; > ... I am concerned that _rocker_neigh_add() may be called by some other caller while a transaction is in process and thus entry->index will be inconsistent across callers. Perhaps we can convince ourselves that all the bases are covered. So far my testing has drawn a blank. But the logic seems difficult to reason about. As we are basically allocating an index I suppose what is really needed for a correct implementation is a transaction aware index allocator, like we have for memory (rocker_port_kzalloc etc...). But that does seem like overkill. I think that we can make entry->index consistent across calls in the same transaction at the expense of breaking the rule that per-transaction data should be set during all transaction phases. Something like this: if (trans != SWITCHDEV_TRANS_COMMIT) /* Avoid index being set to different values across calls * to this function by the same caller within the same * transaction. */ entry->index = rocker->neigh_tbl_next_index++; if (trans == SWITCHDEV_TRANS_PREPARE) return;