1. 26 3月, 2008 21 次提交
  2. 25 3月, 2008 2 次提交
    • K
    • P
      [NEIGH]: Fix race between pneigh deletion and ipv6's ndisc_recv_ns (v3). · fa86d322
      Pavel Emelyanov 提交于
      Proxy neighbors do not have any reference counting, so any caller
      of pneigh_lookup (unless it's a netlink triggered add/del routine)
      should _not_ perform any actions on the found proxy entry. 
      
      There's one exception from this rule - the ipv6's ndisc_recv_ns() 
      uses found entry to check the flags for NTF_ROUTER.
      
      This creates a race between the ndisc and pneigh_delete - after 
      the pneigh is returned to the caller, the nd_tbl.lock is dropped 
      and the deleting procedure may proceed.
      
      One of the fixes would be to add a reference counting, but this
      problem exists for ndisc only. Besides such a patch would be too 
      big for -rc4.
      
      So I propose to introduce a __pneigh_lookup() which is supposed
      to be called with the lock held and use it in ndisc code to check
      the flags on alive pneigh entry.
      
      
      Changes from v2:
      As David noticed, Exported the __pneigh_lookup() to ipv6 module. 
      The checkpatch generates a warning on it, since the EXPORT_SYMBOL 
      does not follow the symbol itself, but in this file all the 
      exports come at the end, so I decided no to break this harmony.
      
      Changes from v1:
      Fixed comments from YOSHIFUJI - indentation of prototype in header
      and the pndisc_check_router() name - and a compilation fix, pointed
      by Daniel - the is_routed was (falsely) considered as uninitialized
      by gcc.
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fa86d322
  3. 24 3月, 2008 3 次提交
  4. 23 3月, 2008 6 次提交
  5. 22 3月, 2008 3 次提交
  6. 21 3月, 2008 5 次提交
    • J
      [NET] ifb: set separate lockdep classes for queue locks · 94833dfb
      Jarek Poplawski 提交于
      [   10.536424] =======================================================
      [   10.536424] [ INFO: possible circular locking dependency detected ]
      [   10.536424] 2.6.25-rc3-devel #3
      [   10.536424] -------------------------------------------------------
      [   10.536424] swapper/0 is trying to acquire lock:
      [   10.536424]  (&dev->queue_lock){-+..}, at: [<c0299b4a>] 
      dev_queue_xmit+0x175/0x2f3
      [   10.536424]
      [   10.536424] but task is already holding lock:
      [   10.536424]  (&p->tcfc_lock){-+..}, at: [<f8a67154>] tcf_mirred+0x20/0x178 
      [act_mirred]
      [   10.536424]
      [   10.536424] which lock already depends on the new lock.
      
      lockdep warns of locking order while using ifb with sch_ingress and
      act_mirred: ingress_lock, tcfc_lock, queue_lock (usually queue_lock
      is at the beginning). This patch is only to tell lockdep that ifb is
      a different device (e.g. from eth) and has its own pair of queue
      locks. (This warning is a false-positive in common scenario of using
      ifb; yet there are possible situations, when this order could be
      dangerous; lockdep should warn in such a case.) (With suggestions by
      David S. Miller)
      Reported-and-tested-by: NDenys Fedoryshchenko <denys@visp.net.lb>
      Signed-off-by: NJarek Poplawski <jarkao2@gmail.com>
      Acked-by: NJamal Hadi Salim <hadi@cyberus.ca>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      94833dfb
    • Y
      [IPV6] KCONFIG: Fix description about IPV6_TUNNEL. · 38fe999e
      YOSHIFUJI Hideaki 提交于
      Based on notice from "Colin" <colins@sjtu.edu.cn>.
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      38fe999e
    • P
      [TCP]: Fix shrinking windows with window scaling · 607bfbf2
      Patrick McHardy 提交于
      When selecting a new window, tcp_select_window() tries not to shrink
      the offered window by using the maximum of the remaining offered window
      size and the newly calculated window size. The newly calculated window
      size is always a multiple of the window scaling factor, the remaining
      window size however might not be since it depends on rcv_wup/rcv_nxt.
      This means we're effectively shrinking the window when scaling it down.
      
      
      The dump below shows the problem (scaling factor 2^7):
      
      - Window size of 557 (71296) is advertised, up to 3111907257:
      
      IP 172.2.2.3.33000 > 172.2.2.2.33000: . ack 3111835961 win 557 <...>
      
      - New window size of 514 (65792) is advertised, up to 3111907217, 40 bytes
        below the last end:
      
      IP 172.2.2.3.33000 > 172.2.2.2.33000: . 3113575668:3113577116(1448) ack 3111841425 win 514 <...>
      
      The number 40 results from downscaling the remaining window:
      
      3111907257 - 3111841425 = 65832
      65832 / 2^7 = 514
      65832 % 2^7 = 40
      
      If the sender uses up the entire window before it is shrunk, this can have
      chaotic effects on the connection. When sending ACKs, tcp_acceptable_seq()
      will notice that the window has been shrunk since tcp_wnd_end() is before
      tp->snd_nxt, which makes it choose tcp_wnd_end() as sequence number.
      This will fail the receivers checks in tcp_sequence() however since it
      is before it's tp->rcv_wup, making it respond with a dupack.
      
      If both sides are in this condition, this leads to a constant flood of
      ACKs until the connection times out.
      
      Make sure the window is never shrunk by aligning the remaining window to
      the window scaling factor.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      607bfbf2
    • J
      netpoll: zap_completion_queue: adjust skb->users counter · 8a455b08
      Jarek Poplawski 提交于
      zap_completion_queue() retrieves skbs from completion_queue where they have
      zero skb->users counter.  Before dev_kfree_skb_any() it should be non-zero
      yet, so it's increased now.
      Reported-and-tested-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJarek Poplawski <jarkao2@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8a455b08
    • F
      bridge: use time_before() in br_fdb_cleanup() · 2bec008c
      Fabio Checconi 提交于
      In br_fdb_cleanup() next_timer and this_timer are in jiffies, so they
      should be compared using the time_after() macro.
      Signed-off-by: NFabio Checconi <fabio@gandalf.sssup.it>
      Signed-off-by: NStephen Hemminger <stephen.hemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2bec008c