1. 14 8月, 2016 1 次提交
  2. 13 8月, 2016 2 次提交
  3. 12 8月, 2016 2 次提交
  4. 11 8月, 2016 4 次提交
  5. 10 8月, 2016 13 次提交
    • L
      netfilter: nft_exthdr: Add size check on u8 nft_exthdr attributes · 4da449ae
      Laura Garcia Liebana 提交于
      Fix the direct assignment of offset and length attributes included in
      nft_exthdr structure from u32 data to u8.
      Signed-off-by: NLaura Garcia Liebana <nevola@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      4da449ae
    • T
      bridge: Fix problems around fdb entries pointing to the bridge device · 7bb90c37
      Toshiaki Makita 提交于
      Adding fdb entries pointing to the bridge device uses fdb_insert(),
      which lacks various checks and does not respect added_by_user flag.
      
      As a result, some inconsistent behavior can happen:
      * Adding temporary entries succeeds but results in permanent entries.
      * Same goes for "dynamic" and "use".
      * Changing mac address of the bridge device causes deletion of
        user-added entries.
      * Replacing existing entries looks successful from userspace but actually
        not, regardless of NLM_F_EXCL flag.
      
      Use the same logic as other entries and fix them.
      
      Fixes: 3741873b ("bridge: allow adding of fdb entries pointing to the bridge device")
      Signed-off-by: NToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Acked-by: NRoopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7bb90c37
    • W
      net: phy: micrel: Add specific suspend · 836384d2
      Wenyou Yang 提交于
      Disable all interrupts when suspend, they will be enabled
      when resume. Otherwise, the suspend/resume process will be
      blocked occasionally.
      Signed-off-by: NWenyou Yang <wenyou.yang@atmel.com>
      Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      836384d2
    • S
      dm9000: Fix irq trigger type setup on non-dt platforms · a96d3b75
      Sylwester Nawrocki 提交于
      Commit b5a099c6 "net: ethernet: davicom: fix devicetree irq
      resource" causes an interrupt storm after the ethernet interface
      is activated on S3C24XX platform (ARM non-dt), due to the interrupt
      trigger type not being set properly.
      
      It seems, after adding parsing of IRQ flags in commit 7085a740
      "drivers: platform: parse IRQ flags from resources", there is no path
      for non-dt platforms where irq_set_type callback could be invoked when
      we don't pass the trigger type flags to the request_irq() call.
      
      In case of a board where the regression is seen the interrupt trigger
      type flags are passed through a platform device's resource and it is
      not currently handled properly without passing the irq trigger type
      flags to the request_irq() call.  In case of OF an of_irq_get() call
      within platform_get_irq() function seems to be ensuring required irq_chip
      setup, but there is no equivalent code for non OF/ACPI platforms.
      
      This patch mostly restores irq trigger type setting code which has been
      removed in commit ("net: ethernet: davicom: fix devicetree irq resource").
      
      Fixes: b5a099c6 ("net: ethernet: davicom: fix devicetree irq resource")
      Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
      Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a96d3b75
    • Z
      bonding: fix the typo · 0d039f33
      Zhu Yanjun 提交于
      The message "803.ad" should be "802.3ad".
      Signed-off-by: NZhu Yanjun <zyjzyj2000@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0d039f33
    • G
      drivers: net: cpsw: fix kmemleak false-positive reports for sk buffers · 254a49d5
      Grygorii Strashko 提交于
      Kmemleak reports following false positive memory leaks for each sk
      buffers allocated by CPSW (__netdev_alloc_skb_ip_align()) in
      cpsw_ndo_open() and cpsw_rx_handler():
      
      unreferenced object 0xea915000 (size 2048):
        comm "systemd-network", pid 713, jiffies 4294938323 (age 102.180s)
        hex dump (first 32 bytes):
          00 58 91 ea ff ff ff ff ff ff ff ff ff ff ff ff  .X..............
          ff ff ff ff ff ff fd 0f 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<c0108680>] __kmalloc_track_caller+0x1a4/0x230
          [<c0529eb4>] __alloc_skb+0x68/0x16c
          [<c052c884>] __netdev_alloc_skb+0x40/0x104
          [<bf1ad29c>] cpsw_ndo_open+0x374/0x670 [ti_cpsw]
          [<c053c3d4>] __dev_open+0xb0/0x114
          [<c053c690>] __dev_change_flags+0x9c/0x14c
          [<c053c760>] dev_change_flags+0x20/0x50
          [<c054bdcc>] do_setlink+0x2cc/0x78c
          [<c054c358>] rtnl_setlink+0xcc/0x100
          [<c054b34c>] rtnetlink_rcv_msg+0x184/0x224
          [<c056467c>] netlink_rcv_skb+0xa8/0xc4
          [<c054b1c0>] rtnetlink_rcv+0x2c/0x34
          [<c0564018>] netlink_unicast+0x16c/0x1f8
          [<c0564498>] netlink_sendmsg+0x334/0x348
          [<c052015c>] sock_sendmsg+0x1c/0x2c
          [<c05213e0>] SyS_sendto+0xc0/0xe8
      
      unreferenced object 0xec861780 (size 192):
        comm "softirq", pid 0, jiffies 4294938759 (age 109.540s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          00 00 00 00 00 b0 5a ed 00 00 00 00 00 00 00 00  ......Z.........
        backtrace:
          [<c0107830>] kmem_cache_alloc+0x190/0x208
          [<c052c768>] __build_skb+0x30/0x98
          [<c052c8fc>] __netdev_alloc_skb+0xb8/0x104
          [<bf1abc54>] cpsw_rx_handler+0x68/0x1e4 [ti_cpsw]
          [<bf11aa30>] __cpdma_chan_free+0xa8/0xc4 [davinci_cpdma]
          [<bf11ab98>] __cpdma_chan_process+0x14c/0x16c [davinci_cpdma]
          [<bf11abfc>] cpdma_chan_process+0x44/0x5c [davinci_cpdma]
          [<bf1adc78>] cpsw_rx_poll+0x1c/0x9c [ti_cpsw]
          [<c0539180>] net_rx_action+0x1f0/0x2ec
          [<c003881c>] __do_softirq+0x134/0x258
          [<c0038a00>] do_softirq+0x68/0x70
          [<c0038adc>] __local_bh_enable_ip+0xd4/0xe8
          [<c0640994>] _raw_spin_unlock_bh+0x30/0x34
          [<c05f4e9c>] igmp6_group_added+0x4c/0x1bc
          [<c05f6600>] ipv6_dev_mc_inc+0x398/0x434
          [<c05dba74>] addrconf_dad_work+0x224/0x39c
      
      This happens because CPSW allocates SK buffers and then passes
      pointers on them in CPDMA where they stored in internal CPPI RAM
      (SRAM) which belongs to DEV MMIO space. Kmemleak does not scan IO
      memory and so reports memory leaks.
      
      Hence, mark allocated sk buffers as false positive explicitly.
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      254a49d5
    • L
      vti: flush x-netns xfrm cache when vti interface is removed · a5d0dc81
      Lance Richardson 提交于
      When executing the script included below, the netns delete operation
      hangs with the following message (repeated at 10 second intervals):
      
        kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1
      
      This occurs because a reference to the lo interface in the "secure" netns
      is still held by a dst entry in the xfrm bundle cache in the init netns.
      
      Address this problem by garbage collecting the tunnel netns flow cache
      when a cross-namespace vti interface receives a NETDEV_DOWN notification.
      
      A more detailed description of the problem scenario (referencing commands
      in the script below):
      
      (1) ip link add vti_test type vti local 1.1.1.1 remote 1.1.1.2 key 1
      
        The vti_test interface is created in the init namespace. vti_tunnel_init()
        attaches a struct ip_tunnel to the vti interface's netdev_priv(dev),
        setting the tunnel net to &init_net.
      
      (2) ip link set vti_test netns secure
      
        The vti_test interface is moved to the "secure" netns. Note that
        the associated struct ip_tunnel still has tunnel->net set to &init_net.
      
      (3) ip netns exec secure ping -c 4 -i 0.02 -I 192.168.100.1 192.168.200.1
      
        The first packet sent using the vti device causes xfrm_lookup() to be
        called as follows:
      
            dst = xfrm_lookup(tunnel->net, skb_dst(skb), fl, NULL, 0);
      
        Note that tunnel->net is the init namespace, while skb_dst(skb) references
        the vti_test interface in the "secure" namespace. The returned dst
        references an interface in the init namespace.
      
        Also note that the first parameter to xfrm_lookup() determines which flow
        cache is used to store the computed xfrm bundle, so after xfrm_lookup()
        returns there will be a cached bundle in the init namespace flow cache
        with a dst referencing a device in the "secure" namespace.
      
      (4) ip netns del secure
      
        Kernel begins to delete the "secure" namespace.  At some point the
        vti_test interface is deleted, at which point dst_ifdown() changes
        the dst->dev in the cached xfrm bundle flow from vti_test to lo (still
        in the "secure" namespace however).
        Since nothing has happened to cause the init namespace's flow cache
        to be garbage collected, this dst remains attached to the flow cache,
        so the kernel loops waiting for the last reference to lo to go away.
      
      <Begin script>
      ip link add br1 type bridge
      ip link set dev br1 up
      ip addr add dev br1 1.1.1.1/8
      
      ip netns add secure
      ip link add vti_test type vti local 1.1.1.1 remote 1.1.1.2 key 1
      ip link set vti_test netns secure
      ip netns exec secure ip link set vti_test up
      ip netns exec secure ip link s lo up
      ip netns exec secure ip addr add dev lo 192.168.100.1/24
      ip netns exec secure ip route add 192.168.200.0/24 dev vti_test
      ip xfrm policy flush
      ip xfrm state flush
      ip xfrm policy add dir out tmpl src 1.1.1.1 dst 1.1.1.2 \
         proto esp mode tunnel mark 1
      ip xfrm policy add dir in tmpl src 1.1.1.2 dst 1.1.1.1 \
         proto esp mode tunnel mark 1
      ip xfrm state add src 1.1.1.1 dst 1.1.1.2 proto esp spi 1 \
         mode tunnel enc des3_ede 0x112233445566778811223344556677881122334455667788
      ip xfrm state add src 1.1.1.2 dst 1.1.1.1 proto esp spi 1 \
         mode tunnel enc des3_ede 0x112233445566778811223344556677881122334455667788
      
      ip netns exec secure ping -c 4 -i 0.02 -I 192.168.100.1 192.168.200.1
      
      ip netns del secure
      <End script>
      Reported-by: NHangbin Liu <haliu@redhat.com>
      Reported-by: NJan Tluka <jtluka@redhat.com>
      Signed-off-by: NLance Richardson <lrichard@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a5d0dc81
    • D
      Merge tag 'rxrpc-fixes-20160809' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs · aee4eda1
      David S. Miller 提交于
      David Howells says:
      
      ====================
      rxrpc: Miscellaneous fixes
      
      Here are a bunch of miscellaneous fixes to AF_RXRPC:
      
       (*) Fix an uninitialised pointer.
      
       (*) Fix error handling when we fail to connect a call.
      
       (*) Fix a NULL pointer dereference.
      
       (*) Fix two occasions where a packet is accessed again after being queued
           for someone else to deal with.
      
       (*) Fix a missing skb free.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aee4eda1
    • D
      rxrpc: Free packets discarded in data_ready · 992c273a
      David Howells 提交于
      Under certain conditions, the data_ready handler will discard a packet.
      These need to be freed.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      992c273a
    • D
      rxrpc: Fix a use-after-push in data_ready handler · 50fd85a1
      David Howells 提交于
      Fix a use of a packet after it has been enqueued onto the packet processing
      queue in the data_ready handler.  Once on a call's Rx queue, we mustn't
      touch it any more as it may be dequeued and freed by the call processor
      running on a work queue.
      
      Save the values we need before enqueuing.
      
      Without this, we can get an oops like the following:
      
      BUG: unable to handle kernel NULL pointer dereference at 000000000000009c
      IP: [<ffffffffa01854e8>] rxrpc_fast_process_packet+0x724/0xa11 [af_rxrpc]
      PGD 0 
      Oops: 0000 [#1] SMP
      Modules linked in: kafs(E) af_rxrpc(E) [last unloaded: af_rxrpc]
      CPU: 2 PID: 0 Comm: swapper/2 Tainted: G            E   4.7.0-fsdevel+ #1336
      Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
      task: ffff88040d6863c0 task.stack: ffff88040d68c000
      RIP: 0010:[<ffffffffa01854e8>]  [<ffffffffa01854e8>] rxrpc_fast_process_packet+0x724/0xa11 [af_rxrpc]
      RSP: 0018:ffff88041fb03a78  EFLAGS: 00010246
      RAX: ffffffffffffffff RBX: ffff8803ff195b00 RCX: 0000000000000001
      RDX: ffffffffa01854d1 RSI: 0000000000000008 RDI: ffff8803ff195b00
      RBP: ffff88041fb03ab0 R08: 0000000000000000 R09: 0000000000000001
      R10: ffff88041fb038c8 R11: 0000000000000000 R12: ffff880406874800
      R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000
      FS:  0000000000000000(0000) GS:ffff88041fb00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 000000000000009c CR3: 0000000001c14000 CR4: 00000000001406e0
      Stack:
       ffff8803ff195ea0 ffff880408348800 ffff880406874800 ffff8803ff195b00
       ffff880408348800 ffff8803ff195ed8 0000000000000000 ffff88041fb03af0
       ffffffffa0186072 0000000000000000 ffff8804054da000 0000000000000000
      Call Trace:
       <IRQ> 
       [<ffffffffa0186072>] rxrpc_data_ready+0x89d/0xbae [af_rxrpc]
       [<ffffffff814c94d7>] __sock_queue_rcv_skb+0x24c/0x2b2
       [<ffffffff8155c59a>] __udp_queue_rcv_skb+0x4b/0x1bd
       [<ffffffff8155e048>] udp_queue_rcv_skb+0x281/0x4db
       [<ffffffff8155ea8f>] __udp4_lib_rcv+0x7ed/0x963
       [<ffffffff8155ef9a>] udp_rcv+0x15/0x17
       [<ffffffff81531d86>] ip_local_deliver_finish+0x1c3/0x318
       [<ffffffff81532544>] ip_local_deliver+0xbb/0xc4
       [<ffffffff81531bc3>] ? inet_del_offload+0x40/0x40
       [<ffffffff815322a9>] ip_rcv_finish+0x3ce/0x42c
       [<ffffffff81532851>] ip_rcv+0x304/0x33d
       [<ffffffff81531edb>] ? ip_local_deliver_finish+0x318/0x318
       [<ffffffff814dff9d>] __netif_receive_skb_core+0x601/0x6e8
       [<ffffffff814e072e>] __netif_receive_skb+0x13/0x54
       [<ffffffff814e082a>] netif_receive_skb_internal+0xbb/0x17c
       [<ffffffff814e1838>] napi_gro_receive+0xf9/0x1bd
       [<ffffffff8144eb9f>] rtl8169_poll+0x32b/0x4a8
       [<ffffffff814e1c7b>] net_rx_action+0xe8/0x357
       [<ffffffff81051074>] __do_softirq+0x1aa/0x414
       [<ffffffff810514ab>] irq_exit+0x3d/0xb0
       [<ffffffff810184a2>] do_IRQ+0xe4/0xfc
       [<ffffffff81612053>] common_interrupt+0x93/0x93
       <EOI> 
       [<ffffffff814af837>] ? cpuidle_enter_state+0x1ad/0x2be
       [<ffffffff814af832>] ? cpuidle_enter_state+0x1a8/0x2be
       [<ffffffff814af96a>] cpuidle_enter+0x12/0x14
       [<ffffffff8108956f>] call_cpuidle+0x39/0x3b
       [<ffffffff81089855>] cpu_startup_entry+0x230/0x35d
       [<ffffffff810312ea>] start_secondary+0xf4/0xf7
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      50fd85a1
    • D
      rxrpc: Once packet posted in data_ready, don't retry posting · 2e7e9758
      David Howells 提交于
      Once a packet has been posted to a connection in the data_ready handler, we
      mustn't try reposting if we then find that the connection is dying as the
      refcount has been given over to the dying connection and the packet might
      no longer exist.
      
      Losing the packet isn't a problem as the peer will retransmit.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      2e7e9758
    • D
      rxrpc: Don't access connection from call if pointer is NULL · f9dc5757
      David Howells 提交于
      The call state machine processor sets up the message parameters for a UDP
      message that it might need to transmit in advance on the basis that there's
      a very good chance it's going to have to transmit either an ACK or an
      ABORT.  This requires it to look in the connection struct to retrieve some
      of the parameters.
      
      However, if the call is complete, the call connection pointer may be NULL
      to dissuade the processor from transmitting a message.  However, there are
      some situations where the processor is still going to be called - and it's
      still going to set up message parameters whether it needs them or not.
      
      This results in a NULL pointer dereference at:
      
      	net/rxrpc/call_event.c:837
      
      To fix this, skip the message pre-initialisation if there's no connection
      attached.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      f9dc5757
    • D
      rxrpc: Need to flag call as being released on connect failure · 17b963e3
      David Howells 提交于
      If rxrpc_new_client_call() fails to make a connection, the call record that
      it allocated needs to be marked as RXRPC_CALL_RELEASED before it is passed
      to rxrpc_put_call() to indicate that it no longer has any attachment to the
      AF_RXRPC socket.
      
      Without this, an assertion failure may occur at:
      
      	net/rxrpc/call_object:635
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      17b963e3
  6. 09 8月, 2016 18 次提交