1. 16 Jul, 2017 1 commit
    • Arvind Yadav's avatar
      isdn: hisax: constify pci_device_id. · cd7b03e9
      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: default avatarArvind Yadav <arvind.yadav.cs@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cd7b03e9
  2. 15 Jul, 2017 14 commits
    • Neal Cardwell's avatar
      tcp_bbr: init pacing rate on first RTT sample · 32984565
      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: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarSoheil Hassas Yeganeh <soheil@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      32984565
    • Neal Cardwell's avatar
      tcp_bbr: remove sk_pacing_rate=0 transient during init · 1d3648eb
      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: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarSoheil Hassas Yeganeh <soheil@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1d3648eb
    • Neal Cardwell's avatar
      tcp_bbr: introduce bbr_init_pacing_rate_from_rtt() helper · 79135b89
      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: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarSoheil Hassas Yeganeh <soheil@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      79135b89
    • Neal Cardwell's avatar
      tcp_bbr: introduce bbr_bw_to_pacing_rate() helper · f19fd62d
      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: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarSoheil Hassas Yeganeh <soheil@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f19fd62d
    • Neal Cardwell's avatar
      tcp_bbr: cut pacing rate only if filled pipe · 4aea287e
      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: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarSoheil Hassas Yeganeh <soheil@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4aea287e
    • Greg Rose's avatar
      openvswitch: Fix for force/commit action failures · 8b97ac5b
      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: default avatarJoe Stringer <joe@ovn.org>
      Signed-off-by: default avatarGreg Rose <gvrose8192@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8b97ac5b
    • Alexander Potapenko's avatar
      sctp: don't dereference ptr before leaving _sctp_walk_{params, errors}() · b1f5bfc2
      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: default avatarAlexander Potapenko <glider@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b1f5bfc2
    • Vasily Averin's avatar
      ipv4: ip_do_fragment: fix headroom tests · 254d900b
      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: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      254d900b
    • Zhu Yanjun's avatar
      mlx4_en: remove unnecessary returned value check · e36fef66
      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: default avatarZhu Yanjun <yanjun.zhu@oracle.com>
      Reviewed-by: default avatarYuval Shaia <yuval.shaia@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e36fef66
    • Jason A. Donenfeld's avatar
      ioc3-eth: store pointer to net_device for priviate area · dfcc16c9
      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: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dfcc16c9
    • David S. Miller's avatar
      Merge branch 'bgmac-stingray-soc' · 521ea952
      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: default avatarDavid S. Miller <davem@davemloft.net>
      521ea952
    • Abhishek Shah's avatar
      Documentation: devicetree: net: optional idm regs for bgmac · 10d79f7d
      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: default avatarAbhishek Shah <abhishek.shah@broadcom.com>
      Reviewed-by: default avatarRay Jui <ray.jui@broadcom.com>
      Reviewed-by: default avatarOza Oza <oza.oza@broadcom.com>
      Reviewed-by: default avatarScott Branden <scott.branden@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      10d79f7d
    • Abhishek Shah's avatar
      net: ethernet: bgmac: Make IDM register space optional · a163bdb0
      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: default avatarAbhishek Shah <abhishek.shah@broadcom.com>
      Reviewed-by: default avatarOza Oza <oza.oza@broadcom.com>
      Reviewed-by: default avatarRay Jui <ray.jui@broadcom.com>
      Reviewed-by: default avatarScott Branden <scott.branden@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a163bdb0
    • Abhishek Shah's avatar
      net: ethernet: bgmac: Remove unnecessary 'return' from platform_bgmac_idm_write · 83a5c5af
      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: default avatarAbhishek Shah <abhishek.shah@broadcom.com>
      Reviewed-by: default avatarOza Oza <oza.oza@broadcom.com>
      Reviewed-by: default avatarRay Jui <ray.jui@broadcom.com>
      Reviewed-by: default avatarScott Branden <scott.branden@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      83a5c5af
  3. 14 Jul, 2017 17 commits
    • Xin Long's avatar
      sctp: fix an array overflow when all ext chunks are set · 10b3bf54
      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: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      10b3bf54
    • Arnd Bergmann's avatar
      liquidio: fix possible eeprom format string overflow · 56c0da49
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      56c0da49
    • Arnd Bergmann's avatar
      vmxnet3: avoid format strint overflow warning · c7673e4d
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c7673e4d
    • Arnd Bergmann's avatar
      net: thunder_bgx: avoid format string overflow warning · c41626ce
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c41626ce
    • Arnd Bergmann's avatar
      bnx2x: fix format overflow warning · be9cdf1b
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      be9cdf1b
    • Arnd Bergmann's avatar
      net: niu: fix format string overflow warning: · 73066f6c
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      73066f6c
    • Arnd Bergmann's avatar
      isdn: divert: fix sprintf buffer overflow warning · 45e0b4b3
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      45e0b4b3
    • Timur Tabi's avatar
      net: qcom/emac: fix double free of SGMII IRQ during shutdown · c98b0537
      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: default avatarTimur Tabi <timur@codeaurora.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c98b0537
    • Petr Kulhavy's avatar
      smsc95xx: use ethtool_op_get_ts_info() · a8f5cb9e
      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: default avatarPetr Kulhavy <brain@jikos.cz>
      Reviewed-by: default avatarWoojung Huh <Woojung.Huh@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a8f5cb9e
    • Roman Mashak's avatar
      net sched actions: rename act_get_notify() to tcf_get_notify() · c4c4290c
      Roman Mashak authored
      Make name consistent with other TC event notification routines, such as
      tcf_add_notify() and tcf_del_notify()
      Signed-off-by: default avatarRoman Mashak <mrv@mojatatu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c4c4290c
    • Iván Briano's avatar
      net/packet: Fix Tx queue selection for AF_PACKET · ccd4eb49
      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: default avatarIván Briano <ivan.briano@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ccd4eb49
    • Nikolay Aleksandrov's avatar
      net: bridge: fix dest lookup when vlan proto doesn't match · 31a4562d
      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: default avatarAnitha Narasimha Murthy <anitha@cumulusnetworks.com>
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Acked-by: default avatarToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      31a4562d
    • Ganesh Goudar's avatar
      cxgb4: ptp_clock_register() returns error pointers · 40fbbce0
      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: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Signed-off-by: default avatarGanesh Goudar <ganeshgr@chelsio.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      40fbbce0
    • LiuJian's avatar
      net: hns: add acpi function of xge led control · 1e4babee
      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: default avatarLiuJian <liujian56@huawei.com>
      Reviewed-by: default avatarJohn Garry <john.garry@huawei.com>
      Reviewed-by: default avatarYunsheng Lin <linyunsheng@huawei.com>
      Reviewed-by: default avatarDaode Huang <huangdaode@hisilicon.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1e4babee
    • WANG Cong's avatar
      netpoll: shut up a kernel warning on refcount · 230cd127
      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: default avatarDave Jones <davej@codemonkey.org.uk>
      Cc: Reshetova, Elena <elena.reshetova@intel.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      230cd127
    • Enrico Mioso's avatar
      cdc_ncm: Set NTB format again after altsetting switch for Huawei devices · 2b02c20c
      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: default avatarEnrico Mioso <mrkiko.rs@gmail.com>
      Reported-and-tested-by: default avatarChristian Panton <christian@panton.org>
      Reviewed-by: default avatarBjø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: default avatarDavid S. Miller <davem@davemloft.net>
      2b02c20c
    • Martin Blumenstingl's avatar
      mdio: mux: fix parsing mux registers outside of the PHY address range · 457839ed
      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: default avatarMartin Blumenstingl <martin.blumenstingl@googlemail.com>
      Acked-by: default avatarNeil Armstrong <narmstrong@baylibre.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      457839ed
  4. 13 Jul, 2017 8 commits