1. 22 Jun, 2016 2 commits
    • Ido Schimmel's avatar
      team: Fix possible deadlock during team enslave · 942f64c4
      Ido Schimmel authored
      Both dev_uc_sync_multiple() and dev_mc_sync_multiple() require the
      source device to be locked by netif_addr_lock_bh(), but this is missing
      in team's enslave function, so add it.
      
      This fixes the following lockdep warning:
      
      Possible interrupt unsafe locking scenario:
      
              CPU0                    CPU1
              ----                    ----
         lock(_xmit_ETHER/1);
                                      local_irq_disable();
                                      lock(&(&mc->mca_lock)->rlock);
                                      lock(&team_netdev_addr_lock_key);
         <Interrupt>
           lock(&(&mc->mca_lock)->rlock);
      
        *** DEADLOCK ***
      
      Fixes: cb41c997 ("team: team should sync the port's uc/mc addrs when add a port")
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      942f64c4
    • David S. Miller's avatar
      Merge tag 'linux-can-fixes-for-4.7-20160620' of... · 6b65ca06
      David S. Miller authored
      Merge tag 'linux-can-fixes-for-4.7-20160620' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
      
      Marc Kleine-Budde says:
      
      ====================
      pull-request: can 2016-06-20
      
      this is a pull request of 3 patches for the upcoming linux-4.7 release.
      
      The first patch is by Thor Thayer for the c_can/d_can driver. It fixes the
      registar access on Altera Cyclone devices, which caused CAN frames to have 0x0
      in the first two bytes incorrectly. Wolfgang Grandegger's patch for the at91
      driver fixes a hanging driver under high bus load situations. A patch for the
      gs_usb driver by Maximilian Schneider adds support for the bytewerk.org
      candleLight interface.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6b65ca06
  2. 20 Jun, 2016 3 commits
  3. 19 Jun, 2016 8 commits
  4. 18 Jun, 2016 7 commits
  5. 17 Jun, 2016 4 commits
  6. 16 Jun, 2016 14 commits
    • Alexander Duyck's avatar
      mlx4e: Do not attempt to offload VXLAN ports that are unrecognized · a547224d
      Alexander Duyck authored
      The mlx4e driver does not support more than one port for VXLAN offload.  As
      such expecting the hardware to offload other ports is invalid since it
      appears the parsing logic is used to perform Tx checksum and segmentation
      offloads.  Use the vxlan_port number to determine in which cases we can
      apply the offload and in which cases we can not.
      Signed-off-by: default avatarAlexander Duyck <aduyck@mirantis.com>
      Reviewed-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a547224d
    • Arnd Bergmann's avatar
      net: sfc: avoid -Wtype-limits warning · 17471c7b
      Arnd Bergmann authored
      When building with -Wextra, we get a harmless warning from the
      EFX_EXTRACT_OWORD32 macro:
      
      ethernet/sfc/farch.c: In function 'efx_farch_test_registers':
      ethernet/sfc/farch.c:119:30: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
      ethernet/sfc/farch.c:124:144: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
      ethernet/sfc/farch.c:124:392: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
      ethernet/sfc/farch.c:124:731: error: comparison of unsigned expression < 0 is always false [-Werror=type-limits]
      
      The macro and the caller are both correct, but we can avoid the
      warning by changing the index variable to a signed type.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarBert Kenward <bkenward@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      17471c7b
    • David S. Miller's avatar
      Merge branch 'r8152-fixes' · 13eab83f
      David S. Miller authored
      Hayes Wang says:
      
      ====================
      r8152: fix known issues
      
      These patches fix some known issues.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      13eab83f
    • hayeswang's avatar
      r8152: correct the rx early size · a59e6d81
      hayeswang authored
      The rx early size should be
      
      	(agg_buf_sz - packet size) / 8
      Signed-off-by: default avatarHayes Wang <hayeswang@realtek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a59e6d81
    • hayeswang's avatar
      r8152: reset the bmu · 93fe9b18
      hayeswang authored
      Reset the BMU to clear the rx/tx fifo. This avoids that the unexpected
      data remains in the hw.
      Signed-off-by: default avatarHayes Wang <hayeswang@realtek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      93fe9b18
    • hayeswang's avatar
      r8152: disable MAC clock speed down · 4e384ac1
      hayeswang authored
      Disable MAC clock speed down. It may casue the first control
      transfer to contain the wrong data, when the power state change
      from U1 to U0.
      Signed-off-by: default avatarHayes Wang <hayeswang@realtek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4e384ac1
    • David S. Miller's avatar
      Merge branch 'bpf-fixes' · 8c08c732
      David S. Miller authored
      Alexei Starovoitov says:
      
      ====================
      bpf fixes
      
      Fixes for two bpf bugs:
      1st bug reported by Sasha Goldshtein here:
      https://github.com/iovisor/bcc/issues/570
      2nd discovered by Daniel Borkmann by manual code analysis.
      See patches for details.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8c08c732
    • Alexei Starovoitov's avatar
      bpf, trace: check event type in bpf_perf_event_read · ad572d17
      Alexei Starovoitov authored
      similar to bpf_perf_event_output() the bpf_perf_event_read() helper
      needs to check the type of the perf_event before reading the counter.
      
      Fixes: a43eec30 ("bpf: introduce bpf_perf_event_output() helper")
      Reported-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ad572d17
    • Alexei Starovoitov's avatar
      bpf: fix matching of data/data_end in verifier · 19de99f7
      Alexei Starovoitov authored
      The ctx structure passed into bpf programs is different depending on bpf
      program type. The verifier incorrectly marked ctx->data and ctx->data_end
      access based on ctx offset only. That caused loads in tracing programs
      int bpf_prog(struct pt_regs *ctx) { .. ctx->ax .. }
      to be incorrectly marked as PTR_TO_PACKET which later caused verifier
      to reject the program that was actually valid in tracing context.
      Fix this by doing program type specific matching of ctx offsets.
      
      Fixes: 969bf05e ("bpf: direct packet access")
      Reported-by: default avatarSasha Goldshtein <goldshtn@gmail.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      19de99f7
    • Eric Dumazet's avatar
      gre: fix error handler · e582615a
      Eric Dumazet authored
      1) gre_parse_header() can be called from gre_err()
      
         At this point transport header points to ICMP header, not the inner
      header.
      
      2) We can not really change transport header as ipgre_err() will later
      assume transport header still points to ICMP header (using icmp_hdr())
      
      3) pskb_may_pull() logic in gre_parse_header() really works
        if we are interested at zone pointed by skb->data
      
      4) As Jiri explained in commit b7f8fe25 ("gre: do not pull header in
      ICMP error processing") we should not pull headers in error handler.
      
      So this fix :
      
      A) changes gre_parse_header() to use skb->data instead of
      skb_transport_header()
      
      B) Adds a nhs parameter to gre_parse_header() so that we can skip the
      not pulled IP header from error path.
        This offset is 0 for normal receive path.
      
      C) remove obsolete IPV6 includes
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Tom Herbert <tom@herbertland.com>
      Cc: Maciej Żenczykowski <maze@google.com>
      Cc: Jiri Benc <jbenc@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e582615a
    • Jason A. Donenfeld's avatar
      net: Don't forget pr_fmt on net_dbg_ratelimited for CONFIG_DYNAMIC_DEBUG · daddef76
      Jason A. Donenfeld authored
      The implementation of net_dbg_ratelimited in the CONFIG_DYNAMIC_DEBUG
      case was added with 2c94b537 ("net: Implement net_dbg_ratelimited() for
      CONFIG_DYNAMIC_DEBUG case"). The implementation strategy was to take the
      usual definition of the dynamic_pr_debug macro, but alter it by adding a
      call to "net_ratelimit()" in the if statement. This is, in fact, the
      correct approach.
      
      However, while doing this, the author of the commit forgot to surround
      fmt by pr_fmt, resulting in unprefixed log messages appearing in the
      console. So, this commit adds back the pr_fmt(fmt) invocation, making
      net_dbg_ratelimited properly consistent across DEBUG, no DEBUG, and
      DYNAMIC_DEBUG cases, and bringing parity with the behavior of
      dynamic_pr_debug as well.
      
      Fixes: 2c94b537 ("net: Implement net_dbg_ratelimited() for CONFIG_DYNAMIC_DEBUG case")
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Cc: Tim Bingham <tbingham@akamai.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      daddef76
    • Arnd Bergmann's avatar
      net: skfb: remove obsolete -I cflag · 4a183670
      Arnd Bergmann authored
      The skfp driver has been moved to drivers/net/fddi/skfp a long time
      ago, but we still attempt to include headers from the old location,
      which causes a warning when building with W=1:
      
      cc1: error: /git/arm-soc/drivers/net/skfp: No such file or directory [-Werror=missing-include-dirs]
      cc1: error: drivers/net/skfp: No such file or directory [-Werror=missing-include-dirs]
      
      Clearly this include directive is not needed any more, so we can
      just remove it now.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4a183670
    • Ying Xue's avatar
      tipc: eliminate uninitialized variable warning · c91522f8
      Ying Xue authored
      net/tipc/link.c: In function ‘tipc_link_timeout’:
      net/tipc/link.c:744:28: warning: ‘mtyp’ may be used uninitialized in this function [-Wuninitialized]
      
      Fixes: 42b18f60 ("tipc: refactor function tipc_link_timeout()")
      Acked-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c91522f8
    • Ying Xue's avatar
      tipc: fix suspicious RCU usage · 66d95b67
      Ying Xue authored
      When run tipcTS&tipcTC test suite, the following complaint appears:
      
      [   56.926168] ===============================
      [   56.926169] [ INFO: suspicious RCU usage. ]
      [   56.926171] 4.7.0-rc1+ #160 Not tainted
      [   56.926173] -------------------------------
      [   56.926174] net/tipc/bearer.c:408 suspicious rcu_dereference_protected() usage!
      [   56.926175]
      [   56.926175] other info that might help us debug this:
      [   56.926175]
      [   56.926177]
      [   56.926177] rcu_scheduler_active = 1, debug_locks = 1
      [   56.926179] 3 locks held by swapper/4/0:
      [   56.926180]  #0:  (((&req->timer))){+.-...}, at: [<ffffffff810e79b5>] call_timer_fn+0x5/0x340
      [   56.926203]  #1:  (&(&req->lock)->rlock){+.-...}, at: [<ffffffffa000c29b>] disc_timeout+0x1b/0xd0 [tipc]
      [   56.926212]  #2:  (rcu_read_lock){......}, at: [<ffffffffa00055e0>] tipc_bearer_xmit_skb+0xb0/0x2e0 [tipc]
      [   56.926218]
      [   56.926218] stack backtrace:
      [   56.926221] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 4.7.0-rc1+ #160
      [   56.926222] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      [   56.926224]  0000000000000000 ffff880016803d28 ffffffff813c4423 ffff8800154252c0
      [   56.926227]  0000000000000001 ffff880016803d58 ffffffff810b7512 ffff8800124d8120
      [   56.926230]  ffff880013f8a160 ffff8800132b5ccc ffff8800124d8120 ffff880016803d88
      [   56.926234] Call Trace:
      [   56.926235]  <IRQ>  [<ffffffff813c4423>] dump_stack+0x67/0x94
      [   56.926250]  [<ffffffff810b7512>] lockdep_rcu_suspicious+0xe2/0x120
      [   56.926256]  [<ffffffffa00051f1>] tipc_l2_send_msg+0x131/0x1c0 [tipc]
      [   56.926261]  [<ffffffffa000567c>] tipc_bearer_xmit_skb+0x14c/0x2e0 [tipc]
      [   56.926266]  [<ffffffffa00055e0>] ? tipc_bearer_xmit_skb+0xb0/0x2e0 [tipc]
      [   56.926273]  [<ffffffffa000c280>] ? tipc_disc_init_msg+0x1f0/0x1f0 [tipc]
      [   56.926278]  [<ffffffffa000c280>] ? tipc_disc_init_msg+0x1f0/0x1f0 [tipc]
      [   56.926283]  [<ffffffffa000c2d6>] disc_timeout+0x56/0xd0 [tipc]
      [   56.926288]  [<ffffffff810e7a68>] call_timer_fn+0xb8/0x340
      [   56.926291]  [<ffffffff810e79b5>] ? call_timer_fn+0x5/0x340
      [   56.926296]  [<ffffffffa000c280>] ? tipc_disc_init_msg+0x1f0/0x1f0 [tipc]
      [   56.926300]  [<ffffffff810e8f4a>] run_timer_softirq+0x23a/0x390
      [   56.926306]  [<ffffffff810f89ff>] ? clockevents_program_event+0x7f/0x130
      [   56.926316]  [<ffffffff819727c3>] __do_softirq+0xc3/0x4a2
      [   56.926323]  [<ffffffff8106ba5a>] irq_exit+0x8a/0xb0
      [   56.926327]  [<ffffffff81972456>] smp_apic_timer_interrupt+0x46/0x60
      [   56.926331]  [<ffffffff81970a49>] apic_timer_interrupt+0x89/0x90
      [   56.926333]  <EOI>  [<ffffffff81027fda>] ? default_idle+0x2a/0x1a0
      [   56.926340]  [<ffffffff81027fd8>] ? default_idle+0x28/0x1a0
      [   56.926342]  [<ffffffff810289cf>] arch_cpu_idle+0xf/0x20
      [   56.926345]  [<ffffffff810adf0f>] default_idle_call+0x2f/0x50
      [   56.926347]  [<ffffffff810ae145>] cpu_startup_entry+0x215/0x3e0
      [   56.926353]  [<ffffffff81040ad9>] start_secondary+0xf9/0x100
      
      The warning appears as rtnl_dereference() is wrongly used in
      tipc_l2_send_msg() under RCU read lock protection. Instead the proper
      usage should be that rcu_dereference_rtnl() is called here.
      
      Fixes: 5b7066c3 ("tipc: stricter filtering of packets in bearer layer")
      Acked-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      66d95b67
  7. 15 Jun, 2016 2 commits