Message ID | 20210119193313.43791-1-ljp@linux.ibm.com (mailing list archive) |
---|---|
State | Not Applicable |
Headers | show |
Series | [net,RFC] ibmvnic: device remove has higher precedence over reset | expand |
Context | Check | Description |
---|---|---|
snowpatch_ozlabs/apply_patch | success | Successfully applied on branch powerpc/merge (41d8cb7ece7c81e4eb897ed7ec7d3c3d72fd0af4) |
snowpatch_ozlabs/build-ppc64le | success | Build succeeded |
snowpatch_ozlabs/build-ppc64be | success | Build succeeded |
snowpatch_ozlabs/build-ppc64e | success | Build succeeded |
snowpatch_ozlabs/build-pmac32 | success | Build succeeded |
snowpatch_ozlabs/checkpatch | warning | total: 0 errors, 1 warnings, 0 checks, 20 lines checked |
snowpatch_ozlabs/needsstable | warning | Please consider tagging this patch for stable! |
On Tue, Jan 19, 2021 at 01:33:13PM -0600, Lijun Pan wrote: > Returning -EBUSY in ibmvnic_remove() does not actually hold the > removal procedure since driver core doesn't care for the return > value (see __device_release_driver() in drivers/base/dd.c > calling dev->bus->remove()) though vio_bus_remove > (in arch/powerpc/platforms/pseries/vio.c) records the > return value and passes it on. [1] > > During the device removal precedure, we should not schedule > any new reset, and rely on the flush_work and flush_delayed_work > to complete the pending resets, and specifically we need to > let __ibmvnic_reset() keep running while in REMOVING state since > flush_work and flush_delayed_work shall call __ibmvnic_reset finally. > > [1] https://lore.kernel.org/linuxppc-dev/20210117101242.dpwayq6wdgfdzirl@pengutronix.de/T/#m48f5befd96bc9842ece2a3ad14f4c27747206a53 > Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > Fixes: 7d7195a026ba ("ibmvnic: Do not process device remove during device reset") > Signed-off-by: Lijun Pan <ljp@linux.ibm.com> > --- > drivers/net/ethernet/ibm/ibmvnic.c | 8 +------- > 1 file changed, 1 insertion(+), 7 deletions(-) > > diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c > index aed985e08e8a..11f28fd03057 100644 > --- a/drivers/net/ethernet/ibm/ibmvnic.c > +++ b/drivers/net/ethernet/ibm/ibmvnic.c > @@ -2235,8 +2235,7 @@ static void __ibmvnic_reset(struct work_struct *work) > while (rwi) { > spin_lock_irqsave(&adapter->state_lock, flags); > > - if (adapter->state == VNIC_REMOVING || > - adapter->state == VNIC_REMOVED) { > + if (adapter->state == VNIC_REMOVED) { I think you need to keep the check for VNIC_REMOVING. Otherwise you don't prevent that a new reset being queued after ibmvnic_remove() set the state to VNIC_REMOVING. Am I missing something? > spin_unlock_irqrestore(&adapter->state_lock, flags); > kfree(rwi); > rc = EBUSY; > @@ -5372,11 +5371,6 @@ static int ibmvnic_remove(struct vio_dev *dev) > unsigned long flags; > > spin_lock_irqsave(&adapter->state_lock, flags); > - if (test_bit(0, &adapter->resetting)) { > - spin_unlock_irqrestore(&adapter->state_lock, flags); > - return -EBUSY; > - } > - > adapter->state = VNIC_REMOVING; > spin_unlock_irqrestore(&adapter->state_lock, flags); Best regards Uwe
On Tue, Jan 19, 2021 at 1:56 PM Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: > > On Tue, Jan 19, 2021 at 01:33:13PM -0600, Lijun Pan wrote: > > Returning -EBUSY in ibmvnic_remove() does not actually hold the > > removal procedure since driver core doesn't care for the return > > value (see __device_release_driver() in drivers/base/dd.c > > calling dev->bus->remove()) though vio_bus_remove > > (in arch/powerpc/platforms/pseries/vio.c) records the > > return value and passes it on. [1] > > > > During the device removal precedure, we should not schedule > > any new reset, and rely on the flush_work and flush_delayed_work > > to complete the pending resets, and specifically we need to > > let __ibmvnic_reset() keep running while in REMOVING state since > > flush_work and flush_delayed_work shall call __ibmvnic_reset finally. > > > > [1] https://lore.kernel.org/linuxppc-dev/20210117101242.dpwayq6wdgfdzirl@pengutronix.de/T/#m48f5befd96bc9842ece2a3ad14f4c27747206a53 > > Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > > Fixes: 7d7195a026ba ("ibmvnic: Do not process device remove during device reset") > > Signed-off-by: Lijun Pan <ljp@linux.ibm.com> > > --- > > drivers/net/ethernet/ibm/ibmvnic.c | 8 +------- > > 1 file changed, 1 insertion(+), 7 deletions(-) > > > > diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c > > index aed985e08e8a..11f28fd03057 100644 > > --- a/drivers/net/ethernet/ibm/ibmvnic.c > > +++ b/drivers/net/ethernet/ibm/ibmvnic.c > > @@ -2235,8 +2235,7 @@ static void __ibmvnic_reset(struct work_struct *work) > > while (rwi) { > > spin_lock_irqsave(&adapter->state_lock, flags); > > > > - if (adapter->state == VNIC_REMOVING || > > - adapter->state == VNIC_REMOVED) { > > + if (adapter->state == VNIC_REMOVED) { > > I think you need to keep the check for VNIC_REMOVING. Otherwise you > don't prevent that a new reset being queued after ibmvnic_remove() set > the state to VNIC_REMOVING. Am I missing something? I leave the checking for REMOVING there in ibmvnic_reset, which is the function to schedule/queue up the resets. Here I delete the REMOVING in __ibmvnic_reset to let it run and finish. Otherwise flush_work will not do anything if __ibmvnic_reset() just return doing nothing. I can explain it in the commit message. > > > spin_unlock_irqrestore(&adapter->state_lock, flags); > > kfree(rwi); > > rc = EBUSY; > > @@ -5372,11 +5371,6 @@ static int ibmvnic_remove(struct vio_dev *dev) > > unsigned long flags; > > > > spin_lock_irqsave(&adapter->state_lock, flags); > > - if (test_bit(0, &adapter->resetting)) { > > - spin_unlock_irqrestore(&adapter->state_lock, flags); > > - return -EBUSY; > > - } > > - > > adapter->state = VNIC_REMOVING; > > spin_unlock_irqrestore(&adapter->state_lock, flags); > > Best regards > Uwe > > -- > Pengutronix e.K. | Uwe Kleine-König | > Industrial Linux Solutions | https://www.pengutronix.de/ |
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c index aed985e08e8a..11f28fd03057 100644 --- a/drivers/net/ethernet/ibm/ibmvnic.c +++ b/drivers/net/ethernet/ibm/ibmvnic.c @@ -2235,8 +2235,7 @@ static void __ibmvnic_reset(struct work_struct *work) while (rwi) { spin_lock_irqsave(&adapter->state_lock, flags); - if (adapter->state == VNIC_REMOVING || - adapter->state == VNIC_REMOVED) { + if (adapter->state == VNIC_REMOVED) { spin_unlock_irqrestore(&adapter->state_lock, flags); kfree(rwi); rc = EBUSY; @@ -5372,11 +5371,6 @@ static int ibmvnic_remove(struct vio_dev *dev) unsigned long flags; spin_lock_irqsave(&adapter->state_lock, flags); - if (test_bit(0, &adapter->resetting)) { - spin_unlock_irqrestore(&adapter->state_lock, flags); - return -EBUSY; - } - adapter->state = VNIC_REMOVING; spin_unlock_irqrestore(&adapter->state_lock, flags);
Returning -EBUSY in ibmvnic_remove() does not actually hold the removal procedure since driver core doesn't care for the return value (see __device_release_driver() in drivers/base/dd.c calling dev->bus->remove()) though vio_bus_remove (in arch/powerpc/platforms/pseries/vio.c) records the return value and passes it on. [1] During the device removal precedure, we should not schedule any new reset, and rely on the flush_work and flush_delayed_work to complete the pending resets, and specifically we need to let __ibmvnic_reset() keep running while in REMOVING state since flush_work and flush_delayed_work shall call __ibmvnic_reset finally. [1] https://lore.kernel.org/linuxppc-dev/20210117101242.dpwayq6wdgfdzirl@pengutronix.de/T/#m48f5befd96bc9842ece2a3ad14f4c27747206a53 Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Fixes: 7d7195a026ba ("ibmvnic: Do not process device remove during device reset") Signed-off-by: Lijun Pan <ljp@linux.ibm.com> --- drivers/net/ethernet/ibm/ibmvnic.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-)