* [GIT] Networking
From: David Miller @ 2018-01-09 3:13 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
Highlights:
1) Frag and UDP handling fixes in i40e driver, from Amritha Nambiar and
Alexander Duyck.
2) Undo unintentional UAPI change in netfilter conntrack, from Florian
Westphal.
3) Revert a change to how error codes are returned from
dev_get_valid_name(), it broke some apps.
4) Cannot cache routes for ipv6 tunnels in the tunnel is ipv4/ipv6
dual-stack. From Eli Cooper.
5) Fix missed PMTU updates in geneve, from Xin Long.
6) Cure double free in macvlan, from Gao Feng.
7) Fix heap out-of-bounds write in rds_message_alloc_sgs(), from
Mohamed Ghannam.
8) FEC bug fixes from FUgang Duan (mis-accounting of dev_id, missed
deferral of probe when the regulator is not ready yet).
9) Missing DMA mapping error checks in 3c59x, from Neil Horman.
10) Turn off Broadcom tags for some b53 switches, from Florian
Fainelli.
11) Fix OOPS when get_target_net() is passed an SKB whose NETLINK_CB()
isn't initialized. From Andrei Vagin.
12) Fix crashes in fib6_add(), from Wei Wang.
13) PMTU bug fixes in SCTP from Marcelo Ricardo Leitner.
Please pull, thanks a lot!
The following changes since commit 2758b3e3e630ba304fc4aca434d591e70e528298:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-12-28 23:20:21 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to 50f3d740d376f664f6accc7e86c9afd8f1c7e1e4:
sh_eth: fix TXALCR1 offsets (2018-01-08 14:31:38 -0500)
----------------------------------------------------------------
Alexander Duyck (1):
i40e/i40evf: Account for frags split over multiple descriptors in check linearize
Amritha Nambiar (1):
i40e: Remove UDP support for big buffer
Andrei Vagin (1):
rtnetlink: give a user socket to get_target_net()
Arjun Vynipadath (1):
cxgb4: Fix FW flash errors
Benjamin Poirier (1):
e1000e: Fix e1000_check_for_copper_link_ich8lan return value.
Christophe JAILLET (1):
mdio-sun4i: Fix a memory leak
David S. Miller (10):
Revert "net: core: dev_get_valid_name is now the same as dev_alloc_name_ns"
Merge branch '1GbE' of git://git.kernel.org/.../jkirsher/net-queue
Merge branch 'fec-clean-up-in-the-cases-of-probe-error'
Merge branch 'ena-fixes'
Merge branch '40GbE' of git://git.kernel.org/.../jkirsher/net-queue
Merge tag 'mac80211-for-davem-2018-01-04' of git://git.kernel.org/.../jberg/mac80211
Merge git://git.kernel.org/.../pablo/nf
Merge tag 'linux-can-fixes-for-4.15-20180104' of git://git.kernel.org/.../mkl/linux-can
Merge branch 'bnxt_en_fixes'
Merge branch 'SCTP-PMTU-discovery-fixes'
Eduardo Otubo (1):
xen-netfront: enable device after manual module load
Eli Cooper (1):
ip6_tunnel: disable dst caching if tunnel is dual-stack
Felix Janda (1):
uapi libc compat: add fallback for unsupported libcs
Florian Fainelli (1):
net: dsa: b53: Turn off Broadcom tags for more switches
Florian Westphal (1):
netfilter: uapi: correct UNTRACKED conntrack state bit number
Fugang Duan (3):
net: fec: restore dev_id in the cases of probe error
net: fec: defer probe if regulator is not ready
net: fec: free/restore resource in related probe error pathes
Gao Feng (1):
macvlan: Fix one possible double free
Gustavo A. R. Silva (1):
phylink: mark expected switch fall-throughs in phylink_mii_ioctl
Hangbin Liu (1):
netfilter: nf_tables: fix potential NULL-ptr deref in nf_tables_dump_obj_done()
Hao Chen (1):
nl80211: Check for the required netlink attribute presence
Hauke Mehrtens (1):
uapi/if_ether.h: prevent redefinition of struct ethhdr
Ido Schimmel (2):
mlxsw: spectrum_router: Fix NULL pointer deref
mlxsw: spectrum: Relax sanity checks during enslavement
Jacob Keller (1):
i40e: don't remove netdev->dev_addr when syncing uc list
Jerome Brunet (1):
net: stmmac: enable EEE in MII, GMII or RGMII only
Jiri Pirko (1):
i40e: flower: Fix return value for unsupported offload
Johannes Berg (1):
mac80211: mesh: drop frames appearing to be from us
Jon Maloy (1):
tipc: fix problems with multipoint-to-point flow control
Luu An Phu (1):
can: flex_can: Correct the checking for frame length in flexcan_start_xmit()
Marcelo Ricardo Leitner (3):
sctp: fix error path in sctp_stream_init
sctp: do not retransmit upon FragNeeded if PMTU discovery is disabled
sctp: fix the handling of ICMP Frag Needed for too small MTUs
Martin Lederhilger (1):
can: ems_usb: improve error reporting for error warning and error passive
Mohamed Ghannam (2):
RDS: Heap OOB write in rds_message_alloc_sgs()
RDS: null pointer dereference in rds_atomic_free_op
Neil Horman (1):
3c59x: fix missing dma_mapping_error check and bad ring refill logic
Netanel Belgazal (2):
net: ena: unmask MSI-X only after device initialization is completed
net: ena: fix error handling in ena_down() sequence
Oliver Hartkopp (1):
can: vxcan: improve handling of missing peer name attribute
Pablo Neira Ayuso (1):
netfilter: nf_tables: fix chain filter in nf_tables_dump_rules()
Pravin B Shelar (1):
MAINTAINERS: Update my email address.
Roi Dayan (1):
net/sched: Fix update of lastuse in act modules implementing stats_update
Russell King (2):
phylink: ensure we report link down when LOS asserted
sfp: fix sfp-bus oops when removing socket/upstream
SZ Lin (林上智) (1):
NET: usb: qmi_wwan: add support for YUGA CLM920-NC5 PID 0x9625
Sergei Shtylyov (3):
sh_eth: fix TSU resource handling
sh_eth: fix SH7757 GEther initialization
sh_eth: fix TXALCR1 offsets
Stephen Hemminger (1):
ethtool: do not print warning for applications using legacy API
Sunil Challa (1):
bnxt_en: Fix population of flow_type in bnxt_hwrm_cfa_flow_alloc()
Tushar Dave (1):
e1000: fix disabling already-disabled warning
Venkat Duvvuru (1):
bnxt_en: Fix the 'Invalid VF' id check in bnxt_vf_ndo_prep routine.
Wei Wang (1):
ipv6: fix general protection fault in fib6_add()
William Tu (1):
vxlan: trivial indenting fix.
Wolfgang Grandegger (1):
can: gs_usb: fix return value of the "set_bittiming" callback
Xin Long (2):
geneve: update skb dst pmtu on tx path
ip6_tunnel: allow ip6gre dev mtu to be set below 1280
MAINTAINERS | 2 +-
drivers/net/can/flexcan.c | 2 +-
drivers/net/can/usb/ems_usb.c | 1 +
drivers/net/can/usb/gs_usb.c | 2 +-
drivers/net/can/vxcan.c | 2 +-
drivers/net/dsa/b53/b53_common.c | 9 ++++---
drivers/net/ethernet/3com/3c59x.c | 90 ++++++++++++++++++++++++++++--------------------------------------
drivers/net/ethernet/amazon/ena/ena_netdev.c | 45 ++++++++++++++++++++++-----------
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 2 +-
drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c | 2 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 -
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 17 ++++++-------
drivers/net/ethernet/freescale/fec_main.c | 7 +++++-
drivers/net/ethernet/intel/e1000/e1000.h | 3 ++-
drivers/net/ethernet/intel/e1000/e1000_main.c | 27 ++++++++++++++++----
drivers/net/ethernet/intel/e1000e/ich8lan.c | 11 +++++---
drivers/net/ethernet/intel/i40e/i40e_main.c | 37 +++++++++++++++++++--------
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 26 ++++++++++++++++---
drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 26 ++++++++++++++++---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 11 ++++++--
drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 2 ++
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 2 +-
drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 6 +++++
drivers/net/ethernet/renesas/sh_eth.c | 33 ++++++++++++++++++------
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++++
drivers/net/geneve.c | 14 +++++++++++
drivers/net/macvlan.c | 7 +++++-
drivers/net/phy/mdio-sun4i.c | 6 +++--
drivers/net/phy/phylink.c | 5 ++--
drivers/net/phy/sfp-bus.c | 6 +++--
drivers/net/usb/qmi_wwan.c | 1 +
drivers/net/xen-netfront.c | 1 +
include/linux/sh_eth.h | 1 -
include/net/sctp/structs.h | 2 +-
include/net/vxlan.h | 2 +-
include/uapi/linux/if_ether.h | 3 +++
include/uapi/linux/libc-compat.h | 61 ++++++++++++++++++++++++++++++++++++++++++++-
include/uapi/linux/netfilter/nf_conntrack_common.h | 2 +-
net/core/dev.c | 14 ++++++++++-
net/core/ethtool.c | 15 ++---------
net/core/rtnetlink.c | 10 ++++----
net/ipv6/ip6_fib.c | 35 +++++++++++++++-----------
net/ipv6/ip6_tunnel.c | 15 +++++------
net/mac80211/rx.c | 2 ++
net/netfilter/nf_tables_api.c | 8 +++---
net/rds/rdma.c | 4 +++
net/sched/act_gact.c | 2 +-
net/sched/act_mirred.c | 2 +-
net/sctp/input.c | 28 ++++++++++++---------
net/sctp/stream.c | 22 ++++++++--------
net/sctp/transport.c | 29 +++++++++++++--------
net/tipc/group.c | 22 +++++++++++++---
net/wireless/nl80211.c | 3 ++-
53 files changed, 474 insertions(+), 220 deletions(-)
^ permalink raw reply
* Re: [PATCH 16/18] net: mpls: prevent bounds-check bypass via speculative execution
From: Eric W. Biederman @ 2018-01-09 3:11 UTC (permalink / raw)
To: Dan Williams
Cc: linux-kernel, linux-arch, peterz, netdev, gregkh, tglx, torvalds,
David S. Miller, Elena Reshetova, alan
In-Reply-To: <151520108080.32271.16420298348259030860.stgit@dwillia2-desk3.amr.corp.intel.com>
Dan Williams <dan.j.williams@intel.com> writes:
> Static analysis reports that 'index' may be a user controlled value that
> is used as a data dependency reading 'rt' from the 'platform_label'
> array. In order to avoid potential leaks of kernel memory values, block
> speculative execution of the instruction stream that could issue further
> reads based on an invalid 'rt' value.
In detail.
a) This code is fast path packet forwarding code. Introducing an
unconditional pipeline stall is not ok.
AKA either there is no speculation and so this is invulnerable
or there is speculation and you are creating an unconditional
pipeline stall here.
My back of the napkin caluculations say that a pipeline stall
is about 20 cycles. Which is about the same length of time
as a modern cache miss.
On a good day this code will perform with 0 cache misses. On a less
good day 1 cache miss. Which means you are quite possibly doubling
the runtime of mpls_forward.
b) The array is dynamically allocated which should provide some
protection, as it will be more difficult to predict the address
of the array which is needed to craft an malicious userspace value.
c) The code can be trivially modified to say:
static struct mpls_route *mpls_route_input_rcu(struct net *net, unsigned index)
{
struct mpls_route *rt = NULL;
if (index < net->mpls.platform_labels) {
struct mpls_route __rcu **platform_label =
rcu_dereference(net->mpls.platform_label);
rt = rcu_dereference(platform_label[index & ((1 << 20) - 1)]);
}
return rt;
}
AKA a static mask will ensure that there is not a primitive that can be
used to access all of memory. That is max a 1 cycle slowdown in the
code, which is a much better trade off.
d) If we care more it is straight forward to modify
resize_platform_label_table() to ensure that the size of the array
is always a power of 2.
e) The fact that a pointer is returned from the array and it is treated
like a pointer would seem to provide a defense against the
exfiltration technique of using the value read as an index into
a small array, that user space code can probe aliased cached
lines of, to see which value was dereferenced.
So to this patch in particular.
Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
This code path will be difficult to exploit. This change messes with
performance. There are ways to make this code path useless while
preserving the performance of the code.
Eric
>
> Based on an original patch by Elena Reshetova.
>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Eric W. Biederman <ebiederm@xmission.com>
> Cc: netdev@vger.kernel.org
> Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
> net/mpls/af_mpls.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c
> index 8ca9915befc8..ebcf0e246cfe 100644
> --- a/net/mpls/af_mpls.c
> +++ b/net/mpls/af_mpls.c
> @@ -8,6 +8,7 @@
> #include <linux/ipv6.h>
> #include <linux/mpls.h>
> #include <linux/netconf.h>
> +#include <linux/compiler.h>
> #include <linux/vmalloc.h>
> #include <linux/percpu.h>
> #include <net/ip.h>
> @@ -77,12 +78,13 @@ static void rtmsg_lfib(int event, u32 label, struct mpls_route *rt,
> static struct mpls_route *mpls_route_input_rcu(struct net *net, unsigned index)
> {
> struct mpls_route *rt = NULL;
> + struct mpls_route __rcu **platform_label =
> + rcu_dereference(net->mpls.platform_label);
> + struct mpls_route __rcu **rtp;
>
> - if (index < net->mpls.platform_labels) {
> - struct mpls_route __rcu **platform_label =
> - rcu_dereference(net->mpls.platform_label);
> - rt = rcu_dereference(platform_label[index]);
> - }
> + if ((rtp = nospec_array_ptr(platform_label, index,
> + net->mpls.platform_labels)))
> + rt = rcu_dereference(*rtp);
> return rt;
> }
>
^ permalink raw reply
* Re: [PATCH net-next 12/20] net: hns3: Add packet statistics of netdev
From: David Miller @ 2018-01-09 3:06 UTC (permalink / raw)
To: lipeng321; +Cc: kubakici, netdev, linux-kernel, linuxarm, salil.mehta
In-Reply-To: <937b5edd-8b05-56db-5510-6d09b0004a0b@huawei.com>
From: "lipeng (Y)" <lipeng321@huawei.com>
Date: Tue, 9 Jan 2018 10:48:04 +0800
> So I think it is OK if you can revert [patch 12/20 ]("net: hns3: Add
> packet statistics of netdev").
I think it is OK if you send the revert patch, which is what I
am asking for :-)
^ permalink raw reply
* Re: [PATCH net-next v2 1/6] net: Fix netdev_WARN_ONCE macro
From: David Miller @ 2018-01-09 3:05 UTC (permalink / raw)
To: joe; +Cc: galp, netdev, tariqt, saeedm
In-Reply-To: <1515465721.9619.78.camel@perches.com>
From: Joe Perches <joe@perches.com>
Date: Mon, 08 Jan 2018 18:42:01 -0800
> On Sun, 2018-01-07 at 12:08 +0200, Gal Pressman wrote:
>> netdev_WARN_ONCE is broken (whoops..), this fix will remove the
>> unnecessary "condition" parameter, add the missing comma and change
>> "arg" to "args".
>>
>> Fixes: 375ef2b1f0d0 ("net: Introduce netdev_*_once functions")
>> Signed-off-by: Gal Pressman <galp@mellanox.com>
>> Reviewed-by: Saeed Mahameed <saeedm@mellanox.com>
>> ---
>> include/linux/netdevice.h | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>> index 352066e..5ff1ef9 100644
>> --- a/include/linux/netdevice.h
>> +++ b/include/linux/netdevice.h
>> @@ -4407,8 +4407,8 @@ do { \
>> WARN(1, "netdevice: %s%s\n" format, netdev_name(dev), \
>> netdev_reg_state(dev), ##args)
>>
>> -#define netdev_WARN_ONCE(dev, condition, format, arg...) \
>> - WARN_ONCE(1, "netdevice: %s%s\n" format, netdev_name(dev) \
>> +#define netdev_WARN_ONCE(dev, format, args...) \
>> + WARN_ONCE(1, "netdevice: %s%s\n" format, netdev_name(dev), \
>
> You sure you want the newline before the format?
Hmmm, Gal please send me a relative fix for this.
^ permalink raw reply
* Re: [PATCH v2] openvswitch: Trim off padding before L3+ netfilter processing
From: Ed Swierk @ 2018-01-09 3:02 UTC (permalink / raw)
To: Pravin Shelar; +Cc: ovs-dev, netdev, Benjamin Warren, Keith Holleman
In-Reply-To: <CAOrHB_A1sQWforWuUve5phrxPjSOpbTEQ4F5h3beh1C9qWmUTw@mail.gmail.com>
On 1/6/18 10:57, Pravin Shelar wrote:
> On Fri, Jan 5, 2018 at 10:59 PM, Ed Swierk <eswierk@skyportsystems.com> wrote:
>>
>>
>> On Jan 5, 2018 22:17, "Pravin Shelar" <pshelar@ovn.org> wrote:
>>
>> On Fri, Jan 5, 2018 at 3:20 PM, Ed Swierk <eswierk@skyportsystems.com>
>> wrote:
>>> On Fri, Jan 5, 2018 at 10:14 AM, Ed Swierk <eswierk@skyportsystems.com>
>>> wrote:
>>>> On Thu, Jan 4, 2018 at 7:36 PM, Pravin Shelar <pshelar@ovn.org> wrote:
>>>>> OVS already pull all required headers in skb linear data, so no need
>>>>> to redo all of it. only check required is the ip-checksum validation.
>>>>> I think we could avoid it in most of cases by checking skb length to
>>>>> ipheader length before verifying the ip header-checksum.
>>>>
>>>> Shouldn't the IP header checksum be verified even earlier, like in
>>>> key_extract(), before actually using any of the fields in the IP
>>>> header?
>>>
>>> Something like this for verifying the IP header checksum (not tested):
>>>
>> AFAIU openflow does not need this verification, so it is not required
>> in flow extract.
>>
>>
>> Okay. How about my proposed trimming implementation, caching the pad length
>> in the ovs cb?
>>
> Caching the length is not that simple, OVS actions can change the
> length. Keeping it consistent with packet would be more work, so lets
> calculate it in ovs-ct function.
>
Something like this?
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index a38c80e..282325d 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -4084,6 +4084,8 @@ struct sk_buff *skb_checksum_trimmed(struct sk_buff *skb,
unsigned int transport_len,
__sum16(*skb_chkf)(struct sk_buff *skb));
+int skb_network_trim(struct sk_buff *skb);
+
/**
* skb_head_is_locked - Determine if the skb->head is locked down
* @skb: skb to check
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 08f5740..c68e927 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -4740,6 +4740,41 @@ struct sk_buff *skb_checksum_trimmed(struct sk_buff *skb,
}
EXPORT_SYMBOL(skb_checksum_trimmed);
+/**
+ * skb_network_trim - trim skb to length specified by the network header
+ * @skb: the skb to trim
+ *
+ * Trims the skb to the length specified by the network header,
+ * removing any trailing padding. Leaves the skb alone if the protocol
+ * is not IP or IPv6. Frees the skb on error.
+ *
+ * Caller needs to pull the skb to the network header.
+ */
+int skb_network_trim(struct sk_buff *skb)
+{
+ unsigned int len;
+ int err;
+
+ switch (skb->protocol) {
+ case htons(ETH_P_IP):
+ len = ntohs(ip_hdr(skb)->tot_len);
+ break;
+ case htons(ETH_P_IPV6):
+ len = sizeof(struct ipv6hdr)
+ + ntohs(ipv6_hdr(skb)->payload_len);
+ break;
+ default:
+ len = skb->len;
+ }
+
+ err = pskb_trim_rcsum(skb, len);
+ if (unlikely(err))
+ kfree_skb(skb);
+
+ return err;
+}
+EXPORT_SYMBOL(skb_network_trim);
+
void __skb_warn_lro_forwarding(const struct sk_buff *skb)
{
net_warn_ratelimited("%s: received packets cannot be forwarded while LRO is enabled\n",
diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index b27c5c6..73418d3 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -1112,6 +1112,10 @@ int ovs_ct_execute(struct net *net, struct sk_buff *skb,
nh_ofs = skb_network_offset(skb);
skb_pull_rcsum(skb, nh_ofs);
+ err = skb_network_trim(skb);
+ if (err)
+ return err;
+
if (key->ip.frag != OVS_FRAG_TYPE_NONE) {
err = handle_fragments(net, key, info->zone.id, skb);
if (err)
^ permalink raw reply related
* Re: [PATCH v2] openvswitch: Trim off padding before L3+ netfilter processing
From: Ed Swierk @ 2018-01-09 3:02 UTC (permalink / raw)
To: Pravin Shelar; +Cc: ovs-dev, netdev, Benjamin Warren, Keith Holleman
In-Reply-To: <CAOrHB_A1sQWforWuUve5phrxPjSOpbTEQ4F5h3beh1C9qWmUTw@mail.gmail.com>
On 1/6/18 10:57, Pravin Shelar wrote:
> On Fri, Jan 5, 2018 at 10:59 PM, Ed Swierk <eswierk@skyportsystems.com> wrote:
>>
>>
>> On Jan 5, 2018 22:17, "Pravin Shelar" <pshelar@ovn.org> wrote:
>>
>> On Fri, Jan 5, 2018 at 3:20 PM, Ed Swierk <eswierk@skyportsystems.com>
>> wrote:
>>> On Fri, Jan 5, 2018 at 10:14 AM, Ed Swierk <eswierk@skyportsystems.com>
>>> wrote:
>>>> On Thu, Jan 4, 2018 at 7:36 PM, Pravin Shelar <pshelar@ovn.org> wrote:
>>>>> OVS already pull all required headers in skb linear data, so no need
>>>>> to redo all of it. only check required is the ip-checksum validation.
>>>>> I think we could avoid it in most of cases by checking skb length to
>>>>> ipheader length before verifying the ip header-checksum.
>>>>
>>>> Shouldn't the IP header checksum be verified even earlier, like in
>>>> key_extract(), before actually using any of the fields in the IP
>>>> header?
>>>
>>> Something like this for verifying the IP header checksum (not tested):
>>>
>> AFAIU openflow does not need this verification, so it is not required
>> in flow extract.
>>
>>
>> Okay. How about my proposed trimming implementation, caching the pad length
>> in the ovs cb?
>>
> Caching the length is not that simple, OVS actions can change the
> length. Keeping it consistent with packet would be more work, so lets
> calculate it in ovs-ct function.
>
Something like this?
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index a38c80e..282325d 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -4084,6 +4084,8 @@ struct sk_buff *skb_checksum_trimmed(struct sk_buff *skb,
unsigned int transport_len,
__sum16(*skb_chkf)(struct sk_buff *skb));
+int skb_network_trim(struct sk_buff *skb);
+
/**
* skb_head_is_locked - Determine if the skb->head is locked down
* @skb: skb to check
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 08f5740..c68e927 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -4740,6 +4740,41 @@ struct sk_buff *skb_checksum_trimmed(struct sk_buff *skb,
}
EXPORT_SYMBOL(skb_checksum_trimmed);
+/**
+ * skb_network_trim - trim skb to length specified by the network header
+ * @skb: the skb to trim
+ *
+ * Trims the skb to the length specified by the network header,
+ * removing any trailing padding. Leaves the skb alone if the protocol
+ * is not IP or IPv6. Frees the skb on error.
+ *
+ * Caller needs to pull the skb to the network header.
+ */
+int skb_network_trim(struct sk_buff *skb)
+{
+ unsigned int len;
+ int err;
+
+ switch (skb->protocol) {
+ case htons(ETH_P_IP):
+ len = ntohs(ip_hdr(skb)->tot_len);
+ break;
+ case htons(ETH_P_IPV6):
+ len = sizeof(struct ipv6hdr)
+ + ntohs(ipv6_hdr(skb)->payload_len);
+ break;
+ default:
+ len = skb->len;
+ }
+
+ err = pskb_trim_rcsum(skb, len);
+ if (unlikely(err))
+ kfree_skb(skb);
+
+ return err;
+}
+EXPORT_SYMBOL(skb_network_trim);
+
void __skb_warn_lro_forwarding(const struct sk_buff *skb)
{
net_warn_ratelimited("%s: received packets cannot be forwarded while LRO is enabled\n",
diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index b27c5c6..73418d3 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -1112,6 +1112,10 @@ int ovs_ct_execute(struct net *net, struct sk_buff *skb,
nh_ofs = skb_network_offset(skb);
skb_pull_rcsum(skb, nh_ofs);
+ err = skb_network_trim(skb);
+ if (err)
+ return err;
+
if (key->ip.frag != OVS_FRAG_TYPE_NONE) {
err = handle_fragments(net, key, info->zone.id, skb);
if (err)
^ permalink raw reply related
* [v2] net: gianfar_ptp: move set_fipers() to spinlock protecting area
From: Yangbo Lu @ 2018-01-09 3:02 UTC (permalink / raw)
To: Fabio Estevam, Claudiu Manoil, Richard Cochran, netdev,
linux-kernel
Cc: Yangbo Lu
set_fipers() calling should be protected by spinlock in
case that any interrupt breaks related registers setting
and the function we expect. This patch is to move set_fipers()
to spinlock protecting area in ptp_gianfar_adjtime().
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
---
Changes for v2:
- explained why spinlock was needed in commit message.
---
drivers/net/ethernet/freescale/gianfar_ptp.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar_ptp.c b/drivers/net/ethernet/freescale/gianfar_ptp.c
index 5441142..9f8d4f8 100644
--- a/drivers/net/ethernet/freescale/gianfar_ptp.c
+++ b/drivers/net/ethernet/freescale/gianfar_ptp.c
@@ -319,11 +319,10 @@ static int ptp_gianfar_adjtime(struct ptp_clock_info *ptp, s64 delta)
now = tmr_cnt_read(etsects);
now += delta;
tmr_cnt_write(etsects, now);
+ set_fipers(etsects);
spin_unlock_irqrestore(&etsects->lock, flags);
- set_fipers(etsects);
-
return 0;
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net-next 12/20] net: hns3: Add packet statistics of netdev
From: lipeng (Y) @ 2018-01-09 2:48 UTC (permalink / raw)
To: David Miller, kubakici; +Cc: netdev, linux-kernel, linuxarm, salil.mehta
In-Reply-To: <20180108.205440.1825662768273316692.davem@davemloft.net>
On 2018/1/9 9:54, David Miller wrote:
> From: Jakub Kicinski <kubakici@wp.pl>
> Date: Mon, 8 Jan 2018 17:50:21 -0800
>
>> Oh, I only noticed this extra misleading comment now. Unless each queue
>> has a netdev, I don't see how these are per-queue.
> If it isn't per-queue I want this change reverted.
[patch 12/20 ] add statistics of netdev for ethtool -S, netdev may have
multi queue.
As discussion here, it is duplicate to add this patch.
I revert [patch 12/20 ] , and then test on my board, HNS3 basic function and ethtool -S work well.
So I think it is OK if you can revert [patch 12/20 ]("net: hns3: Add packet statistics of netdev").
Thanks
Peng Li
> .
>
^ permalink raw reply
* Re: [PATCH net-next v2 1/6] net: Fix netdev_WARN_ONCE macro
From: Joe Perches @ 2018-01-09 2:42 UTC (permalink / raw)
To: Gal Pressman, David S. Miller; +Cc: netdev, Tariq Toukan, Saeed Mahameed
In-Reply-To: <1515319720-18428-2-git-send-email-galp@mellanox.com>
On Sun, 2018-01-07 at 12:08 +0200, Gal Pressman wrote:
> netdev_WARN_ONCE is broken (whoops..), this fix will remove the
> unnecessary "condition" parameter, add the missing comma and change
> "arg" to "args".
>
> Fixes: 375ef2b1f0d0 ("net: Introduce netdev_*_once functions")
> Signed-off-by: Gal Pressman <galp@mellanox.com>
> Reviewed-by: Saeed Mahameed <saeedm@mellanox.com>
> ---
> include/linux/netdevice.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 352066e..5ff1ef9 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -4407,8 +4407,8 @@ do { \
> WARN(1, "netdevice: %s%s\n" format, netdev_name(dev), \
> netdev_reg_state(dev), ##args)
>
> -#define netdev_WARN_ONCE(dev, condition, format, arg...) \
> - WARN_ONCE(1, "netdevice: %s%s\n" format, netdev_name(dev) \
> +#define netdev_WARN_ONCE(dev, format, args...) \
> + WARN_ONCE(1, "netdevice: %s%s\n" format, netdev_name(dev), \
You sure you want the newline before the format?
> netdev_reg_state(dev), ##args)
>
> /* netif printk helpers, similar to netdev_printk */
^ permalink raw reply
* RE: [PATCH net-next v2 5/6] bnx2x: Replace WARN_ONCE with netdev_WARN_ONCE
From: Kalluru, Sudarsana @ 2018-01-09 2:40 UTC (permalink / raw)
To: Gal Pressman, David S. Miller
Cc: netdev@vger.kernel.org, Tariq Toukan, Saeed Mahameed,
Elior, Ariel
In-Reply-To: <1515319720-18428-6-git-send-email-galp@mellanox.com>
-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On Behalf Of Gal Pressman
Sent: 07 January 2018 15:39
To: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org; Tariq Toukan <tariqt@mellanox.com>; Saeed Mahameed <saeedm@mellanox.com>; Gal Pressman <galp@mellanox.com>; Elior, Ariel <Ariel.Elior@cavium.com>
Subject: [PATCH net-next v2 5/6] bnx2x: Replace WARN_ONCE with netdev_WARN_ONCE
Use the more appropriate netdev_WARN_ONCE instead of WARN_ONCE macro.
Signed-off-by: Gal Pressman <galp@mellanox.com>
Reviewed-by: Saeed Mahameed <saeedm@mellanox.com>
Cc: Ariel Elior <ariel.elior@cavium.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
index 57eb26d..d7c98e8 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -738,8 +738,9 @@ static void bnx2x_gro_receive(struct bnx2x *bp, struct bnx2x_fastpath *fp,
bnx2x_gro_csum(bp, skb, bnx2x_gro_ipv6_csum);
break;
default:
- WARN_ONCE(1, "Error: FW GRO supports only IPv4/IPv6, not 0x%04x\n",
- be16_to_cpu(skb->protocol));
+ netdev_WARN_ONCE(bp->dev,
+ "Error: FW GRO supports only IPv4/IPv6, not 0x%04x\n",
+ be16_to_cpu(skb->protocol));
}
}
#endif
--
2.7.4
Acked-by: Sudarsana Kalluru <Sudarsana.Kalluru@cavium.com>
^ permalink raw reply related
* RE: [patch iproute2 v6 0/3] tc: Add -bs option to batch mode
From: Chris Mi @ 2018-01-09 2:35 UTC (permalink / raw)
To: Phil Sutter
Cc: dsahern@gmail.com, marcelo.leitner@gmail.com,
netdev@vger.kernel.org, gerlitz.or@gmail.com,
stephen@networkplumber.org
In-Reply-To: <20180108133150.GE14358@orbyte.nwl.cc>
> -----Original Message-----
> From: n0-1@orbyte.nwl.cc [mailto:n0-1@orbyte.nwl.cc] On Behalf Of Phil
> Sutter
> Sent: Monday, January 8, 2018 9:32 PM
> To: Chris Mi <chrism@mellanox.com>
> Cc: dsahern@gmail.com; marcelo.leitner@gmail.com;
> netdev@vger.kernel.org; gerlitz.or@gmail.com;
> stephen@networkplumber.org
> Subject: Re: [patch iproute2 v6 0/3] tc: Add -bs option to batch mode
>
> Hi Chris,
>
> On Mon, Jan 08, 2018 at 02:03:53AM +0000, Chris Mi wrote:
> > > On Thu, Jan 04, 2018 at 04:34:51PM +0900, Chris Mi wrote:
> > > > The insertion rate is improved more than 10%.
> > >
> > > Did you measure the effect of increasing batch sizes?
> > Yes. Even if we enlarge the batch size bigger than 10, there is no big
> improvement.
> > I think that's because current kernel doesn't process the requests in
> parallel.
> > If kernel processes the requests in parallel, I believe specifying a
> > bigger batch size will get a better result.
>
> But throughput doesn't regress at some point, right? I think that's the critical
> aspect when considering an "unlimited" batch size.
>
> On Mon, Jan 08, 2018 at 08:00:00AM +0000, Chris Mi wrote:
> > After testing, I find that the message passed to kernel should not be too
> big.
> > If it is bigger than about 64K, sendmsg returns -1, errno is 90 (EMSGSIZE).
> > That is about 400 commands. So how about set batch size to 128 which is
> big enough?
>
> If that's the easiest way, why not. At first, I thought one could maybe send
> the collected messages in chunks of suitable size, but that's probably not
> worth the effort.
I did a testing. If we read a million commands in memory and send them in chunks of 128,
we'll have a big regression. It takes about 21 seconds.
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: introduce BPF_JIT_ALWAYS_ON config
From: Alexei Starovoitov @ 2018-01-09 2:23 UTC (permalink / raw)
To: Jakub Kicinski, Daniel Borkmann
Cc: Alexei Starovoitov, davem, torvalds, jannh, alan, netdev,
kernel-team
In-Reply-To: <20180108160218.1e735fca@cakuba.netronome.com>
On 1/8/18 4:02 PM, Jakub Kicinski wrote:
> On Mon, 8 Jan 2018 22:59:04 +0100, Daniel Borkmann wrote:
>>> @@ -1453,6 +1457,11 @@ struct bpf_prog *bpf_prog_select_runtime(struct bpf_prog *fp, int *err)
>>> */
>>> *err = bpf_check_tail_call(fp);
>>>
>>> +#ifdef CONFIG_BPF_JIT_ALWAYS_ON
>>> + if (!fp->jited)
>>> + *err = -ENOTSUPP;
>>> +#endif
>
> I think programs JITed for offload won't have fp->jited set, but
> those are pretty safe from CPU bugs. Should we set fp->jited = 1; in
> bpf_prog_offload_compile()? Just throwing "&& !bpf_prog_is_dev_bound()"
> in here seems cleaner to me.
good catch. will fix in the v2.
^ permalink raw reply
* Re: [PATCH net-next 1/3] ethtool: Ensure new ring parameters are within bounds during SRINGPARAM
From: Jakub Kicinski @ 2018-01-09 2:23 UTC (permalink / raw)
To: Tariq Toukan; +Cc: David S. Miller, netdev, Eran Ben Elisha, Eugenia Emantayev
In-Reply-To: <1515420026-11970-2-git-send-email-tariqt@mellanox.com>
On Mon, 8 Jan 2018 16:00:24 +0200, Tariq Toukan wrote:
> From: Eugenia Emantayev <eugenia@mellanox.com>
>
> Add a sanity check to ensure that all requested ring parameters
> are within bounds, which should reduce errors in driver implementation.
(y)
> Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
> Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
> ---
> net/core/ethtool.c | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> index 50a79203043b..9ea7cd52fde0 100644
> --- a/net/core/ethtool.c
> +++ b/net/core/ethtool.c
> @@ -1704,14 +1704,23 @@ static int ethtool_get_ringparam(struct net_device *dev, void __user *useraddr)
>
> static int ethtool_set_ringparam(struct net_device *dev, void __user *useraddr)
> {
> - struct ethtool_ringparam ringparam;
> + struct ethtool_ringparam ringparam, max = { .cmd = ETHTOOL_GRINGPARAM };
>
> - if (!dev->ethtool_ops->set_ringparam)
> + if (!dev->ethtool_ops->set_ringparam || !dev->ethtool_ops->get_ringparam)
> return -EOPNOTSUPP;
>
> if (copy_from_user(&ringparam, useraddr, sizeof(ringparam)))
> return -EFAULT;
>
> + dev->ethtool_ops->get_ringparam(dev, &max);
Perhaps check the return value here? It's pretty unlikely but
get_ringparam may fail.
> + /* ensure new ring parameters are within the maximums */
> + if (ringparam.rx_pending > max.rx_max_pending ||
> + ringparam.rx_mini_pending > max.rx_mini_max_pending ||
> + ringparam.rx_jumbo_pending > max.rx_jumbo_max_pending ||
> + ringparam.tx_pending > max.tx_max_pending)
> + return -EINVAL;
> +
> return dev->ethtool_ops->set_ringparam(dev, &ringparam);
> }
>
^ permalink raw reply
* Re: [PATCH 07/18] [media] uvcvideo: prevent bounds-check bypass via speculative execution
From: Dan Williams @ 2018-01-09 2:11 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Linux Kernel Mailing List, linux-arch, Alan Cox, Peter Zijlstra,
Netdev, Greg KH, Thomas Gleixner, Mauro Carvalho Chehab,
Linus Torvalds, Elena Reshetova, Linux-media@vger.kernel.org
In-Reply-To: <8223870.kpF3YQejF4@avalon>
On Mon, Jan 8, 2018 at 3:23 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Dan,
>
> Thank you for the patch.
>
> On Saturday, 6 January 2018 03:10:32 EET Dan Williams wrote:
>> Static analysis reports that 'index' may be a user controlled value that
>> is used as a data dependency to read 'pin' from the
>> 'selector->baSourceID' array. In order to avoid potential leaks of
>> kernel memory values, block speculative execution of the instruction
>> stream that could issue reads based on an invalid value of 'pin'.
>
> I won't repeat the arguments already made in the thread regarding having
> documented coverity rules for this, even if I agree with them.
>
>> Based on an original patch by Elena Reshetova.
>>
>> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
>> Cc: linux-media@vger.kernel.org
>> Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
>> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>> ---
>> drivers/media/usb/uvc/uvc_v4l2.c | 7 +++++--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c
>> b/drivers/media/usb/uvc/uvc_v4l2.c index 3e7e283a44a8..7442626dc20e 100644
>> --- a/drivers/media/usb/uvc/uvc_v4l2.c
>> +++ b/drivers/media/usb/uvc/uvc_v4l2.c
>> @@ -22,6 +22,7 @@
>> #include <linux/mm.h>
>> #include <linux/wait.h>
>> #include <linux/atomic.h>
>> +#include <linux/compiler.h>
>>
>> #include <media/v4l2-common.h>
>> #include <media/v4l2-ctrls.h>
>> @@ -810,6 +811,7 @@ static int uvc_ioctl_enum_input(struct file *file, void
>> *fh, struct uvc_entity *iterm = NULL;
>> u32 index = input->index;
>> int pin = 0;
>> + __u8 *elem;
>>
>> if (selector == NULL ||
>> (chain->dev->quirks & UVC_QUIRK_IGNORE_SELECTOR_UNIT)) {
>> @@ -820,8 +822,9 @@ static int uvc_ioctl_enum_input(struct file *file, void
>> *fh, break;
>> }
>> pin = iterm->id;
>> - } else if (index < selector->bNrInPins) {
>> - pin = selector->baSourceID[index];
>> + } else if ((elem = nospec_array_ptr(selector->baSourceID, index,
>> + selector->bNrInPins))) {
>> + pin = *elem;
>> list_for_each_entry(iterm, &chain->entities, chain) {
>> if (!UVC_ENTITY_IS_ITERM(iterm))
>> continue;
>
> (adding a bit more context)
>
>> if (iterm->id == pin)
>> break;
>> }
>> }
>>
>> if (iterm == NULL || iterm->id != pin)
>> return -EINVAL;
>>
>> memset(input, 0, sizeof(*input));
>> input->index = index;
>> strlcpy(input->name, iterm->name, sizeof(input->name));
>> if (UVC_ENTITY_TYPE(iterm) == UVC_ITT_CAMERA)
>> input->type = V4L2_INPUT_TYPE_CAMERA;
>
> So pin is used to search for an entry in the chain->entities list. Entries in
> that list are allocated separately through kmalloc and can thus end up in
> different cache lines, so I agree we have an issue. However, this is mitigated
> by the fact that typical UVC devices have a handful (sometimes up to a dozen)
> entities, so an attacker would only be able to read memory values that are
> equal to the entity IDs used by the device. Entity IDs can be freely allocated
> but typically count continuously from 0. It would take a specially-crafted UVC
> device to be able to read all memory.
>
> On the other hand, as this is nowhere close to being a fast path, I think we
> can close this potential hole as proposed in the patch. So,
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Thanks Laurent!
> Will you merge the whole series in one go, or would you like me to take the
> patch in my tree ? In the latter case I'll wait until the nospec_array_ptr()
> gets merged in mainline.
I'll track it for now. Until the 'nospec_array_ptr()' discussion
resolves there won't be a stabilized commit-id for you to base a
branch.
^ permalink raw reply
* Re: Subject: [RFC][PATCH 04/11] stmmac: fix breakage in stmmac_hw_setup()
From: David Miller @ 2018-01-09 2:02 UTC (permalink / raw)
To: viro; +Cc: netdev, peppe.cavallaro, Cavallaro, Giuseppe
In-Reply-To: <E1eXXig-0002B1-IA@ZenIV.linux.org.uk>
From: Al Viro <viro@ftp.linux.org.uk>
Date: Fri, 05 Jan 2018 19:31:58 +0000
> Since "drivers: net: stmmac: reworking the PCS code" ->pcs_ctrl_ane()
> had been taking iomem address to access as the first argument; its
> predecessor (->ctrl_ane()) used to take struct mac_device_info instead.
>
> One of the callers had not been converted; as the result, instead of
> reading and modifying a word in card iomem we read and modify a word
> in (or near) the in-core strucct mac_device_info.
>
> Fixes: 70523e639bf8 (drivers: net: stmmac: reworking the PCS code)
> Cc: stable@vger.kernel.org
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Yikes...
Al, can you split the bug fixes like this one into a separate series
for me to pull into my net GIT tree?
Don't include the pure annotation or partial endianness conversion
ones, those should go to net-next.
^ permalink raw reply
* Re: [RESEND PATCH 3/3] net: tipc: remove unused hardirq.h
From: David Miller @ 2018-01-09 1:59 UTC (permalink / raw)
To: yang.s; +Cc: netdev, linux-kernel, jon.maloy
In-Reply-To: <1515441174-122496-3-git-send-email-yang.s@alibaba-inc.com>
From: "Yang Shi" <yang.s@alibaba-inc.com>
Date: Tue, 09 Jan 2018 03:52:54 +0800
> Preempt counter APIs have been split out, currently, hardirq.h just
> includes irq_enter/exit APIs which are not used by TIPC at all.
>
> So, remove the unused hardirq.h.
>
> Signed-off-by: Yang Shi <yang.s@alibaba-inc.com>
> Acked-by: Ying Xue <ying.xue@windriver.com>
> Tested-by: Ying Xue <ying.xue@windriver.com>
Applied.
^ permalink raw reply
* Re: [RESEND PATCH 2/3] net: ovs: remove unused hardirq.h
From: David Miller @ 2018-01-09 1:59 UTC (permalink / raw)
To: yang.s; +Cc: netdev, linux-kernel, dev
In-Reply-To: <1515441174-122496-2-git-send-email-yang.s@alibaba-inc.com>
From: "Yang Shi" <yang.s@alibaba-inc.com>
Date: Tue, 09 Jan 2018 03:52:53 +0800
> Preempt counter APIs have been split out, currently, hardirq.h just
> includes irq_enter/exit APIs which are not used by openvswitch at all.
>
> So, remove the unused hardirq.h.
>
> Signed-off-by: Yang Shi <yang.s@alibaba-inc.com>
> Acked-by: Pravin B Shelar <pshelar@ovn.org>
Applied.
^ permalink raw reply
* Re: [RESEND PATCH 1/3] net: caif: remove unused hardirq.h
From: David Miller @ 2018-01-09 1:59 UTC (permalink / raw)
To: yang.s; +Cc: netdev, linux-kernel, dmitry.tarnyagin
In-Reply-To: <1515441174-122496-1-git-send-email-yang.s@alibaba-inc.com>
From: "Yang Shi" <yang.s@alibaba-inc.com>
Date: Tue, 09 Jan 2018 03:52:52 +0800
> Preempt counter APIs have been split out, currently, hardirq.h just
> includes irq_enter/exit APIs which are not used by caif at all.
>
> So, remove the unused hardirq.h.
>
> Signed-off-by: Yang Shi <yang.s@alibaba-inc.com>
Applied.
^ permalink raw reply
* Re: [PATCH 00/52] Netfilter/IPVS updates for net-next
From: David Miller @ 2018-01-09 1:55 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <20180108202000.12989-1-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Mon, 8 Jan 2018 21:19:08 +0100
> The following patchset contains Netfilter/IPVS updates for your
> net-next tree:
...
> 4) Add generic flow table offload infrastructure for nf_tables, this
> includes the netlink control plane and support for IPv4, IPv6 and
> mixed IPv4/IPv6 dataplanes. This comes with NAT support too. This
> patchset adds the IPS_OFFLOAD conntrack status bit to indicate that
> this flow has been offloaded.
Have driver maintainers signed off on your offload design and driver
interfaces?
I've pulled, but the above is really important to indicate when a new
offload feature is added.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 12/20] net: hns3: Add packet statistics of netdev
From: David Miller @ 2018-01-09 1:54 UTC (permalink / raw)
To: kubakici; +Cc: lipeng321, netdev, linux-kernel, linuxarm, salil.mehta
In-Reply-To: <20180108175021.4a769c33@cakuba.netronome.com>
From: Jakub Kicinski <kubakici@wp.pl>
Date: Mon, 8 Jan 2018 17:50:21 -0800
> Oh, I only noticed this extra misleading comment now. Unless each queue
> has a netdev, I don't see how these are per-queue.
If it isn't per-queue I want this change reverted.
^ permalink raw reply
* Re: [PATCH net-next v2 0/6] Replace WARN_ONCE usages with netdev_WARN_ONCE
From: David Miller @ 2018-01-09 1:53 UTC (permalink / raw)
To: galp; +Cc: netdev, tariqt, saeedm
In-Reply-To: <1515319720-18428-1-git-send-email-galp@mellanox.com>
From: Gal Pressman <galp@mellanox.com>
Date: Sun, 7 Jan 2018 12:08:34 +0200
> This series will fix an issue in netdev_WARN_ONCE, improve its formatting and
> replace drivers' usage of WARN_ONCE to netdev_WARN_ONCE.
>
> Driver specific patches were compilation tested, in addition, functional tested
> on Mellanox NIC.
>
> v1->v2:
> - Addressed commit message comments in patch #1
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 12/20] net: hns3: Add packet statistics of netdev
From: Jakub Kicinski @ 2018-01-09 1:50 UTC (permalink / raw)
To: David Miller; +Cc: lipeng321, netdev, linux-kernel, linuxarm, salil.mehta
In-Reply-To: <20180108174602.34bee66b@cakuba.netronome.com>
On Mon, 8 Jan 2018 17:46:02 -0800, Jakub Kicinski wrote:
> On Mon, 08 Jan 2018 20:39:13 -0500 (EST), David Miller wrote:
> > From: Jakub Kicinski <kubakici@wp.pl>
> > Date: Mon, 8 Jan 2018 12:04:31 -0800
> >
> > > Ugh, I so didn't review this in time :( I think there is a consensus
> > > that we should avoid duplicating standard stats in ethtool. Especially
> > > those old ones. Like "collisions", I assume this is a modern NIC, are
> > > collisions still a thing?
> >
> > There is no standard way to get per-queue values, and ethtool stats are
> > how pretty much every driver provides it.
>
> Right, agreed. I'm only objecting to this patch (12/20), where we can
> see the telltale code like this:
>
> + const struct rtnl_link_stats64 *net_stats;
> + struct rtnl_link_stats64 temp;
> +
> + net_stats = dev_get_stats(netdev, &temp);
> + for (i = 0; i < HNS3_NETDEV_STATS_COUNT; i++) {
> + stat = (u8 *)net_stats + hns3_netdev_stats[i].stats_offset;
> + *data++ = *(u64 *)stat;
> + }
>
> Where:
>
> +#define HNS3_NETDEV_STAT(_string, _member) { \
> + .stats_string = _string, \
> + .stats_offset = offsetof(struct rtnl_link_stats64, _member) \
> +}
> +
> +static const struct hns3_stats hns3_netdev_stats[] = {
> + /* Rx per-queue statistics */
Oh, I only noticed this extra misleading comment now. Unless each queue
has a netdev, I don't see how these are per-queue.
> + HNS3_NETDEV_STAT("rx_packets", rx_packets),
> + HNS3_NETDEV_STAT("tx_packets", tx_packets),
>
> etc. IOW dumping struct rtnl_link_stats64 to ethtool -S member by
> member.
>
> Let me put the netlink per-queue stats on my soft TODO list :)
>
^ permalink raw reply
* RE: [patch iproute2 v6 0/3] tc: Add -bs option to batch mode
From: Chris Mi @ 2018-01-09 1:49 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Ahern, Phil Sutter, marcelo.leitner@gmail.com,
netdev@vger.kernel.org, gerlitz.or@gmail.com
In-Reply-To: <20180108074014.458333d1@xeon-e3>
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Monday, January 8, 2018 11:40 PM
> To: Chris Mi <chrism@mellanox.com>
> Cc: David Ahern <dsahern@gmail.com>; Phil Sutter <phil@nwl.cc>;
> marcelo.leitner@gmail.com; netdev@vger.kernel.org; gerlitz.or@gmail.com
> Subject: Re: [patch iproute2 v6 0/3] tc: Add -bs option to batch mode
>
> On Mon, 8 Jan 2018 08:00:00 +0000
> Chris Mi <chrism@mellanox.com> wrote:
>
> > > >> I wonder whether specifying the batch size is necessary at all.
> > > >> Couldn't batch mode just collect messages until either EOF or an
> > > >> incompatible command is encountered which then triggers a commit
> > > >> to kernel? This might simplify code quite a bit.
> > > > That's a good suggestion.
> > >
> > > Thanks for your time on this, Chris.
> > After testing, I find that the message passed to kernel should not be too
> big.
> > If it is bigger than about 64K, sendmsg returns -1, errno is 90 (EMSGSIZE).
> > That is about 400 commands. So how about set batch size to 128 which is
> big enough?
>
>
> Use sendmmsg?
Maybe we can try that, but there is also a limit on it.
^ permalink raw reply
* Re: [PATCH net-next 12/20] net: hns3: Add packet statistics of netdev
From: Jakub Kicinski @ 2018-01-09 1:46 UTC (permalink / raw)
To: David Miller; +Cc: lipeng321, netdev, linux-kernel, linuxarm, salil.mehta
In-Reply-To: <20180108.203913.1283013651432416478.davem@davemloft.net>
On Mon, 08 Jan 2018 20:39:13 -0500 (EST), David Miller wrote:
> From: Jakub Kicinski <kubakici@wp.pl>
> Date: Mon, 8 Jan 2018 12:04:31 -0800
>
> > Ugh, I so didn't review this in time :( I think there is a consensus
> > that we should avoid duplicating standard stats in ethtool. Especially
> > those old ones. Like "collisions", I assume this is a modern NIC, are
> > collisions still a thing?
>
> There is no standard way to get per-queue values, and ethtool stats are
> how pretty much every driver provides it.
Right, agreed. I'm only objecting to this patch (12/20), where we can
see the telltale code like this:
+ const struct rtnl_link_stats64 *net_stats;
+ struct rtnl_link_stats64 temp;
+
+ net_stats = dev_get_stats(netdev, &temp);
+ for (i = 0; i < HNS3_NETDEV_STATS_COUNT; i++) {
+ stat = (u8 *)net_stats + hns3_netdev_stats[i].stats_offset;
+ *data++ = *(u64 *)stat;
+ }
Where:
+#define HNS3_NETDEV_STAT(_string, _member) { \
+ .stats_string = _string, \
+ .stats_offset = offsetof(struct rtnl_link_stats64, _member) \
+}
+
+static const struct hns3_stats hns3_netdev_stats[] = {
+ /* Rx per-queue statistics */
+ HNS3_NETDEV_STAT("rx_packets", rx_packets),
+ HNS3_NETDEV_STAT("tx_packets", tx_packets),
etc. IOW dumping struct rtnl_link_stats64 to ethtool -S member by
member.
Let me put the netlink per-queue stats on my soft TODO list :)
^ permalink raw reply
* [PATCH v2] b43: Replace mdelay with usleep_range in b43_radio_2057_init_post
From: Jia-Ju Bai @ 2018-01-09 1:40 UTC (permalink / raw)
To: Larry.Finger, kvalo, kstewart, johannes.berg, tiwai, gregkh,
colin.king, andrew.zaborowski
Cc: linux-kernel, linux-wireless, netdev, b43-dev, Jia-Ju Bai
b43_radio_2057_init_post is not called in an interrupt handler
nor holding a spinlock.
The function mdelay in it can be replaced with usleep_range,
to reduce busy wait.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
v2:
* Replace mdelay with usleep_range, instead of msleep in v1.
Thank Larry for good advice.
---
drivers/net/wireless/broadcom/b43/phy_n.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/b43/phy_n.c b/drivers/net/wireless/broadcom/b43/phy_n.c
index a5557d7..f2a2f41 100644
--- a/drivers/net/wireless/broadcom/b43/phy_n.c
+++ b/drivers/net/wireless/broadcom/b43/phy_n.c
@@ -1031,7 +1031,7 @@ static void b43_radio_2057_init_post(struct b43_wldev *dev)
b43_radio_set(dev, R2057_RFPLL_MISC_CAL_RESETN, 0x78);
b43_radio_set(dev, R2057_XTAL_CONFIG2, 0x80);
- mdelay(2);
+ usleep_range(2000, 3000);
b43_radio_mask(dev, R2057_RFPLL_MISC_CAL_RESETN, ~0x78);
b43_radio_mask(dev, R2057_XTAL_CONFIG2, ~0x80);
--
1.7.9.5
^ permalink raw reply related
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