“36691e1be6ec551eef4a5225f126a281f8c051c2”上不存在“README.md”
  1. 14 12月, 2011 1 次提交
  2. 13 12月, 2011 3 次提交
    • E
      sch_gred: should not use GFP_KERNEL while holding a spinlock · 3f1e6d3f
      Eric Dumazet 提交于
      gred_change_vq() is called under sch_tree_lock(sch).
      
      This means a spinlock is held, and we are not allowed to sleep in this
      context.
      
      We might pre-allocate memory using GFP_KERNEL before taking spinlock,
      but this is not suitable for stable material.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3f1e6d3f
    • T
      ipip, sit: copy parms.name after register_netdevice · 72b36015
      Ted Feng 提交于
      Same fix as 731abb9c for ipip and sit tunnel.
      Commit 1c5cae81 removed an explicit call to dev_alloc_name in
      ipip_tunnel_locate and ipip6_tunnel_locate, because register_netdevice
      will now create a valid name, however the tunnel keeps a copy of the
      name in the private parms structure. Fix this by copying the name back
      after register_netdevice has successfully returned.
      
      This shows up if you do a simple tunnel add, followed by a tunnel show:
      
      $ sudo ip tunnel add mode ipip remote 10.2.20.211
      $ ip tunnel
      tunl0: ip/ip  remote any  local any  ttl inherit  nopmtudisc
      tunl%d: ip/ip  remote 10.2.20.211  local any  ttl inherit
      $ sudo ip tunnel add mode sit remote 10.2.20.212
      $ ip tunnel
      sit0: ipv6/ip  remote any  local any  ttl 64  nopmtudisc 6rd-prefix 2002::/16
      sit%d: ioctl 89f8 failed: No such device
      sit%d: ipv6/ip  remote 10.2.20.212  local any  ttl inherit
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NTed Feng <artisdom@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      72b36015
    • L
      ipv6: Fix for adding multicast route for loopback device automatically. · 4af04aba
      Li Wei 提交于
      There is no obvious reason to add a default multicast route for loopback
      devices, otherwise there would be a route entry whose dst.error set to
      -ENETUNREACH that would blocking all multicast packets.
      
      ====================
      
      [ more detailed explanation ]
      
      The problem is that the resulting routing table depends on the sequence
      of interface's initialization and in some situation, that would block all
      muticast packets. Suppose there are two interfaces on my computer
      (lo and eth0), if we initailize 'lo' before 'eth0', the resuting routing
      table(for multicast) would be
      
      # ip -6 route show | grep ff00::
      unreachable ff00::/8 dev lo metric 256 error -101
      ff00::/8 dev eth0 metric 256
      
      When sending multicasting packets, routing subsystem will return the first
      route entry which with a error set to -101(ENETUNREACH).
      
      I know the kernel will set the default ipv6 address for 'lo' when it is up
      and won't set the default multicast route for it, but there is no reason to
      stop 'init' program from setting address for 'lo', and that is exactly what
      systemd did.
      
      I am sure there is something wrong with kernel or systemd, currently I preferred
      kernel caused this problem.
      
      ====================
      Signed-off-by: NLi Wei <lw@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4af04aba
  3. 08 12月, 2011 1 次提交
    • J
      mac80211: fix another race in aggregation start · 15062e6a
      Johannes Berg 提交于
      Emmanuel noticed that when mac80211 stops the queues
      for aggregation that can leave a packet pending. This
      packet will be given to the driver after the AMPDU
      callback, but as a non-aggregated packet which messes
      up the sequence number etc.
      
      I also noticed by looking at the code that if packets
      are being processed while we clear the WANT_START bit,
      they might see it cleared already and queue up on
      tid_tx->pending. If the driver then rejects the new
      aggregation session we leak the packet.
      
      Fix both of these issues by changing this code to not
      stop the queues at all. Instead, let packets queue up
      on the tid_tx->pending queue instead of letting them
      get to the driver, and add code to recover properly
      in case the driver rejects the session.
      
      (The patch looks large because it has to move two
      functions to before their new use.)
      
      Cc: stable@vger.kernel.org
      Reported-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      15062e6a
  4. 07 12月, 2011 4 次提交
  5. 06 12月, 2011 1 次提交
  6. 03 12月, 2011 2 次提交
  7. 02 12月, 2011 6 次提交
  8. 01 12月, 2011 7 次提交
  9. 30 11月, 2011 2 次提交
    • P
      netlabel: Fix build problems when IPv6 is not enabled · 1281bc25
      Paul Moore 提交于
      A recent fix to the the NetLabel code caused build problem with
      configurations that did not have IPv6 enabled; see below:
      
       netlabel_kapi.c: In function 'netlbl_cfg_unlbl_map_add':
       netlabel_kapi.c:165:4:
        error: implicit declaration of function 'netlbl_af6list_add'
      
      This patch fixes this problem by making the IPv6 specific code conditional
      on the IPv6 configuration flags as we done in the rest of NetLabel and the
      network stack as a whole.  We have to move some variable declarations
      around as a result so things may not be quite as pretty, but at least it
      builds cleanly now.
      
      Some additional IPv6 conditionals were added to the NetLabel code as well
      for the sake of consistency.
      Reported-by: NRandy Dunlap <rdunlap@xenotime.net>
      Signed-off-by: NPaul Moore <pmoore@redhat.com>
      Acked-by: NRandy Dunlap <rdunlap@xenotime.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1281bc25
    • X
      sctp: better integer overflow check in sctp_auth_create_key() · c89304b8
      Xi Wang 提交于
      The check from commit 30c2235c is incomplete and cannot prevent
      cases like key_len = 0x80000000 (INT_MAX + 1).  In that case, the
      left-hand side of the check (INT_MAX - key_len), which is unsigned,
      becomes 0xffffffff (UINT_MAX) and bypasses the check.
      
      However this shouldn't be a security issue.  The function is called
      from the following two code paths:
      
       1) setsockopt()
      
       2) sctp_auth_asoc_set_secret()
      
      In case (1), sca_keylength is never going to exceed 65535 since it's
      bounded by a u16 from the user API.  As such, the key length will
      never overflow.
      
      In case (2), sca_keylength is computed based on the user key (1 short)
      and 2 * key_vector (3 shorts) for a total of 7 * USHRT_MAX, which still
      will not overflow.
      
      In other words, this overflow check is not really necessary.  Just
      make it more correct.
      Signed-off-by: NXi Wang <xi.wang@gmail.com>
      Cc: Vlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c89304b8
  10. 29 11月, 2011 6 次提交
  11. 27 11月, 2011 7 次提交
新手
引导
客服 返回
顶部