1. 11 10月, 2015 1 次提交
  2. 08 10月, 2015 2 次提交
  3. 07 10月, 2015 11 次提交
  4. 05 10月, 2015 9 次提交
  5. 30 9月, 2015 6 次提交
  6. 29 9月, 2015 4 次提交
    • D
      net: sctp: Don't use 64 kilobyte lookup table for four elements · 2103d6b8
      Denys Vlasenko 提交于
      Seemingly innocuous sctp_trans_state_to_prio_map[] array
      is way bigger than it looks, since
      "[SCTP_UNKNOWN] = 2" expands into "[0xffff] = 2" !
      
      This patch replaces it with switch() statement.
      Signed-off-by: NDenys Vlasenko <dvlasenk@redhat.com>
      CC: Vlad Yasevich <vyasevich@gmail.com>
      CC: Neil Horman <nhorman@tuxdriver.com>
      CC: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      CC: linux-sctp@vger.kernel.org
      CC: netdev@vger.kernel.org
      CC: linux-kernel@vger.kernel.org
      Acked-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2103d6b8
    • A
      l2tp: protect tunnel->del_work by ref_count · 06a15f51
      Alexander Couzens 提交于
      There is a small chance that tunnel_free() is called before tunnel->del_work scheduled
      resulting in a zero pointer dereference.
      Signed-off-by: NAlexander Couzens <lynxis@fe80.eu>
      Acked-by: NJames Chapman <jchapman@katalix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      06a15f51
    • K
      sctp: Prevent soft lockup when sctp_accept() is called during a timeout event · 635682a1
      Karl Heiss 提交于
      A case can occur when sctp_accept() is called by the user during
      a heartbeat timeout event after the 4-way handshake.  Since
      sctp_assoc_migrate() changes both assoc->base.sk and assoc->ep, the
      bh_sock_lock in sctp_generate_heartbeat_event() will be taken with
      the listening socket but released with the new association socket.
      The result is a deadlock on any future attempts to take the listening
      socket lock.
      
      Note that this race can occur with other SCTP timeouts that take
      the bh_lock_sock() in the event sctp_accept() is called.
      
       BUG: soft lockup - CPU#9 stuck for 67s! [swapper:0]
       ...
       RIP: 0010:[<ffffffff8152d48e>]  [<ffffffff8152d48e>] _spin_lock+0x1e/0x30
       RSP: 0018:ffff880028323b20  EFLAGS: 00000206
       RAX: 0000000000000002 RBX: ffff880028323b20 RCX: 0000000000000000
       RDX: 0000000000000000 RSI: ffff880028323be0 RDI: ffff8804632c4b48
       RBP: ffffffff8100bb93 R08: 0000000000000000 R09: 0000000000000000
       R10: ffff880610662280 R11: 0000000000000100 R12: ffff880028323aa0
       R13: ffff8804383c3880 R14: ffff880028323a90 R15: ffffffff81534225
       FS:  0000000000000000(0000) GS:ffff880028320000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
       CR2: 00000000006df528 CR3: 0000000001a85000 CR4: 00000000000006e0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
       Process swapper (pid: 0, threadinfo ffff880616b70000, task ffff880616b6cab0)
       Stack:
       ffff880028323c40 ffffffffa01c2582 ffff880614cfb020 0000000000000000
       <d> 0100000000000000 00000014383a6c44 ffff8804383c3880 ffff880614e93c00
       <d> ffff880614e93c00 0000000000000000 ffff8804632c4b00 ffff8804383c38b8
       Call Trace:
       <IRQ>
       [<ffffffffa01c2582>] ? sctp_rcv+0x492/0xa10 [sctp]
       [<ffffffff8148c559>] ? nf_iterate+0x69/0xb0
       [<ffffffff814974a0>] ? ip_local_deliver_finish+0x0/0x2d0
       [<ffffffff8148c716>] ? nf_hook_slow+0x76/0x120
       [<ffffffff814974a0>] ? ip_local_deliver_finish+0x0/0x2d0
       [<ffffffff8149757d>] ? ip_local_deliver_finish+0xdd/0x2d0
       [<ffffffff81497808>] ? ip_local_deliver+0x98/0xa0
       [<ffffffff81496ccd>] ? ip_rcv_finish+0x12d/0x440
       [<ffffffff81497255>] ? ip_rcv+0x275/0x350
       [<ffffffff8145cfeb>] ? __netif_receive_skb+0x4ab/0x750
       ...
      
      With lockdep debugging:
      
       =====================================
       [ BUG: bad unlock balance detected! ]
       -------------------------------------
       CslRx/12087 is trying to release lock (slock-AF_INET) at:
       [<ffffffffa01bcae0>] sctp_generate_timeout_event+0x40/0xe0 [sctp]
       but there are no more locks to release!
      
       other info that might help us debug this:
       2 locks held by CslRx/12087:
       #0:  (&asoc->timers[i]){+.-...}, at: [<ffffffff8108ce1f>] run_timer_softirq+0x16f/0x3e0
       #1:  (slock-AF_INET){+.-...}, at: [<ffffffffa01bcac3>] sctp_generate_timeout_event+0x23/0xe0 [sctp]
      
      Ensure the socket taken is also the same one that is released by
      saving a copy of the socket before entering the timeout event
      critical section.
      Signed-off-by: NKarl Heiss <kheiss@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      635682a1
    • K
      sctp: Whitespace fix · f05940e6
      Karl Heiss 提交于
      Fix indentation in sctp_generate_heartbeat_event.
      Signed-off-by: NKarl Heiss <kheiss@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f05940e6
  7. 26 9月, 2015 1 次提交
    • D
      net: Fix panic in icmp_route_lookup · bdb06cbf
      David Ahern 提交于
      Andrey reported a panic:
      
      [ 7249.865507] BUG: unable to handle kernel pointer dereference at 000000b4
      [ 7249.865559] IP: [<c16afeca>] icmp_route_lookup+0xaa/0x320
      [ 7249.865598] *pdpt = 0000000030f7f001 *pde = 0000000000000000
      [ 7249.865637] Oops: 0000 [#1]
      ...
      [ 7249.866811] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
      4.3.0-999-generic #201509220155
      [ 7249.866876] Hardware name: MSI MS-7250/MS-7250, BIOS 080014  08/02/2006
      [ 7249.866916] task: c1a5ab00 ti: c1a52000 task.ti: c1a52000
      [ 7249.866949] EIP: 0060:[<c16afeca>] EFLAGS: 00210246 CPU: 0
      [ 7249.866981] EIP is at icmp_route_lookup+0xaa/0x320
      [ 7249.867012] EAX: 00000000 EBX: f483ba48 ECX: 00000000 EDX: f2e18a00
      [ 7249.867045] ESI: 000000c0 EDI: f483ba70 EBP: f483b9ec ESP: f483b974
      [ 7249.867077]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      [ 7249.867108] CR0: 8005003b CR2: 000000b4 CR3: 36ee07c0 CR4: 000006f0
      [ 7249.867141] Stack:
      [ 7249.867165]  320310ee 00000000 00000042 320310ee 00000000 c1aeca00
      f3920240 f0c69180
      [ 7249.867268]  f483ba04 f855058b a89b66cd f483ba44 f8962f4b 00000000
      e659266c f483ba54
      [ 7249.867361]  8004753c f483ba5c f8962f4b f2031140 000003c1 ffbd8fa0
      c16b0e00 00000064
      [ 7249.867448] Call Trace:
      [ 7249.867494]  [<f855058b>] ? e1000_xmit_frame+0x87b/0xdc0 [e1000e]
      [ 7249.867534]  [<f8962f4b>] ? tcp_in_window+0xeb/0xb10 [nf_conntrack]
      [ 7249.867576]  [<f8962f4b>] ? tcp_in_window+0xeb/0xb10 [nf_conntrack]
      [ 7249.867615]  [<c16b0e00>] ? icmp_send+0xa0/0x380
      [ 7249.867648]  [<c16b102f>] icmp_send+0x2cf/0x380
      [ 7249.867681]  [<f89c8126>] nf_send_unreach+0xa6/0xc0 [nf_reject_ipv4]
      [ 7249.867714]  [<f89cd0da>] reject_tg+0x7a/0x9f [ipt_REJECT]
      [ 7249.867746]  [<f88c29a7>] ipt_do_table+0x317/0x70c [ip_tables]
      [ 7249.867780]  [<f895e0a6>] ? __nf_conntrack_find_get+0x166/0x3b0
      [nf_conntrack]
      [ 7249.867838]  [<f895eea8>] ? nf_conntrack_in+0x398/0x600 [nf_conntrack]
      [ 7249.867889]  [<f84c0035>] iptable_filter_hook+0x35/0x80 [iptable_filter]
      [ 7249.867933]  [<c16776a1>] nf_iterate+0x71/0x80
      [ 7249.867970]  [<c1677715>] nf_hook_slow+0x65/0xc0
      [ 7249.868002]  [<c1681811>] __ip_local_out_sk+0xc1/0xd0
      [ 7249.868034]  [<c1680f30>] ? ip_forward_options+0x1a0/0x1a0
      [ 7249.868066]  [<c1681836>] ip_local_out_sk+0x16/0x30
      [ 7249.868097]  [<c1684054>] ip_send_skb+0x14/0x80
      [ 7249.868129]  [<c16840f4>] ip_push_pending_frames+0x34/0x40
      [ 7249.868163]  [<c16844a2>] ip_send_unicast_reply+0x282/0x310
      [ 7249.868196]  [<c16a0863>] tcp_v4_send_reset+0x1b3/0x380
      [ 7249.868227]  [<c16a1b63>] tcp_v4_rcv+0x323/0x990
      [ 7249.868257]  [<c16776a1>] ? nf_iterate+0x71/0x80
      [ 7249.868289]  [<c167dc2b>] ip_local_deliver_finish+0x8b/0x230
      [ 7249.868322]  [<c167df4c>] ip_local_deliver+0x4c/0xa0
      [ 7249.868353]  [<c167dba0>] ? ip_rcv_finish+0x390/0x390
      [ 7249.868384]  [<c167d88c>] ip_rcv_finish+0x7c/0x390
      [ 7249.868415]  [<c167e280>] ip_rcv+0x2e0/0x420
      ...
      
      Prior to the VRF change the oif was not set in the flow struct, so the
      VRF support should really have only added the vrf_master_ifindex lookup.
      
      Fixes: 613d09b3 ("net: Use VRF device index for lookups on TX")
      Cc: Andrey Melnikov <temnota.am@gmail.com>
      Signed-off-by: NDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bdb06cbf
  8. 25 9月, 2015 6 次提交
    • C
      xprtrdma: Replace global lkey with lkey local to PD · bb6c96d7
      Chuck Lever 提交于
      The core API has changed so that devices that do not have a global
      DMA lkey automatically create an mr, per-PD, and make that lkey
      available. The global DMA lkey interface is going away in favor of
      the per-PD DMA lkey.
      
      The per-PD DMA lkey is always available. Convert xprtrdma to use the
      device's per-PD DMA lkey for regbufs, no matter which memory
      registration scheme is in use.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NSagi Grimberg <sagig@mellanox.com>
      Cc: linux-nfs <linux-nfs@vger.kernel.org>
      Acked-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      bb6c96d7
    • R
      net: fix net_device refcounting · 9861f720
      Russell King 提交于
      of_find_net_device_by_node() uses class_find_device() internally to
      lookup the corresponding network device.  class_find_device() returns
      a reference to the embedded struct device, with its refcount
      incremented.
      
      Add a comment to the definition in net/core/net-sysfs.c indicating the
      need to drop this refcount, and fix the DSA code to drop this refcount
      when the OF-generated platform data is cleaned up and freed.  Also
      arrange for the ref to be dropped when handling errors.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9861f720
    • R
      net: dsa: fix of_mdio_find_bus() device refcount leak · e496ae69
      Russell King 提交于
      Current users of of_mdio_find_bus() leak a struct device refcount, as
      they fail to clean up the reference obtained inside class_find_device().
      
      Fix the DSA code to properly refcount the returned MDIO bus by:
      1. taking a reference on the struct device whenever we assign it to
         pd->chip[x].host_dev.
      2. dropping the reference when we overwrite the existing reference.
      3. dropping the reference when we free the data structure.
      4. dropping the initial reference we obtained after setting up the
         platform data structure, or on failure.
      
      In step 2 above, where we obtain a new MDIO bus, there is no need to
      take a reference on it as we would only have to drop it immediately
      after assignment again, iow:
      
      	put_device(cd->host_dev);	/* drop original assignment ref */
      	cd->host_dev = get_device(&mdio_bus_switch->dev); /* get our ref */
      	put_device(&mdio_bus_switch->dev); /* drop of_mdio_find_bus ref */
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e496ae69
    • M
      ip6_tunnel: Reduce log level in ip6_tnl_err() to debug · 17a10c92
      Matt Bennett 提交于
      Currently error log messages in ip6_tnl_err are printed at 'warn'
      level. This is different to other tunnel types which don't print
      any messages. These log messages don't provide any information that
      couldn't be deduced with networking tools. Also it can be annoying
      to have one end of the tunnel go down and have the logs fill with
      pointless messages such as "Path to destination invalid or inactive!".
      
      This patch reduces the log level of these messages to 'dbg' level to
      bring the visible behaviour into line with other tunnel types.
      Signed-off-by: NMatt Bennett <matt.bennett@alliedtelesis.co.nz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      17a10c92
    • M
      ip6_gre: Reduce log level in ip6gre_err() to debug · a46496ce
      Matt Bennett 提交于
      Currently error log messages in ip6gre_err are printed at 'warn'
      level. This is different to most other tunnel types which don't
      print any messages. These log messages don't provide any information
      that couldn't be deduced with networking tools. Also it can be annoying
      to have one end of the tunnel go down and have the logs fill with
      pointless messages such as "Path to destination invalid or inactive!".
      
      This patch reduces the log level of these messages to 'dbg' level to
      bring the visible behaviour into line with other tunnel types.
      Signed-off-by: NMatt Bennett <matt.bennett@alliedtelesis.co.nz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a46496ce
    • W
      fib_rules: fix fib rule dumps across multiple skbs · 41fc0143
      Wilson Kok 提交于
      dump_rules returns skb length and not error.
      But when family == AF_UNSPEC, the caller of dump_rules
      assumes that it returns an error. Hence, when family == AF_UNSPEC,
      we continue trying to dump on -EMSGSIZE errors resulting in
      incorrect dump idx carried between skbs belonging to the same dump.
      This results in fib rule dump always only dumping rules that fit
      into the first skb.
      
      This patch fixes dump_rules to return error so that we exit correctly
      and idx is correctly maintained between skbs that are part of the
      same dump.
      Signed-off-by: NWilson Kok <wkok@cumulusnetworks.com>
      Signed-off-by: NRoopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      41fc0143