1. 10 Jan, 2011 3 commits
  2. 09 Jan, 2011 1 commit
  3. 06 Jan, 2011 1 commit
  4. 05 Jan, 2011 1 commit
  5. 31 Dec, 2010 5 commits
    • Shmulik Ravid's avatar
      dcbnl: adding DCBX feature flags get-set · ea45fe4e
      Shmulik Ravid authored
      
      
      Adding a pair of set-get routines to dcbnl for setting the negotiation
      flags of the various DCB features. Conforms to the CEE flavor of DCBX
      The user sets these flags (enable, advertise, willing) for each feature
      to be used by the DCBX engine. The 'get' routine returns which of the
      features is enabled after the negotiation.
      
      This patch is dependent on the following patches:
      [net-next-2.6 PATCH 1/3] dcbnl: add support for ieee8021Qaz attributes
      [net-next-2.6 PATCH 2/3] dcbnl: add appliction tlv handlers
      [net-next-2.6 PATCH 3/3] net_dcb: add application notifiers
      Signed-off-by: default avatarShmulik Ravid <shmulikr@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ea45fe4e
    • Shmulik Ravid's avatar
      dcbnl: adding DCBX engine capability · 6241b625
      Shmulik Ravid authored
      
      
      Adding an optional DCBX capability and a pair for get-set routines for
      setting the device DCBX mode. The DCBX capability is a bit field of
      supported attributes. The user is expected to set the DCBX mode with a
      subset of the advertised attributes.
      
      This patch is dependent on the following patches:
      [net-next-2.6 PATCH 1/3] dcbnl: add support for ieee8021Qaz attributes
      [net-next-2.6 PATCH 2/3] dcbnl: add appliction tlv handlers
      [net-next-2.6 PATCH 3/3] net_dcb: add application notifiers
      Signed-off-by: default avatarShmulik Ravid <shmulikr@broadcom.com>
      Acked-by: default avatarJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6241b625
    • John Fastabend's avatar
      net_dcb: add application notifiers · 96b99684
      John Fastabend authored
      
      
      DCBx applications priorities can be changed dynamically. If
      application stacks are expected to keep the skb priority
      consistent with the dcbx priority the stack will need to
      be notified when these changes occur.
      
      This patch adds application notifiers for the stack to register
      with.
      Signed-off-by: default avatarJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      96b99684
    • John Fastabend's avatar
      dcbnl: add appliction tlv handlers · 9ab933ab
      John Fastabend authored
      
      
      This patch adds application tlv handlers. Networking stacks
      may use the application priority to set the skb priority of
      their stack using the negoatiated dcbx priority.
      
      This patch provides the dcb_{get|set}app() routines for the
      stack to query these parameters. Notice lower layer drivers
      can use the dcbnl_ops routines if additional handling is
      needed. Perhaps in the firmware case for example
      Signed-off-by: default avatarJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: default avatarShmulik Ravid <shmulikr@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9ab933ab
    • John Fastabend's avatar
      dcbnl: add support for ieee8021Qaz attributes · 3e29027a
      John Fastabend authored
      
      
      The IEEE8021Qaz is the IEEE standard version of CEE. The
      standard has had enough significant changes from the CEE
      version that many of the CEE attributes have no meaning
      in the new spec or do not easily map to IEEE standards.
      
      Rather then attempt to create a complicated mapping
      between CEE and IEEE standards this patch adds a nested
      IEEE attribute to the list of DCB attributes. The policy
      is,
      
      	[DCB_ATTR_IFNAME]
      	[DCB_ATTR_STATE]
      	...
      	[DCB_ATTR_IEEE]
      		[DCB_ATTR_IEEE_ETS]
      		[DCB_ATTR_IEEE_PFC]
      		[DCB_ATTR_IEEE_APP_TABLE]
      			[DCB_ATTR_IEEE_APP]
      			...
      
      The following dcbnl_rtnl_ops routines were added to handle
      the IEEE standard,
      
      	int (*ieee_getets) (struct net_device *, struct ieee_ets *);
      	int (*ieee_setets) (struct net_device *, struct ieee_ets *);
      	int (*ieee_getpfc) (struct net_device *, struct ieee_pfc *);
      	int (*ieee_setpfc) (struct net_device *, struct ieee_pfc *);
      	int (*ieee_getapp) (struct net_device *, struct dcb_app *);
      	int (*ieee_setapp) (struct net_device *, struct dcb_app *);
      Signed-off-by: default avatarJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3e29027a
  6. 23 Dec, 2010 1 commit
    • David S. Miller's avatar
      Revert "ipv4: Allow configuring subnets as local addresses" · e0584649
      David S. Miller authored
      This reverts commit 4465b469.
      
      Conflicts:
      
      	net/ipv4/fib_frontend.c
      
      As reported by Ben Greear, this causes regressions:
      
      > Change 4465b469
      
       caused rules
      > to stop matching the input device properly because the
      > FLOWI_FLAG_MATCH_ANY_IIF is always defined in ip_dev_find().
      >
      > This breaks rules such as:
      >
      > ip rule add pref 512 lookup local
      > ip rule del pref 0 lookup local
      > ip link set eth2 up
      > ip -4 addr add 172.16.0.102/24 broadcast 172.16.0.255 dev eth2
      > ip rule add to 172.16.0.102 iif eth2 lookup local pref 10
      > ip rule add iif eth2 lookup 10001 pref 20
      > ip route add 172.16.0.0/24 dev eth2 table 10001
      > ip route add unreachable 0/0 table 10001
      >
      > If you had a second interface 'eth0' that was on a different
      > subnet, pinging a system on that interface would fail:
      >
      >   [root@ct503-60 ~]# ping 192.168.100.1
      >   connect: Invalid argument
      Reported-by: default avatarBen Greear <greearb@candelatech.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e0584649
  7. 22 Dec, 2010 7 commits
  8. 21 Dec, 2010 1 commit
    • David S. Miller's avatar
      net: Fix range checks in tcf_valid_offset(). · da521b2c
      David S. Miller authored
      
      
      This function has three bugs:
      
      1) The offset should be valid most of the time, this is just
         a sanity check, therefore we should use "likely" not "unlikely"
      
      2) This is the only place where we can check for arithmetic overflow
         of the pointer plus the length.
      
      3) The existing range checks are off by one, the valid range is
         skb->head to skb_tail_pointer(), inclusive.
      
      Based almost entirely upon a patch by Ralph Loader.
      Reported-by: default avatarRalph Loader <suckfish@ihug.co.nz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      da521b2c
  9. 20 Dec, 2010 7 commits
  10. 19 Dec, 2010 2 commits
  11. 16 Dec, 2010 5 commits
    • Octavian Purdila's avatar
      net: fix nulls list corruptions in sk_prot_alloc · fcbdf09d
      Octavian Purdila authored
      
      
      Special care is taken inside sk_port_alloc to avoid overwriting
      skc_node/skc_nulls_node. We should also avoid overwriting
      skc_bind_node/skc_portaddr_node.
      
      The patch fixes the following crash:
      
       BUG: unable to handle kernel paging request at fffffffffffffff0
       IP: [<ffffffff812ec6dd>] udp4_lib_lookup2+0xad/0x370
       [<ffffffff812ecc22>] __udp4_lib_lookup+0x282/0x360
       [<ffffffff812ed63e>] __udp4_lib_rcv+0x31e/0x700
       [<ffffffff812bba45>] ? ip_local_deliver_finish+0x65/0x190
       [<ffffffff812bbbf8>] ? ip_local_deliver+0x88/0xa0
       [<ffffffff812eda35>] udp_rcv+0x15/0x20
       [<ffffffff812bba45>] ip_local_deliver_finish+0x65/0x190
       [<ffffffff812bbbf8>] ip_local_deliver+0x88/0xa0
       [<ffffffff812bb2cd>] ip_rcv_finish+0x32d/0x6f0
       [<ffffffff8128c14c>] ? netif_receive_skb+0x99c/0x11c0
       [<ffffffff812bb94b>] ip_rcv+0x2bb/0x350
       [<ffffffff8128c14c>] netif_receive_skb+0x99c/0x11c0
      Signed-off-by: default avatarLeonard Crestez <lcrestez@ixiacom.com>
      Signed-off-by: default avatarOctavian Purdila <opurdila@ixiacom.com>
      Acked-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fcbdf09d
    • Eric Dumazet's avatar
      tcp: relax tcp_paws_check() · bc2ce894
      Eric Dumazet authored
      Some windows versions have wrong RFC1323 implementations, with SYN and
      SYNACKS messages containing zero tcp timestamps.
      
      We relaxed in commit fc1ad92d the passive connection case
      (Windows connects to a linux machine), but the reverse case (linux
      connects to a Windows machine) has an analogue problem when tsvals from
      windows machine are 'negative' (high order bit set) : PAWS triggers and
      we drops incoming messages.
      
      Fix this by making zero ts_recent value special, allowing frame to be
      processed.
      
      Based on a report and initial patch from Dmitiy Balakin
      
      Bugzilla reference : https://bugzilla.kernel.org/show_bug.cgi?id=24842
      
      
      
      Reported-by: dmitriy.balakin@nicneiron.ru
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bc2ce894
    • Octavian Purdila's avatar
      net: factorize sync-rcu call in unregister_netdevice_many · 44345724
      Octavian Purdila authored
      
      
      Add dev_close_many and dev_deactivate_many to factorize another
      sync-rcu operation on the netdevice unregister path.
      
      $ modprobe dummy numdummies=10000
      $ ip link set dev dummy* up
      $ time rmmod dummy
      
      Without the patch           With the patch
      
      real    0m 24.63s           real    0m 5.15s
      user    0m 0.00s            user    0m 0.00s
      sys     0m 6.05s            sys     0m 5.14s
      Signed-off-by: default avatarOctavian Purdila <opurdila@ixiacom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      44345724
    • Luis R. Rodriguez's avatar
      cfg80211: fix null pointer dereference with a custom regulatory request · 2784fe91
      Luis R. Rodriguez authored
      
      
      Once we moved the core regulatory request to the queue and let
      the scheduler process it last_request will have been left NULL
      until the schedular decides to process the first request. When
      this happens and we are loading a driver with a custom regulatory
      request like all Atheros drivers we end up with a NULL pointer
      dereference. We fix this by checking if the request was a
      custom one.
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
      IP: [<ffffffffa016de87>] freq_reg_info_regd.clone.2+0x27/0x130 [cfg80211]
      PGD 71f91067 PUD 712b2067 PMD 0
      Oops: 0000 [#1] PREEMPT SMP
      last sysfs file: /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1/firmware/2-1/loading
      CPU 0
      Modules linked in: ath9k_htc(+) ath9k_common ath9k_hw ath <etc>
      Pid: 3094, comm: insmod Tainted: G        W   2.6.37-rc5-wl #16 INVALID/28427ZQ
      RIP: 0010:[<ffffffffa016de87>]  [<ffffffffa016de87>] freq_reg_info_regd.clone.2+0x27/0x130 [cfg80211]
      RSP: 0018:ffff88007045db78  EFLAGS: 00010282
      RAX: 0000000000000000 RBX: ffffffffa047d9a0 RCX: ffff88007045dbd0
      RDX: 0000000000004e20 RSI: 000000000024cde0 RDI: ffff8800700483e0
      RBP: ffff88007045db98 R08: ffffffffa02f5b40 R09: 0000000000000001
      R10: 000000000000000e R11: 0000000000000001 R12: 0000000000000000
      R13: ffff88007004e3b0 R14: 0000000000000000 R15: ffff880070048340
      FS:  00007f635a707700(0000) GS:ffff880077400000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000004 CR3: 00000000708a9000 CR4: 00000000000006f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process insmod (pid: 3094, threadinfo ffff88007045c000, task ffff8800713e3ec0)
      Stack:
       ffffffffa047d9a0 0000000000000000 ffff88007004e3b0 0000000000000000
       ffff88007045dc08 ffffffffa016e147 000000007045dc08 0000000000000002
       ffff8800700483e0 ffffffffa02f5b40 ffff88007045dbd8 0000000000000000
      Call Trace:
       [<ffffffffa016e147>] wiphy_apply_custom_regulatory+0x137/0x1d0 [cfg80211]
       [<ffffffffa047a690>] ? ath9k_reg_notifier+0x0/0x50 [ath9k_htc]
       [<ffffffffa02f47f7>] ath_regd_init+0x347/0x430 [ath]
       [<ffffffffa047b1f5>] ath9k_htc_probe_device+0x6c5/0x960 [ath9k_htc]
       [<ffffffffa0472a2c>] ath9k_htc_hw_init+0xc/0x30 [ath9k_htc]
       [<ffffffffa04747e6>] ath9k_hif_usb_probe+0x216/0x3b0 [ath9k_htc]
       [<ffffffffa03bb6bc>] usb_probe_interface+0x10c/0x210 [usbcore]
       [<ffffffff812aec26>] driver_probe_device+0x96/0x1c0
       [<ffffffff812aedf3>] __driver_attach+0xa3/0xb0
       [<ffffffff812aed50>] ? __driver_attach+0x0/0xb0
       [<ffffffff812adaae>] bus_for_each_dev+0x5e/0x90
       [<ffffffff812ae8c9>] driver_attach+0x19/0x20
       [<ffffffff812ae438>] bus_add_driver+0x168/0x320
       [<ffffffff812af071>] driver_register+0x71/0x140
       [<ffffffff811fc4a8>] ? __raw_spin_lock_init+0x38/0x70
       [<ffffffffa03ba39c>] usb_register_driver+0xdc/0x190 [usbcore]
       [<ffffffffa03a2000>] ? ath9k_htc_init+0x0/0x4f [ath9k_htc]
       [<ffffffffa047499e>] ath9k_hif_usb_init+0x1e/0x20 [ath9k_htc]
       [<ffffffffa03a202b>] ath9k_htc_init+0x2b/0x4f [ath9k_htc]
       [<ffffffff8100212f>] do_one_initcall+0x3f/0x180
       [<ffffffff8109ef5b>] sys_init_module+0xbb/0x200
       [<ffffffff8100bf52>] system_call_fastpath+0x16/0x1b
      Code: <etc, who cares>
      RIP  [<ffffffffa016de87>] freq_reg_info_regd.clone.2+0x27/0x130 [cfg80211]
       RSP <ffff88007045db78>
      CR2: 0000000000000004
      ---[ end trace 79e4193601c8b713 ]---
      Reported-by: default avatarSujith Manoharan <Sujith.Manoharan@atheros.com>
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2784fe91
    • Jouni Malinen's avatar
      nl80211: Add notification for dropped Deauth/Disassoc · cf4e594e
      Jouni Malinen authored
      
      
      Add a new notification to indicate that a received, unprotected
      Deauthentication or Disassociation frame was dropped due to
      management frame protection being in use. This notification is
      needed to allow user space (e.g., wpa_supplicant) to implement
      SA Query procedure to recover from association state mismatch
      between an AP and STA.
      
      This is needed to avoid getting stuck in non-working state when MFP
      (IEEE 802.11w) is used and a protected Deauthentication or
      Disassociation frame is dropped for any reason. After that, the
      station would silently discard any unprotected Deauthentication or
      Disassociation frame that could be indicating that the AP does not
      have association for the STA (when the Reason Code would be 6 or 7).
      IEEE Std 802.11w-2009, 11.13 describes this recovery mechanism.
      Signed-off-by: default avatarJouni Malinen <j@w1.fi>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      cf4e594e
  12. 15 Dec, 2010 2 commits
  13. 14 Dec, 2010 1 commit
  14. 13 Dec, 2010 3 commits
    • David S. Miller's avatar
      net: Abstract default ADVMSS behind an accessor. · 0dbaee3b
      David S. Miller authored
      
      
      Make all RTAX_ADVMSS metric accesses go through a new helper function,
      dst_metric_advmss().
      
      Leave the actual default metric as "zero" in the real metric slot,
      and compute the actual default value dynamically via a new dst_ops
      AF specific callback.
      
      For stacked IPSEC routes, we use the advmss of the path which
      preserves existing behavior.
      
      Unlike ipv4/ipv6, DecNET ties the advmss to the mtu and thus updates
      advmss on pmtu updates.  This inconsistency in advmss handling
      results in more raw metric accesses than I wish we ended up with.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0dbaee3b
    • Johannes Berg's avatar
      cfg80211/nl80211: separate unicast/multicast default TX keys · dbd2fd65
      Johannes Berg authored
      
      
      Allow userspace to specify that a given key
      is default only for unicast and/or multicast
      transmissions. Only WEP keys are for both,
      WPA/RSN keys set here are GTKs for multicast
      only. For more future flexibility, allow to
      specify all combiations.
      
      Wireless extensions can only set both so use
      nl80211; WEP keys (connect keys) must be set
      as default for both (but 802.1X WEP is still
      possible).
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      dbd2fd65
    • Bruno Randolf's avatar
      cfg80211: Add antenna availability information · a7ffac95
      Bruno Randolf authored
      
      
      Add a field to wiphy for the hardware to report the availble antennas for
      configuration. Only if this is set to something bigger than zero, will the
      anntenna configuration ops be executed.
      
      Allthough this could be a simple number of antennas, I defined it as a bitmap
      of antennas which are available for configuration, since it's more consistent
      with the rest of the antenna API and there could be cases where the
      hardware allows only configuration of certain antennas. As it does not make
      much of a difference in size or normal usage, I think it's better to be able to
      support this, in case the need arises.
      
      The antenna configuration is now also checked against the availabe antennas and
      rejected if it does not match.
      Signed-off-by: default avatarBruno Randolf <br1@einfach.org>
      
      --
      v3:	always apply available antenna mask (for "all" antennas case).
      
      v2:	reject antenna configurations which don't match the available antennas
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      a7ffac95