* Re: [PATCH net-next] flow_dissector: fix vlan tag handling
From: Jiri Pirko @ 2016-10-24 8:17 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Tom Herbert, David S. Miller, Alexander Duyck, Jiri Pirko,
Hadar Hen Zion, Gao Feng, Amir Vadai,
Linux Kernel Network Developers, LKML, Linus Torvalds
In-Reply-To: <3590200.oN5tv3ZPpc@wuerfel>
Sat, Oct 22, 2016 at 10:30:08PM CEST, arnd@arndb.de wrote:
>gcc warns about an uninitialized pointer dereference in the vlan
>priority handling:
>
>net/core/flow_dissector.c: In function '__skb_flow_dissect':
>net/core/flow_dissector.c:281:61: error: 'vlan' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
>As pointed out by Jiri Pirko, the variable is never actually used
>without being initialized first as the only way it end up uninitialized
>is with skb_vlan_tag_present(skb)==true, and that means it does not
>get accessed.
>
>However, the warning hints at some related issues that I'm addressing
>here:
>
>- the second check for the vlan tag is different from the first one
> that tests the skb for being NULL first, causing both the warning
> and a possible NULL pointer dereference that was not entirely fixed.
>- The same patch that introduced the NULL pointer check dropped an
> earlier optimization that skipped the repeated check of the
> protocol type
>- The local '_vlan' variable is referenced through the 'vlan' pointer
> but the variable has gone out of scope by the time that it is
> accessed, causing undefined behavior as the stack may have been
> overwritten.
>
>Caching the result of the 'skb && skb_vlan_tag_present(skb)' check
>in a local variable allows the compiler to further optimize the
>later check. With those changes, the warning also disappears.
>
>Fixes: 3805a938a6c2 ("flow_dissector: Check skb for VLAN only if skb specified.")
>Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>---
>
>diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
>index 44e6ba9d3a6b..17be1b66cc41 100644
>--- a/net/core/flow_dissector.c
>+++ b/net/core/flow_dissector.c
>@@ -246,13 +246,10 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
> case htons(ETH_P_8021AD):
> case htons(ETH_P_8021Q): {
> const struct vlan_hdr *vlan;
>+ struct vlan_hdr _vlan;
>+ bool vlan_tag_present = (skb && skb_vlan_tag_present(skb));
Drop the unnecessary "()"
>
>- if (skb && skb_vlan_tag_present(skb))
>- proto = skb->protocol;
This does not look correct. I believe that you need to set proto for
further processing.
>-
>- if (eth_type_vlan(proto)) {
>- struct vlan_hdr _vlan;
>-
>+ if (!vlan_tag_present || eth_type_vlan(skb->protocol)) {
> vlan = __skb_header_pointer(skb, nhoff, sizeof(_vlan),
> data, hlen, &_vlan);
> if (!vlan)
>@@ -270,7 +267,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
> FLOW_DISSECTOR_KEY_VLAN,
> target_container);
>
>- if (skb_vlan_tag_present(skb)) {
>+ if (vlan_tag_present) {
> key_vlan->vlan_id = skb_vlan_tag_get_id(skb);
> key_vlan->vlan_priority =
> (skb_vlan_tag_get_prio(skb) >> VLAN_PRIO_SHIFT);
>
^ permalink raw reply
* Re: [PATCH 0/4] STM32F429: Add Ethernet fixes
From: Alexandre Torgue @ 2016-10-24 7:30 UTC (permalink / raw)
To: David Miller
Cc: peppe.cavallaro-qxv4g6HH51o,
mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w, arnd-r2nGTMty4D4,
robh-DgEjT+Ai2ygdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161020.144140.1794871934594140769.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Hi David,
On 10/20/2016 08:41 PM, David Miller wrote:
> From: Alexandre TORGUE <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
> Date: Thu, 20 Oct 2016 17:21:22 +0200
>
>> This series adds several fixes for Ethernet for stm32f429 MCU.
>> First 2 patches have already been reviewed some months ago when
>> stm32 Ethernet glue has been pushed (I added in this series to keep
>> history). Fixes are:
>> -Change DT to be compliant to stm32 ethernet glue binding
>> -Add phy-handle to correctly use mdio subnode
>> -Remove WoL support
>
> I'm assuming this will be merged via the ARM tree.
Yes, I will take it in my next pull request (if no issues).
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH kernel v3] PCI: Enable access to custom VPD for Chelsio devices (cxgb3)
From: Alexey Kardashevskiy @ 2016-10-24 7:04 UTC (permalink / raw)
To: linux-kernel
Cc: Alexey Kardashevskiy, linux-pci, Alexander Duyck, Netdev,
Santosh Raspatur
There is at least one Chelsio 10Gb card which uses VPD area to store
some custom blocks (example below). However pci_vpd_size() returns
the length of the first block only assuming that there can be only
one VPD "End Tag" and VFIO blocks access beyond that offset
(since 4e1a63555) which leads to the situation when the guest "cxgb3"
driver fails to probe the device. The host system does not have this
problem as the drives accesses the config space directly without
pci_read_vpd()/...
This adds a quirk to override the VPD size to a bigger value.
The maximum size is taken from EEPROMSIZE in
drivers/net/ethernet/chelsio/cxgb3/common.h. We do not read the tag
as the cxgb3 driver does as the driver supports writing to EEPROM/VPD
and when it writes, it only checks for 8192 bytes boundary. The quirk
is registerted for all devices supported by the cxgb3 driver.
This adds a quirk to the PCI layer (not to the cxgb3 driver) as
the cxgb3 driver itself accesses VPD directly and the problem only exists
with the vfio-pci driver (when cxgb3 is not running on the host and
may not be even loaded) which blocks accesses beyond the first block
of VPD data. However vfio-pci itself does not have quirks mechanism so
we add it to PCI.
This is the controller:
Ethernet controller [0200]: Chelsio Communications Inc T310 10GbE Single Port Adapter [1425:0030]
This is what I parsed from its vpd:
===
b'\x82*\x0010 Gigabit Ethernet-SR PCI Express Adapter\x90J\x00EC\x07D76809 FN\x0746K'
0000 Large item 42 bytes; name 0x2 Identifier String
b'10 Gigabit Ethernet-SR PCI Express Adapter'
002d Large item 74 bytes; name 0x10
#00 [EC] len=7: b'D76809 '
#0a [FN] len=7: b'46K7897'
#14 [PN] len=7: b'46K7897'
#1e [MN] len=4: b'1037'
#25 [FC] len=4: b'5769'
#2c [SN] len=12: b'YL102035603V'
#3b [NA] len=12: b'00145E992ED1'
007a Small item 1 bytes; name 0xf End Tag
0c00 Large item 16 bytes; name 0x2 Identifier String
b'S310E-SR-X '
0c13 Large item 234 bytes; name 0x10
#00 [PN] len=16: b'TBD '
#13 [EC] len=16: b'110107730D2 '
#26 [SN] len=16: b'97YL102035603V '
#39 [NA] len=12: b'00145E992ED1'
#48 [V0] len=6: b'175000'
#51 [V1] len=6: b'266666'
#5a [V2] len=6: b'266666'
#63 [V3] len=6: b'2000 '
#6c [V4] len=2: b'1 '
#71 [V5] len=6: b'c2 '
#7a [V6] len=6: b'0 '
#83 [V7] len=2: b'1 '
#88 [V8] len=2: b'0 '
#8d [V9] len=2: b'0 '
#92 [VA] len=2: b'0 '
#97 [RV] len=80: b's\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'...
0d00 Large item 252 bytes; name 0x11
#00 [VC] len=16: b'122310_1222 dp '
#13 [VD] len=16: b'610-0001-00 H1\x00\x00'
#26 [VE] len=16: b'122310_1353 fp '
#39 [VF] len=16: b'610-0001-00 H1\x00\x00'
#4c [RW] len=173: b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'...
0dff Small item 0 bytes; name 0xf End Tag
10f3 Large item 13315 bytes; name 0x62
!!! unknown item name 98: b'\xd0\x03\x00@`\x0c\x08\x00\x00\x00\x00\x00\x00\x00\x00\x00'
===
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
v3:
* unconditionally set VPD size to 8192
v2:
* used pci_set_vpd_size() helper
* added explicit list of IDs from cxgb3 driver
* added a note in the commit log why the quirk is not in cxgb3
---
drivers/pci/quirks.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index c232729..bc7c541 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3255,6 +3255,25 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PORT_RIDGE,
quirk_thunderbolt_hotplug_msi);
+static void quirk_chelsio_extend_vpd(struct pci_dev *dev)
+{
+ pci_set_vpd_size(dev, 8192);
+}
+
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x20, quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x21, quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x22, quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x23, quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x24, quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x25, quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x26, quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x30, quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x31, quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x32, quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x35, quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x36, quirk_chelsio_extend_vpd);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x37, quirk_chelsio_extend_vpd);
+
#ifdef CONFIG_ACPI
/*
* Apple: Shutdown Cactus Ridge Thunderbolt controller.
--
2.5.0.rc3
^ permalink raw reply related
* Re: send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_packet_transmit
From: Xin Long @ 2016-10-24 6:30 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: netdev@vger.kernel.org, Marcelo Ricardo Leitner, Vlad Yasevich,
Daniel Borkmann, David Miller, linux-sctp@vger.kernel.org,
Michael Tuexen, Eric Dumazet, Brenda Butler, gabor
In-Reply-To: <2fa21505-59c2-fb8b-6e89-11fccc953d25@mojatatu.com>
[1]
>> This patch doesn't ignore all the ENOMEN cases, only after msg is
>> enqueued in out queue/send queue, in the lower layer, when alloc
>> new skb and copy data from old skb, if it fails to alloc new skb, sctp
>> will ignore this ENOMEM, as this msg will be taken care by retransmit
>> mechanism, it's reasonable and also safe, user can't feel that.
>>
>
> Yes, that part i got.
>
[2]
>> But for the cases before enqueue, like in sctp_sendmsg,
>> sctp_datamsg_from_user may return ENOMEM, this err will return
>> back to user, and can't be ignored.
>>
>
> The hard part is distinguishing between the above case and real
> failure.
> I am assuming in the case above user is _not_ required to send
> again. But in the general case they are required to send again.
> Correct?
in case [1], user can't see the ENOMEM, ENOMEM is more like
a internal err.
in case [2], user will got the ENOMEM, they should resend this msg,
It's the the general case mentioned-above
>
>> So I don't really think we should change something in manpage, what
>> do you think ? maybe a little explanation there is also nice, :)
>
>
> Yes, that would help. In particular it should be clear what user space
> is expected to do. While this is about sctp - I am assuming equivalent
> behavior for all callers of sendxxx() regardless of protocol.
here sctp's behavior is actually same with tcp's, in tcp, tcp_transmit_skb
also may fail to alloc skb, but it doesn't return any err to user, just like
sctp_packet_transmit. That's why I don't think we should change something
in manpage, as here sctp is consistent with tcp now.
make sense ?
^ permalink raw reply
* [PATCH net] MAINTAINERS: Update qlogic networking drivers
From: Yuval Mintz @ 2016-10-24 5:48 UTC (permalink / raw)
To: davem, netdev
Cc: ameen.rahman, Ariel.Elior, harish.patil, rasesh.mody,
Manish.Chopra, Sudarsana.Kalluru, rahul.verma, Yuval Mintz
Following Cavium's acquisition of qlogic we need to update all the qlogic
drivers maintainer's entries to point to our new e-mail addresses,
as well as update some of the driver's maintainers as those are no longer
working for Cavium.
I would like to thank Sony Chacko and Rajesh Borundia for their support
and development of our various networking drivers.
Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
---
MAINTAINERS | 41 ++++++++++++++++++++++-------------------
1 file changed, 22 insertions(+), 19 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1fc66f0a..af299a7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2543,15 +2543,18 @@ S: Supported
F: drivers/net/ethernet/broadcom/genet/
BROADCOM BNX2 GIGABIT ETHERNET DRIVER
-M: Sony Chacko <sony.chacko@qlogic.com>
-M: Dept-HSGLinuxNICDev@qlogic.com
+M: Rasesh Mody <rasesh.mody@cavium.com>
+M: Harish Patil <harish.patil@cavium.com>
+M: Dept-GELinuxNICDev@cavium.com
L: netdev@vger.kernel.org
S: Supported
F: drivers/net/ethernet/broadcom/bnx2.*
F: drivers/net/ethernet/broadcom/bnx2_*
BROADCOM BNX2X 10 GIGABIT ETHERNET DRIVER
-M: Ariel Elior <ariel.elior@qlogic.com>
+M: Yuval Mintz <Yuval.Mintz@cavium.com>
+M: Ariel Elior <ariel.elior@cavium.com>
+M: everest-linux-l2@cavium.com
L: netdev@vger.kernel.org
S: Supported
F: drivers/net/ethernet/broadcom/bnx2x/
@@ -2758,7 +2761,9 @@ S: Supported
F: drivers/scsi/bfa/
BROCADE BNA 10 GIGABIT ETHERNET DRIVER
-M: Rasesh Mody <rasesh.mody@qlogic.com>
+M: Rasesh Mody <rasesh.mody@cavium.com>
+M: Sudarsana Kalluru <sudarsana.kalluru@cavium.com>
+M: Dept-GELinuxNICDev@cavium.com
L: netdev@vger.kernel.org
S: Supported
F: drivers/net/ethernet/brocade/bna/
@@ -8492,11 +8497,10 @@ F: Documentation/devicetree/bindings/net/wireless/
F: drivers/net/wireless/
NETXEN (1/10) GbE SUPPORT
-M: Manish Chopra <manish.chopra@qlogic.com>
-M: Sony Chacko <sony.chacko@qlogic.com>
-M: Rajesh Borundia <rajesh.borundia@qlogic.com>
+M: Manish Chopra <manish.chopra@cavium.com>
+M: Rahul Verma <rahul.verma@cavium.com>
+M: Dept-GELinuxNICDev@cavium.com
L: netdev@vger.kernel.org
-W: http://www.qlogic.com
S: Supported
F: drivers/net/ethernet/qlogic/netxen/
@@ -9873,33 +9877,32 @@ F: Documentation/scsi/LICENSE.qla4xxx
F: drivers/scsi/qla4xxx/
QLOGIC QLA3XXX NETWORK DRIVER
-M: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
-M: Ron Mercer <ron.mercer@qlogic.com>
-M: linux-driver@qlogic.com
+M: Dept-GELinuxNICDev@cavium.com
L: netdev@vger.kernel.org
S: Supported
F: Documentation/networking/LICENSE.qla3xxx
F: drivers/net/ethernet/qlogic/qla3xxx.*
QLOGIC QLCNIC (1/10)Gb ETHERNET DRIVER
-M: Dept-GELinuxNICDev@qlogic.com
+M: Harish Patil <harish.patil@cavium.com>
+M: Manish Chopra <manish.chopra@cavium.com>
+M: Dept-GELinuxNICDev@cavium.com
L: netdev@vger.kernel.org
S: Supported
F: drivers/net/ethernet/qlogic/qlcnic/
QLOGIC QLGE 10Gb ETHERNET DRIVER
-M: Harish Patil <harish.patil@qlogic.com>
-M: Sudarsana Kalluru <sudarsana.kalluru@qlogic.com>
-M: Dept-GELinuxNICDev@qlogic.com
-M: linux-driver@qlogic.com
+M: Harish Patil <harish.patil@cavium.com>
+M: Manish Chopra <manish.chopra@cavium.com>
+M: Dept-GELinuxNICDev@cavium.com
L: netdev@vger.kernel.org
S: Supported
F: drivers/net/ethernet/qlogic/qlge/
QLOGIC QL4xxx ETHERNET DRIVER
-M: Yuval Mintz <Yuval.Mintz@qlogic.com>
-M: Ariel Elior <Ariel.Elior@qlogic.com>
-M: everest-linux-l2@qlogic.com
+M: Yuval Mintz <Yuval.Mintz@cavium.com>
+M: Ariel Elior <Ariel.Elior@cavium.com>
+M: everest-linux-l2@cavium.com
L: netdev@vger.kernel.org
S: Supported
F: drivers/net/ethernet/qlogic/qed/
--
1.9.3
^ permalink raw reply related
* [PATCH net] netvsc: fix incorrect receive checksum offloading
From: Stephen Hemminger @ 2016-10-24 4:32 UTC (permalink / raw)
To: David Miller, KY Srinivasan, Haiyang Zhang; +Cc: netdev
From: Stephen Hemminger <sthemmin@microsoft.com>
The Hyper-V netvsc driver was looking at the incorrect status bits
in the checksum info. It was setting the receive checksum unnecessary
flag based on the IP header checksum being correct. The checksum
flag is skb is about TCP and UDP checksum status. Because of this
bug, any packet received with bad TCP checksum would be passed
up the stack and to the application causing data corruption.
The problem is reproducible via netcat and netem.
This had a side effect of not doing receive checksum offload
on IPv6. The driver was also also always doing checksum offload
independent of the checksum setting done via ethtool.
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
---
Please apply to -stable as well!
drivers/net/hyperv/netvsc_drv.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 5d6e75a..c71d966 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -607,15 +607,18 @@ static struct sk_buff *netvsc_alloc_recv_skb(struct net_device *net,
packet->total_data_buflen);
skb->protocol = eth_type_trans(skb, net);
- if (csum_info) {
- /* We only look at the IP checksum here.
- * Should we be dropping the packet if checksum
- * failed? How do we deal with other checksums - TCP/UDP?
- */
- if (csum_info->receive.ip_checksum_succeeded)
+
+ /* skb is already created with CHECKSUM_NONE */
+ skb_checksum_none_assert(skb);
+
+ /*
+ * In Linux, the IP checksum is always checked.
+ * Do L4 checksum offload if enabled and present.
+ */
+ if (csum_info && (net->features & NETIF_F_RXCSUM)) {
+ if (csum_info->receive.tcp_checksum_succeeded ||
+ csum_info->receive.udp_checksum_succeeded)
skb->ip_summed = CHECKSUM_UNNECESSARY;
- else
- skb->ip_summed = CHECKSUM_NONE;
}
if (vlan_tci & VLAN_TAG_PRESENT)
--
2.9.3
^ permalink raw reply related
* Re: [PATCH net-next RFC WIP] Patch for XDP support for virtio_net
From: Shrijeet Mukherjee @ 2016-10-24 1:51 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Shrijeet Mukherjee, mst, Tom Herbert, Netdev, Roopa Prabhu,
Nikolay Aleksandrov
In-Reply-To: <20161023093808.161535f3@xeon-e3>
On Sun, Oct 23, 2016 at 9:38 AM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> Overall, I am glad to see XDP support more widely available. Minor stuff
> in implementation.
>
>>
>> +/* this function is not called from the receive_buf path directly as
>> + * we want to use the page model for rx merge buffer and big buffers
>> + * and not use the fast path for driving skb's around
>> + */
>> +static inline u32 do_xdp_prog(struct virtnet_info *vi,
>> + struct receive_queue *rq,
>> + void *buf, int offset, int len)
>> +{
>
> Do not mark non-trivial static functions as inline. The compiler will
> do it anyway if it thinks it is appropriate.
>
> +static int virtnet_xdp_query(struct net_device *dev)
>
> Use bool here.
>
Ack on the bool.
the inline was my feeble attempt to minimize the overhead in the
"normal" path as currently I need a rcu deref followed by a
conditional. Wanted to ensure that we don't incur a call stack
overhead as well. But I will trust the compiler :)
> @@ -366,13 +420,22 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
hdr_len;
>
> This parts of the patch is white space creep. I.e other edits you did
> that stayed around.
Will clean up, thought I did .. but something must have come through.
>
> Do you have any performance numbers? Does the receive into pages hurt
> the non XDP performance?
>
No perf yet, on my limited env (laptop) I see higher packet drop rates
using the xdp_drop example, which is no surprise .. but I did not
change anything to recv into pages and instead opted to not support
the skb direct recv at all. And the other two modes were receiving
into pages and then forming skb's which is what I skipped if anything
other than XDP_PASS was returned.
The main goal of this patch was to start that discussion. My v2 patch
rejects the ndo op if neither of rx_mergeable or big_buffers are set.
Does that sound like a good tradeoff ? Don't know enough about who
turns these features off and why.
I can say that virtualbox always has the device features enabled .. so
seems like a good tradeoff ?
^ permalink raw reply
* Re: [PATCH net-next 1/2] firewire: net: fix maximum possible MTU
From: Jarod Wilson @ 2016-10-24 1:50 UTC (permalink / raw)
To: Stefan Richter; +Cc: David S. Miller, netdev, linux1394-devel, linux-kernel
In-Reply-To: <20161023162903.4166a35d@kant>
On Sun, Oct 23, 2016 at 04:29:03PM +0200, Stefan Richter wrote:
> Commit b3e3893e1253 ("net: use core MTU range checking in misc drivers")
> mistakenly introduced an upper limit for firewire-net's MTU based on the
> local link layer controller's reception capability. Revert this. Neither
> RFC 2734 nor our implementation impose any particular upper limit.
>
> Actually, to be on the safe side and to make the code explicit, set
> ETH_MAX_MTU = 65535 as upper limit now.
>
> (I replaced sizeof(struct rfc2734_header) by the equivalent
> RFC2374_FRAG_HDR_SIZE in order to avoid distracting long/int conversions.)
>
> Fixes: b3e3893e1253('net: use core MTU range checking in misc drivers')
> CC: netdev@vger.kernel.org
> CC: linux1394-devel@lists.sourceforge.net
> CC: Jarod Wilson <jarod@redhat.com>
> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Acked-by: Jarod Wilson <jarod@redhat.com>
--
Jarod Wilson
jarod@redhat.com
^ permalink raw reply
* Re: [PATCH net-next 2/2] firewire: net: set initial MTU = 1500 unconditionally, fix IPv6 on some CardBus cards
From: Jarod Wilson @ 2016-10-24 1:50 UTC (permalink / raw)
To: Stefan Richter; +Cc: David S. Miller, netdev, linux1394-devel, linux-kernel
In-Reply-To: <20161023163056.6bc38610@kant>
On Sun, Oct 23, 2016 at 04:30:56PM +0200, Stefan Richter wrote:
> firewire-net, like the older eth1394 driver, reduced the initial MTU to
> less than 1500 octets if the local link layer controller's asynchronous
> packet reception limit was lower.
>
> This is bogus, since this reception limit does not have anything to do
> with the transmission limit. Neither did this reduction affect the TX
> path positively, nor could it prevent link fragmentation at the RX path.
>
> Many FireWire CardBus cards have a max_rec of 9, causing an initial MTU
> of 1024 - 16 = 1008. RFC 2734 and RFC 3146 allow a minimum max_rec = 8,
> which would result in an initial MTU of 512 - 16 = 496. On such cards,
> IPv6 could only be employed if the MTU was manually increased to 1280 or
> more, i.e. IPv6 would not work without intervention from userland.
>
> We now always initialize the MTU to 1500, which is the default according
> to RFC 2734 and RFC 3146.
>
> On a VIA VT6316 based CardBus card which was affected by this, changing
> the MTU from 1008 to 1500 also increases TX bandwidth by 6 %.
> RX remains unaffected.
>
> CC: netdev@vger.kernel.org
> CC: linux1394-devel@lists.sourceforge.net
> CC: Jarod Wilson <jarod@redhat.com>
> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
> ---
> drivers/firewire/net.c | 8 +-------
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
> index 99379542b263..03715e7d9d92 100644
> --- a/drivers/firewire/net.c
> +++ b/drivers/firewire/net.c
> @@ -1463,13 +1463,7 @@ static int fwnet_probe(struct fw_unit *unit,
> goto out;
> dev->local_fifo = dev->handler.offset;
>
> - /*
> - * Use the RFC 2734 default 1500 octets or the maximum payload
> - * as initial MTU
> - */
> - net->mtu = min(1500U,
> - (1U << (card->max_receive + 1))
> - - RFC2374_FRAG_HDR_SIZE - IEEE1394_GASP_HDR_SIZE);
> + net->mtu = 1500U;
Should be able to do just net->mtu = ETH_DATA_LEN;
--
Jarod Wilson
jarod@redhat.com
^ permalink raw reply
* Re: [PATCH] batman-adv: Revert "use core MTU range checking in misc drivers"
From: Jarod Wilson @ 2016-10-24 1:48 UTC (permalink / raw)
To: Sven Eckelmann; +Cc: netdev, davem, b.a.t.m.a.n, linux-kernel
In-Reply-To: <2358358.cV5hCSMD7y@sven-edge>
On Sun, Oct 23, 2016 at 09:17:50AM +0200, Sven Eckelmann wrote:
> On Samstag, 22. Oktober 2016 21:08:26 CEST Jarod Wilson wrote:
> [...]
> > You're going to
> > need more than just this revert though, since batman-adv calls
> > ether_setup, which will set min_mtu = 68, max_mtu = 1500, unless
> > batadv_hardif_min_mtu() always returns something 1500 or less.
>
> It does only returns 1500 or less at the moment.
>
> return min_t(int, min_mtu - batadv_max_header_len(), ETH_DATA_LEN);
>
> > Actually,
> > looking at that, you could omit the mtu < 68 bit from
> > batadv_interface_change_mtu() too, since that'll already get done in the
> > core, but I have no clue what you need for max_mtu.
>
> I would like to get this revert through net-next.git before anything else.
Looks like that should work fine then.
--
Jarod Wilson
jarod@redhat.com
^ permalink raw reply
* Re: [RFC PATCH 01/13] pinctrl: meson: Add GXL pinctrl definitions
From: Linus Walleij @ 2016-10-24 1:03 UTC (permalink / raw)
To: Neil Armstrong
Cc: Kevin Hilman, Carlo Caione,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
open list:ARM/Amlogic Meson...,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1477060838-14164-2-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On Fri, Oct 21, 2016 at 4:40 PM, Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
> Add support for the Amlogic Meson GXL SoC, this is a partially complete
> definition only based on the Amlogic Vendor tree.
>
> This definition differs a lot from the GXBB and needs a separate entry.
>
> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Looks good to me. Tell me when I may apply it, it looks orthogonal
to the rest of the patches.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net] udp: fix IP_CHECKSUM handling
From: Eric Dumazet @ 2016-10-24 1:03 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Sam Kumar, Willem de Bruijn, Tom Herbert
From: Eric Dumazet <edumazet@google.com>
First bug was added in commit ad6f939ab193 ("ip: Add offset parameter to
ip_cmsg_recv") : Tom missed that ipv4 udp messages could be received on
AF_INET6 socket. ip_cmsg_recv(msg, skb) should have been replaced by
ip_cmsg_recv_offset(msg, skb, sizeof(struct udphdr));
Then commit e6afc8ace6dd ("udp: remove headers from UDP packets before
queueing") forgot to adjust the offsets now UDP headers are pulled
before skb are put in receive queue.
Fixes: ad6f939ab193 ("ip: Add offset parameter to ip_cmsg_recv")
Fixes: e6afc8ace6dd ("udp: remove headers from UDP packets before queueing")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Sam Kumar <samanthakumar@google.com>
Cc: Willem de Bruijn <willemb@google.com>
---
Tom, I would appreciate your feedback on this patch, I presume
you have tests to verify IP_CHECKSUM feature ? Thanks !
include/net/ip.h | 4 ++--
net/ipv4/ip_sockglue.c | 11 ++++++-----
net/ipv4/udp.c | 2 +-
net/ipv6/udp.c | 3 ++-
4 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/include/net/ip.h b/include/net/ip.h
index c9d07988911e..5413883ac47f 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -578,7 +578,7 @@ int ip_options_rcv_srr(struct sk_buff *skb);
*/
void ipv4_pktinfo_prepare(const struct sock *sk, struct sk_buff *skb);
-void ip_cmsg_recv_offset(struct msghdr *msg, struct sk_buff *skb, int offset);
+void ip_cmsg_recv_offset(struct msghdr *msg, struct sk_buff *skb, int tlen, int offset);
int ip_cmsg_send(struct sock *sk, struct msghdr *msg,
struct ipcm_cookie *ipc, bool allow_ipv6);
int ip_setsockopt(struct sock *sk, int level, int optname, char __user *optval,
@@ -600,7 +600,7 @@ void ip_local_error(struct sock *sk, int err, __be32 daddr, __be16 dport,
static inline void ip_cmsg_recv(struct msghdr *msg, struct sk_buff *skb)
{
- ip_cmsg_recv_offset(msg, skb, 0);
+ ip_cmsg_recv_offset(msg, skb, 0, 0);
}
bool icmp_global_allow(void);
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index af4919792b6a..b8a2d63d1fb8 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -98,7 +98,7 @@ static void ip_cmsg_recv_retopts(struct msghdr *msg, struct sk_buff *skb)
}
static void ip_cmsg_recv_checksum(struct msghdr *msg, struct sk_buff *skb,
- int offset)
+ int tlen, int offset)
{
__wsum csum = skb->csum;
@@ -106,8 +106,9 @@ static void ip_cmsg_recv_checksum(struct msghdr *msg, struct sk_buff *skb,
return;
if (offset != 0)
- csum = csum_sub(csum, csum_partial(skb_transport_header(skb),
- offset, 0));
+ csum = csum_sub(csum,
+ csum_partial(skb_transport_header(skb) + tlen,
+ offset, 0));
put_cmsg(msg, SOL_IP, IP_CHECKSUM, sizeof(__wsum), &csum);
}
@@ -153,7 +154,7 @@ static void ip_cmsg_recv_dstaddr(struct msghdr *msg, struct sk_buff *skb)
}
void ip_cmsg_recv_offset(struct msghdr *msg, struct sk_buff *skb,
- int offset)
+ int tlen, int offset)
{
struct inet_sock *inet = inet_sk(skb->sk);
unsigned int flags = inet->cmsg_flags;
@@ -216,7 +217,7 @@ void ip_cmsg_recv_offset(struct msghdr *msg, struct sk_buff *skb,
}
if (flags & IP_CMSG_CHECKSUM)
- ip_cmsg_recv_checksum(msg, skb, offset);
+ ip_cmsg_recv_checksum(msg, skb, tlen, offset);
}
EXPORT_SYMBOL(ip_cmsg_recv_offset);
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 311613e413cb..d123d68f4d1d 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1322,7 +1322,7 @@ int udp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len, int noblock,
*addr_len = sizeof(*sin);
}
if (inet->cmsg_flags)
- ip_cmsg_recv_offset(msg, skb, sizeof(struct udphdr) + off);
+ ip_cmsg_recv_offset(msg, skb, sizeof(struct udphdr), off);
err = copied;
if (flags & MSG_TRUNC)
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 9aa7c1c7a9ce..b2ef061e6836 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -427,7 +427,8 @@ int udpv6_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
if (is_udp4) {
if (inet->cmsg_flags)
- ip_cmsg_recv(msg, skb);
+ ip_cmsg_recv_offset(msg, skb,
+ sizeof(struct udphdr), off);
} else {
if (np->rxopt.all)
ip6_datagram_recv_specific_ctl(sk, msg, skb);
^ permalink raw reply related
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2016-10-23 23:34 UTC (permalink / raw)
To: David Miller, Networking
Cc: linux-next, linux-kernel, Eric Dumazet, Paolo Abeni
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
include/net/udp.h
between commit:
286c72deabaa ("udp: must lock the socket in udp_disconnect()")
from the net tree and commit:
f970bd9e3a06 ("udp: implement memory accounting helpers")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/net/udp.h
index 4948790d393d,18f1e6b91927..000000000000
--- a/include/net/udp.h
+++ b/include/net/udp.h
@@@ -258,7 -261,7 +261,8 @@@ void udp_flush_pending_frames(struct so
void udp4_hwcsum(struct sk_buff *skb, __be32 src, __be32 dst);
int udp_rcv(struct sk_buff *skb);
int udp_ioctl(struct sock *sk, int cmd, unsigned long arg);
+ int udp_init_sock(struct sock *sk);
+int __udp_disconnect(struct sock *sk, int flags);
int udp_disconnect(struct sock *sk, int flags);
unsigned int udp_poll(struct file *file, struct socket *sock, poll_table *wait);
struct sk_buff *skb_udp_tunnel_segment(struct sk_buff *skb,
^ permalink raw reply
* Re: [PATCH net 1/1] net sched filters: fix notification of filter delete with proper handle
From: Daniel Borkmann @ 2016-10-23 22:30 UTC (permalink / raw)
To: Jamal Hadi Salim, davem; +Cc: netdev, xiyou.wangcong, eric.dumazet
In-Reply-To: <1477236912-5789-1-git-send-email-jhs@emojatatu.com>
On 10/23/2016 05:35 PM, Jamal Hadi Salim wrote:
> From: Jamal Hadi Salim <jhs@mojatatu.com>
>
An actual commit message would be good especially if it's a fix
for -net tree plus stable. Thanks.
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
> ---
> net/sched/cls_api.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
> index 2ee29a3..2b2a797 100644
> --- a/net/sched/cls_api.c
> +++ b/net/sched/cls_api.c
> @@ -345,7 +345,8 @@ static int tc_ctl_tfilter(struct sk_buff *skb, struct nlmsghdr *n)
> if (err == 0) {
> struct tcf_proto *next = rtnl_dereference(tp->next);
>
> - tfilter_notify(net, skb, n, tp, fh,
> + tfilter_notify(net, skb, n, tp,
> + t->tcm_handle,
> RTM_DELTFILTER, false);
> if (tcf_destroy(tp, false))
> RCU_INIT_POINTER(*back, next);
>
^ permalink raw reply
* Re: pull request: bluetooth 2016-10-21
From: David Miller @ 2016-10-23 21:52 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth, netdev
In-Reply-To: <20161021144053.GA14245@x1c.dominarus.com>
From: Johan Hedberg <johan.hedberg@gmail.com>
Date: Fri, 21 Oct 2016 17:40:53 +0300
> Here are some more Bluetooth fixes for the 4.9 kernel:
>
> - Fix to btwilink driver probe function return value
> - Power management fix to hci_bcm
> - Fix to encoding name in scan response data
>
> Please let me know if there are any issues pulling. Thanks.
Pulled, thanks Johan.
^ permalink raw reply
* Re: [PATCH net-next] lwt: Remove unused len field
From: David Miller @ 2016-10-23 21:45 UTC (permalink / raw)
To: tgraf; +Cc: tom, roopa, netdev
In-Reply-To: <fb52764c89fa8c11ec832bd4ddf7595b6a673ce1.1477058913.git.tgraf@suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Fri, 21 Oct 2016 16:10:22 +0200
> The field is initialized by ILA and MPLS but never used. Remove it.
>
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
Applied, thanks Thomas.
^ permalink raw reply
* Re: [PATCH] net: sctp, forbid negative length
From: David Miller @ 2016-10-23 21:44 UTC (permalink / raw)
To: jslaby; +Cc: vyasevich, linux-kernel, nhorman, linux-sctp, netdev
In-Reply-To: <20161021121324.13942-1-jslaby@suse.cz>
From: Jiri Slaby <jslaby@suse.cz>
Date: Fri, 21 Oct 2016 14:13:24 +0200
> Most of getsockopt handlers in net/sctp/socket.c check len against
> sizeof some structure like:
> if (len < sizeof(int))
> return -EINVAL;
>
> On the first look, the check seems to be correct. But since len is int
> and sizeof returns size_t, int gets promoted to unsigned size_t too. So
> the test returns false for negative lengths. Yes, (-1 < sizeof(long)) is
> false.
>
> Fix this in sctp by explicitly checking len < 0 before any getsockopt
> handler is called.
>
> Note that sctp_getsockopt_events already handled the negative case.
> Since we added the < 0 check elsewhere, this one can be removed.
>
> If not checked, this is the result:
...
> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] net: fec: Call swap_buffer() prior to IP header alignment
From: David Miller @ 2016-10-23 21:42 UTC (permalink / raw)
To: festevam
Cc: fugang.duan, henri.roosen, eric, kernel, rmk, netdev,
fabio.estevam
In-Reply-To: <1477049669-25101-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <festevam@gmail.com>
Date: Fri, 21 Oct 2016 09:34:29 -0200
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Commit 3ac72b7b63d5 ("net: fec: align IP header in hardware") breaks
> networking on mx28.
>
> There is an erratum on mx28 (ENGR121613 - ENET big endian mode
> not compatible with ARM little endian) that requires an additional
> byte-swap operation to workaround this problem.
>
> So call swap_buffer() prior to performing the IP header alignment
> to restore network functionality on mx28.
>
> Fixes: 3ac72b7b63d5 ("net: fec: align IP header in hardware")
> Reported-and-tested-by: Henri Roosen <henri.roosen@ginzinger.com>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH v2 net-next 1/1] driver: tun: Forbid to set IFF_TUN and IFF_TAP at the same time
From: David Miller @ 2016-10-23 21:40 UTC (permalink / raw)
To: fgao; +Cc: jasowang, edumazet, pabeni, netdev, gfree.wind
In-Reply-To: <1477047735-26003-1-git-send-email-fgao@ikuai8.com>
From: fgao@ikuai8.com
Date: Fri, 21 Oct 2016 19:02:15 +0800
> From: Gao Feng <fgao@ikuai8.com>
>
> Current tun driver permits the ifr_flags is set with IFF_TUN and
> IFF_TAP at the same time. But actually there is only IFF_TUN flag
> works. And it does not make sense these two flags are set, so add
> this check.
>
> Signed-off-by: Gao Feng <fgao@ikuai8.com>
We've allowed this for too long to start failing on it now, sorry.
^ permalink raw reply
* Re: [PATCH] ipv6: do not increment mac header when it's unset
From: David Miller @ 2016-10-23 21:40 UTC (permalink / raw)
To: Jason
Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel, pageexec,
re.emese
In-Reply-To: <20161021092825.28085-1-Jason@zx2c4.com>
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
Date: Fri, 21 Oct 2016 18:28:25 +0900
> Otherwise we'll overflow the integer. This occurs when layer 3 tunneled
> packets are handed off to the IPv6 layer.
>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Applied, thanks.
Have fun playing with WireGuard.
^ permalink raw reply
* Re: [PATCH net 1/1] bnx2x: Use the correct divisor value for PHC clock readings.
From: David Miller @ 2016-10-23 21:35 UTC (permalink / raw)
To: Sony.Chacko; +Cc: netdev, Ariel.Elior, Yuval.Mintz, sudarsana.kalluru
In-Reply-To: <1477030157-30700-1-git-send-email-Sony.Chacko@cavium.com>
From: <Sony.Chacko@cavium.com>
Date: Fri, 21 Oct 2016 02:09:17 -0400
> From: Sudarsana Reddy Kalluru <sudarsana.kalluru@cavium.com>
>
> Time Sync (PTP) implementation uses the divisor/shift value for converting
> the clock ticks to nanoseconds. Driver currently defines shift value as 1,
> this results in the nanoseconds value to be calculated as half the actual
> value. Hence the user application fails to synchronize the device clock
> value with the PTP master device clock. Need to use the 'shift' value of 0.
>
> Signed-off-by: Sony.Chacko <Sony.Chacko@cavium.com>
> Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
> Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: allow to kill a task which waits net_mutex in copy_new_ns
From: David Miller @ 2016-10-23 21:34 UTC (permalink / raw)
To: avagin-GEFAQzZX7r8dnm+yROfE0A
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1477017943-18786-1-git-send-email-avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
From: Andrei Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Date: Thu, 20 Oct 2016 19:45:43 -0700
> From: Andrey Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
>
> net_mutex can be locked for a long time. It may be because many
> namespaces are being destroyed or many processes decide to create
> a network namespace.
>
> Both these operations are heavy, so it is better to have an ability to
> kill a process which is waiting net_mutex.
>
> Cc: "David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> Cc: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Andrei Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net/sched: em_meta: Fix 'meta vlan' to correctly recognize zero VID frames
From: David Miller @ 2016-10-23 21:31 UTC (permalink / raw)
To: shmulik.ladkani; +Cc: jhs, netdev, jiri, eric.dumazet, stephen
In-Reply-To: <1476998288-13341-1-git-send-email-shmulik.ladkani@gmail.com>
From: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Date: Fri, 21 Oct 2016 00:18:08 +0300
> META_COLLECTOR int_vlan_tag() assumes that if the accel tag (vlan_tci)
> is zero, then no vlan accel tag is present.
>
> This is incorrect for zero VID vlan accel packets, making the following
> match fail:
> tc filter add ... basic match 'meta(vlan mask 0xfff eq 0)' ...
>
> Apparently 'int_vlan_tag' was implemented prior VLAN_TAG_PRESENT was
> introduced in 05423b2 "vlan: allow null VLAN ID to be used"
> (and at time introduced, the 'vlan_tx_tag_get' call in em_meta was not
> adapted).
>
> Fix, testing skb_vlan_tag_present instead of testing skb_vlan_tag_get's
> value.
>
> Fixes: 05423b2413 ("vlan: allow null VLAN ID to be used")
> Fixes: 1a31f2042e ("netsched: Allow meta match on vlan tag on receive")
>
> Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [patch net-next 0/6] mlxsw: Driver update
From: David Miller @ 2016-10-23 21:22 UTC (permalink / raw)
To: jiri; +Cc: netdev, idosch, eladr, yotamg, nogahf, ogerlitz
In-Reply-To: <1477058843-9981-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Fri, 21 Oct 2016 16:07:17 +0200
> Mostly cosmetics and small resource values management rewrite.
Series applied, thanks Jiri.
^ permalink raw reply
* Re: send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_packet_transmit
From: Jamal Hadi Salim @ 2016-10-23 19:52 UTC (permalink / raw)
To: Xin Long
Cc: netdev@vger.kernel.org, Marcelo Ricardo Leitner, Vlad Yasevich,
Daniel Borkmann, David Miller, linux-sctp@vger.kernel.org,
Michael Tuexen, Eric Dumazet, Brenda Butler, gabor
In-Reply-To: <CADvbK_ci-aaX6-mgXTgR0mJm9ww7+48DmXH+m5R+-0PyMDH16g@mail.gmail.com>
On 16-10-23 02:20 PM, Xin Long wrote:
> This patch doesn't ignore all the ENOMEN cases, only after msg is
> enqueued in out queue/send queue, in the lower layer, when alloc
> new skb and copy data from old skb, if it fails to alloc new skb, sctp
> will ignore this ENOMEM, as this msg will be taken care by retransmit
> mechanism, it's reasonable and also safe, user can't feel that.
>
Yes, that part i got.
> But for the cases before enqueue, like in sctp_sendmsg,
> sctp_datamsg_from_user may return ENOMEM, this err will return
> back to user, and can't be ignored.
>
The hard part is distinguishing between the above case and real
failure.
I am assuming in the case above user is _not_ required to send
again. But in the general case they are required to send again.
Correct?
> So I don't really think we should change something in manpage, what
> do you think ? maybe a little explanation there is also nice, :)
Yes, that would help. In particular it should be clear what user space
is expected to do. While this is about sctp - I am assuming equivalent
behavior for all callers of sendxxx() regardless of protocol.
cheers,
jamal
^ 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