mbox series

[net-next,v2,0/7] ibmvnic: Use more consistent locking

Message ID 20210112181441.206545-1-sukadev@linux.ibm.com
Headers show
Series ibmvnic: Use more consistent locking | expand

Message

Sukadev Bhattiprolu Jan. 12, 2021, 6:14 p.m. UTC 
Use more consistent locking when reading/writing the adapter->state
field. This patch set fixes a race condition during ibmvnic_open()
where the adapter could be left in the PROBED state if a reset occurs
at the wrong time. This can cause networking to not come up during
boot and potentially require manual intervention in bringing up
applications that depend on the network.

Changelog[v2] [Address comments from Jakub Kicinski]
	- Fix up commit log for patch 5/7 and drop unnecessary variable
	- Format Fixes line properly (no wrapping, no blank lines)

Sukadev Bhattiprolu (7):
  ibmvnic: restore state in change-param reset
  ibmvnic: update reset function prototypes
  ibmvnic: avoid allocating rwi entries
  ibmvnic: switch order of checks in ibmvnic_reset
  ibmvnic: serialize access to work queue
  ibmvnic: check adapter->state under state_lock
  ibmvnic: add comments about state_lock

 drivers/net/ethernet/ibm/ibmvnic.c | 347 ++++++++++++++++++++---------
 drivers/net/ethernet/ibm/ibmvnic.h |  70 +++++-
 2 files changed, 306 insertions(+), 111 deletions(-)

Comments

Jakub Kicinski Jan. 13, 2021, 2 a.m. UTC | #1 
On Tue, 12 Jan 2021 10:14:34 -0800 Sukadev Bhattiprolu wrote:
> Use more consistent locking when reading/writing the adapter->state
> field. This patch set fixes a race condition during ibmvnic_open()
> where the adapter could be left in the PROBED state if a reset occurs
> at the wrong time. This can cause networking to not come up during
> boot and potentially require manual intervention in bringing up
> applications that depend on the network.

Apologies for not having enough time to suggest details, but let me
state this again - the patches which fix bugs need to go into net with
Fixes tags, the refactoring needs to go to net-next without Fixes tags.
If there are dependencies, patches go to net first, then within a week
or so the reset can be posted for net-next, after net -> net-next merge.
Sukadev Bhattiprolu Jan. 14, 2021, 2:35 a.m. UTC | #2 
Jakub Kicinski [kuba@kernel.org] wrote:
> On Tue, 12 Jan 2021 10:14:34 -0800 Sukadev Bhattiprolu wrote:

> > Use more consistent locking when reading/writing the adapter->state

> > field. This patch set fixes a race condition during ibmvnic_open()

> > where the adapter could be left in the PROBED state if a reset occurs

> > at the wrong time. This can cause networking to not come up during

> > boot and potentially require manual intervention in bringing up

> > applications that depend on the network.

> 

> Apologies for not having enough time to suggest details, but let me

> state this again - the patches which fix bugs need to go into net with

> Fixes tags, the refactoring needs to go to net-next without Fixes tags.

> If there are dependencies, patches go to net first, then within a week

> or so the reset can be posted for net-next, after net -> net-next merge.


I think the locking bug fixes need the refactoring. So would it be ok to
send the refactoring (patches 2 through 4) first to net-next and when
they are merged send the the bug fixes (1, 5 and 6)? Patch 7 can be
sent to net-next later after that.

Thanks,

Sukadev