0875f ("ibmvnic: Updated reset handling")
> Signed-off-by: Dany Madden
Given that the likely reason for set_link_state() failing is that the
CRQ is inactive and that we will attempt to free the CRQ and re-register
it in ibmvnic_reset_crq() further down, I think its okay to ignore the
error
Lijun Pan [lijunp...@gmail.com] wrote:
> On Fri, Mar 5, 2021 at 12:44 PM Sukadev Bhattiprolu
> wrote:
> >
> > Lijun Pan [l...@linux.ibm.com] wrote:
> > > The reset path will call ibmvnic_cleanup->ibmvnic_napi_disable
> > > ->napi_disable(). This is
napi_complete() will prevent a new call to ibmvnic_poll() but what if
ibmvnic_poll() is already executing and attempting to access the scrqs
while the reset path is freeing them?
Sukadev
5413:1-18:
> ERROR: nested lock+irqsave that reuses flags from line 5404.
>
Thanks. Please add
Fixes: 4a41c421f367 ("ibmvnic: serialize access to work queue on remove")
> Signed-off-by: Junlin Yang
Reviewed-by: Sukadev Bhattiprolu
a false positive. However, there is no reason to
> not initialize the variables unconditionally avoiding the warning.
Yeah, its a false positive, but initializing doesn't hurt.
>
> Fixes: 635e442f4a48 ("ibmvnic: merge ibmvnic_reset_init and ibmvnic_init")
> Signed-off-by: Michal Suchanek
Reviewed-by: Sukadev Bhattiprolu
nly the reset
functions and ibmvnic_open() can set the adapter to OPEN state and this
must happen under rtnl.
Fixes: 7d7195a026ba ("ibmvnic: Do not process device remove during device
reset")
Signed-off-by: Sukadev Bhattiprolu
Reviewed-by: Dany Madden
---
Changelog[v4]
[Jakub Kici
ntainer of the conflicting tree to minimise any particularly
> complex conflicts.
The changes look good to me. Thanks.
Sukadev
92b ("ibmvnic: Flush existing work items before device removal")
Signed-off-by: Sukadev Bhattiprolu
Cc:Uwe Kleine-König
Cc:Saeed Mahameed
---
Changelog
An earlier version was reviewed by Saeed Mahmeed. But I have deferred
some earlier patches in that set. Also, now exte
nly the reset
functions and ibmvnic_open() can set the adapter to OPEN state and this
must happen under rtnl.
Fixes: 7d7195a026ba ("ibmvnic: Do not process device remove during device
reset")
Signed-off-by: Sukadev Bhattiprolu
Reviewed-by: Dany Madden
---
Changelog[v3]
[Ja
: 01d9bd792d16 ("ibmvnic: Reorganize device close")
Signed-off-by: Sukadev Bhattiprolu
Reported-by: Abdul Haleem
---
drivers/net/ethernet/ibm/ibmvnic.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c
b/drivers/net/ethernet/ibm/ibmvn
>From f6a04bc0abfae1065577888fc6467f9f162863f6 Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu
Date: Wed, 3 Feb 2021 13:15:23 -0800
Subject: [PATCH net] ibmvnic: Set to CLOSED state even on error
If set_link_state() fails for any reason, we still cleanup the adapter
state and cannot reco
>From 0d6616e843973d2f052ea09237c16667802b52e3 Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu
Date: Wed, 20 Jan 2021 21:10:15 -0800
Subject: [PATCH net v3] ibmvnic: fix a race between open and reset
__ibmvnic_reset() currently reads the adapter->state before getting the
rtnl and save
Willem de Bruijn [willemdebruijn.ker...@gmail.com] wrote:
> On Wed, Feb 3, 2021 at 12:10 AM Sukadev Bhattiprolu
> wrote:
> >
> > If two or more instances of 'ip link set' commands race and first one
> > already brings the interface up (or down), the subseque
Jakub Kicinski [k...@kernel.org] wrote:
> On Thu, 28 Jan 2021 19:47:10 -0800 Sukadev Bhattiprolu wrote:
> > + WARN_ON_ONCE(!rtnl_is_locked());
>
> ASSERT_RTNL() should do nicely here
Yes, Fixed in v2.
Thanks,
Sukadev
Cris Forno for helping isolate the problem and for testing.
Fixes: 1d8504937478 ("powerpc/vnic: Extend "failover pending" window")
Signed-off-by: Sukadev Bhattiprolu
Tested-by: Cristobal Forno
---
drivers/net/ethernet/ibm/ibmvnic.c | 18 +-
1 file changed,
em
Tested-by: Abdul Haleem
Signed-off-by: Sukadev Bhattiprolu
---
Changelog[v2] For consistency with ibmvnic_open() use "goto out" and return
from end of function.
---
drivers/net/ethernet/ibm/ibmvnic.c | 14 ++
1 file changed, 14 insertions(+)
diff --
nly the reset
functions and ibmvnic_open() can set the adapter to OPEN state and this
must happen under rtnl.
Fixes: 7d7195a026ba ("ibmvnic: Do not process device remove during device
reset")
Signed-off-by: Sukadev Bhattiprolu
Reviewed-by: Dany Madden
---
Changelog[v2]
[Jakub Ki
Willem de Bruijn [willemdebruijn.ker...@gmail.com] wrote:
> On Thu, Jan 28, 2021 at 10:51 PM Sukadev Bhattiprolu
> wrote:
> >
> > If two or more instances of 'ip link set' commands race and first one
> > already brings the interface up (or down), the subseque
nly the reset
functions and ibmvnic_open() can set the adapter to OPEN state and this
must happen under rtnl.
Fixes: 7d7195a026ba ("ibmvnic: Do not process device remove during device
reset")
Signed-off-by: Sukadev Bhattiprolu
---
drivers/net/ethernet/ibm/ibmvnic.c | 72 +++
em
Tested-by: Abdul Haleem
Signed-off-by: Sukadev Bhattiprolu
---
drivers/net/ethernet/ibm/ibmvnic.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c
b/drivers/net/ethernet/ibm/ibmvnic.c
index cb7ddfefb03e..84b772921f35 100644
--- a/driv
if (adapter->state == VNIC_REMOVING ||
> > > - adapter->state == VNIC_REMOVED) {
> > > + if (adapter->state == VNIC_REMOVED) {
If the adapter is in REMOVING state, there is no point going
through the reset process. We could just bail out here. We
s
Jakub Kicinski [k...@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 cou
Jakub Kicinski [k...@kernel.org] wrote:
> On Tue, 12 Jan 2021 20:42:47 -0800 Sukadev Bhattiprolu wrote:
> > Jakub Kicinski [k...@kernel.org] wrote:
> > > On Tue, 12 Jan 2021 10:14:34 -0800 Sukadev Bhattiprolu wrote:
> > > > Use more consistent locking when read
Jakub Kicinski [k...@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 cou
ust be last
>this is not the preferred comment style: ^^
>
> I would just drop the comment here, it is clear from the name of the
> enum.
>
Yeah, we debated and figured the comment could serve as another reminder.
Here is updated patch, f
Saeed Mahameed [sa...@kernel.org] wrote:
> On Tue, 2021-01-12 at 10:14 -0800, Sukadev Bhattiprolu wrote:
> > @@ -5467,7 +5472,15 @@ static int ibmvnic_remove(struct vio_dev *dev)
> > return -EBUSY;
> > }
> >
> > + /* If ibmvnic_reset() is s
Restore adapter state before returning from change-param reset.
In case of errors, caller will try a hard-reset anyway.
Fixes: 0cb4bc66ba5e ("ibmvnic: restore adapter state on failed reset")
Signed-off-by: Sukadev Bhattiprolu
---
drivers/net/ethernet/ibm/ibmvnic.c | 2 +-
1 file
) but ignore any rwi entries that remain on the list.
Fixes: 2770a7984db58 ("Introduce hard reset recovery")
Fixes: 36f1031c51a2 ("ibmvnic: Do not process reset during or after device
removal")
Signed-off-by: Sukadev Bhattiprolu
---
drivers/net/eth
We check separately for REMOVING and PROBING in ibmvnic_reset().
Switch the order of checks to facilitate better locking when
checking for REMOVING/REMOVED state.
Fixes: 6a2fb0e99f9c ("ibmvnic: driver initialization for kdump/kexec")
Signed-off-by: Sukadev Bhattiprolu
---
drivers/ne
side
open/close/reset.
Thanks to a lot of input from Dany Madden, Lijun Pan and Rick Lindsley.
Fixes: 7d7195a026ba ("ibmvnic: Do not process device remove during device
reset")
Signed-off-by: Sukadev Bhattiprolu
---
---
drivers/net/ethernet/ibm/ibmvnic.c | 118 -
ing ->state_lock from a spin lock
to to a mutex to allow us to hold it for longer periods of time. Since
work can be scheduled from a tasklet, we cannot block on the mutex, so
use a new spin lock.
Fixes: 6954a9e4192b ("ibmvnic: Flush existing work items before device removal")
Signed
Add some comments, notes and TODOs about ->state_lock and RTNL.
Signed-off-by: Sukadev Bhattiprolu
---
drivers/net/ethernet/ibm/ibmvnic.c | 58 ++
drivers/net/ethernet/ibm/ibmvnic.h | 51 +-
2 files changed, 108 insertions(+), 1 delet
The reset functions need just the 'reset reason' parameter and not
the ibmvnic_rwi list element. Update the functions so we can simplify
the handling of the ->rwi_list in a follow-on patch.
Fixes: 2770a7984db5 ("ibmvnic: Introduce hard reset recovery")
Signed-off-
lly 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
Jakub Kicinski [k...@kernel.org] wrote:
> On Sun, 10 Jan 2021 19:52:25 -0800 Sukadev Bhattiprolu wrote:
> > Jakub Kicinski [k...@kernel.org] wrote:
> > > On Thu, 7 Jan 2021 23:12:34 -0800 Sukadev Bhattiprolu wrote:
> > > > Use a separate lock to serialze ibmv
Jakub Kicinski [k...@kernel.org] wrote:
> On Sun, 10 Jan 2021 19:12:21 -0800 Sukadev Bhattiprolu wrote:
> > Jakub Kicinski [k...@kernel.org] wrote:
> > > On Thu, 7 Jan 2021 23:12:31 -0800 Sukadev Bhattiprolu wrote:
> > > > The reset functions need just the &#
Jakub Kicinski [k...@kernel.org] wrote:
> On Thu, 7 Jan 2021 23:12:34 -0800 Sukadev Bhattiprolu wrote:
> > Use a separate lock to serialze ibmvnic_reset() and ibmvnic_remove()
> > functions. ibmvnic_reset() schedules work for the worker thread and
> > ibmvnic_remove() fl
Jakub Kicinski [k...@kernel.org] wrote:
> On Thu, 7 Jan 2021 23:12:31 -0800 Sukadev Bhattiprolu wrote:
> > The reset functions need just the 'reset reason' parameter and not
> > the ibmvnic_rwi list element. Update the functions so we can simplify
> > the handling o
Restore adapter state before returning from change-param reset.
In case of errors, caller will try a hard-reset anyway.
Fixes: 0cb4bc66ba5e ("ibmvnic: restore adapter state on failed reset")
Signed-off-by: Sukadev Bhattiprolu
---
drivers/net/ethernet/ibm/ibmvnic.c | 2 +-
1 file
We check separately for REMOVING and PROBING in ibmvnic_reset().
Switch the order of checks to facilitate better locking when
checking for REMOVING/REMOVED state.
Fixes: 6a2fb0e99f9c ("ibmvnic: driver initialization for kdump/kexec")
Signed-off-by: Sukadev Bhattiprolu
---
drivers/ne
The reset functions need just the 'reset reason' parameter and not
the ibmvnic_rwi list element. Update the functions so we can simplify
the handling of the ->rwi_list in a follow-on patch.
Fixes: 2770a7984db5 ("ibmvnic: Introduce hard reset recovery")
Signed-off-
side
open/close/reset.
Thanks to a lot of input from Dany Madden, Lijun Pan and Rick Lindsley.
Fixes: 7d7195a026ba ("ibmvnic: Do not process device remove during device
reset")
Signed-off-by: Sukadev Bhattiprolu
---
---
drivers/net/ethernet/ibm/ibmvnic.c | 1
Add some comments, notes and TODOs about ->state_lock and RTNL.
Signed-off-by: Sukadev Bhattiprolu
---
Note: This is fixing lot of comments so not identifying fixes. It
"seems" to fit this patch set but can send to net-next if
necessary.
drivers/net/ethernet/
items before
device removal")
Signed-off-by: Sukadev Bhattiprolu
---
drivers/net/ethernet/ibm/ibmvnic.c | 16 +++-
drivers/net/ethernet/ibm/ibmvnic.h | 2 ++
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c
b/driver
lly require manual intervention in bringing up
applications that depend on the network.
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
ibmv
) but ignore any rwi entries that remain on the list.
Fixes: 2770a7984db58 ("Introduce hard reset recovery")
Fixes: 36f1031c51a2 ("ibmvnic: Do not process reset during or after
device removal")
Signed-off-by: Sukadev Bhattiprolu
---
drivers/net/eth
with debug patches.
Signed-off-by: Sukadev Bhattiprolu
---
Changelog[v2]
[Jakub Kacinski] Change an netdev_err() to netdev_info()? Changed
to netdev_dbg() instead. Also sending to net rather than net-next.
---
drivers/net/ethernet/ibm/ibmvnic.c | 25 ++---
1
Jakub Kicinski [k...@kernel.org] wrote:
> On Mon, 23 Nov 2020 20:34:07 -0800 Sukadev Bhattiprolu wrote:
> > We sometimes run into situations where a soft/hard reset of the adapter
> > takes a long time or fails to complete. Having additional messages that
> > include importa
with debug patches.
Signed-off-by: Sukadev Bhattiprolu
---
Changelog[v2]
[Jakub Kacinski] Change an netdev_err() to netdev_info()? Changed
to netdev_dbg() instead. Also sending to net rather than net-next.
Note: this debug patch is based on following bug fixes and a
Jakub Kicinski [k...@kernel.org] wrote:
> On Fri, 20 Nov 2020 16:40:49 -0600 Lijun Pan wrote:
> > From: Sukadev Bhattiprolu
> >
> > We sometimes run into situations where a soft/hard reset of the adapter
> > takes a long time or fails to complete. Having additiona
with debug patches.
Sending this as an RFC for now, while we continue testing/optimizing the
messages.
Signed-off-by: Sukadev Bhattiprolu
---
drivers/net/ethernet/ibm/ibmvnic.c | 48 +++---
1 file changed, 37 insertions(+), 11 deletions(-)
diff --git a/drivers/net
etends" that
failover occurred "just after" open succeeded, so marks the open successful
and lets the failover complete the open. So, mark the open successful even
if the transport event occurs before we actually start the open.
Signed-off-by: Sukadev Bhattiprolu
---
Changelog [v3]:
Lijun Pan [l...@linux.vnet.ibm.com] wrote:
>On Oct 19, 2020, at 2:52 PM, Sukadev Bhattiprolu
><[1]suka...@linux.ibm.com> wrote:
>
>From 67f8977f636e462a1cd1eadb28edd98ef4f2b756 Mon Sep 17 00:00:00 2001
>From: Sukadev Bhattiprolu <[2]suka...@linux.vnet.ibm
at we either
finish the open or if the open() fails due to the failover pending window,
we can again pretend that open is done and let the failover complete it.
Signed-off-by: Sukadev Bhattiprolu
---
Changelog [v2]:
[Brian King] Ensure we clear failover_pending during hard reset
-
>From 67f8977f636e462a1cd1eadb28edd98ef4f2b756 Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu
Date: Thu, 10 Sep 2020 11:18:41 -0700
Subject: [PATCH 1/1] powerpc/vnic: Extend "failover pending" window
Commit 5a18e1e0c193b introduced the 'failover_pending' state to trac
Lijun Pan [l...@linux.vnet.ibm.com] wrote:
>
>
> > On Sep 22, 2020, at 11:53 PM, Sukadev Bhattiprolu
> > wrote:
> >
> >
> > From 547fa5627b63102f3ef80ed3a032d62c88c5 Mon Sep 17 00:00:00 2001
> > From: Sukadev Bhattiprolu
> > Date: Thu, 10
>From 547fa5627b63102f3ef80ed3a032d62c88c5 Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu
Date: Thu, 10 Sep 2020 11:18:41 -0700
Subject: [PATCH 1/1] powerpc/vnic: Extend "failover pending" window
Commit 5a18e1e0c193b introduced the 'failover_pending' state
Thomas Falcon [tlfal...@linux.ibm.com] wrote:
> Access Control Lists can be defined for each IBM VNIC
> adapter at time of creation. MAC address and VLAN ID's
> may be specified, as well as a Port VLAN ID (PVID).
> These may all be requested though read-only sysfs files:
> mac_acl, vlan_acl, and pv
ked-by: Sukadev Bhattiprolu <[EMAIL PROTECTED]>
|
| ---
|
| diff --git a/net/ipv4/ipvs/ip_vs_sync.c b/net/ipv4/ipvs/ip_vs_sync.c
| index 959c08d..d0798a5 100644
| --- a/net/ipv4/ipvs/ip_vs_sync.c
| +++ b/net/ipv4/ipvs/ip_vs_sync.c
| @@ -794,7 +794,7 @@ static int sync_thread(v
eing used :-)
Acked-by: Sukadev Bhattiprolu <[EMAIL PROTECTED]>
|
| ---
|
| diff --git a/net/core/pktgen.c b/net/core/pktgen.c
| index 3a3154e..93695c2 100644
| --- a/net/core/pktgen.c
| +++ b/net/core/pktgen.c
| @@ -380,7 +380,6 @@ struct pktgen_thread {
| /* Field for thread to
Auke Kok [EMAIL PROTECTED] wrote:
| Sukadev Bhattiprolu wrote:
| >I get following panic on 2.6.20-rc4-mm1 on a 2-cpu AMD Opteron system.
| >
| >Same basic config file seems to work with 2.6.20-rc2-mm1 on this same
| >system. Have not tried -rc3-mm1 yet.
| >
| >Attached are conf
I get following panic on 2.6.20-rc4-mm1 on a 2-cpu AMD Opteron system.
Same basic config file seems to work with 2.6.20-rc2-mm1 on this same
system. Have not tried -rc3-mm1 yet.
Attached are config file and "lspci -vv" output. Let me know if you need
more info.
Suka
---
[ 168.925840] Freeing
Jesse Brandeburg [EMAIL PROTECTED] wrote:
| On 9/28/06, Sukadev Bhattiprolu <[EMAIL PROTECTED]> wrote:
| >Thanks. See below for additional info
| >
| >Auke Kok [EMAIL PROTECTED] wrote:
| >| Sukadev Bhattiprolu wrote:
| >| >
| >| >I am unable to get networking to wor
Thanks. See below for additional info
Auke Kok [EMAIL PROTECTED] wrote:
| Sukadev Bhattiprolu wrote:
| >
| >I am unable to get networking to work with 2.6.18-mm1 on my system.
| >
| >But 2.6.18 kernel on same system works fine. Here is some info about
| >the system/debug attempt
I am unable to get networking to work with 2.6.18-mm1 on my system.
But 2.6.18 kernel on same system works fine. Here is some info about
the system/debug attempts. Attached are the lspci output and config.
Appreciate any help. Please let me know if you need more info.
Suka
System info:
Sukadev Bhattiprolu [EMAIL PROTECTED] wrote:
| Andrew,
|
| Javier Achirica, one of the major contributors to drivers/net/wireless/airo.c
| took a look at this patch, and doesn't have any problems with it. It doesn't
| fix any bugs and is just a cleanup, so it certainly isn't a
66 matches
Mail list logo
