1. 05 11月, 2015 5 次提交
    • J
      Bluetooth: L2CAP: Fix returning correct LE CoC response codes · 8a7889cc
      Johan Hedberg 提交于
      The core spec defines specific response codes for situations when the
      received CID is incorrect. Add the defines for these and return them
      as appropriate from the LE Connect Request handler function.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      8a7889cc
    • M
      Bluetooth: Check for supported white list before issuing commands · 2ab216a7
      Marcel Holtmann 提交于
      The white list commands might not be implemented if the controller does
      not actually support the white list. So check the supported commands
      first before issuing these commands. Not supporting the white list is
      the same as supporting a white list with zero size.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      2ab216a7
    • D
      net: Fix prefsrc lookups · e1b8d903
      David Ahern 提交于
      A bug report (https://bugzilla.kernel.org/show_bug.cgi?id=107071) noted
      that the follwoing ip command is failing with v4.3:
      
          $ ip route add 10.248.5.0/24 dev bond0.250 table vlan_250 src 10.248.5.154
          RTNETLINK answers: Invalid argument
      
      021dd3b8 changed the lookup of the given preferred source address to
      use the table id passed in, but this assumes the local entries are in the
      given table which is not necessarily true for non-VRF use cases. When
      validating the preferred source fallback to the local table on failure.
      
      Fixes: 021dd3b8 ("net: Add routes to the table associated with the device")
      Signed-off-by: NDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e1b8d903
    • W
      ipv4: fix a potential deadlock in mcast getsockopt() path · 87e9f031
      WANG Cong 提交于
      Sasha reported the following lockdep warning:
      
        Possible unsafe locking scenario:
      
              CPU0                    CPU1
              ----                    ----
         lock(sk_lock-AF_INET);
                                      lock(rtnl_mutex);
                                      lock(sk_lock-AF_INET);
         lock(rtnl_mutex);
      
      This is due to that for IP_MSFILTER and MCAST_MSFILTER, we take
      rtnl lock before the socket lock in setsockopt() path, but take
      the socket lock before rtnl lock in getsockopt() path. All the
      rest optnames are setsockopt()-only.
      
      Fix this by aligning the getsockopt() path with the setsockopt()
      path, so that all mcast socket path would be locked in the same
      order.
      
      Note, IPv6 part is different where rtnl lock is not held.
      
      Fixes: 54ff9ef3 ("ipv4, ipv6: kill ip_mc_{join, leave}_group and ipv6_sock_mc_{join, drop}")
      Reported-by: NSasha Levin <sasha.levin@oracle.com>
      Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Reviewed-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      87e9f031
    • W
      ipv4: disable BH when changing ip local port range · 4ee3bd4a
      WANG Cong 提交于
      This fixes the following lockdep warning:
      
       [ INFO: inconsistent lock state ]
       4.3.0-rc7+ #1197 Not tainted
       ---------------------------------
       inconsistent {IN-SOFTIRQ-R} -> {SOFTIRQ-ON-W} usage.
       sysctl/1019 [HC0[0]:SC0[0]:HE1:SE1] takes:
        (&(&net->ipv4.ip_local_ports.lock)->seqcount){+.+-..}, at: [<ffffffff81921de7>] ipv4_local_port_range+0xb4/0x12a
       {IN-SOFTIRQ-R} state was registered at:
         [<ffffffff810bd682>] __lock_acquire+0x2f6/0xdf0
         [<ffffffff810be6d5>] lock_acquire+0x11c/0x1a4
         [<ffffffff818e599c>] inet_get_local_port_range+0x4e/0xae
         [<ffffffff8166e8e3>] udp_flow_src_port.constprop.40+0x23/0x116
         [<ffffffff81671cb9>] vxlan_xmit_one+0x219/0xa6a
         [<ffffffff81672f75>] vxlan_xmit+0xa6b/0xaa5
         [<ffffffff817f2deb>] dev_hard_start_xmit+0x2ae/0x465
         [<ffffffff817f35ed>] __dev_queue_xmit+0x531/0x633
         [<ffffffff817f3702>] dev_queue_xmit_sk+0x13/0x15
         [<ffffffff818004a5>] neigh_resolve_output+0x12f/0x14d
         [<ffffffff81959cfa>] ip6_finish_output2+0x344/0x39f
         [<ffffffff8195bf58>] ip6_finish_output+0x88/0x8e
         [<ffffffff8195bfef>] ip6_output+0x91/0xe5
         [<ffffffff819792ae>] dst_output_sk+0x47/0x4c
         [<ffffffff81979392>] NF_HOOK_THRESH.constprop.30+0x38/0x82
         [<ffffffff8197981e>] mld_sendpack+0x189/0x266
         [<ffffffff8197b28b>] mld_ifc_timer_expire+0x1ef/0x223
         [<ffffffff810de581>] call_timer_fn+0xfb/0x28c
         [<ffffffff810ded1e>] run_timer_softirq+0x1c7/0x1f1
      
      Fixes: b8f1a556 ("udp: Add function to make source port for UDP tunnels")
      Cc: Tom Herbert <tom@herbertland.com>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4ee3bd4a
  2. 04 11月, 2015 6 次提交
  3. 03 11月, 2015 29 次提交