1. 08 6月, 2016 15 次提交
  2. 07 6月, 2016 3 次提交
  3. 06 6月, 2016 1 次提交
    • M
      bnx2x: allow adding VLANs while interface is down · a02cc9d3
      Michal Schmidt 提交于
      Since implementing VLAN filtering in commit 05cc5a39
      ("bnx2x: add vlan filtering offload") bnx2x refuses to add a VLAN while
      the interface is down:
      
        # ip link add link enp3s0f0 enp3s0f0_10 type vlan id 10
        RTNETLINK answers: Bad address
      
      and in dmesg (with bnx2x.debug=0x20):
        bnx2x: [bnx2x_vlan_rx_add_vid:12941(enp3s0f0)]Ignoring VLAN
        configuration the interface is down
      
      Other drivers have no problem with this.
      Fix this peculiar behavior in the following way:
       - Accept requests to add/kill VID regardless of the device state.
         Maintain the requested list of VIDs in the bp->vlan_reg list.
       - If the device is up, try to configure the VID list into the hardware.
         If we run out of VLAN credits or encounter a failure configuring an
         entry, fall back to accepting all VLANs.
         If we successfully configure all entries from the list, turn the
         fallback off.
       - Use the same code for reconfiguring VLANs during NIC load.
      Signed-off-by: NMichal Schmidt <mschmidt@redhat.com>
      Acked-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a02cc9d3
  4. 05 6月, 2016 1 次提交
  5. 04 6月, 2016 13 次提交
  6. 03 6月, 2016 5 次提交
    • F
      brcmfmac: add eth_type_trans back for PCIe full dongle · 31143e29
      Franky Lin 提交于
      A regression was introduced in commit 9c349892 ("brcmfmac: revise
      handling events in receive path") which moves eth_type_trans() call
      to brcmf_rx_frame(). Msgbuf layer doesn't use brcmf_rx_frame() but invokes
      brcmf_netif_rx() directly. In such case the Ethernet header was not
      stripped out resulting in null pointer dereference in the networking
      stack.
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000048
      IP: [<ffffffff814c3ce6>] enqueue_to_backlog+0x56/0x260
      PGD 0
      Oops: 0000 [#1] PREEMPT SMP
      Modules linked in: fuse ipt_MASQUERADE nf_nat_masquerade_ipv4
      iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype
      [...]
      rtsx_pci scsi_mod usbcore usb_common i8042 serio nvme nvme_core
      CPU: 7 PID: 1340 Comm: irq/136-brcmf_p Not tainted 4.7.0-rc1-mainline #1
      Hardware name: Dell Inc. XPS 15 9550/0N7TVV, BIOS 01.02.00 04/07/2016
      task: ffff8804a0c5bd00 ti: ffff88049e124000 task.ti: ffff88049e124000
      RIP: 0010:[<ffffffff814c3ce6>] [<ffffffff814c3ce6>]
      enqueue_to_backlog+0x56/0x260
      RSP: 0018:ffff88049e127ca0 EFLAGS: 00010046
      RAX: 0000000000000000 RBX: ffff8804bddd7c40 RCX: 000000000000002f
      RDX: 0000000000000000 RSI: 0000000000000007 RDI: ffff8804bddd7d4c
      RBP: ffff88049e127ce8 R08: 0000000000000000 R09: 0000000000000000
      R10: ffff8804bddd12c0 R11: 000000000000149e R12: 0000000000017c40
      R13: ffff88049e127d08 R14: ffff8804a9bd6d00 R15: ffff8804bddd7d4c
      FS: 0000000000000000(0000) GS:ffff8804bddc0000(0000) knlGS:0000000000000000
      CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000048 CR3: 0000000001806000 CR4: 00000000003406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Stack:
      ffff8804bdddad00 ffff8804ad089e00 0000000000000000 0000000000000282
      0000000000000000 ffff8804a9bd6d00 ffff8804a1b27e00 ffff8804a9bd6d00
      ffff88002ee88000 ffff88049e127d28 ffffffff814c3f3b ffffffff81311fc3
      Call Trace:
      [<ffffffff814c3f3b>] netif_rx_internal+0x4b/0x170
      [<ffffffff81311fc3>] ? swiotlb_tbl_unmap_single+0xf3/0x120
      [<ffffffff814c5467>] netif_rx_ni+0x27/0xc0
      [<ffffffffa08519e9>] brcmf_netif_rx+0x49/0x70 [brcmfmac]
      [<ffffffffa08564d4>] brcmf_msgbuf_process_rx+0x2b4/0x570 [brcmfmac]
      [<ffffffff81020017>] ? __xen_set_pgd_hyper+0x57/0xd0
      [<ffffffff810d60b0>] ? irq_forced_thread_fn+0x70/0x70
      [<ffffffffa0857381>] brcmf_proto_msgbuf_rx_trigger+0x31/0xe0 [brcmfmac]
      [<ffffffffa0861e8f>] brcmf_pcie_isr_thread+0x7f/0x110 [brcmfmac]
      [<ffffffff810d60d0>] irq_thread_fn+0x20/0x50
      [<ffffffff810d63ad>] irq_thread+0x12d/0x1c0
      [<ffffffff815d07d5>] ? __schedule+0x2f5/0x7a0
      [<ffffffff810d61d0>] ? wake_threads_waitq+0x30/0x30
      [<ffffffff810d6280>] ? irq_thread_dtor+0xb0/0xb0
      [<ffffffff81098ea8>] kthread+0xd8/0xf0
      [<ffffffff815d4b7f>] ret_from_fork+0x1f/0x40
      [<ffffffff81098dd0>] ? kthread_worker_fn+0x170/0x170
      Code: 1c f5 60 9a 8e 81 9c 58 0f 1f 44 00 00 48 89 45 d0 fa 66 0f 1f
      44 00 00 4c 8d bb 0c 01 00 00 4c 89 ff e8 5e 08 11 00 49 8b 56 20 <48>
      8b 52 48 83 e2 01 74 10 8b 8b 08 01 00 00 8b 15 59 c5 42 00
      RIP [<ffffffff814c3ce6>] enqueue_to_backlog+0x56/0x260
      RSP <ffff88049e127ca0>
      CR2: 0000000000000048
      
      Fixes: 9c349892 ("brcmfmac: revise handling events in receive path")
      Reported-by: NRafal Milecki <zajec5@gmail.com>
      Reported-by: NGrey Christoforo <grey@christoforo.net>
      Reviewed-by: NPieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
      Reviewed-by: NArend Van Spriel <arend@broadcom.com>
      Reviewed-by: NHante Meuleman <hante.meuleman@broadcom.com>
      Signed-off-by: NFranky Lin <franky.lin@broadcom.com>
      [arend@broadcom.com: rephrased the commit message]
      Signed-off-by: NArend van Spriel <arend@broadcom.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      31143e29
    • K
      rds: fix an infoleak in rds_inc_info_copy · 4116def2
      Kangjie Lu 提交于
      The last field "flags" of object "minfo" is not initialized.
      Copying this object out may leak kernel stack data.
      Assign 0 to it to avoid leak.
      Signed-off-by: NKangjie Lu <kjlu@gatech.edu>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4116def2
    • K
      tipc: fix an infoleak in tipc_nl_compat_link_dump · 5d2be142
      Kangjie Lu 提交于
      link_info.str is a char array of size 60. Memory after the NULL
      byte is not initialized. Sending the whole object out can cause
      a leak.
      Signed-off-by: NKangjie Lu <kjlu@gatech.edu>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5d2be142
    • E
      Possible problem with e6afc8ac ("udp: remove headers from UDP packets before queueing") · ce25d66a
      Eric Dumazet 提交于
      Paul Moore tracked a regression caused by a recent commit, which
      mistakenly assumed that sk_filter() could be avoided if socket
      had no current BPF filter.
      
      The intent was to avoid udp_lib_checksum_complete() overhead.
      
      But sk_filter() also checks skb_pfmemalloc() and
      security_sock_rcv_skb(), so better call it.
      
      Fixes: e6afc8ac ("udp: remove headers from UDP packets before queueing")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NPaul Moore <paul@paul-moore.com>
      Tested-by: NPaul Moore <paul@paul-moore.com>
      Tested-by: NStephen Smalley <sds@tycho.nsa.gov>
      Cc: samanthakumar <samanthakumar@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ce25d66a
    • V
      stmmac: do not sleep in atomic context for mdio_reset · f55d84b0
      Vincent Palatin 提交于
      stmmac_mdio_reset() has been updated to use msleep rather udelay
      (as some PHY requires a one second delay there).
      It called from stmmac_resume() within the spin_lock_irqsave block
      atomic context triggering 'scheduling while atomic'.
      
      The stmmac_priv lock usage is not fully documented, but it seems
      to protect the access to the MAC registers / DMA structures rather
      than the MDIO bus or the PHY (which have separate locking),
      so we can push the spin_lock after the stmmac_mdio_reset call.
      Signed-off-by: NVincent Palatin <vpalatin@chromium.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f55d84b0
  7. 02 6月, 2016 2 次提交
    • A
      qed: fix qed_fill_link() error handling · 14b84e86
      Arnd Bergmann 提交于
      gcc warns about qed_fill_link possibly accessing uninitialized data:
      
      drivers/net/ethernet/qlogic/qed/qed_main.c: In function 'qed_fill_link':
      drivers/net/ethernet/qlogic/qed/qed_main.c:1170:35: error: 'link_caps' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      While this warning is only about the specific case of CONFIG_QED_SRIOV
      being disabled but the function getting called for a VF (which should
      never happen), another possibility is that qed_mcp_get_*() fails without
      returning data.
      
      This rearranges the code so we bail out in either of the two cases
      and print a warning instead of accessing the uninitialized data.
      
      The qed_link_output structure remains untouched in this case, but
      all callers first call memset() on it, so at least we are not leaking
      stack data then.
      
      As discussed, we also use a compile-time check to ensure we never
      use any of the VF code if CONFIG_QED_SRIOV is disabled, and the
      PCI device table is updated to no longer bind to virtual functions
      in that configuration.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      14b84e86
    • C
      net/ethoc: fix null dereference on error exit path · bfa49cfc
      Colin Ian King 提交于
      priv is assigned to NULL however some of the early error exit paths to
      label 'free' dereference priv, causing a null pointer dereference.
      
      Move the label 'free' to just the free_netdev statement, and add a new
      exit path 'free2' for the error cases were clk_disable_unprepare needs
      calling before the final free.
      
      Fixes issue found by CoverityScan, CID#113260
      Signed-off-by: NColin Ian King <colin.king@canonical.com>
      Reviewed-by: NMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bfa49cfc