1. 13 2月, 2008 8 次提交
    • J
      [AX25] ax25_ds_timer: use mod_timer instead of add_timer · e848b583
      Jarek Poplawski 提交于
      This patch changes current use of: init_timer(), add_timer()
      and del_timer() to setup_timer() with mod_timer(), which
      should be safer anyway.
      Reported-by: NJann Traschewski <jann@gmx.de>
      Signed-off-by: NJarek Poplawski <jarkao2@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e848b583
    • J
      [AX25] ax25_timer: use mod_timer instead of add_timer · 21fab4a8
      Jarek Poplawski 提交于
      According to one of Jann's OOPS reports it looks like
      BUG_ON(timer_pending(timer)) triggers during add_timer()
      in ax25_start_t1timer(). This patch changes current use
      of: init_timer(), add_timer() and del_timer() to
      setup_timer() with mod_timer(), which should be safer
      anyway.
      Reported-by: NJann Traschewski <jann@gmx.de>
      Signed-off-by: NJarek Poplawski <jarkao2@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      21fab4a8
    • J
      [AX25] ax25_route: make ax25_route_lock BH safe · 4de211f1
      Jarek Poplawski 提交于
      > =================================
      > [ INFO: inconsistent lock state ]
      > 2.6.24-dg8ngn-p02 #1
      > ---------------------------------
      > inconsistent {softirq-on-W} -> {in-softirq-R} usage.
      > linuxnet/3046 [HC0[0]:SC1[2]:HE1:SE0] takes:
      >  (ax25_route_lock){--.+}, at: [<f8a0cfb7>] ax25_get_route+0x18/0xb7 [ax25]
      > {softirq-on-W} state was registered at:
      ...
      
      This lockdep report shows that ax25_route_lock is taken for reading in
      softirq context, and for writing in process context with BHs enabled.
      So, to make this safe, all write_locks in ax25_route.c are changed to
      _bh versions.
      
      Reported-by: Jann Traschewski <jann@gmx.de>,
      Signed-off-by: NJarek Poplawski <jarkao2@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4de211f1
    • J
      [AX25] af_ax25: remove sock lock in ax25_info_show() · 1105b5d1
      Jarek Poplawski 提交于
      This lockdep warning:
      
      > =======================================================
      > [ INFO: possible circular locking dependency detected ]
      > 2.6.24 #3
      > -------------------------------------------------------
      > swapper/0 is trying to acquire lock:
      >  (ax25_list_lock){-+..}, at: [<f91dd3b1>] ax25_destroy_socket+0x171/0x1f0 [ax25]
      >
      > but task is already holding lock:
      >  (slock-AF_AX25){-+..}, at: [<f91dbabc>] ax25_std_heartbeat_expiry+0x1c/0xe0 [ax25]
      >
      > which lock already depends on the new lock.
      ...
      
      shows that ax25_list_lock and slock-AF_AX25 are taken in different
      order: ax25_info_show() takes slock (bh_lock_sock(ax25->sk)) while
      ax25_list_lock is held, so reversely to other functions. To fix this
      the sock lock should be moved to ax25_info_start(), and there would
      be still problem with breaking ax25_list_lock (it seems this "proper"
      order isn't optimal yet). But, since it's only for reading proc info
      it seems this is not necessary (e.g.  ax25_send_to_raw() does similar
      reading without this lock too).
      
      So, this patch removes sock lock to avoid deadlock possibility; there
      is also used sock_i_ino() function, which reads sk_socket under proper
      read lock. Additionally printf format of this i_ino is changed to %lu.
      Reported-by: NBernard Pidoux F6BVP <f6bvp@free.fr>
      Signed-off-by: NJarek Poplawski <jarkao2@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1105b5d1
    • S
      fib_trie: /proc/net/route performance improvement · 8315f5d8
      Stephen Hemminger 提交于
      Use key/offset caching to change /proc/net/route (use by iputils route)
      from O(n^2) to O(n). This improves performance from 30sec with 160,000
      routes to 1sec.
      Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8315f5d8
    • S
      fib_trie: handle empty tree · ec28cf73
      Stephen Hemminger 提交于
      This fixes possible problems when trie_firstleaf() returns NULL
      to trie_leafindex().
      Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ec28cf73
    • D
      [IPV4]: Remove IP_TOS setting privilege checks. · e4f8b5d4
      David S. Miller 提交于
      Various RFCs have all sorts of things to say about the CS field of the
      DSCP value.  In particular they try to make the distinction between
      values that should be used by "user applications" and things like
      routing daemons.
      
      This seems to have influenced the CAP_NET_ADMIN check which exists for
      IP_TOS socket option settings, but in fact it has an off-by-one error
      so it wasn't allowing CS5 which is meant for "user applications" as
      well.
      
      Further adding to the inconsistency and brokenness here, IPV6 does not
      validate the DSCP values specified for the IPV6_TCLASS socket option.
      
      The real actual uses of these TOS values are system specific in the
      final analysis, and these RFC recommendations are just that, "a
      recommendation".  In fact the standards very purposefully use
      "SHOULD" and "SHOULD NOT" when describing how these values can be
      used.
      
      In the final analysis the only clean way to provide consistency here
      is to remove the CAP_NET_ADMIN check.  The alternatives just don't
      work out:
      
      1) If we add the CAP_NET_ADMIN check to ipv6, this can break existing
         setups.
      
      2) If we just fix the off-by-one error in the class comparison in
         IPV4, certain DSCP values can be used in IPV6 but not IPV4 by
         default.  So people will just ask for a sysctl asking to
         override that.
      
      I checked several other freely available kernel trees and they
      do not make any privilege checks in this area like we do.  For
      the BSD stacks, this goes back all the way to Stevens Volume 2
      and beyond.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e4f8b5d4
    • D
  2. 12 2月, 2008 32 次提交