* Re: [PATCH v2] ath6kl: mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2018-05-25 18:48 UTC (permalink / raw)
To: Steve deRosier
Cc: Kalle Valo, davem, sergei.shtylyov, linux-wireless,
Network Development, LKML
In-Reply-To: <CALLGbRLFU5xH7PogXmjNSFkayLyo2Q1w1+8hQWgOSDYxS_GgUQ@mail.gmail.com>
On 05/25/2018 01:27 PM, Steve deRosier wrote:
> On Fri, May 25, 2018 at 11:23 AM Gustavo A. R. Silva
> <gustavo@embeddedor.com>
> wrote:
>
>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>> where we are expecting to fall through.
>
>> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>> ---
>> Changes in v2:
>> - Place code comments on a line of their own.
>
>> drivers/net/wireless/ath/ath6kl/cfg80211.c | 3 +++
>> 1 file changed, 3 insertions(+)
>
>> diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c
> b/drivers/net/wireless/ath/ath6kl/cfg80211.c
>> index 2ba8cf3..a16ee5d 100644
>> --- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
>> +++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
>> @@ -3899,16 +3899,19 @@ int ath6kl_cfg80211_init(struct ath6kl *ar)
>> switch (ar->hw.cap) {
>> case WMI_11AN_CAP:
>> ht = true;
>> + /* fall through */
>> case WMI_11A_CAP:
>> band_5gig = true;
>> break;
>> case WMI_11GN_CAP:
>> ht = true;
>> + /* fall through */
>> case WMI_11G_CAP:
>> band_2gig = true;
>> break;
>> case WMI_11AGN_CAP:
>> ht = true;
>> + /* fall through */
>> case WMI_11AG_CAP:
>> band_2gig = true;
>> band_5gig = true;
>> --
>> 2.7.4
>
>
> Gustavo,
>
> Thanks for the adjustment. It now looks good to me.
>
Glad to help. :)
> Reviewed-by: Steve deRosier <derosier@cal-sierra.com>
>
Thanks
--
Gustavo
^ permalink raw reply
* Re: [PATCH v2 net-next] sfc: stop the TX queue before pushing new buffers
From: David Miller @ 2018-05-25 18:50 UTC (permalink / raw)
To: mhabets; +Cc: linux-net-drivers, netdev, jarod
In-Reply-To: <f2749cb0-f1ce-4572-04fe-f1c11fe09237@solarflare.com>
From: Martin Habets <mhabets@solarflare.com>
Date: Thu, 24 May 2018 10:14:00 +0100
> efx_enqueue_skb() can push new buffers for the xmit_more functionality.
> We must stops the TX queue before this or else the TX queue does not get
> restarted and we get a netdev watchdog.
>
> In the error handling we may now need to unwind more than 1 packet, and
> we may need to push the new buffers onto the partner queue.
>
> v2: In the error leg also push this queue if xmit_more is set
>
> Fixes: e9117e5099ea ("sfc: Firmware-Assisted TSO version 2")
> Reported-by: Jarod Wilson <jarod@redhat.com>
> Tested-by: Jarod Wilson <jarod@redhat.com>
> Signed-off-by: Martin Habets <mhabets@solarflare.com>
> ---
>
> Dave, could you please also queue this patch up for stable?
Applied to net-next.
As per -stable, only patches that go into my 'net' tree may be proposed
for -stable.
^ permalink raw reply
* Re: [PATCH net-next] net: fec: remove stale comment
From: David Miller @ 2018-05-25 18:53 UTC (permalink / raw)
To: yuehaibing; +Cc: fugang.duan, netdev, linux-kernel
In-Reply-To: <20180524112707.3580-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 24 May 2018 19:27:07 +0800
> This comment is outdated as fec_ptp_ioctl has been replaced by fec_ptp_set/fec_ptp_get
> since commit 1d5244d0e43b ("fec: Implement the SIOCGHWTSTAMP ioctl")
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH 0/4] pull request for net: batman-adv 2018-05-24
From: David Miller @ 2018-05-25 18:54 UTC (permalink / raw)
To: sw; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <20180524115325.15355-1-sw@simonwunderlich.de>
From: Simon Wunderlich <sw@simonwunderlich.de>
Date: Thu, 24 May 2018 13:53:21 +0200
> here are a couple of bugfixes which we would like to have integrated into net.
>
> Please pull or let me know of any problem!
Looks good, pulled, thanks Simon.
^ permalink raw reply
* Re: [PATCH net-next v2] cxgb4/cxgb4vf: link management changes for new SFP
From: David Miller @ 2018-05-25 18:56 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, leedom
In-Reply-To: <1527164370-16486-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Thu, 24 May 2018 17:49:30 +0530
> newer SFPs like SFP28 and QSFP28 Transceiver Modules present
> several new possibilities which we haven't faced before. Fix the
> assumptions in the code reflecting the more limited capabilities
> of previous Transceiver Module systems
>
> Original work by Casey Leedom <leedom@chelsio.com>
>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
> ---
> V2: Was not getting applied on net-next, respining on net-next
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: clean up init_one
From: David Miller @ 2018-05-25 19:01 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, leedom
In-Reply-To: <1527166935-26051-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Thu, 24 May 2018 18:32:15 +0530
> clean up init_one and use chip_ver consistently throughout
> init_one() for chip version.
>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: netsec: reduce DMA mask to 40 bits
From: Jassi Brar @ 2018-05-25 19:03 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: netdev, David S. Miller, Robin Murphy, Masahisa Kojima,
Ilias Apalodimas
In-Reply-To: <20180525125037.779-1-ard.biesheuvel@linaro.org>
On 25 May 2018 at 18:20, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> The netsec network controller IP can drive 64 address bits for DMA, and
> the DMA mask is set accordingly in the driver. However, the SynQuacer
> SoC, which is the only silicon incorporating this IP at the moment,
> integrates this IP in a manner that leaves address bits [63:40]
> unconnected.
>
> Up until now, this has not resulted in any problems, given that the DDR
> controller doesn't decode those bits to begin with. However, recent
> firmware updates for platforms incorporating this SoC allow the IOMMU
> to be enabled, which does decode address bits [47:40], and allocates
> top down from the IOVA space, producing DMA addresses that have bits
> set that have been left unconnected.
>
> Both the DT and ACPI (IORT) descriptions of the platform take this into
> account, and only describe a DMA address space of 40 bits (using either
> dma-ranges DT properties, or DMA address limits in IORT named component
> nodes). However, even though our IOMMU and bus layers may take such
> limitations into account by setting a narrower DMA mask when creating
> the platform device, the netsec probe() entrypoint follows the common
> practice of setting the DMA mask uncondionally, according to the
> capabilities of the IP block itself rather than to its integration into
> the chip.
>
> It is currently unclear what the correct fix is here. We could hack around
> it by only setting the DMA mask if it deviates from its default value of
> DMA_BIT_MASK(32). However, this makes it impossible for the bus layer to
> use DMA_BIT_MASK(32) as the bus limit, and so it appears that a more
> comprehensive approach is required to take DMA limits imposed by the
> SoC as a whole into account.
>
> In the mean time, let's limit the DMA mask to 40 bits. Given that there
> is currently only one SoC that incorporates this IP, this is a reasonable
> approach that can be backported to -stable and buys us some time to come
> up with a proper fix going forward.
>
I am sure you already thought about it, but why not let the platform
specify the bit mask for the driver (via some "bus-width" property),
to override the default 64 bit mask?
Cheers!
^ permalink raw reply
* Re: [PATCH net-next] cxgb4/cxgb4vf: Notify link changes to OS-dependent code
From: David Miller @ 2018-05-25 19:11 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, leedom, arjun, santosh
In-Reply-To: <1527170617-29905-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Thu, 24 May 2018 19:33:37 +0530
> From: Arjun Vynipadath <arjun@chelsio.com>
>
> We have a confusion of two different abstractions in the Common
> Code: Physical Link (Port) and Logical Network Interface (Virtual
> Interface), and we haven't been properly managing the state of the
> intersection of those two abstractions.
> On the one hand we have the Physical state of the Link -- up or down --
> and on the other we have the logical state of the VI, enabled or not.
> {ethN} refers to both the Physical and Logical State. In this case,
> ifconfig only affects/interrogates the Logical State of a VI,
> and ethtool only deals with the Physical State. And these are different.
>
> So, just because we disable the VI, we don't really want to change the
> Physical Link Up/Down state. Thus, the previous hack to set
> "lc->link_ok = 0" when we disable a VI is completely incorrect.
>
> Where we get into trouble is where the Physical Link State and the
> Logical VI State cross swords. And that happens in
> t4_handle_get_port_info() where we need to manage/safe the Physical
> Link State, but we also need to know when the Logical VI State has
> changed and pass that back up to the OS-dependent Driver routine
> t4_os_link_changed() which is concerned about the Logical Interface.
>
> So we enable a VI and that causes Firmware to send us a new Port
> Information message, but if none of the Physical Link State
> particulars have changed, we don't call t4_os_link_changed().
>
> This fix uses the existing OS Contract APIs for the Common Code to
> inform the OS-dependent portion of the Host Driver when the "Link" (really
> Logical Network Interface) is "up" or "down". A new API
> t4_enable_pi_params() is added which calls t4_enable_vi_params() and,
> if that is successful, then calls back to the OS Contract API
> t4_os_link_changed() notifying the OS-dependent layer of the
> potential Link State change.
>
> Original Work by : Casey Leedom <leedom@chelsio.com>
>
> Signed-off-by: Santosh Rastapur <santosh@chelsio.com>
> Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] selftests/net: Add missing config options for PMTU tests
From: David Miller @ 2018-05-25 19:11 UTC (permalink / raw)
To: sbrivio; +Cc: naresh.kamboju, linux-kselftest, shuahkh, netdev
In-Reply-To: <53b70df32d1d92df98a9c8deaae90e9e7ad37fbc.1527170629.git.sbrivio@redhat.com>
From: Stefano Brivio <sbrivio@redhat.com>
Date: Thu, 24 May 2018 16:10:12 +0200
> PMTU tests in pmtu.sh need support for VTI, VTI6 and dummy
> interfaces: add them to config file.
>
> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> Fixes: d1f1b9cbf34c ("selftests: net: Introduce first PMTU test")
> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net] sctp: not allow to set rto_min with a value below 200 msecs
From: Neil Horman @ 2018-05-25 19:13 UTC (permalink / raw)
To: Xin Long
Cc: network dev, linux-sctp, davem, David Ahern, Eric Dumazet,
Marcelo Ricardo Leitner, syzkaller
In-Reply-To: <dc48b7c6a6dd1d8f19215cea6713d5723779d564.1527270062.git.lucien.xin@gmail.com>
On Sat, May 26, 2018 at 01:41:02AM +0800, Xin Long wrote:
> syzbot reported a rcu_sched self-detected stall on CPU which is caused
> by too small value set on rto_min with SCTP_RTOINFO sockopt. With this
> value, hb_timer will get stuck there, as in its timer handler it starts
> this timer again with this value, then goes to the timer handler again.
>
> This problem is there since very beginning, and thanks to Eric for the
> reproducer shared from a syzbot mail.
>
> This patch fixes it by not allowing to set rto_min with a value below
> 200 msecs, which is based on TCP's, by either setsockopt or sysctl.
>
> Reported-by: syzbot+3dcd59a1f907245f891f@syzkaller.appspotmail.com
> Suggested-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> include/net/sctp/constants.h | 1 +
> net/sctp/socket.c | 10 +++++++---
> net/sctp/sysctl.c | 3 ++-
> 3 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/include/net/sctp/constants.h b/include/net/sctp/constants.h
> index 20ff237..2ee7a7b 100644
> --- a/include/net/sctp/constants.h
> +++ b/include/net/sctp/constants.h
> @@ -277,6 +277,7 @@ enum { SCTP_MAX_GABS = 16 };
> #define SCTP_RTO_INITIAL (3 * 1000)
> #define SCTP_RTO_MIN (1 * 1000)
> #define SCTP_RTO_MAX (60 * 1000)
> +#define SCTP_RTO_HARD_MIN 200
>
> #define SCTP_RTO_ALPHA 3 /* 1/8 when converted to right shifts. */
> #define SCTP_RTO_BETA 2 /* 1/4 when converted to right shifts. */
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index ae7e7c6..6ef12c7 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -3029,7 +3029,8 @@ static int sctp_setsockopt_nodelay(struct sock *sk, char __user *optval,
> * be changed.
> *
> */
> -static int sctp_setsockopt_rtoinfo(struct sock *sk, char __user *optval, unsigned int optlen)
> +static int sctp_setsockopt_rtoinfo(struct sock *sk, char __user *optval,
> + unsigned int optlen)
> {
> struct sctp_rtoinfo rtoinfo;
> struct sctp_association *asoc;
> @@ -3056,10 +3057,13 @@ static int sctp_setsockopt_rtoinfo(struct sock *sk, char __user *optval, unsigne
> else
> rto_max = asoc ? asoc->rto_max : sp->rtoinfo.srto_max;
>
> - if (rto_min)
> + if (rto_min) {
> + if (rto_min < SCTP_RTO_HARD_MIN)
> + return -EINVAL;
> rto_min = asoc ? msecs_to_jiffies(rto_min) : rto_min;
> - else
> + } else {
> rto_min = asoc ? asoc->rto_min : sp->rtoinfo.srto_min;
> + }
>
> if (rto_min > rto_max)
> return -EINVAL;
> diff --git a/net/sctp/sysctl.c b/net/sctp/sysctl.c
> index 33ca5b7..7ec854a 100644
> --- a/net/sctp/sysctl.c
> +++ b/net/sctp/sysctl.c
> @@ -52,6 +52,7 @@ static int rto_alpha_min = 0;
> static int rto_beta_min = 0;
> static int rto_alpha_max = 1000;
> static int rto_beta_max = 1000;
> +static int rto_hard_min = SCTP_RTO_HARD_MIN;
>
> static unsigned long max_autoclose_min = 0;
> static unsigned long max_autoclose_max =
> @@ -116,7 +117,7 @@ static struct ctl_table sctp_net_table[] = {
> .maxlen = sizeof(unsigned int),
> .mode = 0644,
> .proc_handler = proc_sctp_do_rto_min,
> - .extra1 = &one,
> + .extra1 = &rto_hard_min,
> .extra2 = &init_net.sctp.rto_max
> },
> {
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Patch looks fine, you probably want to note this hard minimum in man(7) sctp as
well
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH] PCI: allow drivers to limit the number of VFs to 0
From: Don Dutile @ 2018-05-25 19:27 UTC (permalink / raw)
To: Bjorn Helgaas, Jakub Kicinski
Cc: Bjorn Helgaas, linux-pci, netdev, Sathya Perla, Felix Manlunas,
alexander.duyck, john.fastabend, Jacob Keller, oss-drivers,
Christoph Hellwig
In-Reply-To: <20180525140223.GA45098@bhelgaas-glaptop.roam.corp.google.com>
On 05/25/2018 10:02 AM, Bjorn Helgaas wrote:
> On Thu, May 24, 2018 at 06:20:15PM -0700, Jakub Kicinski wrote:
>> Hi Bjorn!
>>
>> On Thu, 24 May 2018 18:57:48 -0500, Bjorn Helgaas wrote:
>>> On Mon, Apr 02, 2018 at 03:46:52PM -0700, Jakub Kicinski wrote:
>>>> Some user space depends on enabling sriov_totalvfs number of VFs
>>>> to not fail, e.g.:
>>>>
>>>> $ cat .../sriov_totalvfs > .../sriov_numvfs
>>>>
>>>> For devices which VF support depends on loaded FW we have the
>>>> pci_sriov_{g,s}et_totalvfs() API. However, this API uses 0 as
>>>> a special "unset" value, meaning drivers can't limit sriov_totalvfs
>>>> to 0. Remove the special values completely and simply initialize
>>>> driver_max_VFs to total_VFs. Then always use driver_max_VFs.
>>>> Add a helper for drivers to reset the VF limit back to total.
>>>
>>> I still can't really make sense out of the changelog.
>>>
>>> I think part of the reason it's confusing is because there are two
>>> things going on:
>>>
>>> 1) You want this:
>>>
>>> pci_sriov_set_totalvfs(dev, 0);
>>> x = pci_sriov_get_totalvfs(dev)
>>>
>>> to return 0 instead of total_VFs. That seems to connect with
>>> your subject line. It means "sriov_totalvfs" in sysfs could be
>>> 0, but I don't know how that is useful (I'm sure it is; just
>>> educate me :))
>>
>> Let me just quote the bug report that got filed on our internal bug
>> tracker :)
>>
>> When testing Juju Openstack with Ubuntu 18.04, enabling SR-IOV causes
>> errors because Juju gets the sriov_totalvfs for SR-IOV-capable device
>> then tries to set that as the sriov_numvfs parameter.
>>
>> For SR-IOV incapable FW, the sriov_totalvfs parameter should be 0,
>> but it's set to max. When FW is switched to flower*, the correct
>> sriov_totalvfs value is presented.
>>
>> * flower is a project name
>
> From the point of view of the PCI core (which knows nothing about
> device firmware and relies on the architected config space described
> by the PCIe spec), this sounds like an erratum: with some firmware
> installed, the device is not capable of SR-IOV, but still advertises
> an SR-IOV capability with "TotalVFs > 0".
>
> Regardless of whether that's an erratum, we do allow PF drivers to use
> pci_sriov_set_totalvfs() to limit the number of VFs that may be
> enabled by writing to the PF's "sriov_numvfs" sysfs file.
>
+1.
> But the current implementation does not allow a PF driver to limit VFs
> to 0, and that does seem nonsensical.
>
Well, not really -- claiming to support VFs, and then wanting it to be 0...
I could certainly argue is non-sensical.
From a sw perspective, sure, see if we can set VFs to 0 (and reset to another value later).
/me wishes that implementers would follow the architecture vs torquing it into strange shapes.
>> My understanding is OpenStack uses sriov_totalvfs to determine how many
>> VFs can be enabled, looks like this is the code:
>>
>> http://git.openstack.org/cgit/openstack/charm-neutron-openvswitch/tree/hooks/neutron_ovs_utils.py#n464
>>
>>> 2) You're adding the pci_sriov_reset_totalvfs() interface. I'm not
>>> sure what you intend for this. Is *every* driver supposed to
>>> call it in .remove()? Could/should this be done in the core
>>> somehow instead of depending on every driver?
>>
>> Good question, I was just thinking yesterday we may want to call it
>> from the core, but I don't think it's strictly necessary nor always
>> sufficient (we may reload FW without re-probing).
>>
>> We have a device which supports different number of VFs based on the FW
>> loaded. Some legacy FWs does not inform the driver how many VFs it can
>> support, because it supports max. So the flow in our driver is this:
>>
>> load_fw(dev);
>> ...
>> max_vfs = ask_fw_for_max_vfs(dev);
>> if (max_vfs >= 0)
>> return pci_sriov_set_totalvfs(dev, max_vfs);
>> else /* FW didn't tell us, assume max */
>> return pci_sriov_reset_totalvfs(dev);
>>
>> We also reset the max on device remove, but that's not strictly
>> necessary.
>>
>> Other users of pci_sriov_set_totalvfs() always know the value to set
>> the total to (either always get it from FW or it's a constant).
>>
>> If you prefer we can work out the correct max for those legacy cases in
>> the driver as well, although it seemed cleaner to just ask the core,
>> since it already has total_VFs value handy :)
>>
>>> I'm also having a hard time connecting your user-space command example
>>> with the rest of this. Maybe it will make more sense to me tomorrow
>>> after some coffee.
>>
>> OpenStack assumes it will always be able to set sriov_numvfs to
>> sriov_totalvfs, see this 'if':
>>
>> http://git.openstack.org/cgit/openstack/charm-neutron-openvswitch/tree/hooks/neutron_ovs_utils.py#n512
>
> Thanks for educating me. I think there are two issues here that we
> can separate. I extracted the patch below for the first.
>
> The second is the question of resetting driver_max_VFs. I think we
> currently have a general issue in the core:
>
> - load PF driver 1
> - driver calls pci_sriov_set_totalvfs() to reduce driver_max_VFs
> - unload PF driver 1
> - load PF driver 2
>
> Now driver_max_VFs is still stuck at the lower value set by driver 1.
> I don't think that's the way this should work.
>
> I guess this is partly a consequence of setting driver_max_VFs in
> sriov_init(), which is called before driver attach and should only
um, if it's at sriov_init() how is max changed by a PF driver?
or am I missing something subtle (a new sysfs param) as to what is being changed?
> depend on hardware characteristics, so it is related to the patch
> below. But I think we should fix it in general, not just for
> netronome.
>
>
> commit 4a338bc6f94b9ad824ac944f5dfc249d6838719c
> Author: Jakub Kicinski <jakub.kicinski@netronome.com>
> Date: Fri May 25 08:18:34 2018 -0500
>
> PCI/IOV: Allow PF drivers to limit total_VFs to 0
>
> Some SR-IOV PF drivers implement .sriov_configure(), which allows
> user-space to enable VFs by writing the desired number of VFs to the sysfs
> "sriov_numvfs" file (see sriov_numvfs_store()).
>
> The PCI core limits the number of VFs to the TotalVFs advertised by the
> device in its SR-IOV capability. The PF driver can limit the number of VFs
> to even fewer (it may have pre-allocated data structures or knowledge of
> device limitations) by calling pci_sriov_set_totalvfs(), but previously it
> could not limit the VFs to 0.
>
> Change pci_sriov_get_totalvfs() so it always respects the VF limit imposed
> by the PF driver, even if the limit is 0.
>
> This sequence:
>
> pci_sriov_set_totalvfs(dev, 0);
> x = pci_sriov_get_totalvfs(dev);
>
> previously set "x" to TotalVFs from the SR-IOV capability. Now it will set
> "x" to 0.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>
> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
> index 192b82898a38..d0d73dbbd5ca 100644
> --- a/drivers/pci/iov.c
> +++ b/drivers/pci/iov.c
> @@ -469,6 +469,7 @@ static int sriov_init(struct pci_dev *dev, int pos)
> iov->nres = nres;
> iov->ctrl = ctrl;
> iov->total_VFs = total;
> + iov->driver_max_VFs = total;
> pci_read_config_word(dev, pos + PCI_SRIOV_VF_DID, &iov->vf_device);
> iov->pgsz = pgsz;
> iov->self = dev;
> @@ -827,10 +828,7 @@ int pci_sriov_get_totalvfs(struct pci_dev *dev)
> if (!dev->is_physfn)
> return 0;
>
> - if (dev->sriov->driver_max_VFs)
> - return dev->sriov->driver_max_VFs;
> -
> - return dev->sriov->total_VFs;
> + return dev->sriov->driver_max_VFs;
> }
> EXPORT_SYMBOL_GPL(pci_sriov_get_totalvfs);
>
>
^ permalink raw reply
* Re: [PATCH net-next] vrf: add CRC32c offload to device features
From: David Miller @ 2018-05-25 19:36 UTC (permalink / raw)
To: dcaratti; +Cc: dsa, vyasevich, marcelo.leitner, linux-sctp, netdev
In-Reply-To: <bb3aa69eaef613f033f8f52674740286ba67dc31.1527175921.git.dcaratti@redhat.com>
From: Davide Caratti <dcaratti@redhat.com>
Date: Thu, 24 May 2018 17:49:35 +0200
> SCTP sockets originated in a VRF can improve their performance if CRC32c
> computation is delegated to underlying devices: update device features,
> setting NETIF_F_SCTP_CRC. Iterating the following command in the topology
> proposed with [1],
>
> # ip vrf exec vrf-h2 netperf -H 192.0.2.1 -t SCTP_STREAM -- -m 10K
>
> the measured throughput in Mbit/s improved from 2395 ± 1% to 2720 ± 1%.
>
> [1] https://www.spinics.net/lists/netdev/msg486007.html
>
> Signed-off-by: Davide Caratti <dcaratti@redhat.com>
David A., please review.
^ permalink raw reply
* Re: [PATCH] net: netsec: reduce DMA mask to 40 bits
From: Robin Murphy @ 2018-05-25 19:37 UTC (permalink / raw)
To: Jassi Brar
Cc: Ard Biesheuvel, netdev, David S. Miller, Masahisa Kojima,
Ilias Apalodimas, nd
In-Reply-To: <CAJe_ZhfeEuRUTncyueb2ZRJq1uKrV44eiYVvfNrFufXdbDFRAw@mail.gmail.com>
On Sat, 26 May 2018 00:33:05 +0530
Jassi Brar <jaswinder.singh@linaro.org> wrote:
> On 25 May 2018 at 18:20, Ard Biesheuvel <ard.biesheuvel@linaro.org>
> wrote:
> > The netsec network controller IP can drive 64 address bits for DMA,
> > and the DMA mask is set accordingly in the driver. However, the
> > SynQuacer SoC, which is the only silicon incorporating this IP at
> > the moment, integrates this IP in a manner that leaves address bits
> > [63:40] unconnected.
> >
> > Up until now, this has not resulted in any problems, given that the
> > DDR controller doesn't decode those bits to begin with. However,
> > recent firmware updates for platforms incorporating this SoC allow
> > the IOMMU to be enabled, which does decode address bits [47:40],
> > and allocates top down from the IOVA space, producing DMA addresses
> > that have bits set that have been left unconnected.
> >
> > Both the DT and ACPI (IORT) descriptions of the platform take this
> > into account, and only describe a DMA address space of 40 bits
> > (using either dma-ranges DT properties, or DMA address limits in
> > IORT named component nodes). However, even though our IOMMU and bus
> > layers may take such limitations into account by setting a narrower
> > DMA mask when creating the platform device, the netsec probe()
> > entrypoint follows the common practice of setting the DMA mask
> > uncondionally, according to the capabilities of the IP block itself
> > rather than to its integration into the chip.
> >
> > It is currently unclear what the correct fix is here. We could hack
> > around it by only setting the DMA mask if it deviates from its
> > default value of DMA_BIT_MASK(32). However, this makes it
> > impossible for the bus layer to use DMA_BIT_MASK(32) as the bus
> > limit, and so it appears that a more comprehensive approach is
> > required to take DMA limits imposed by the SoC as a whole into
> > account.
> >
> > In the mean time, let's limit the DMA mask to 40 bits. Given that
> > there is currently only one SoC that incorporates this IP, this is
> > a reasonable approach that can be backported to -stable and buys us
> > some time to come up with a proper fix going forward.
> >
> I am sure you already thought about it, but why not let the platform
> specify the bit mask for the driver (via some "bus-width" property),
> to override the default 64 bit mask?
Because lack of a property to describe the integration is not the
problem. There are already at least two ways: the general DT/IORT
properties for describing DMA addressing - which it would be a bit
ungainly for a driver to parse for this reason, but not impossible -
and inferring it from a SoC-specific compatible - which is more
appropriate, and what we happen to be able to do here.
Robin.
^ permalink raw reply
* Re: [PATCH bpf-next v2 0/3] bpf: add boot parameters for sysctl knobs
From: Alexei Starovoitov @ 2018-05-25 19:44 UTC (permalink / raw)
To: Eugene Syromiatnikov
Cc: Jesper Dangaard Brouer, netdev, linux-kernel, linux-doc,
Kees Cook, Kai-Heng Feng, Daniel Borkmann, Alexei Starovoitov,
Jonathan Corbet, Jiri Olsa
In-Reply-To: <20180525165009.GA20952@asgard.redhat.com>
On Fri, May 25, 2018 at 06:50:09PM +0200, Eugene Syromiatnikov wrote:
> On Thu, May 24, 2018 at 04:34:51PM -0700, Alexei Starovoitov wrote:
> > On Thu, May 24, 2018 at 09:41:08AM +0200, Jesper Dangaard Brouer wrote:
> > > On Wed, 23 May 2018 15:02:45 -0700
> > > Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> > >
> > > > On Wed, May 23, 2018 at 02:18:19PM +0200, Eugene Syromiatnikov wrote:
> > > > > Some BPF sysctl knobs affect the loading of BPF programs, and during
> > > > > system boot/init stages these sysctls are not yet configured.
> > > > > A concrete example is systemd, that has implemented loading of BPF
> > > > > programs.
> > > > >
> > > > > Thus, to allow controlling these setting at early boot, this patch set
> > > > > adds the ability to change the default setting of these sysctl knobs
> > > > > as well as option to override them via a boot-time kernel parameter
> > > > > (in order to avoid rebuilding kernel each time a need of changing these
> > > > > defaults arises).
> > > > >
> > > > > The sysctl knobs in question are kernel.unprivileged_bpf_disable,
> > > > > net.core.bpf_jit_harden, and net.core.bpf_jit_kallsyms.
> > > >
> > > > - systemd is root. today it only uses cgroup-bpf progs which require root,
> > > > so disabling unpriv during boot time makes no difference to systemd.
> > > > what is the actual reason to present time?
> systemd also runs a lot of code, some of which is unprivileged.
systemd processes sysctl configs first. It's essential for system
security to do so. If you have concerns in how systemd does that
please bring it up with systemd folks.
> > > > - say in the future systemd wants to use so_reuseport+bpf for faster
> > > > networking. With unpriv disable during boot, it will force systemd
> > > > to do such networking from root, which will lower its security barrier.
> No, it will force systemd not to use SO_REUSEPORT BPF.
sorry this argument makes no sense to me.
> > > > - bpf_jit_kallsyms sysctl has immediate effect on loaded programs.
> > > > Flipping it during the boot or right after or any time after
> > > > is the same thing. Why add such boot flag then?
> Well, that one was for completeness.
Should we convert all sysctls to bootparams for 'completeness' ?
> > > > - jit_harden can be turned on by systemd. so turning it during the boot
> > > > will make systemd progs to be constant blinded.
> > > > Constant blinding protects kernel from unprivileged JIT spraying.
> > > > Are you worried that systemd will attack the kernel with JIT spraying?
> I'm worried that systemd can be exploited for a JIT spraying attack.
I'm afraid we're not on the same page with definition of 'JIT spraying attack'.
> Another thing I'm concerned with is that the generated code is different,
> which introduces additional complication during debugging.
specifically what kind of complication?
^ permalink raw reply
* Re: [PATCH net] net: sched: check netif_xmit_frozen_or_stopped() in sch_direct_xmit()
From: Song Liu @ 2018-05-25 19:46 UTC (permalink / raw)
To: Song Liu, ast; +Cc: netdev, kernel-team, John Fastabend, David S . Miller
In-Reply-To: <20180525181144.224395-1-songliubraving@fb.com>
On Fri, May 25, 2018 at 11:11 AM, Song Liu <songliubraving@fb.com> wrote:
> Summary:
>
> At the end of sch_direct_xmit(), we are in the else path of
> !dev_xmit_complete(ret), which means ret == NETDEV_TX_OK. The following
> condition will always fail and netif_xmit_frozen_or_stopped() is not
> checked at all.
>
> if (ret && netif_xmit_frozen_or_stopped(txq))
> return false;
>
> In this patch, this condition is fixed as:
>
> if (netif_xmit_frozen_or_stopped(txq))
> return false;
>
> and further simplifies the code as:
>
> return !netif_xmit_frozen_or_stopped(txq);
>
> Fixes: 29b86cdac00a ("net: sched: remove remaining uses for qdisc_qlen in xmit path")
> Cc: John Fastabend <john.fastabend@gmail.com>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Song Liu <songliubraving@fb.com>
> ---
> net/sched/sch_generic.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
> index 39c144b..8261d48 100644
> --- a/net/sched/sch_generic.c
> +++ b/net/sched/sch_generic.c
> @@ -346,10 +346,7 @@ bool sch_direct_xmit(struct sk_buff *skb, struct Qdisc *q,
> return false;
> }
>
> - if (ret && netif_xmit_frozen_or_stopped(txq))
> - return false;
> -
> - return true;
> + return !netif_xmit_frozen_or_stopped(txq);
> }
>
> /*
> --
> 2.9.5
>
Alexei and I discussed about this offline. We would like to share our
discussion here to
clarify the motivation.
Before 29b86cdac00a, ret in condition "if (ret &&
netif_xmit_frozen_or_stopped()" is not
the value from dev_hard_start_xmit(), because ret is overwritten by
either qdisc_qlen()
or dev_requeue_skb(). Therefore, 29b86cdac00a changed the behavior of
this condition.
For ret from dev_hard_start_xmit(), I dig into the function and found
it is from return value
of ndo_start_xmit(). Per netdevice.h, ndo_start_xmit() should only
return NETDEV_TX_OK
or NETDEV_TX_BUSY. I survey many drivers, and they all follow the rule. The only
exception is vlan.
Given ret could only be NETDEV_TX_OK or NETDEV_TX_BUSY (ignore vlan for now),
if it fails condition "if (!dev_xmit_complete(ret))", ret must be
NETDEV_TX_OK == 0. So
netif_xmit_frozen_or_stopped() will always be bypassed.
It is probably OK to ignore netif_xmit_frozen_or_stopped(), and return true from
sch_direct_xmit(), as I didn't see that break any functionality. But
it is more like "correct
by accident" to me. This is the motivation of my original patch.
Alexei pointed out that, the following condition is more like original logic:
if (qdisc_qlen(q) && netif_xmit_frozen_or_stopped(txq))
return false;
However, I think John would like to remove qdisc_qlen() from the tx
path. I didn't see
any issue without the extra qdisc_qlen() check, so the patch is
probably good AS-IS.
Please share your comments and feedback on this.
Thanks,
Song
^ permalink raw reply
* [PATCH 1/2] batman-adv: Remove "default n" in Kconfig
From: Sven Eckelmann @ 2018-05-25 19:48 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: mareklindner-rVWd3aGhH2z5bpWLKbzFeg,
sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8,
netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r, a,
joe-6d6DIl74uiNBDgjK7y7TUQ
The "default n" is the default value for any bool or tristate Kconfig
setting. It is therefore not necessary to add it to the an config entry.
Reported-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
Signed-off-by: Sven Eckelmann <sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>
---
net/batman-adv/Kconfig | 5 -----
1 file changed, 5 deletions(-)
diff --git a/net/batman-adv/Kconfig b/net/batman-adv/Kconfig
index de8034d80623..41bb67d70c83 100644
--- a/net/batman-adv/Kconfig
+++ b/net/batman-adv/Kconfig
@@ -24,7 +24,6 @@ config BATMAN_ADV
depends on NET
select CRC16
select LIBCRC32C
- default n
help
B.A.T.M.A.N. (better approach to mobile ad-hoc networking) is
a routing protocol for multi-hop ad-hoc mesh networks. The
@@ -60,7 +59,6 @@ config BATMAN_ADV_BLA
config BATMAN_ADV_DAT
bool "Distributed ARP Table"
depends on BATMAN_ADV && INET
- default n
help
This option enables DAT (Distributed ARP Table), a DHT based
mechanism that increases ARP reliability on sparse wireless
@@ -70,7 +68,6 @@ config BATMAN_ADV_DAT
config BATMAN_ADV_NC
bool "Network Coding"
depends on BATMAN_ADV
- default n
help
This option enables network coding, a mechanism that aims to
increase the overall network throughput by fusing multiple
@@ -84,7 +81,6 @@ config BATMAN_ADV_NC
config BATMAN_ADV_MCAST
bool "Multicast optimisation"
depends on BATMAN_ADV && INET && !(BRIDGE=m && BATMAN_ADV=y)
- default n
help
This option enables the multicast optimisation which aims to
reduce the air overhead while improving the reliability of
@@ -94,7 +90,6 @@ config BATMAN_ADV_DEBUGFS
bool "batman-adv debugfs entries"
depends on BATMAN_ADV
depends on DEBUG_FS
- default n
help
Enable this to export routing related debug tables via debugfs.
The information for each soft-interface and used hard-interface can be
--
2.17.0
^ permalink raw reply related
* [PATCH 2/2] batman-adv: Drop "experimental" from BATMAN_V Kconfig
From: Sven Eckelmann @ 2018-05-25 19:48 UTC (permalink / raw)
To: davem
Cc: netdev, b.a.t.m.a.n, a, sw, mareklindner, joe, sergei.shtylyov,
Sven Eckelmann
In-Reply-To: <20180525194837.12589-1-sven@narfation.org>
The Kconfig option BATMAN_ADV_BATMAN_V is now enabled by default when the
BATMAN_ADV is enabled. A feature which is enabled by default for a module
should not be considered experimental.
Reported-by: Joe Perches <joe@perches.com>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
---
net/batman-adv/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/batman-adv/Kconfig b/net/batman-adv/Kconfig
index 41bb67d70c83..da0b7aa98be9 100644
--- a/net/batman-adv/Kconfig
+++ b/net/batman-adv/Kconfig
@@ -32,7 +32,7 @@ config BATMAN_ADV
tools.
config BATMAN_ADV_BATMAN_V
- bool "B.A.T.M.A.N. V protocol (experimental)"
+ bool "B.A.T.M.A.N. V protocol"
depends on BATMAN_ADV && !(CFG80211=m && BATMAN_ADV=y)
default y
help
--
2.17.0
^ permalink raw reply related
* Re: pull-request: bpf 2018-05-24
From: David Miller @ 2018-05-25 19:51 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev
In-Reply-To: <20180524163802.2938-1-daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Thu, 24 May 2018 18:38:02 +0200
> The following pull-request contains BPF updates for your *net* tree.
>
> The main changes are:
>
> 1) Fix a bug in the original fix to prevent out of bounds speculation when
> multiple tail call maps from different branches or calls end up at the
> same tail call helper invocation, from Daniel.
>
> 2) Two selftest fixes, one in reuseport_bpf_numa where test is skipped in
> case of missing numa support and another one to update kernel config to
> properly support xdp_meta.sh test, from Anders.
>
> Please consider pulling these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Pulled, thanks Danile.
> Would be great if you have a chance to merge net into net-next after that.
>
> The verifier fix would be needed later as a dependency in bpf-next for
> upcomig work there. When you do the merge there's a trivial conflict on
> BPF side with 849fa50662fb ("bpf/verifier: refine retval R0 state for
> bpf_get_stack helper"): Resolution is to keep both functions, the
> do_refine_retval_range() and record_func_map().
I'll try to push it along as soon as I can.
Thanks for the merge conflict heads-up.
^ permalink raw reply
* Re: pull-request: bpf 2018-05-24
From: Daniel Borkmann @ 2018-05-25 19:54 UTC (permalink / raw)
To: David Miller; +Cc: ast, netdev
In-Reply-To: <20180525.155153.205200316874660386.davem@davemloft.net>
On 05/25/2018 09:51 PM, David Miller wrote:
> From: Daniel Borkmann <daniel@iogearbox.net>
> Date: Thu, 24 May 2018 18:38:02 +0200
>
>> The following pull-request contains BPF updates for your *net* tree.
>>
>> The main changes are:
>>
>> 1) Fix a bug in the original fix to prevent out of bounds speculation when
>> multiple tail call maps from different branches or calls end up at the
>> same tail call helper invocation, from Daniel.
>>
>> 2) Two selftest fixes, one in reuseport_bpf_numa where test is skipped in
>> case of missing numa support and another one to update kernel config to
>> properly support xdp_meta.sh test, from Anders.
>>
>> Please consider pulling these changes from:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
>
> Pulled, thanks Danile.
>
>> Would be great if you have a chance to merge net into net-next after that.
>>
>> The verifier fix would be needed later as a dependency in bpf-next for
>> upcomig work there. When you do the merge there's a trivial conflict on
>> BPF side with 849fa50662fb ("bpf/verifier: refine retval R0 state for
>> bpf_get_stack helper"): Resolution is to keep both functions, the
>> do_refine_retval_range() and record_func_map().
>
> I'll try to push it along as soon as I can.
>
> Thanks for the merge conflict heads-up.
Awesome, thanks a lot David!
^ permalink raw reply
* Re: [PATCH net-next] vrf: add CRC32c offload to device features
From: David Ahern @ 2018-05-25 20:06 UTC (permalink / raw)
To: Davide Caratti, Vlad Yasevich, Marcelo Ricardo Leitner; +Cc: linux-sctp, netdev
In-Reply-To: <bb3aa69eaef613f033f8f52674740286ba67dc31.1527175921.git.dcaratti@redhat.com>
On 5/24/18 9:49 AM, Davide Caratti wrote:
> SCTP sockets originated in a VRF can improve their performance if CRC32c
> computation is delegated to underlying devices: update device features,
> setting NETIF_F_SCTP_CRC. Iterating the following command in the topology
> proposed with [1],
>
> # ip vrf exec vrf-h2 netperf -H 192.0.2.1 -t SCTP_STREAM -- -m 10K
>
> the measured throughput in Mbit/s improved from 2395 ± 1% to 2720 ± 1%.
>
> [1] https://www.spinics.net/lists/netdev/msg486007.html
>
> Signed-off-by: Davide Caratti <dcaratti@redhat.com>
> ---
> drivers/net/vrf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: David Ahern <dsa@cumulusnetworks.com>
^ permalink raw reply
* Re: [PATCH net-next 0/5] qed*: ethtool rx flow classification enhancements.
From: David Miller @ 2018-05-25 20:11 UTC (permalink / raw)
To: manish.chopra; +Cc: netdev, ariel.elior, michal.kalderon
In-Reply-To: <20180524165453.11852-1-manish.chopra@cavium.com>
From: Manish Chopra <manish.chopra@cavium.com>
Date: Thu, 24 May 2018 09:54:48 -0700
> This series re-structures the driver's ethtool rx flow
> classification flow, following that it adds other flow
> profiles and rx flow classification enhancements
> via "ethtool -N/-U"
>
> Please consider applying this to "net-next"
The code is definitely easier to read and understand, especially after
patch #1.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next] tcp: use data length instead of skb->len in tcp_probe
From: David Miller @ 2018-05-25 20:27 UTC (permalink / raw)
To: songliubraving; +Cc: laoar.shao, netdev, linux-kernel
In-Reply-To: <630ED9AE-A932-4B6A-8236-D133CE3E0726@fb.com>
From: Song Liu <songliubraving@fb.com>
Date: Thu, 24 May 2018 17:44:46 +0000
> We should also rename __entry->length to __entry->data_len, so that whoever
> using this field will notice the change.
Agreed.
^ permalink raw reply
* Re: Poor TCP performance with XPS enabled after scrubbing skb
From: David Miller @ 2018-05-25 20:29 UTC (permalink / raw)
To: fbl; +Cc: eric.dumazet, netdev, pabeni
In-Reply-To: <20180524191729.GA3770@plex.lan>
From: Flavio Leitner <fbl@sysclose.org>
Date: Thu, 24 May 2018 16:17:29 -0300
> veth originally called skb_orphan() on veth_xmit() most probably
> because there was no TX completion. Then the code got generalized to
> dev_forward_skb() and later on moved to skb_scrub_packet().
>
> The issue is that we call skb_scrub_packet() on TX and RX paths and
> that is done while crossing netns. It doesn't look correct to keep
> the ->sk because I suspect that iptables/selinux/bpf, or some code
> path that I am probably missing could expose/use the wrong ->sk, for
> example.
>
> However, netdev_pick_tx() can't store the queue mapping without ->sk.
>
> The hack in the first email relies on the headers (skb_tx_hash) to
> always selected the same TX queue, which solves the original problem
> but not the TCP small queues you mentioned.
Right, we can't allow a socket reference to escape over a netns
crossing.
However, that is where we get the queue mapping state.
We might need to put the sk based decision into the skb somehow in
order to satisfy these two incompatibel requirements.
^ permalink raw reply
* Re: [PATCH net] ibmvnic: Fix partial success login retries
From: David Miller @ 2018-05-25 20:36 UTC (permalink / raw)
To: tlfalcon; +Cc: netdev, nfont, jallen
In-Reply-To: <1527190673-11146-1-git-send-email-tlfalcon@linux.vnet.ibm.com>
From: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Date: Thu, 24 May 2018 14:37:53 -0500
> In its current state, the driver will handle backing device
> login in a loop for a certain number of retries while the
> device returns a partial success, indicating that the driver
> may need to try again using a smaller number of resources.
>
> The variable it checks to continue retrying may change
> over the course of operations, resulting in reallocation
> of resources but exits without sending the login attempt.
> Guard against this by introducing a boolean variable that
> will retain the state indicating that the driver needs to
> reattempt login with backing device firmware.
>
> Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCH] 8139too: Remove unnecessary netif_napi_del()
From: David Miller @ 2018-05-25 20:37 UTC (permalink / raw)
To: chenbo; +Cc: netdev, linux-kernel
In-Reply-To: <20180524194835.14700-1-chenbo@pdx.edu>
From: Bo Chen <chenbo@pdx.edu>
Date: Thu, 24 May 2018 12:48:35 -0700
> The call to free_netdev() in __rtl8139_cleanup_dev() clears the network device
> napi list, and explicit calls to netif_napi_del() are unnecessary.
>
> Signed-off-by: Bo Chen <chenbo@pdx.edu>
Since this is just unnecessary work and not a bug, applied to net-next.
Thanks.
^ 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