* [PATCH v2 2/3] Bluetooth: btusb: Load firmware exclusively for Intel BT
From: Kai-Heng Feng @ 2019-07-17 7:49 UTC (permalink / raw)
To: johannes.berg, emmanuel.grumbach, luciano.coelho, marcel,
johan.hedberg
Cc: linuxwifi, linux-wireless, netdev, linux-bluetooth, linux-kernel,
Kai-Heng Feng
In-Reply-To: <20190717074920.21624-1-kai.heng.feng@canonical.com>
To avoid the firmware loading race between Bluetooth and WiFi on Intel
8260, load firmware exclusively when IWLWIFI is enabled.
BugLink: https://bugs.launchpad.net/bugs/1832988
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
---
v2:
- Add bug report link.
- Rebase on latest wireless-next.
drivers/bluetooth/btusb.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 50aed5259c2b..ca7a5757a2ba 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2272,8 +2272,16 @@ static int btusb_setup_intel_new(struct hci_dev *hdev)
set_bit(BTUSB_DOWNLOADING, &data->flags);
+#if IS_ENABLED(CONFIG_IWLWIFI)
+ btintel_firmware_lock();
+#endif
+
/* Start firmware downloading and get boot parameter */
err = btintel_download_firmware(hdev, fw, &boot_param);
+
+#if IS_ENABLED(CONFIG_IWLWIFI)
+ btintel_firmware_unlock();
+#endif
if (err < 0)
goto done;
--
2.17.1
^ permalink raw reply related
* [PATCH v2 3/3] iwlwifi: Load firmware exclusively for Intel WiFi
From: Kai-Heng Feng @ 2019-07-17 7:49 UTC (permalink / raw)
To: johannes.berg, emmanuel.grumbach, luciano.coelho, marcel,
johan.hedberg
Cc: linuxwifi, linux-wireless, netdev, linux-bluetooth, linux-kernel,
Kai-Heng Feng
In-Reply-To: <20190717074920.21624-1-kai.heng.feng@canonical.com>
To avoid the firmware loading race between Bluetooth and WiFi on Intel
8260, load firmware exclusively when BT_INTEL is enabled.
BugLink: https://bugs.launchpad.net/bugs/1832988
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
---
v2:
- Add bug report link.
- Rebase on latest wireless-next.
.../net/wireless/intel/iwlwifi/pcie/trans.c | 37 ++++++++++++++++++-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
index 602c31b3992a..e10ff847b216 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -72,6 +72,7 @@
#include <linux/pm_runtime.h>
#include <linux/module.h>
#include <linux/wait.h>
+#include <linux/intel-wifi-bt.h>
#include "iwl-drv.h"
#include "iwl-trans.h"
@@ -1335,6 +1336,10 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans *trans,
bool hw_rfkill;
int ret;
+#if IS_ENABLED(CONFIG_BT_INTEL)
+ void (*firmware_lock_func)(void);
+ void (*firmware_unlock_func)(void);
+#endif
/* This may fail if AMT took ownership of the device */
if (iwl_pcie_prepare_card_hw(trans)) {
IWL_WARN(trans, "Exit HW not ready\n");
@@ -1394,6 +1399,7 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans *trans,
* RF-Kill switch is toggled, we will find out after having loaded
* the firmware and return the proper value to the caller.
*/
+
iwl_enable_fw_load_int(trans);
/* really make sure rfkill handshake bits are cleared */
@@ -1401,8 +1407,37 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans *trans,
iwl_write32(trans, CSR_UCODE_DRV_GP1_CLR, CSR_UCODE_SW_BIT_RFKILL);
/* Load the given image to the HW */
- if (trans->cfg->device_family >= IWL_DEVICE_FAMILY_8000)
+ if (trans->cfg->device_family >= IWL_DEVICE_FAMILY_8000) {
+#if IS_ENABLED(CONFIG_BT_INTEL)
+ firmware_lock_func = symbol_request(btintel_firmware_lock);
+ firmware_unlock_func = symbol_request(btintel_firmware_unlock);
+ if (!firmware_lock_func || !firmware_unlock_func) {
+ if (firmware_lock_func) {
+ symbol_put(btintel_firmware_lock);
+ firmware_lock_func = NULL;
+ }
+
+ if (firmware_unlock_func) {
+ symbol_put(btintel_firmware_unlock);
+ firmware_unlock_func = NULL;
+ }
+ }
+
+ if (firmware_lock_func)
+ firmware_lock_func();
+#endif
ret = iwl_pcie_load_given_ucode_8000(trans, fw);
+
+#if IS_ENABLED(CONFIG_BT_INTEL)
+ if (firmware_unlock_func) {
+ firmware_unlock_func();
+ symbol_put(btintel_firmware_lock);
+ firmware_lock_func = NULL;
+ symbol_put(btintel_firmware_unlock);
+ firmware_unlock_func = NULL;
+ }
+#endif
+ }
else
ret = iwl_pcie_load_given_ucode(trans, fw);
--
2.17.1
^ permalink raw reply related
* [PATCH v2 1/3] Bluetooth: btintel: Add firmware lock function
From: Kai-Heng Feng @ 2019-07-17 7:49 UTC (permalink / raw)
To: johannes.berg, emmanuel.grumbach, luciano.coelho, marcel,
johan.hedberg
Cc: linuxwifi, linux-wireless, netdev, linux-bluetooth, linux-kernel,
Kai-Heng Feng
When Intel 8260 starts to load Bluetooth firmware and WiFi firmware, by
calling btintel_download_firmware() and iwl_pcie_load_given_ucode_8000()
respectively, the Bluetooth btintel_download_firmware() aborts half way:
[ 11.950216] Bluetooth: hci0: Failed to send firmware data (-38)
Let btusb and iwlwifi load firmwares exclusively can avoid the issue, so
introduce a lock to use in btusb and iwlwifi.
This issue still occurs with latest WiFi and Bluetooth firmwares.
BugLink: https://bugs.launchpad.net/bugs/1832988
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
---
v2:
- Add bug report link.
- Rebase on latest wireless-next.
drivers/bluetooth/btintel.c | 14 ++++++++++++++
drivers/bluetooth/btintel.h | 10 ++++++++++
include/linux/intel-wifi-bt.h | 8 ++++++++
3 files changed, 32 insertions(+)
create mode 100644 include/linux/intel-wifi-bt.h
diff --git a/drivers/bluetooth/btintel.c b/drivers/bluetooth/btintel.c
index bb99c8653aab..93ab18d6ddad 100644
--- a/drivers/bluetooth/btintel.c
+++ b/drivers/bluetooth/btintel.c
@@ -20,6 +20,8 @@
#define BDADDR_INTEL (&(bdaddr_t) {{0x00, 0x8b, 0x9e, 0x19, 0x03, 0x00}})
+static DEFINE_MUTEX(firmware_lock);
+
int btintel_check_bdaddr(struct hci_dev *hdev)
{
struct hci_rp_read_bd_addr *bda;
@@ -709,6 +711,18 @@ int btintel_download_firmware(struct hci_dev *hdev, const struct firmware *fw,
}
EXPORT_SYMBOL_GPL(btintel_download_firmware);
+void btintel_firmware_lock(void)
+{
+ mutex_lock(&firmware_lock);
+}
+EXPORT_SYMBOL_GPL(btintel_firmware_lock);
+
+void btintel_firmware_unlock(void)
+{
+ mutex_unlock(&firmware_lock);
+}
+EXPORT_SYMBOL_GPL(btintel_firmware_unlock);
+
MODULE_AUTHOR("Marcel Holtmann <marcel@holtmann.org>");
MODULE_DESCRIPTION("Bluetooth support for Intel devices ver " VERSION);
MODULE_VERSION(VERSION);
diff --git a/drivers/bluetooth/btintel.h b/drivers/bluetooth/btintel.h
index 3d846190f2bf..b3682d27d2ee 100644
--- a/drivers/bluetooth/btintel.h
+++ b/drivers/bluetooth/btintel.h
@@ -87,6 +87,8 @@ int btintel_read_boot_params(struct hci_dev *hdev,
struct intel_boot_params *params);
int btintel_download_firmware(struct hci_dev *dev, const struct firmware *fw,
u32 *boot_param);
+void btintel_firmware_lock(void);
+void btintel_firmware_unlock(void);
#else
static inline int btintel_check_bdaddr(struct hci_dev *hdev)
@@ -181,4 +183,12 @@ static inline int btintel_download_firmware(struct hci_dev *dev,
{
return -EOPNOTSUPP;
}
+
+static inline void btintel_firmware_lock(void)
+{
+}
+
+static inline void btintel_firmware_unlock(void)
+{
+}
#endif
diff --git a/include/linux/intel-wifi-bt.h b/include/linux/intel-wifi-bt.h
new file mode 100644
index 000000000000..260ed628d19b
--- /dev/null
+++ b/include/linux/intel-wifi-bt.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __INTEL_WIFI_BT_H__
+#define __INTEL_WIFI_BT_H__
+
+void btintel_firmware_lock(void);
+void btintel_firmware_unlock(void);
+
+#endif
--
2.17.1
^ permalink raw reply related
* [PATCH net] bnxt_en: Fix VNIC accounting when enabling aRFS on 57500 chips.
From: Michael Chan @ 2019-07-17 7:07 UTC (permalink / raw)
To: davem; +Cc: netdev
Unlike legacy chips, 57500 chips don't need additional VNIC resources
for aRFS/ntuple. Fix the code accordingly so that we don't reserve
and allocate additional VNICs on 57500 chips. Without this patch,
the driver is failing to initialize when it tries to allocate extra
VNICs.
Fixes: ac33906c67e2 ("bnxt_en: Add support for aRFS on 57500 chips.")
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
Please queue this for 5.2 -stable also. Thanks.
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 1069eb0..7134d2c 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -3075,7 +3075,7 @@ static int bnxt_alloc_vnics(struct bnxt *bp)
int num_vnics = 1;
#ifdef CONFIG_RFS_ACCEL
- if (bp->flags & BNXT_FLAG_RFS)
+ if ((bp->flags & (BNXT_FLAG_RFS | BNXT_FLAG_CHIP_P5)) == BNXT_FLAG_RFS)
num_vnics += bp->rx_nr_rings;
#endif
@@ -7186,6 +7186,9 @@ static int bnxt_alloc_rfs_vnics(struct bnxt *bp)
#ifdef CONFIG_RFS_ACCEL
int i, rc = 0;
+ if (bp->flags & BNXT_FLAG_CHIP_P5)
+ return 0;
+
for (i = 0; i < bp->rx_nr_rings; i++) {
struct bnxt_vnic_info *vnic;
u16 vnic_id = i + 1;
@@ -9645,7 +9648,7 @@ int bnxt_check_rings(struct bnxt *bp, int tx, int rx, bool sh, int tcs,
return -ENOMEM;
vnics = 1;
- if (bp->flags & BNXT_FLAG_RFS)
+ if ((bp->flags & (BNXT_FLAG_RFS | BNXT_FLAG_CHIP_P5)) == BNXT_FLAG_RFS)
vnics += rx_rings;
if (bp->flags & BNXT_FLAG_AGG_RINGS)
--
2.5.1
^ permalink raw reply related
* Re: [RFC PATCH 0/5] PTP: add support for Intel's TGPIO controller
From: Felipe Balbi @ 2019-07-17 6:52 UTC (permalink / raw)
To: Richard Cochran
Cc: netdev, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
H . Peter Anvin, x86, linux-kernel, Christopher S . Hall
In-Reply-To: <20190716164123.GB2125@localhost>
Hi,
Richard Cochran <richardcochran@gmail.com> writes:
> On Tue, Jul 16, 2019 at 10:20:33AM +0300, Felipe Balbi wrote:
>> TGPIO is a new IP which allows for time synchronization between systems
>> without any other means of synchronization such as PTP or NTP. The
>> driver is implemented as part of the PTP framework since its features
>> covered most of what this controller can do.
>
> Can you provide some background on this new HW? Is the interface
> copper wires between chips? Or is it perhaps coax between hosts?
It's just a pin, like a GPIO. So it would be a PCB trace, flat flex,
copper wire... Anything, really.
I think most of the usecases will involve devices somehow on the same
PCB, so a trace or flat flex would be more common. Perhaps Chris has a
better idea in mind? :-)
--
balbi
^ permalink raw reply
* Re: [RFC PATCH 5/5] PTP: Add support for Intel PMC Timed GPIO Controller
From: Felipe Balbi @ 2019-07-17 6:51 UTC (permalink / raw)
To: Shannon Nelson, Richard Cochran
Cc: netdev, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
H . Peter Anvin, x86, linux-kernel, Christopher S . Hall
In-Reply-To: <33864ede-1ce1-92f2-f049-a975060b2743@pensando.io>
Hi,
Shannon Nelson <snelson@pensando.io> writes:
> On 7/16/19 12:20 AM, Felipe Balbi wrote:
>> Add a driver supporting Intel Timed GPIO controller available as part
>> of some Intel PMCs.
>>
>> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>
> Hi Felipe, just a couple of quick comments:
>
> There are several places where a line is continued on the next line, but
> should be indented to match the opening parenthesis on a function call
> or 'if' expression.
>
> Shouldn't there be a kthread_stop() in intel_pmc_tgpio_remove(), or did
> I miss that somewhere?
Oops :-p
I could've sworn I had added it when disabling the pin. I'll review
that, sure.
--
balbi
^ permalink raw reply
* Re: [RFC PATCH 4/5] PTP: Add flag for non-periodic output
From: Felipe Balbi @ 2019-07-17 6:49 UTC (permalink / raw)
To: Richard Cochran
Cc: netdev, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
H . Peter Anvin, x86, linux-kernel, Christopher S . Hall
In-Reply-To: <20190716163927.GA2125@localhost>
Hi Richard,
Richard Cochran <richardcochran@gmail.com> writes:
> On Tue, Jul 16, 2019 at 10:20:37AM +0300, Felipe Balbi wrote:
>> When this new flag is set, we can use single-shot output.
>>
>> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>> ---
>> include/uapi/linux/ptp_clock.h | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/uapi/linux/ptp_clock.h b/include/uapi/linux/ptp_clock.h
>> index 674db7de64f3..439cbdfc3d9b 100644
>> --- a/include/uapi/linux/ptp_clock.h
>> +++ b/include/uapi/linux/ptp_clock.h
>> @@ -67,7 +67,9 @@ struct ptp_perout_request {
>> struct ptp_clock_time start; /* Absolute start time. */
>> struct ptp_clock_time period; /* Desired period, zero means disable. */
>> unsigned int index; /* Which channel to configure. */
>> - unsigned int flags; /* Reserved for future use. */
>> +
>> +#define PTP_PEROUT_ONE_SHOT BIT(0)
>> + unsigned int flags; /* Bit 0 -> oneshot output. */
>> unsigned int rsv[4]; /* Reserved for future use. */
>
> Unfortunately, the code never checked that .flags and .rsv are zero,
> and so the de-facto ABI makes extending these fields impossible. That
> was my mistake from the beginning.
>
> In order to actually support extensions, you will first have to
> introduce a new ioctl.
No worries, I'll work on this after vacations (I'll off for 2 weeks
starting next week). I thought about adding a new IOCTL until I saw that
rsv field. Oh well :-)
--
balbi
^ permalink raw reply
* [PATCH] net: dsa: sja1105: Fix missing unlock on error in sk_buff()
From: Wei Yongjun @ 2019-07-17 6:29 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Vladimir Oltean
Cc: Wei Yongjun, netdev, kernel-janitors
Add the missing unlock before return from function sk_buff()
in the error handling case.
Fixes: f3097be21bf1 ("net: dsa: sja1105: Add a state machine for RX timestamping")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
net/dsa/tag_sja1105.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/dsa/tag_sja1105.c b/net/dsa/tag_sja1105.c
index 1d96c9d4a8e9..26363d72d25b 100644
--- a/net/dsa/tag_sja1105.c
+++ b/net/dsa/tag_sja1105.c
@@ -216,6 +216,7 @@ static struct sk_buff
if (!skb) {
dev_err_ratelimited(dp->ds->dev,
"Failed to copy stampable skb\n");
+ spin_unlock(&sp->data->meta_lock);
return NULL;
}
sja1105_transfer_meta(skb, meta);
^ permalink raw reply related
* Re: [PATCH bpf] bpf: fix narrower loads on s390
From: Y Song @ 2019-07-17 5:11 UTC (permalink / raw)
To: Ilya Leoshkevich; +Cc: bpf, netdev, gor, heiko.carstens
In-Reply-To: <CAH3MdRWGVDjW8cA9EbnFjK8ko1EqeyDyC_LoRTsxhLsYn1fZtw@mail.gmail.com>
[sorry, resend again as previous one has come text messed out due to
networking issues]
On Tue, Jul 16, 2019 at 10:08 PM Y Song <ys114321@gmail.com> wrote:
>
> On Tue, Jul 16, 2019 at 4:59 AM Ilya Leoshkevich <iii@linux.ibm.com> wrote:
> >
> > test_pkt_md_access is failing on s390, since the associated eBPF prog
> > returns TC_ACT_SHOT, which in turn happens because loading a part of a
> > struct __sk_buff field produces an incorrect result.
> >
> > The problem is that when verifier emits the code to replace partial load
> > of a field with a full load, a shift and a bitwise AND, it assumes that
> > the machine is little endian.
> >
> > Adjust shift count calculation to account for endianness.
> >
> > Fixes: 31fd85816dbe ("bpf: permits narrower load from bpf program context fields")
> > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
> > ---
> > kernel/bpf/verifier.c | 8 ++++++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index 5900cbb966b1..3f9353653558 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -8616,8 +8616,12 @@ static int convert_ctx_accesses(struct bpf_verifier_env *env)
> > }
> >
> > if (is_narrower_load && size < target_size) {
> > - u8 shift = (off & (size_default - 1)) * 8;
> > -
> > + u8 load_off = off & (size_default - 1);
> > +#ifdef __LITTLE_ENDIAN
> > + u8 shift = load_off * 8;
> > +#else
> > + u8 shift = (size_default - (load_off + size)) * 8;
> > +#endif
>
All the values are in register. The shifting operations should be the
same for big endian and little endian, e.g., value 64 >> 2 = 16 when
value "64" is in register. So I did not see a problem here.
Could you elaborate which field access in test_pkt_md_access
caused problem?
It would be good if you can give detailed memory layout and register values
to illustrate the problem.
>
> > if (ctx_field_size <= 4) {
> > if (shift)
> > insn_buf[cnt++] = BPF_ALU32_IMM(BPF_RSH,
> > --
> > 2.21.0
> >
^ permalink raw reply
* Re: [PATCH bpf] bpf: fix narrower loads on s390
From: Y Song @ 2019-07-17 5:08 UTC (permalink / raw)
To: Ilya Leoshkevich; +Cc: bpf, netdev, gor, heiko.carstens
In-Reply-To: <20190716115910.23093-1-iii@linux.ibm.com>
On Tue, Jul 16, 2019 at 4:59 AM Ilya Leoshkevich <iii@linux.ibm.com> wrote:
>
> test_pkt_md_access is failing on s390, since the associated eBPF prog
> returns TC_ACT_SHOT, which in turn happens because loading a part of a
> struct __sk_buff field produces an incorrect result.
>
> The problem is that when verifier emits the code to replace partial load
> of a field with a full load, a shift and a bitwise AND, it assumes that
> the machine is little endian.
>
> Adjust shift count calculation to account for endianness.
>
> Fixes: 31fd85816dbe ("bpf: permits narrower load from bpf program context fields")
> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
> ---
> kernel/bpf/verifier.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 5900cbb966b1..3f9353653558 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -8616,8 +8616,12 @@ static int convert_ctx_accesses(struct bpf_verifier_env *env)
> }
>
> if (is_narrower_load && size < target_size) {
> - u8 shift = (off & (size_default - 1)) * 8;
> -
> + u8 load_off = off & (size_default - 1);
> +#ifdef __LITTLE_ENDIAN
> + u8 shift = load_off * 8;
> +#else
> + u8 shift = (size_default - (load_off + size)) * 8;
> +#endif
All the values are in register. The shifting operations should be the
same for big endian and little endian, e.g., value 64 >> 2 = 16 when
value "64" is in register. So I did not see a problem here.
Could you elaborate which field access in test_pkt_md_access
caused problem?
It would be good if you can give detailed memory la
> if (ctx_field_size <= 4) {
> if (shift)
> insn_buf[cnt++] = BPF_ALU32_IMM(BPF_RSH,
> --
> 2.21.0
>
^ permalink raw reply
* Re: [PATCH net] be2net: Signal that the device cannot transmit during reconfiguration
From: Firo Yang @ 2019-07-17 4:23 UTC (permalink / raw)
To: Benjamin Poirier, David Miller
Cc: Ajit Khaparde, Sathya Perla, Somnath Kotur, Sriharsha Basavapatna,
Saeed Mahameed, netdev@vger.kernel.org
In-Reply-To: <20190716081655.7676-1-bpoirier@suse.com>
I think there is a problem if dev_watchdog() is triggered before netif_carrier_off(). dev_watchdog() might call ->ndo_tx_timeout(), i.e. be_tx_timeout(), if txq timeout happens. Thus be_tx_timeout() could still be able to access the memory which is being freed by be_update_queues().
Thanks,
Firo
________________________________________
From: Benjamin Poirier
Sent: Tuesday, July 16, 2019 4:16 PM
To: David Miller
Cc: Ajit Khaparde; Sathya Perla; Somnath Kotur; Sriharsha Basavapatna; Saeed Mahameed; Firo Yang; netdev@vger.kernel.org
Subject: [PATCH net] be2net: Signal that the device cannot transmit during reconfiguration
While changing the number of interrupt channels, be2net stops adapter
operation (including netif_tx_disable()) but it doesn't signal that it
cannot transmit. This may lead dev_watchdog() to falsely trigger during
that time.
Add the missing call to netif_carrier_off(), following the pattern used in
many other drivers. netif_carrier_on() is already taken care of in
be_open().
Signed-off-by: Benjamin Poirier <bpoirier@suse.com>
---
drivers/net/ethernet/emulex/benet/be_main.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 82015c8a5ed7..b7a246b33599 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -4697,8 +4697,12 @@ int be_update_queues(struct be_adapter *adapter)
struct net_device *netdev = adapter->netdev;
int status;
- if (netif_running(netdev))
+ if (netif_running(netdev)) {
+ /* device cannot transmit now, avoid dev_watchdog timeouts */
+ netif_carrier_off(netdev);
+
be_close(netdev);
+ }
be_cancel_worker(adapter);
--
2.22.0
^ permalink raw reply related
* Re: [bpf PATCH v3 0/8] sockmap/tls fixes
From: Jakub Kicinski @ 2019-07-17 4:03 UTC (permalink / raw)
To: John Fastabend; +Cc: ast, daniel, netdev, edumazet, bpf
In-Reply-To: <156322373173.18678.6003379631139659856.stgit@john-XPS-13-9370>
On Mon, 15 Jul 2019 13:49:01 -0700, John Fastabend wrote:
> Resolve a series of splats discovered by syzbot and an unhash
> TLS issue noted by Eric Dumazet.
I spent most of today poking at this set, and I'll continue tomorrow.
I'm not capitulating yet, but if I can't get it to work for tls_device
soon, I'll make a version which skips the unhash for offload for now..
^ permalink raw reply
* Re: [bpf-next RFC 3/6] bpf: add bpf_tcp_gen_syncookie helper
From: Petar Penkov @ 2019-07-17 3:33 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Eric Dumazet, Networking, bpf, davem, Alexei Starovoitov,
Daniel Borkmann, Eric Dumazet, Lorenz Bauer, Stanislav Fomichev,
Petar Penkov
In-Reply-To: <20190717022635.yt7kczxa73kbi7ep@ast-mbp.dhcp.thefacebook.com>
Thank you for your feedback!
On Tue, Jul 16, 2019 at 7:26 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Tue, Jul 16, 2019 at 09:59:26AM +0200, Eric Dumazet wrote:
> >
> >
> > On 7/16/19 2:26 AM, Petar Penkov wrote:
> > > From: Petar Penkov <ppenkov@google.com>
> > >
> > > This helper function allows BPF programs to try to generate SYN
> > > cookies, given a reference to a listener socket. The function works
> > > from XDP and with an skb context since bpf_skc_lookup_tcp can lookup a
> > > socket in both cases.
> > >
> > ...
> > >
> > > +BPF_CALL_5(bpf_tcp_gen_syncookie, struct sock *, sk, void *, iph, u32, iph_len,
> > > + struct tcphdr *, th, u32, th_len)
> > > +{
> > > +#ifdef CONFIG_SYN_COOKIES
> > > + u32 cookie;
> > > + u16 mss;
> > > +
> > > + if (unlikely(th_len < sizeof(*th)))
> >
> >
> > You probably need to check that th_len == th->doff * 4
>
> +1
> that is surely necessary for safety.
I'll make sure to include this check in the next version.
>
> Considering the limitation of 5 args the api choice is good.
> struct bpf_syncookie approach doesn't look natural to me.
> And I couldn't come up with any better way to represent this helper.
> So let's go with
> return htonl(cookie) | ((u64)mss << 32);
> My only question is why htonl ?
I did it to mirror bpf_tcp_check_syncookie which sees a network order
cookie. That said, it is probably better for the caller to call
bpf_htonl() as they see fit, rather than to do it in the helper. Will
update, thanks.
>
> Independently of that...
> Since we've been hitting this 5 args limit too much,
> we need to start thinking how to extend BPF ISA to pass
> args 6,7,8 on stack.
>
Agreed, having an additional argument would have been helpful for this function.
^ permalink raw reply
* Re: [PATCH] skbuff: fix compilation warnings in skb_dump()
From: Joe Perches @ 2019-07-17 3:06 UTC (permalink / raw)
To: Willem de Bruijn, Qian Cai
Cc: David Miller, Willem de Bruijn, clang-built-linux,
Network Development, LKML
In-Reply-To: <CAF=yD-KW-XnDvD0i8VbzrkLGNWEY6cPoaEcHy40hbghGXTo+kA@mail.gmail.com>
On Tue, 2019-07-16 at 17:04 +0200, Willem de Bruijn wrote:
> On Tue, Jul 16, 2019 at 4:56 PM Qian Cai <cai@lca.pw> wrote:
> > Fix them by using the proper types, and also fix some checkpatch
> > warnings by using pr_info().
> >
> > WARNING: printk() should include KERN_<LEVEL> facility level
> > + printk("%ssk family=%hu type=%u proto=%u\n",
>
> Converting printk to pr_info lowers all levels to KERN_INFO.
>
> skb_dump takes an explicit parameter level to be able to log at
> KERN_ERR or KERN_WARNING
>
> I would like to avoid those checkpatch warnings, but this is not the
> right approach.
Just ignore checkpatch when it doesn't know that
the printk actually includes a KERN_<LEVEL> via
"%s...", level
^ permalink raw reply
* Re: [bpf-next RFC 3/6] bpf: add bpf_tcp_gen_syncookie helper
From: Alexei Starovoitov @ 2019-07-17 2:26 UTC (permalink / raw)
To: Eric Dumazet
Cc: Petar Penkov, netdev, bpf, davem, ast, daniel, edumazet, lmb, sdf,
Petar Penkov
In-Reply-To: <b6ef24b0-0415-c67d-5a66-21f1c2530414@gmail.com>
On Tue, Jul 16, 2019 at 09:59:26AM +0200, Eric Dumazet wrote:
>
>
> On 7/16/19 2:26 AM, Petar Penkov wrote:
> > From: Petar Penkov <ppenkov@google.com>
> >
> > This helper function allows BPF programs to try to generate SYN
> > cookies, given a reference to a listener socket. The function works
> > from XDP and with an skb context since bpf_skc_lookup_tcp can lookup a
> > socket in both cases.
> >
> ...
> >
> > +BPF_CALL_5(bpf_tcp_gen_syncookie, struct sock *, sk, void *, iph, u32, iph_len,
> > + struct tcphdr *, th, u32, th_len)
> > +{
> > +#ifdef CONFIG_SYN_COOKIES
> > + u32 cookie;
> > + u16 mss;
> > +
> > + if (unlikely(th_len < sizeof(*th)))
>
>
> You probably need to check that th_len == th->doff * 4
+1
that is surely necessary for safety.
Considering the limitation of 5 args the api choice is good.
struct bpf_syncookie approach doesn't look natural to me.
And I couldn't come up with any better way to represent this helper.
So let's go with
return htonl(cookie) | ((u64)mss << 32);
My only question is why htonl ?
Independently of that...
Since we've been hitting this 5 args limit too much,
we need to start thinking how to extend BPF ISA to pass
args 6,7,8 on stack.
^ permalink raw reply
* Re: [PATCH v5] net: netfilter: Fix rpfilter dropping vrf packets by mistake
From: linmiaohe @ 2019-07-17 2:11 UTC (permalink / raw)
To: Pablo Neira Ayuso, davem@davemloft.net
Cc: kadlec@blackhole.kfki.hu, fw@strlen.de, kuznet@ms2.inr.ac.ru,
yoshfuji@linux-ipv6.org, netfilter-devel@vger.kernel.org,
coreteam@netfilter.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Mingfangsen
> On Tue, Jul 17, 2019 at 19:17:36PM +0000, Pablo wrote:
> > On Tue, Jul 02, 2019 at 03:59:36AM +0000, Miaohe Lin wrote:
> > When firewalld is enabled with ipv4/ipv6 rpfilter, vrf
> > ipv4/ipv6 packets will be dropped. Vrf device will pass through
> > netfilter hook twice. One with enslaved device and another one with l3
> > master device. So in device may dismatch witch out device because out
> > device is always enslaved device.So failed with the check of the
> > rpfilter and drop the packets by mistake.
>
> Applied to nf.git, thanks.
Many thanks. It's really a longterm stuff. Thanks for your
patience. Have a nice day!
Best wishes.
^ permalink raw reply
* [PATCH] gve: replace kfree with kvfree
From: Chuhong Yuan @ 2019-07-17 2:05 UTC (permalink / raw)
Cc: Catherine Sullivan, David S . Miller, netdev, linux-kernel,
Chuhong Yuan
Variables allocated by kvzalloc should not be freed by kfree.
Because they may be allocated by vmalloc.
So we replace kfree with kvfree here.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
---
drivers/net/ethernet/google/gve/gve_main.c | 22 +++++++++++-----------
drivers/net/ethernet/google/gve/gve_rx.c | 4 ++--
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
index 24f16e3368cd..10b8e9720c32 100644
--- a/drivers/net/ethernet/google/gve/gve_main.c
+++ b/drivers/net/ethernet/google/gve/gve_main.c
@@ -232,7 +232,7 @@ static int gve_alloc_notify_blocks(struct gve_priv *priv)
abort_with_msix_enabled:
pci_disable_msix(priv->pdev);
abort_with_msix_vectors:
- kfree(priv->msix_vectors);
+ kvfree(priv->msix_vectors);
priv->msix_vectors = NULL;
return err;
}
@@ -256,7 +256,7 @@ static void gve_free_notify_blocks(struct gve_priv *priv)
priv->ntfy_blocks = NULL;
free_irq(priv->msix_vectors[priv->mgmt_msix_idx].vector, priv);
pci_disable_msix(priv->pdev);
- kfree(priv->msix_vectors);
+ kvfree(priv->msix_vectors);
priv->msix_vectors = NULL;
}
@@ -445,12 +445,12 @@ static int gve_alloc_rings(struct gve_priv *priv)
return 0;
free_rx:
- kfree(priv->rx);
+ kvfree(priv->rx);
priv->rx = NULL;
free_tx_queue:
gve_tx_free_rings(priv);
free_tx:
- kfree(priv->tx);
+ kvfree(priv->tx);
priv->tx = NULL;
return err;
}
@@ -500,7 +500,7 @@ static void gve_free_rings(struct gve_priv *priv)
gve_remove_napi(priv, ntfy_idx);
}
gve_tx_free_rings(priv);
- kfree(priv->tx);
+ kvfree(priv->tx);
priv->tx = NULL;
}
if (priv->rx) {
@@ -509,7 +509,7 @@ static void gve_free_rings(struct gve_priv *priv)
gve_remove_napi(priv, ntfy_idx);
}
gve_rx_free_rings(priv);
- kfree(priv->rx);
+ kvfree(priv->rx);
priv->rx = NULL;
}
}
@@ -592,9 +592,9 @@ static void gve_free_queue_page_list(struct gve_priv *priv,
gve_free_page(&priv->pdev->dev, qpl->pages[i],
qpl->page_buses[i], gve_qpl_dma_dir(priv, id));
- kfree(qpl->page_buses);
+ kvfree(qpl->page_buses);
free_pages:
- kfree(qpl->pages);
+ kvfree(qpl->pages);
priv->num_registered_pages -= qpl->num_entries;
}
@@ -635,7 +635,7 @@ static int gve_alloc_qpls(struct gve_priv *priv)
free_qpls:
for (j = 0; j <= i; j++)
gve_free_queue_page_list(priv, j);
- kfree(priv->qpls);
+ kvfree(priv->qpls);
return err;
}
@@ -644,12 +644,12 @@ static void gve_free_qpls(struct gve_priv *priv)
int num_qpls = gve_num_tx_qpls(priv) + gve_num_rx_qpls(priv);
int i;
- kfree(priv->qpl_cfg.qpl_id_map);
+ kvfree(priv->qpl_cfg.qpl_id_map);
for (i = 0; i < num_qpls; i++)
gve_free_queue_page_list(priv, i);
- kfree(priv->qpls);
+ kvfree(priv->qpls);
}
/* Use this to schedule a reset when the device is capable of continuing
diff --git a/drivers/net/ethernet/google/gve/gve_rx.c b/drivers/net/ethernet/google/gve/gve_rx.c
index c1aeabd1c594..1914b8350da7 100644
--- a/drivers/net/ethernet/google/gve/gve_rx.c
+++ b/drivers/net/ethernet/google/gve/gve_rx.c
@@ -35,7 +35,7 @@ static void gve_rx_free_ring(struct gve_priv *priv, int idx)
gve_unassign_qpl(priv, rx->data.qpl->id);
rx->data.qpl = NULL;
- kfree(rx->data.page_info);
+ kvfree(rx->data.page_info);
slots = rx->data.mask + 1;
bytes = sizeof(*rx->data.data_ring) * slots;
@@ -168,7 +168,7 @@ static int gve_rx_alloc_ring(struct gve_priv *priv, int idx)
rx->q_resources, rx->q_resources_bus);
rx->q_resources = NULL;
abort_filled:
- kfree(rx->data.page_info);
+ kvfree(rx->data.page_info);
abort_with_slots:
bytes = sizeof(*rx->data.data_ring) * slots;
dma_free_coherent(hdev, bytes, rx->data.data_ring, rx->data.data_bus);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH bpf] selftests/bpf: fix perf_buffer on s390
From: Alexei Starovoitov @ 2019-07-17 1:43 UTC (permalink / raw)
To: Andrii Nakryiko; +Cc: Ilya Leoshkevich, bpf, Networking, gor, Heiko Carstens
In-Reply-To: <CAEf4BzbWVJcQ2pN9UwYagtBpgoL+8Q+DMwwiUt1iCMciH8YUKA@mail.gmail.com>
On Tue, Jul 16, 2019 at 10:42 AM Andrii Nakryiko
<andrii.nakryiko@gmail.com> wrote:
>
> On Tue, Jul 16, 2019 at 5:59 AM Ilya Leoshkevich <iii@linux.ibm.com> wrote:
> >
> > perf_buffer test fails for exactly the same reason test_attach_probe
> > used to fail: different nanosleep syscall kprobe name.
> >
> > Reuse the test_attach_probe fix.
> >
> > Fixes: ee5cf82ce04a ("selftests/bpf: test perf buffer API")
> > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
> > ---
>
> Thanks for the fix!
>
> Acked-by: Andrii Nakryiko <andriin@fb.com>
Applied. Thanks!
^ permalink raw reply
* Re: [PATCH bpf 1/2] selftests/bpf: fix test_verifier/test_maps make dependencies
From: Alexei Starovoitov @ 2019-07-17 1:35 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Stanislav Fomichev, Andrii Nakryiko, bpf, Networking,
Daniel Borkmann, Alexei Starovoitov, Kernel Team,
Ilya Leoshkevich, Stanislav Fomichev, Martin KaFai Lau
In-Reply-To: <CAEf4BzZQ9MRTNH434=oyxBjQQXWEfjMV4nU14-=LfvERafwRKw@mail.gmail.com>
On Tue, Jul 16, 2019 at 5:22 PM Andrii Nakryiko
<andrii.nakryiko@gmail.com> wrote:
> > Makefile becomes hairier by the day, thx for cleaning it up a bit :-)
> >
> > > But I also don't think we need to worry about creating them, because
> > > there is always at least one test (otherwise those tests are useless
> > > anyways) in those directories, so we might as well just remove those
> > > dependencies, I guess.
> > We probably care about them for "make -C tools/selftests O=$PWD/xyz" case
> > where OUTPUT would point to a fresh/clean directory.
>
> Oh, yes, out-of-tree builds, forgot about that, so yeah, we need that.
Anyhow the patches fixed the issue I was seeing.
Hence both applied.
^ permalink raw reply
* RE: [EXT] [PATCH v1] net: fec: optionally reset PHY via a reset-controller
From: Andy Duan @ 2019-07-17 1:32 UTC (permalink / raw)
To: Sven Van Asbroeck
Cc: David S . Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CAGngYiUb5==QSM1-oa4bSeqhGyoaTw_dWjygLo=0X60eX=wQhQ@mail.gmail.com>
From: Sven Van Asbroeck <thesven73@gmail.com> Sent: Tuesday, July 16, 2019 9:19 PM
> Hi Andy,
>
> On Mon, Jul 15, 2019 at 10:02 PM Andy Duan <fugang.duan@nxp.com>
> wrote:
> >
> > the phylib already can handle mii bus reset and phy device reset
>
> That's a great suggestion, thank you !! I completely overlooked that code.
> What will happen to the legacy phy reset code in fec? Are there many users
> left?
Yes, so the old legacy code is kept there. But it is better to clean up all if
there have enough boards to verify them.
^ permalink raw reply
* Re: [PATCH RFC 0/4] Add support to directly attach BPF program to ftrace
From: Alexei Starovoitov @ 2019-07-17 1:30 UTC (permalink / raw)
To: Steven Rostedt
Cc: Joel Fernandes, linux-kernel, Adrian Ratiu, Alexei Starovoitov,
bpf, Brendan Gregg, connoro, Daniel Borkmann, duyuchao,
Ingo Molnar, jeffv, Karim Yaghmour, kernel-team, linux-kselftest,
Manali Shukla, Manjo Raja Rao, Martin KaFai Lau, Masami Hiramatsu,
Matt Mullins, Michal Gregorczyk, Michal Gregorczyk,
Mohammad Husain, namhyung, namhyung, netdev, paul.chaignon,
primiano, Qais Yousef, Shuah Khan, Song Liu, Srinivas Ramana,
Tamir Carmeli, Yonghong Song
In-Reply-To: <20190716183117.77b3ed49@gandalf.local.home>
On Tue, Jul 16, 2019 at 06:31:17PM -0400, Steven Rostedt wrote:
> On Tue, 16 Jul 2019 17:30:50 -0400
> Joel Fernandes <joel@joelfernandes.org> wrote:
>
> > I don't see why a new bpf node for a trace event is a bad idea, really.
> > tracefs is how we deal with trace events on Android. We do it in production
> > systems. This is a natural extension to that and fits with the security model
> > well.
>
> What I would like to see is a way to have BPF inject data into the
> ftrace ring buffer directly. There's a bpf_trace_printk() that I find a
> bit of a hack (especially since it hooks into trace_printk() which is
> only for debugging purposes). Have a dedicated bpf ftrace ring
> buffer event that can be triggered is what I am looking for. Then comes
> the issue of what ring buffer to place it in, as ftrace can have
> multiple ring buffer instances. But these instances are defined by the
> tracefs instances directory. Having a way to associate a bpf program to
> a specific event in a specific tracefs directory could allow for ways to
> trigger writing into the correct ftrace buffer.
bpf can write anything (including full skb) into perf ring buffer.
I don't think there is a use case yet to write into ftrace ring buffer.
But I can be convinced otherwise :)
> But looking over the patches, I see what Alexei means that there's no
> overlap with ftrace and these patches except for the tracefs directory
> itself (which is part of the ftrace infrastructure). And the trace
> events are technically part of the ftrace infrastructure too. I see the
> tracefs interface being used, but I don't see how the bpf programs
> being added affect the ftrace ring buffer or other parts of ftrace. And
> I'm guessing that's what is confusing Alexei.
yep.
What I really like to see some day is proper integration of real ftrace
and bpf. So that bpf progs can be invoked from some of the ftrace machinery.
And the other way around.
Like I'd love to be able to start ftracing all functions from bpf
and stop it from bpf.
The use case is kernel debugging. I'd like to examine a bunch of condition
and start ftracing the execution. Then later decide wether this collection
of ip addresses is interesting to analyze and post process it quickly
while still inside bpf program.
^ permalink raw reply
* Re: [PATCH RFC 0/4] Add support to directly attach BPF program to ftrace
From: Alexei Starovoitov @ 2019-07-17 1:24 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Adrian Ratiu, Alexei Starovoitov, bpf,
Brendan Gregg, connoro, Daniel Borkmann, duyuchao, Ingo Molnar,
jeffv, Karim Yaghmour, kernel-team, linux-kselftest,
Manali Shukla, Manjo Raja Rao, Martin KaFai Lau, Masami Hiramatsu,
Matt Mullins, Michal Gregorczyk, Michal Gregorczyk,
Mohammad Husain, namhyung, namhyung, netdev, paul.chaignon,
primiano, Qais Yousef, Shuah Khan, Song Liu, Srinivas Ramana,
Steven Rostedt, Tamir Carmeli, Yonghong Song
In-Reply-To: <20190716235500.GA199237@google.com>
On Tue, Jul 16, 2019 at 07:55:00PM -0400, Joel Fernandes wrote:
> On Tue, Jul 16, 2019 at 06:41:50PM -0400, Joel Fernandes wrote:
> > On Tue, Jul 16, 2019 at 03:26:52PM -0700, Alexei Starovoitov wrote:
> > > On Tue, Jul 16, 2019 at 05:30:50PM -0400, Joel Fernandes wrote:
> > > >
> > > > I also thought about the pinning idea before, but we also want to add support
> > > > for not just raw tracepoints, but also regular tracepoints (events if you
> > > > will). I am hesitant to add a new BPF API just for creating regular
> > > > tracepoints and then pinning those as well.
> > >
> > > and they should be done through the pinning as well.
> >
> > Hmm ok, I will give it some more thought.
>
> I think I can make the new BPF API + pinning approach work, I will try to
> work on something like this and post it soon.
>
> Also, I had a question below if you don't mind taking a look:
>
> thanks Alexei!
>
> > > > I don't see why a new bpf node for a trace event is a bad idea, really.
> > >
> > > See the patches for kprobe/uprobe FD-based api and the reasons behind it.
> > > tldr: text is racy, doesn't scale, poor security, etc.
> >
> > Is it possible to use perf without CAP_SYS_ADMIN and control security at the
> > per-event level? We are selective about who can access which event, using
> > selinux. That's how our ftrace-based tracers work. Its fine grained per-event
> > control. That's where I was going with the tracefs approach since we get that
> > granularity using the file system.
android's choice of selinux is not a factor in deciding kernel apis.
It's completely separate discusion wether disallowing particular tracepoints
for given user make sense at all.
Just because you can hack it in via selinux blocking particular
/sys/debug/tracing/ directory and convince yourself that it's somehow
makes android more secure. It doesn't mean that all new api should fit
into this model.
I think allowing one tracepoint and disallowing another is pointless
from security point of view. Tracing bpf program can do bpf_probe_read
of anything.
^ permalink raw reply
* Re: [RFC bpf-next 0/8] bpf: accelerate insn patching speed
From: Alexei Starovoitov @ 2019-07-17 1:17 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Jiong Wang, Andrii Nakryiko, Daniel Borkmann, Edward Cree,
Naveen N. Rao, Andrii Nakryiko, bpf, Networking, oss-drivers,
Yonghong Song
In-Reply-To: <20190716151223.7208c033@cakuba.netronome.com>
On Tue, Jul 16, 2019 at 3:12 PM Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
>
> On Tue, 16 Jul 2019 09:17:03 -0700, Alexei Starovoitov wrote:
> > I don't think we have a test for such 'dead prog only due to verifier walk'
> > situation. I wonder what happens :)
>
> FWIW we do have verifier and BTF self tests for dead code removal
> of entire subprogs! :)
Thanks! Indeed.
^ permalink raw reply
* Re: [PATCH net v3 6/7] net/rds: Keep track of and wait for FRWR segments in use upon shutdown
From: santosh.shilimkar @ 2019-07-17 0:28 UTC (permalink / raw)
To: Gerd Rausch, netdev, linux-rdma, rds-devel; +Cc: David Miller
In-Reply-To: <28ded44a-bce9-8632-d7e8-fe843140658e@oracle.com>
On 7/16/19 3:29 PM, Gerd Rausch wrote:
> Since "rds_ib_free_frmr" and "rds_ib_free_frmr_list" simply put
> the FRMR memory segments on the "drop_list" or "free_list",
> and it is the job of "rds_ib_flush_mr_pool" to reap those entries
> by ultimately issuing a "IB_WR_LOCAL_INV" work-request,
> we need to trigger and then wait for all those memory segments
> attached to a particular connection to be fully released before
> we can move on to release the QP, CQ, etc.
>
> So we make "rds_ib_conn_path_shutdown" wait for one more
> atomic_t called "i_fastreg_inuse_count" that keeps track of how
> many FRWR memory segments are out there marked "FRMR_IS_INUSE"
> (and also wake_up rds_ib_ring_empty_wait, as they go away).
>
> Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com>
> ---
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
^ permalink raw reply
* Re: [PATCH net v3 7/7] net/rds: Initialize ic->i_fastreg_wrs upon allocation
From: santosh.shilimkar @ 2019-07-17 0:29 UTC (permalink / raw)
To: Gerd Rausch, netdev, linux-rdma, rds-devel; +Cc: David Miller
In-Reply-To: <94bc1575-1772-3619-e8d5-b74463308e0f@oracle.com>
On 7/16/19 3:29 PM, Gerd Rausch wrote:
> Otherwise, if an IB connection is torn down before "rds_ib_setup_qp"
> is called, the value of "ic->i_fastreg_wrs" is still at zero
> (as it wasn't initialized by "rds_ib_setup_qp").
> Consequently "rds_ib_conn_path_shutdown" will spin forever,
> waiting for it to go back to "RDS_IB_DEFAULT_FR_WR",
> which of course will never happen as there are no
> outstanding work requests.
>
> Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com>
> ---
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox