1. 15 Sep, 2008 1 commit
    • Luis R. Rodriguez's avatar
      cfg80211: Add new wireless regulatory infrastructure · b2e1b302
      Luis R. Rodriguez authored
      This adds the new wireless regulatory infrastructure. The
      main motiviation behind this was to centralize regulatory
      code as each driver was implementing their own regulatory solution,
      and to replace the initial centralized code we have where:
      
      * only 3 regulatory domains are supported: US, JP and EU
      * regulatory domains can only be changed through module parameter
      * all rules were built statically in the kernel
      
      We now have support for regulatory domains for many countries
      and regulatory domains are now queried through a userspace agent
      through udev allowing distributions to update regulatory rules
      without updating the kernel.
      
      Each driver can regulatory_hint() a regulatory domain
      based on either their EEPROM mapped regulatory domain value to a
      respective ISO/IEC 3166-1 country code or pass an internally built
      regulatory domain. We also add support to let the user set the
      regulatory domain through userspace in case of faulty EEPROMs to
      further help compliance.
      
      Support for world roaming will be added soon for cards capable of
      this.
      
      For more information see:
      
      http://wireless.kernel.org/en/developers/Regulatory/CRDA
      
      For now we leave an option to enable the old module parameter,
      ieee80211_regdom, and to build the 3 old regdomains statically
      (US, JP and EU). This option is CONFIG_WIRELESS_OLD_REGULATORY.
      These old static definitions and the module parameter is being
      scheduled for removal for 2.6.29. Note that if you use this
      you won't make use of a world regulatory domain as its pointless.
      If you leave this option enabled and if CRDA is present and you
      use US or JP we will try to ask CRDA to update us a regulatory
      domain for us.
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      b2e1b302
  2. 13 Sep, 2008 3 commits
  3. 12 Sep, 2008 5 commits
    • Alexander Duyck's avatar
      pkt_action: add new action skbedit · ca9b0e27
      Alexander Duyck authored
      This new action will have the ability to change the priority and/or
      queue_mapping fields on an sk_buff.
      Signed-off-by: default avatarAlexander Duyck <alexander.h.duyck@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ca9b0e27
    • Alexander Duyck's avatar
      pkt_sched: Add multiqueue scheduler support · 92651940
      Alexander Duyck authored
      This patch is intended to add a qdisc to support the new tx multiqueue
      architecture by providing a band for each hardware queue.  By doing
      this it is possible to support a different qdisc per physical hardware
      queue.
      
      This qdisc uses the skb->queue_mapping to select which band to place
      the traffic onto.  It then uses a round robin w/ a check to see if the
      subqueue is stopped to determine which band to dequeue the packet from.
      Signed-off-by: default avatarAlexander Duyck <alexander.h.duyck@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      92651940
    • Vegard Nossum's avatar
      tcp_ipv6: fix use of uninitialized memory · 78d15e82
      Vegard Nossum authored
      inet6_rsk() is called on a struct request_sock * before we
      have checked whether the socket is an ipv6 socket or a ipv6-
      mapped ipv4 socket. The access that triggers this is the
      inet_rsk(rsk)->inet6_rsk_offset dereference in inet6_rsk().
      
      This is arguably not a critical error as the inet6_rsk_offset
      is only used to compute a pointer which is never really used
      (in the code path in question) anyway. But it might be a
      latent error, so let's fix it.
      
      Spotted by kmemcheck.
      Signed-off-by: default avatarVegard Nossum <vegard.nossum@gmail.com>
      Acked-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      78d15e82
    • Benjamin Thery's avatar
      net: fix scheduling of dst_gc_task by __dst_free · f262b59b
      Benjamin Thery authored
      The dst garbage collector dst_gc_task() may not be scheduled as we
      expect it to be in __dst_free().
      
      Indeed, when the dst_gc_timer was replaced by the delayed_work
      dst_gc_work, the mod_timer() call used to schedule the garbage
      collector at an earlier date was replaced by a schedule_delayed_work()
      (see commit 86bba269).
      
      But, the behaviour of mod_timer() and schedule_delayed_work() is
      different in the way they handle the delay. 
      
      mod_timer() stops the timer and re-arm it with the new given delay,
      whereas schedule_delayed_work() only check if the work is already
      queued in the workqueue (and queue it (with delay) if it is not)
      BUT it does NOT take into account the new delay (even if the new delay
      is earlier in time).
      schedule_delayed_work() returns 0 if it didn't queue the work,
      but we don't check the return code in __dst_free().
      
      If I understand the code in __dst_free() correctly, we want dst_gc_task
      to be queued after DST_GC_INC jiffies if we pass the test (and not in
      some undetermined time in the future), so I think we should add a call
      to cancel_delayed_work() before schedule_delayed_work(). Patch below.
      
      Or we should at least test the return code of schedule_delayed_work(),
      and reset the values of dst_garbage.timer_inc and dst_garbage.timer_expires
      back to their former values if schedule_delayed_work() failed.
      Otherwise the subsequent calls to __dst_free will test the wrong values
      and assume wrong thing about when the garbage collector is supposed to
      be scheduled.
      
      dst_gc_task() also calls schedule_delayed_work() without checking
      its return code (or calling cancel_scheduled_work() first), but it
      should fine there: dst_gc_task is the routine of the delayed_work, so
      no dst_gc_work should be pending in the queue when it's running.
      Signed-off-by: default avatarBenjamin Thery <benjamin.thery@bull.net>
      Acked-by: default avatarEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f262b59b
    • Alexander Duyck's avatar
      vlan: vlan device not reading gso max size of parent. · 1ae4be22
      Alexander Duyck authored
      The vlan devices are not reading the gso max size of the parent device.  As
      a result devices that do not support 64K max gso size are currently
      failing.
      
      This issue is seen on 2.6.26 kernels as well and the same patch should be
      able to be applied without any issues.
      Signed-off-by: default avatarAlexander Duyck <alexander.h.duyck@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1ae4be22
  4. 11 Sep, 2008 31 commits