- 16 Jul, 2017 7 commits
-
-
Arvind Yadav authored
pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by <linux/pci.h> work with const pci_device_id. So mark the non-const structs as const. File size before: text data bss dec hex filename 13959 4080 24 18063 468f isdn/hardware/mISDN/w6692.o File size After adding 'const': text data bss dec hex filename 14087 3952 24 18063 468f isdn/hardware/mISDN/w6692.o Signed-off-by:
Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Arvind Yadav authored
pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by <linux/pci.h> work with const pci_device_id. So mark the non-const structs as const. File size before: text data bss dec hex filename 63450 1536 1492 66478 103ae isdn/hardware/mISDN/hfcmulti.o File size After adding 'const': text data bss dec hex filename 64698 288 1492 66478 103ae isdn/hardware/mISDN/hfcmulti.o Signed-off-by:
-
Arvind Yadav authored
pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by <linux/pci.h> work with const pci_device_id. So mark the non-const structs as const. File size before: text data bss dec hex filename 10941 1776 16 12733 31bd isdn/hardware/mISDN/netjet.o File size After adding 'const': text data bss dec hex filename 11005 1712 16 12733 31bd isdn/hardware/mISDN/netjet.o Signed-off-by:
-
Arvind Yadav authored
pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by <linux/pci.h> work with const pci_device_id. So mark the non-const structs as const. File size before: text data bss dec hex filename 6224 655 8 6887 1ae7 isdn/hardware/eicon/divasmain.o File size After adding 'const': text data bss dec hex filename 6608 271 8 6887 1ae7 isdn/hardware/eicon/divasmain.o Signed-off-by:
-
Arvind Yadav authored
pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by <linux/pci.h> work with const pci_device_id. So mark the non-const structs as const. File size before: text data bss dec hex filename 5989 576 0 6565 19a5 isdn/hisax/hisax_fcpcipnp.o File size After adding 'const': text data bss dec hex filename 6085 480 0 6565 19a5 isdn/hisax/hisax_fcpcipnp.o Signed-off-by:
-
Arvind Yadav authored
pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by <linux/pci.h> work with const pci_device_id. So mark the non-const structs as const. File size before: text data bss dec hex filename 10512 536 4 11052 2b2c drivers/isdn/hisax/hfc4s8s_l1.o File size After adding 'const': text data bss dec hex filename 10672 376 4 11052 2b2c drivers/isdn/hisax/hfc4s8s_l1.o Signed-off-by:
-
Arvind Yadav authored
pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by <linux/pci.h> work with const pci_device_id. So mark the non-const structs as const. File size before: text data bss dec hex filename 13686 2064 4416 20166 4ec6 drivers/isdn/hisax/config.o File size After adding 'const': text data bss dec hex filename 15030 720 4416 20166 4ec6 drivers/isdn/hisax/config.o Signed-off-by:
-
- 15 Jul, 2017 14 commits
-
-
Neal Cardwell authored
Fixes the following behavior: for connections that had no RTT sample at the time of initializing congestion control, BBR was initializing the pacing rate to a high nominal rate (based an a guess of RTT=1ms, in case this is LAN traffic). Then BBR never adjusted the pacing rate downward upon obtaining an actual RTT sample, if the connection never filled the pipe (e.g. all sends were small app-limited writes()). This fix adjusts the pacing rate upon obtaining the first RTT sample. Fixes: 0f8782ea ("tcp_bbr: add BBR congestion control") Signed-off-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
Yuchung Cheng <ycheng@google.com> Signed-off-by:
Soheil Hassas Yeganeh <soheil@google.com> Signed-off-by:
-
Neal Cardwell authored
Fix a corner case noticed by Eric Dumazet, where BBR's setting sk->sk_pacing_rate to 0 during initialization could theoretically cause packets in the sending host to hang if there were packets "in flight" in the pacing infrastructure at the time the BBR congestion control state is initialized. This could occur if the pacing infrastructure happened to race with bbr_init() in a way such that the pacer read the 0 rather than the immediately following non-zero pacing rate. Fixes: 0f8782ea ("tcp_bbr: add BBR congestion control") Reported-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Neal Cardwell authored
Introduce a helper to initialize the BBR pacing rate unconditionally, based on the current cwnd and RTT estimate. This is a pure refactor, but is needed for two following fixes. Fixes: 0f8782ea ("tcp_bbr: add BBR congestion control") Signed-off-by:
-
Neal Cardwell authored
Introduce a helper to convert a BBR bandwidth and gain factor to a pacing rate in bytes per second. This is a pure refactor, but is needed for two following fixes. Fixes: 0f8782ea ("tcp_bbr: add BBR congestion control") Signed-off-by:
-
Neal Cardwell authored
In bbr_set_pacing_rate(), which decides whether to cut the pacing rate, there was some code that considered exiting STARTUP to be equivalent to the notion of filling the pipe (i.e., bbr_full_bw_reached()). Specifically, as the code was structured, exiting STARTUP and going into PROBE_RTT could cause us to cut the pacing rate down to something silly and low, based on whatever bandwidth samples we've had so far, when it's possible that all of them have been small app-limited bandwidth samples that are not representative of the bandwidth available in the path. (The code was correct at the time it was written, but the state machine changed without this spot being adjusted correspondingly.) Fixes: 0f8782ea ("tcp_bbr: add BBR congestion control") Signed-off-by:
-
Greg Rose authored
When there is an established connection in direction A->B, it is possible to receive a packet on port B which then executes ct(commit,force) without first performing ct() - ie, a lookup. In this case, we would expect that this packet can delete the existing entry so that we can commit a connection with direction B->A. However, currently we only perform a check in skb_nfct_cached() for whether OVS_CS_F_TRACKED is set and OVS_CS_F_INVALID is not set, ie that a lookup previously occurred. In the above scenario, a lookup has not occurred but we should still be able to statelessly look up the existing entry and potentially delete the entry if it is in the opposite direction. This patch extends the check to also hint that if the action has the force flag set, then we will lookup the existing entry so that the force check at the end of skb_nfct_cached has the ability to delete the connection. Fixes: dd41d330b03 ("openvswitch: Add force commit.") CC: Pravin Shelar <pshelar@nicira.com> CC: dev@openvswitch.org Signed-off-by:Joe Stringer <joe@ovn.org> Signed-off-by:
Greg Rose <gvrose8192@gmail.com> Signed-off-by:
-
Alexander Potapenko authored
If the length field of the iterator (|pos.p| or |err|) is past the end of the chunk, we shouldn't access it. This bug has been detected by KMSAN. For the following pair of system calls: socket(PF_INET6, SOCK_STREAM, 0x84 /* IPPROTO_??? */) = 3 sendto(3, "A", 1, MSG_OOB, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 1 the tool has reported a use of uninitialized memory: ================================================================== BUG: KMSAN: use of uninitialized memory in sctp_rcv+0x17b8/0x43b0 CPU: 1 PID: 2940 Comm: probe Not tainted 4.11.0-rc5+ #2926 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:16 dump_stack+0x172/0x1c0 lib/dump_stack.c:52 kmsan_report+0x12a/0x180 mm/kmsan/kmsan.c:927 __msan_warning_32+0x61/0xb0 mm/kmsan/kmsan_instr.c:469 __sctp_rcv_init_lookup net/sctp/input.c:1074 __sctp_rcv_lookup_harder net/sctp/input.c:1233 __sctp_rcv_lookup net/sctp/input.c:1255 sctp_rcv+0x17b8/0x43b0 net/sctp/input.c:170 sctp6_rcv+0x32/0x70 net/sctp/ipv6.c:984 ip6_input_finish+0x82f/0x1ee0 net/ipv6/ip6_input.c:279 NF_HOOK ./include/linux/netfilter.h:257 ip6_input+0x239/0x290 net/ipv6/ip6_input.c:322 dst_input ./include/net/dst.h:492 ip6_rcv_finish net/ipv6/ip6_input.c:69 NF_HOOK ./include/linux/netfilter.h:257 ipv6_rcv+0x1dbd/0x22e0 net/ipv6/ip6_input.c:203 __netif_receive_skb_core+0x2f6f/0x3a20 net/core/dev.c:4208 __netif_receive_skb net/core/dev.c:4246 process_backlog+0x667/0xba0 net/core/dev.c:4866 napi_poll net/core/dev.c:5268 net_rx_action+0xc95/0x1590 net/core/dev.c:5333 __do_softirq+0x485/0x942 kernel/softirq.c:284 do_softirq_own_stack+0x1c/0x30 arch/x86/entry/entry_64.S:902 </IRQ> do_softirq kernel/softirq.c:328 __local_bh_enable_ip+0x25b/0x290 kernel/softirq.c:181 local_bh_enable+0x37/0x40 ./include/linux/bottom_half.h:31 rcu_read_unlock_bh ./include/linux/rcupdate.h:931 ip6_finish_output2+0x19b2/0x1cf0 net/ipv6/ip6_output.c:124 ip6_finish_output+0x764/0x970 net/ipv6/ip6_output.c:149 NF_HOOK_COND ./include/linux/netfilter.h:246 ip6_output+0x456/0x520 net/ipv6/ip6_output.c:163 dst_output ./include/net/dst.h:486 NF_HOOK ./include/linux/netfilter.h:257 ip6_xmit+0x1841/0x1c00 net/ipv6/ip6_output.c:261 sctp_v6_xmit+0x3b7/0x470 net/sctp/ipv6.c:225 sctp_packet_transmit+0x38cb/0x3a20 net/sctp/output.c:632 sctp_outq_flush+0xeb3/0x46e0 net/sctp/outqueue.c:885 sctp_outq_uncork+0xb2/0xd0 net/sctp/outqueue.c:750 sctp_side_effects net/sctp/sm_sideeffect.c:1773 sctp_do_sm+0x6962/0x6ec0 net/sctp/sm_sideeffect.c:1147 sctp_primitive_ASSOCIATE+0x12c/0x160 net/sctp/primitive.c:88 sctp_sendmsg+0x43e5/0x4f90 net/sctp/socket.c:1954 inet_sendmsg+0x498/0x670 net/ipv4/af_inet.c:762 sock_sendmsg_nosec net/socket.c:633 sock_sendmsg net/socket.c:643 SYSC_sendto+0x608/0x710 net/socket.c:1696 SyS_sendto+0x8a/0xb0 net/socket.c:1664 do_syscall_64+0xe6/0x130 arch/x86/entry/common.c:285 entry_SYSCALL64_slow_path+0x25/0x25 arch/x86/entry/entry_64.S:246 RIP: 0033:0x401133 RSP: 002b:00007fff6d99cd38 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00000000004002b0 RCX: 0000000000401133 RDX: 0000000000000001 RSI: 0000000000494088 RDI: 0000000000000003 RBP: 00007fff6d99cd90 R08: 00007fff6d99cd50 R09: 000000000000001c R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000000 R13: 00000000004063d0 R14: 0000000000406460 R15: 0000000000000000 origin: save_stack_trace+0x37/0x40 arch/x86/kernel/stacktrace.c:59 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:302 kmsan_internal_poison_shadow+0xb1/0x1a0 mm/kmsan/kmsan.c:198 kmsan_poison_shadow+0x6d/0xc0 mm/kmsan/kmsan.c:211 slab_alloc_node mm/slub.c:2743 __kmalloc_node_track_caller+0x200/0x360 mm/slub.c:4351 __kmalloc_reserve net/core/skbuff.c:138 __alloc_skb+0x26b/0x840 net/core/skbuff.c:231 alloc_skb ./include/linux/skbuff.h:933 sctp_packet_transmit+0x31e/0x3a20 net/sctp/output.c:570 sctp_outq_flush+0xeb3/0x46e0 net/sctp/outqueue.c:885 sctp_outq_uncork+0xb2/0xd0 net/sctp/outqueue.c:750 sctp_side_effects net/sctp/sm_sideeffect.c:1773 sctp_do_sm+0x6962/0x6ec0 net/sctp/sm_sideeffect.c:1147 sctp_primitive_ASSOCIATE+0x12c/0x160 net/sctp/primitive.c:88 sctp_sendmsg+0x43e5/0x4f90 net/sctp/socket.c:1954 inet_sendmsg+0x498/0x670 net/ipv4/af_inet.c:762 sock_sendmsg_nosec net/socket.c:633 sock_sendmsg net/socket.c:643 SYSC_sendto+0x608/0x710 net/socket.c:1696 SyS_sendto+0x8a/0xb0 net/socket.c:1664 do_syscall_64+0xe6/0x130 arch/x86/entry/common.c:285 return_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.S:246 ================================================================== Signed-off-by:Alexander Potapenko <glider@google.com> Signed-off-by:
-
Vasily Averin authored
Some time ago David Woodhouse reported skb_under_panic when we try to push ethernet header to fragmented ipv6 skbs. It was fixed for ipv6 by Florian Westphal in commit 1d325d21 ("ipv6: ip6_fragment: fix headroom tests and skb leak") However similar problem still exist in ipv4. It does not trigger skb_under_panic due paranoid check in ip_finish_output2, however according to Alexey Kuznetsov current state is abnormal and ip_fragment should be fixed too. Signed-off-by:
Vasily Averin <vvs@virtuozzo.com> Signed-off-by:
-
Zhu Yanjun authored
The function __mlx4_zone_remove_one_entry always returns zero. So it is not necessary to check it. Cc: Joe Jin <joe.jin@oracle.com> Cc: Junxiao Bi <junxiao.bi@oracle.com> Signed-off-by:
Zhu Yanjun <yanjun.zhu@oracle.com> Reviewed-by:
Yuval Shaia <yuval.shaia@oracle.com> Signed-off-by:
-
Jason A. Donenfeld authored
Computing the alignment manually for going from priv to pub is probably not such a good idea, and in general the assumption that going from priv to pub is possible trivially could change, so rather than relying on that, we change things to just store a pointer to pub. This was sugested by DaveM in [1]. [1] http://www.spinics.net/lists/netdev/msg443992.htmlSigned-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
-
David S. Miller authored
Abhishek Shah says: ==================== Extend BGMAC driver for Stingray SoC The patchset extends Broadcom BGMAC driver for Broadcom Stingray SoC. This patchset is based on Linux-4.12 and tested on NS2 and Stingray. ==================== Signed-off-by: -
Abhishek Shah authored
Specifying IDM register space in DT is not mendatory for SoCs where firmware takes care of IDM operations. This patch updates BGMAC driver's DT binding documentation indicating the same. Signed-off-by:
Abhishek Shah <abhishek.shah@broadcom.com> Reviewed-by:
Ray Jui <ray.jui@broadcom.com> Reviewed-by:
Oza Oza <oza.oza@broadcom.com> Reviewed-by:
Scott Branden <scott.branden@broadcom.com> Signed-off-by:
-
Abhishek Shah authored
IDM operations are usually one time ops and should be done in firmware itself. Driver is not supposed to touch IDM registers. However, for some SoCs', driver is performing IDM read/writes. So this patch masks IDM operations in case firmware is taking care of IDM operations. Signed-off-by:
-
Abhishek Shah authored
Return type for idm register write callback should be void as 'writel' API is used for write operation. However, there no need to have 'return' in this function. Signed-off-by:
-
- 14 Jul, 2017 17 commits
-
-
Xin Long authored
Marcelo noticed an array overflow caused by commit c28445c3 ("sctp: add reconf_enable in asoc ep and netns"), in which sctp would add SCTP_CID_RECONF into extensions when reconf_enable is set in sctp_make_init and sctp_make_init_ack. Then now when all ext chunks are set, 4 ext chunk ids can be put into extensions array while extensions array size is 3. It would cause a kernel panic because of this overflow. This patch is to fix it by defining extensions array size is 4 in both sctp_make_init and sctp_make_init_ack. Fixes: c28445c3 ("sctp: add reconf_enable in asoc ep and netns") Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
-
Arnd Bergmann authored
gcc reports that the temporary buffer for computing the string length may be too small here: drivers/net/ethernet/cavium/liquidio/lio_ethtool.c: In function 'lio_get_eeprom_len': /drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:345:21: error: 'sprintf' may write a terminating nul past the end of the destination [-Werror=format-overflow=] len = sprintf(buf, "boardname:%s serialnum:%s maj:%lld min:%lld\n", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:345:6: note: 'sprintf' output between 35 and 167 bytes into a destination of size 128 len = sprintf(buf, "boardname:%s serialnum:%s maj:%lld min:%lld\n", This extends it to 192 bytes, which is certainly enough. As far as I could tell, there are no other constraints that require a specific maximum size. Signed-off-by:Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
gcc-7 notices that "-event-%d" could be more than 11 characters long if we had larger 'vector' numbers: drivers/net/vmxnet3/vmxnet3_drv.c: In function 'vmxnet3_activate_dev': drivers/net/vmxnet3/vmxnet3_drv.c:2095:40: error: 'sprintf' may write a terminating nul past the end of the destination [-Werror=format-overflow=] sprintf(intr->event_msi_vector_name, "%s-event-%d", ^~~~~~~~~~~~~ drivers/net/vmxnet3/vmxnet3_drv.c:2095:3: note: 'sprintf' output between 9 and 33 bytes into a destination of size 32 The current code is safe, but making the string a little longer is harmless and lets gcc see that it's ok. Signed-off-by: -
Arnd Bergmann authored
gcc warns that the temporary buffer might be too small here: drivers/net/ethernet/cavium/thunder/thunder_bgx.c: In function 'bgx_probe': drivers/net/ethernet/cavium/thunder/thunder_bgx.c:1020:16: error: '%d' directive writing between 1 and 10 bytes into a region of size between 9 and 11 [-Werror=format-overflow=] sprintf(str, "BGX%d LMAC%d mode", bgx->bgx_id, lmacid); ^~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/cavium/thunder/thunder_bgx.c:1020:16: note: directive argument in the range [0, 2147483647] drivers/net/ethernet/cavium/thunder/thunder_bgx.c:1020:3: note: 'sprintf' output between 16 and 27 bytes into a destination of size 20 This probably can't happen, but it can't hurt to make it long enough for the theoretical limit. Signed-off-by: -
Arnd Bergmann authored
gcc notices that large queue numbers would overflow the queue name string: drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c: In function 'bnx2x_get_strings': drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c:3165:25: error: '%d' directive writing between 1 and 10 bytes into a region of size 5 [-Werror=format-overflow=] drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c:3165:25: note: directive argument in the range [0, 2147483647] drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c:3165:5: note: 'sprintf' output between 2 and 11 bytes into a destination of size 5 There is a hard limit in place that makes the number at most two digits, so the code is fine. This changes it to use snprintf() to truncate instead of overflowing, which shuts up that warning. Signed-off-by:
-
Arnd Bergmann authored
We get a warning for the port_name string that might be longer than six characters if we had more than 10 ports: drivers/net/ethernet/sun/niu.c: In function 'niu_put_parent': drivers/net/ethernet/sun/niu.c:9563:21: error: '%d' directive writing between 1 and 3 bytes into a region of size 2 [-Werror=format-overflow=] sprintf(port_name, "port%d", port); ^~~~~~~~ drivers/net/ethernet/sun/niu.c:9563:21: note: directive argument in the range [0, 255] drivers/net/ethernet/sun/niu.c:9563:2: note: 'sprintf' output between 6 and 8 bytes into a destination of size 6 sprintf(port_name, "port%d", port); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/sun/niu.c: In function 'niu_pci_init_one': drivers/net/ethernet/sun/niu.c:9538:22: error: '%d' directive writing between 1 and 3 bytes into a region of size 2 [-Werror=format-overflow=] sprintf(port_name, "port%d", port); ^~~~~~~~ drivers/net/ethernet/sun/niu.c:9538:22: note: directive argument in the range [0, 255] drivers/net/ethernet/sun/niu.c:9538:3: note: 'sprintf' output between 6 and 8 bytes into a destination of size 6 While we know that the port number is small, there is no harm in making the format string two bytes longer to avoid the warning. Signed-off-by: -
Arnd Bergmann authored
One string we pass into the cs->info buffer might be too long, as pointed out by gcc: drivers/isdn/divert/isdn_divert.c: In function 'll_callback': drivers/isdn/divert/isdn_divert.c:488:22: error: '%d' directive writing between 1 and 3 bytes into a region of size between 1 and 69 [-Werror=format-overflow=] sprintf(cs->info, "%d 0x%lx %s %s %s %s 0x%x 0x%x %d %d %s\n", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/isdn/divert/isdn_divert.c:488:22: note: directive argument in the range [0, 255] drivers/isdn/divert/isdn_divert.c:488:4: note: 'sprintf' output 25 or more bytes (assuming 129) into a destination of size 90 This is unlikely to actually cause problems, so let's use snprintf as a simple workaround to shut up the warning and truncate the buffer instead. Signed-off-by: -
Timur Tabi authored
If the interface is not up, then don't try to close it during a shutdown. This avoids possible double free of the IRQ, which can happen during a shutdown. Fixes: 03eb3eb4 ("net: qcom/emac: add shutdown function") Signed-off-by:
Timur Tabi <timur@codeaurora.org> Signed-off-by:
-
Petr Kulhavy authored
This change enables the use of SW timestamping on Raspberry PI. smsc95xx uses the usbnet transmit function usbnet_start_xmit(), which implements software timestamping. However the SOF_TIMESTAMPING_TX_SOFTWARE capability was missing and only SOF_TIMESTAMPING_RX_SOFTWARE was announced. By using ethtool_op_get_ts_info() as get_ts_info() also the SOF_TIMESTAMPING_TX_SOFTWARE is announced. Signed-off-by:
Petr Kulhavy <brain@jikos.cz> Reviewed-by:
Woojung Huh <Woojung.Huh@microchip.com> Signed-off-by:
-
Roman Mashak authored
Make name consistent with other TC event notification routines, such as tcf_add_notify() and tcf_del_notify() Signed-off-by:
Roman Mashak <mrv@mojatatu.com> Signed-off-by:
-
Iván Briano authored
When PACKET_QDISC_BYPASS is not used, Tx queue selection will be done before the packet is enqueued, taking into account any mappings set by a queuing discipline such as mqprio without hardware offloading. This selection may be affected by a previously saved queue_mapping, either on the Rx path, or done before the packet reaches the device, as it's currently the case for AF_PACKET. In order for queue selection to work as expected when using traffic control, there can't be another selection done before that point is reached, so move the call to packet_pick_tx_queue to packet_direct_xmit, leaving the default xmit path as it was before PACKET_QDISC_BYPASS was introduced. A forward declaration of packet_pick_tx_queue() is introduced to avoid the need to reorder the functions within the file. Fixes: d346a3fa ("packet: introduce PACKET_QDISC_BYPASS socket option") Signed-off-by:
Iván Briano <ivan.briano@intel.com> Signed-off-by:
-
Nikolay Aleksandrov authored
With 802.1ad support the vlan_ingress code started checking for vlan protocol mismatch which causes the current tag to be inserted and the bridge vlan protocol & pvid to be set. The vlan tag insertion changes the skb mac_header and thus the lookup mac dest pointer which was loaded prior to calling br_allowed_ingress in br_handle_frame_finish is VLAN_HLEN bytes off now, pointing to the last two bytes of the destination mac and the first four of the source mac causing lookups to always fail and broadcasting all such packets to all ports. Same thing happens for locally originated packets when passing via br_dev_xmit. So load the dest pointer after the vlan checks and possible skb change. Fixes: 8580e211 ("bridge: Prepare for 802.1ad vlan filtering support") Reported-by:
Anitha Narasimha Murthy <anitha@cumulusnetworks.com> Signed-off-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Acked-by:
Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> Signed-off-by:
-
Ganesh Goudar authored
Check ptp_clock_register() return not only for NULL but also for error pointers, and also nullify adapter->ptp_clock if ptp_clock_register() fails. Fixes: 9c33e420 ("cxgb4: Add PTP Hardware Clock (PHC) support") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Richard Cochran <richardcochran@gmail.com> Signed-off-by:
Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by:
-
LiuJian authored
The current code only support DT method to control xge led. This patch is the implementation of acpi method to control xge led. Signed-off-by:
LiuJian <liujian56@huawei.com> Reviewed-by:
John Garry <john.garry@huawei.com> Reviewed-by:
Yunsheng Lin <linyunsheng@huawei.com> Reviewed-by:
Daode Huang <huangdaode@hisilicon.com> Signed-off-by:
-
WANG Cong authored
When we convert atomic_t to refcount_t, a new kernel warning on "increment on 0" is introduced in the netpoll code, zap_completion_queue(). In fact for this special case, we know the refcount is 0 and we just have to set it to 1 to satisfy the following dev_kfree_skb_any(), so we can just use refcount_set(..., 1) instead. Fixes: 63354797 ("net: convert sk_buff.users from atomic_t to refcount_t") Reported-by:
Dave Jones <davej@codemonkey.org.uk> Cc: Reshetova, Elena <elena.reshetova@intel.com> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
Enrico Mioso authored
Some firmwares in Huawei E3372H devices have been observed to switch back to NTB 32-bit format after altsetting switch. This patch implements a driver flag to check for the device settings and set NTB format to 16-bit again if needed. The flag has been activated for devices controlled by the huawei_cdc_ncm.c driver. V1->V2: - fixed broken error checks - some corrections to the commit message V2->V3: - variable name changes, to clarify what's happening - check (and possibly set) the NTB format later in the common bind code path Signed-off-by:
Enrico Mioso <mrkiko.rs@gmail.com> Reported-and-tested-by:
Christian Panton <christian@panton.org> Reviewed-by:
Bjørn Mork <bjorn@mork.no> CC: Bjørn Mork <bjorn@mork.no> CC: Christian Panton <christian@panton.org> CC: linux-usb@vger.kernel.org CC: netdev@vger.kernel.org CC: Oliver Neukum <oliver@neukum.org> Signed-off-by:
-
Martin Blumenstingl authored
mdio_mux_init parses the child nodes of the MDIO mux. When using "mdio-mux-mmioreg" the child nodes are describing the register value that is written to switch between the MDIO busses. The change which makes the error messages more verbose changed the parsing of the "reg" property from a simple of_property_read_u32 call to of_mdio_parse_addr. On a Khadas VIM (based on the Meson GXL SoC, which uses mdio-mux-mmioreg) this prevents registering the MDIO mux (because the "reg" values on the MDIO mux child nodes are 0x2009087f and 0xe40908ff) and leads to the following errors: mdio-mux-mmioreg c883455c.eth-phy-mux: /soc/periphs@c8834000/eth-phy-mux/mdio@e40908ff PHY address -469169921 is too large mdio-mux-mmioreg c883455c.eth-phy-mux: Error: Failed to find reg for child /soc/periphs@c8834000/eth-phy-mux/mdio@e40908ff mdio-mux-mmioreg c883455c.eth-phy-mux: /soc/periphs@c8834000/eth-phy-mux/mdio@2009087f PHY address 537462911 is too large mdio-mux-mmioreg c883455c.eth-phy-mux: Error: Failed to find reg for child /soc/periphs@c8834000/eth-phy-mux/mdio@2009087f mdio-mux-mmioreg c883455c.eth-phy-mux: Error: No acceptable child buses found mdio-mux-mmioreg c883455c.eth-phy-mux: failed to register mdio-mux bus /soc/periphs@c8834000/eth-phy-mux (as a result of that ethernet is not working, because the PHY which is connected through the mux' child MDIO bus, which is not being registered). Fix this by reverting the change from of_mdio_parse_addr to of_mdio_parse_addr. Fixes: 342fa196 ("mdio: mux: make child bus walking more permissive and errors more verbose") Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
- 13 Jul, 2017 2 commits
-
-
David Ahern authored
The configure callback of fib_rules_ops can change the refcnt of a fib rule. For instance, mlxsw takes a refcnt when adding the processing of the rule to a work queue. Thus the rule refcnt can not be reset to to 1 afterwards. Move the refcnt setting to after the allocation. Fixes: 5361e209 ("net: avoid one splat in fib_nl_delrule()") Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
Rolf Eike Beer authored
Signed-off-by:
Rolf Eike Beer <eb@emlix.com> Signed-off-by:
-
