Merge branch 'rocker-transaction-fixes'
authorDavid S. Miller <davem@davemloft.net>
Thu, 21 May 2015 21:20:55 +0000 (17:20 -0400)
committerDavid S. Miller <davem@davemloft.net>
Thu, 21 May 2015 21:20:55 +0000 (17:20 -0400)
commit4ac2dc8928d186f93572398b3897c59e9eb591e5
tree338bdd1e6d8a5ddd231c36d10588d353be52193b
parente26cc7ff77ac9726c05e9595998121a7e17d32ee
parentdf6a20673011e89f7fbe3d667eee0a9550679841
Merge branch 'rocker-transaction-fixes'

Simon Horman says:

====================
rocker: transaction fixes

this series addresses what appear to be errors in the handling of
prepare and then commit transactions in the rocker driver.

In all cases the problem is that data structures visible outside of
the transaction are modified during the prepare phase.

In the case of the first two patches this results in the kernel reporting a
BUG. I have noted test-cases in the change logs.

The third patch is also a bug fix, as noted by  Toshiaki Makita,
however I have not been able to reliably reproduce the problem and
thus have not provided a test case.

The last patch is a correctness fix that does not fix a bug
that manifests as far as I can tell.

Changes: v3->v4
* All patches
  - Add Jiri Pirko's ack
* "rocker: do not make neighbour entry changes when preparing transactions"
  - Setting of entry values in all transaction phases
    as suggested by Toshiaki Makita
* "rocker: make rocker_port_internal_vlan_id_{get,put}() non-transactional"
  - Remove Fixes tag as I believe this is a correctness rather than a bug fix

Changes: v2->v3
* "rocker: do not make neighbour entry changes when preparing transactions"
  - Correct inverted logic
  - Added ack from Scott Feldman

Changes: v1->v2
* "rocker: do not make neighbour entry changes when preparing transactions"
  - Revised changelog to reflect information from Toshiaki Makita
    that there is a bug that can manifest
  - Update address and ttl regardless of the value of the transaction state
* All other patches
  - Added acks from Scott Feldman
====================

Signed-off-by: David S. Miller <davem@davemloft.net>