* Re: [PATCH net-next-2.6] 3c59x: Fix call to mdio_sync() with the wrong argument
From: David Miller @ 2010-07-23 20:05 UTC (permalink / raw)
To: ben; +Cc: netdev, dktrkranz, 589989
In-Reply-To: <1279844308.4883.365.camel@localhost>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Fri, 23 Jul 2010 01:18:28 +0100
> commit a095cfc40ec7ebe63e9532383c5b5c2a27b14075
> "3c59x: Specify window explicitly for access to windowed registers"
> changed the first parameter to mdio_sync(), from a pointer to the
> register mapping, to a pointer to the vortex_private structure,
> and changed all but one of the call sites. Fix that last one.
>
> Reported-by: Luca Falavigna <dktrkranz@debian.org>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Applied.
^ permalink raw reply
* Re: [patch -next v2] mv643xx_eth: potential null dereference
From: David Miller @ 2010-07-23 20:05 UTC (permalink / raw)
To: buytenh; +Cc: error27, joe, jpirko, kirjanov, saeed, netdev, kernel-janitors
In-Reply-To: <20100723111818.GV21121@mail.wantstofly.org>
From: Lennert Buytenhek <buytenh@wantstofly.org>
Date: Fri, 23 Jul 2010 13:18:18 +0200
> On Fri, Jul 23, 2010 at 01:05:05PM +0200, Dan Carpenter wrote:
>
>> We assume that "pd" can be null on the previous line, and throughout the
>> function so we should check it here as well. This was introduced by
>> 9b2c2ff7a1c0 "mv643xx_eth: use sw csum for big packets"
>>
>> Signed-off-by: Dan Carpenter <error27@gmail.com>
>
> Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
Applied.
^ permalink raw reply
* Re: [PATCH] net: s2io: fix buffer overflow
From: David Miller @ 2010-07-23 20:06 UTC (permalink / raw)
To: segooon
Cc: kernel-janitors, ramkrishna.vepa, sivakumar.subramani,
sreenivasa.honnur, jon.mason, joe, jpirko, netdev
In-Reply-To: <1279902976-27146-1-git-send-email-segooon@gmail.com>
From: Kulikov Vasiliy <segooon@gmail.com>
Date: Fri, 23 Jul 2010 20:36:15 +0400
> vpd_data[] is allocated as kmalloc(256, GFP_KERNEL), so if cnt = 255
> then (cnt + 3) overflows 256. memset() is executed without checking.
> vpd_data[cnt+2] must be less than 256-cnt-2 as the latter is number of
> vpd_data[] elements to copy.
>
> Do not fill with zero the beginning of nic->serial_num as it will
> be filled with vpd_data[].
>
> String in product_name[] should be terminated by '\0'.
>
> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: 3c59x: fix leak of iomaps
From: David Miller @ 2010-07-23 20:06 UTC (permalink / raw)
To: segooon
Cc: kernel-janitors, klassert, eric.dumazet, ben, adobriyan, joe,
netdev
In-Reply-To: <1279903485-28247-1-git-send-email-segooon@gmail.com>
From: Kulikov Vasiliy <segooon@gmail.com>
Date: Fri, 23 Jul 2010 20:44:44 +0400
> If vortex_probe1() fails we should unmap ioaddr mapped earlier.
>
> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Applied. Thanks for following up on this.
^ permalink raw reply
* Re: 2.6.35-rc6: Reported regressions from 2.6.34
From: Rafael J. Wysocki @ 2010-07-23 20:09 UTC (permalink / raw)
To: Larry Finger
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Linus Torvalds, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
In-Reply-To: <4C49A577.3020306@lwfinger.net>
On Friday, July 23, 2010, Larry Finger wrote:
> On 07/23/2010 06:42 AM, Rafael J. Wysocki wrote:
> > This message contains a list of some regressions from 2.6.34,
> > for which there are no fixes in the mainline known to the tracking team.
> > If any of them have been fixed already, please let us know.
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16312
> > Subject : WARNING: at fs/fs-writeback.c:1127 __mark_inode_dirty
> > Submitter : Zdenek Kabelac<zdenek.kabelac@gmail.com>
> > Date : 2010-06-28 9:40 (26 days old)
> > Message-ID :<AANLkTin24fr5O4_q5Xbo9Y_NKkEmtcp6Hgmr9_4qXaFz@mail.gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127771804806465&w=2
>
> I still have this in 2.6.35-rc5.
Thanks for the update.
Rafael
^ permalink raw reply
* Re: Linux 2.6.35-rc6
From: Rafael J. Wysocki @ 2010-07-23 20:16 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Rothwell, Linus Torvalds, Linux Kernel Mailing List,
Russell King, James Bottomley, David Miller, netdev,
John W. Linville, Michal Marek, ACPI Devel Maling List
In-Reply-To: <20100723122213.GA689@kroah.com>
On Friday, July 23, 2010, Greg KH wrote:
> On Fri, Jul 23, 2010 at 11:21:42AM +1000, Stephen Rothwell wrote:
> > Hi Linus,
> >
> > On Thu, 22 Jul 2010 12:26:13 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > >
> > I actually hope/think that this is going to be the last -rc. Things
> > > have been pretty quiet, and while this -rc has more commits than -rc5
> > > had, it's not by a large amount, nor does it look scary to me. So
> > > there doesn't seem to be any point in dragging out the release any
> > > more, unless we find something new that calls for it.
> >
> > I have no idea how important this stuff is, but I still have the
> > following in linux-next that are (in theory) destined for v2.6.35:
>
> <snip>
>
> Yes, there are a few minor USB patches in my tree (minor bugfixes and
> new device ids) that I wanted to send to you, but no need to hold up a
> .35 release.
>
> We're still working on the network namespace sysfs issues, but if that
> option is disabled, all works fine. I have 3 tiny patches to work to
> resolve that problem in my tree, I can send them to you tonight if you
> want.
>
> But even there, nothing that should hold up .35 from release.
There are a few things, including regression fixes, in the ACPI land AFAICS.
Rafael
^ permalink raw reply
* Re: [PATCH] iproute: fix tc generating ipv6 priority filter
From: Stephen Hemminger @ 2010-07-23 20:21 UTC (permalink / raw)
To: Petr Lautrbach; +Cc: shemminger, netdev
In-Reply-To: <1276522588-23727-1-git-send-email-plautrba@redhat.com>
On Mon, 14 Jun 2010 15:36:28 +0200
Petr Lautrbach <plautrba@redhat.com> wrote:
> This patch adds ipv6 filter priority/traffic class function
> static int parse_ip6_class(int *argc_p, char ***argv_p, struct tc_u32_sel *sel)
> shifting filter value to 5th bit and ignoring "at" as header position
> is exactly given.
>
> Signed-off-by: Petr Lautrbach <plautrba@redhat.com>
> ---
> Hello,
>
> According to [1], tc doesn't generate right filters for IPv6
> "priority".
>
> Priority or Traffic Classes is 8 bits starting at 5th bit
> based on RFC 2460 [2]. There is parse_u8(&argc, &argv, sel, 4, 0)
> function used in current version, which shifts filter by 4 bytes
> instead of 4 bits.
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=584913
> [2] http://www.faqs.org/rfcs/rfc2460.html
>
> tc/f_u32.c | 39 ++++++++++++++++++++++++++++++++++++++-
> 1 files changed, 38 insertions(+), 1 deletions(-)
>
> diff --git a/tc/f_u32.c b/tc/f_u32.c
> index 4f5f74e..31e13b5 100644
> --- a/tc/f_u32.c
> +++ b/tc/f_u32.c
> @@ -403,6 +403,43 @@ static int parse_ip6_addr(int *argc_p, char ***argv_p,
> return res;
> }
>
> +static int parse_ip6_class(int *argc_p, char ***argv_p, struct tc_u32_sel *sel)
> +{
> + int res = -1;
> + int argc = *argc_p;
> + char **argv = *argv_p;
> + __u32 key;
> + __u32 mask;
> + int off = 0;
> + int offmask = 0;
> +
> + if (argc < 2)
> + return -1;
> +
> + if (get_u32(&key, *argv, 0))
> + return -1;
> + argc--; argv++;
> +
> + if (get_u32(&mask, *argv, 16))
> + return -1;
> + argc--; argv++;
> +
> + if (key > 0xFF || mask > 0xFF)
> + return -1;
> +
> + key <<= 20;
> + mask <<= 20;
> + key = htonl(key);
> + mask = htonl(mask);
> +
> + if (res = pack_key(sel, key, mask, off, offmask) < 0)
> + return -1;
> +
> + *argc_p = argc;
> + *argv_p = argv;
> + return 0;
> +}
> +
> static int parse_ether_addr(int *argc_p, char ***argv_p,
> struct tc_u32_sel *sel, int off)
> {
> @@ -522,7 +559,7 @@ static int parse_ip6(int *argc_p, char ***argv_p, struct tc_u32_sel *sel)
> res = parse_ip6_addr(&argc, &argv, sel, 24);
> } else if (strcmp(*argv, "priority") == 0) {
> NEXT_ARG();
> - res = parse_u8(&argc, &argv, sel, 4, 0);
> + res = parse_ip6_class(&argc, &argv, sel);
> } else if (strcmp(*argv, "protocol") == 0) {
> NEXT_ARG();
> res = parse_u8(&argc, &argv, sel, 6, 0);
Applied
--
^ permalink raw reply
* Re: [PATCH] iproute2: Add dsfield as alias for tos for ip rules
From: Stephen Hemminger @ 2010-07-23 20:22 UTC (permalink / raw)
To: Arnd Hannemann; +Cc: shemminger, netdev
In-Reply-To: <1274451009-29456-1-git-send-email-hannemann@nets.rwth-aachen.de>
On Fri, 21 May 2010 16:10:09 +0200
Arnd Hannemann <hannemann@nets.rwth-aachen.de> wrote:
> From: Arnd Hannemann <arnd@rhea.(none)>
>
> Get ip rule parsing of "dsfield" in sync with ip route parsing and manual page.
>
> Signed-off-by: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
> ---
> ip/iprule.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/ip/iprule.c b/ip/iprule.c
> index 7140375..cbf8226 100644
> --- a/ip/iprule.c
> +++ b/ip/iprule.c
> @@ -270,7 +270,8 @@ static int iprule_modify(int cmd, int argc, char **argv)
> if (get_u32(&pref, *argv, 0))
> invarg("preference value is invalid\n", *argv);
> addattr32(&req.n, sizeof(req), FRA_PRIORITY, pref);
> - } else if (strcmp(*argv, "tos") == 0) {
> + } else if (strcmp(*argv, "tos") == 0 ||
> + matches(*argv, "dsfield") == 0) {
> __u32 tos;
> NEXT_ARG();
> if (rtnl_dsfield_a2n(&tos, *argv))
Applied
--
^ permalink raw reply
* Re: [PATCH] bonding: set device in RLB ARP packet handler
From: Andy Gospodarek @ 2010-07-23 20:25 UTC (permalink / raw)
To: Greg Edwards
Cc: Andy Gospodarek, Jay Vosburgh,
bonding-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <20100723195947.GA7123@w-gedwards.lhn.com>
On Fri, Jul 23, 2010 at 01:59:47PM -0600, Greg Edwards wrote:
> On Fri, Jul 23, 2010 at 07:34:56PM +0000, Andy Gospodarek wrote:
> > On Thu, Jul 22, 2010 at 3:52 PM, Greg Edwards <greg.edwards@hp.com> wrote:
> >> With commit 6146b1a4, the dev field in the RLB ARP packet handler was
> >> set to NULL to wildcard and accommodate balancing VLANs on top of
> >> bonds.
> >>
> >> This has the side-effect of the packet handler being called against
> >> other, non RLB-enabled bonds, and a kernel oops results when it tries
> >> to
> >> dereference rx_hashtbl in rlb_update_entry_from_arp(), which won't be
> >> set for those bonds, e.g. active-backup.
> >>
> >> With the __netif_receive_skb() changes from commit 1f3c8804, frames
> >> received on VLANs correctly make their way to the bond's handler,
> >> so we no longer need to wildcard the device.
> >
> > I see this problem as well, but I would propose to fix it another way to
> > not alter the receive path so close to the release of 2.6.35 and to
> > catch this for 802.3ad bonds as well.
>
> Is the problem demonstrable with 802.3ad bonds? bond_register_lacpdu()
> sets pk_type->dev = bond->dev.
>
Doh! You are right.
Plus Jay just posted your patch again, so we can go with that solution.
> >> Signed-off-by: Greg Edwards <greg.edwards@hp.com>
> >> ---
> >> Jay,
> >>
> >> The oops can be reproduced by:
> >>
> >> modprobe bonding
> >>
> >> echo active-backup > /sys/class/net/bond0/bonding/mode
> >> echo 100 > /sys/class/net/bond0/bonding/miimon
> >> ifconfig bond0 xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx
> >> echo +eth0 > /sys/class/net/bond0/bonding/slaves
> >> echo +eth1 > /sys/class/net/bond0/bonding/slaves
> >>
> >> echo +bond1 > /sys/class/net/bonding_masters
> >> echo balance-alb > /sys/class/net/bond1/bonding/mode
> >> echo 100 > /sys/class/net/bond1/bonding/miimon
> >> ifconfig bond1 xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx
> >> echo +eth2 > /sys/class/net/bond1/bonding/slaves
> >> echo +eth3 > /sys/class/net/bond1/bonding/slaves
> >>
> >> Pass some traffic on bond0. Boom.
> >>
> >
> > bonding: make sure mode-specific handlers handle appropriate frames
> >
> > This patch will exit out of rlb_arp_recv and bond_3ad_lacpdu_recv early
> > if the bond receiving the frame isn't using that mode.
>
> I had originally thought of doing something like this, but it didn't
> seem as clean. I don't have strong feelings one way or the other,
> though.
>
> Greg
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next-2.6] bonding: set device in RLB ARP packet handler
From: Andy Gospodarek @ 2010-07-23 20:26 UTC (permalink / raw)
To: Jay Vosburgh
Cc: Greg Edwards, netdev, David S. Miller, bonding-devel,
linux-kernel
In-Reply-To: <28252.1279915324@death>
On Fri, Jul 23, 2010 at 01:02:04PM -0700, Jay Vosburgh wrote:
>
> From: Greg Edwards <greg.edwards@hp.com>
>
> After:
>
> commit 6146b1a4da98377e4abddc91ba5856bef8f23f1e
> Author: Jay Vosburgh <fubar@us.ibm.com>
> Date: Tue Nov 4 17:51:15 2008 -0800
>
> bonding: Fix ALB mode to balance traffic on VLANs
>
> the dev field in the RLB ARP packet handler was set to NULL to wildcard
> and accommodate balancing VLANs on top of bonds.
>
> This has the side-effect of the packet handler being called against
> other, non RLB-enabled bonds, and a kernel oops results when it tries to
> dereference rx_hashtbl in rlb_update_entry_from_arp(), which won't be
> set for those bonds, e.g. active-backup.
>
> With the __netif_receive_skb() changes from:
>
> commit 1f3c8804acba841b5573b953f5560d2683d2db0d
> Author: Andy Gospodarek <andy@greyhouse.net>
> Date: Mon Dec 14 10:48:58 2009 +0000
>
> bonding: allow arp_ip_targets on separate vlans to use arp validation
>
> frames received on VLANs correctly make their way to the bond's handler,
> so we no longer need to wildcard the device.
>
> The oops can be reproduced by:
>
> modprobe bonding
>
> echo active-backup > /sys/class/net/bond0/bonding/mode
> echo 100 > /sys/class/net/bond0/bonding/miimon
> ifconfig bond0 xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx
> echo +eth0 > /sys/class/net/bond0/bonding/slaves
> echo +eth1 > /sys/class/net/bond0/bonding/slaves
>
> echo +bond1 > /sys/class/net/bonding_masters
> echo balance-alb > /sys/class/net/bond1/bonding/mode
> echo 100 > /sys/class/net/bond1/bonding/miimon
> ifconfig bond1 xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx
> echo +eth2 > /sys/class/net/bond1/bonding/slaves
> echo +eth3 > /sys/class/net/bond1/bonding/slaves
>
> Pass some traffic on bond0. Boom.
>
> [ Tested, behaves as advertised. I do not believe a test of the bonding
> mode is necessary, as there is no race between the packet handler and
> the bonding mode changing (the mode can only change when the device is
> closed). Also updated the log message to include the reproduction and
> full commit ids. -J ]
>
> Signed-off-by: Greg Edwards <greg.edwards@hp.com>
> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Acked-by: Andy Gospodarek <andy@greyhouse.net>
>
> ---
>
> drivers/net/bonding/bond_alb.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
> index df48307..8d7dfd2 100644
> --- a/drivers/net/bonding/bond_alb.c
> +++ b/drivers/net/bonding/bond_alb.c
> @@ -822,7 +822,7 @@ static int rlb_initialize(struct bonding *bond)
>
> /*initialize packet type*/
> pk_type->type = cpu_to_be16(ETH_P_ARP);
> - pk_type->dev = NULL;
> + pk_type->dev = bond->dev;
> pk_type->func = rlb_arp_recv;
>
> /* register to receive ARPs */
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* pull request: wireless-next-2.6 2010-07-23
From: John W. Linville @ 2010-07-23 20:40 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Dave,
Yet another batch intended for 2.6.36... Mostly the usual random lot
of stuff, mostly driver updates. This batch also includes a flurry
of Sparse-inspired patches from me -- it is hard to resist once the
"bug" bites! As usual, all of these have been cooking in linux-next
for at least several days.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit e955cead031177b083fbf18d04a03c06e330a439:
CAN: Add Flexcan CAN controller driver (2010-07-22 18:06:25 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git master
Bob Copeland (2):
ath5k: move reset to mac80211 workqueue
ath5k: disable tasklets during reset
Bruno Randolf (1):
ath5k: clean up rxlink handling
Christian Lamparter (1):
mac80211: skip HT parsing if HW does not support HT
Dan Carpenter (1):
orinoco_usb: potential null dereference
David Gnedt (1):
mac80211: set carrier on for monitor interfaces on ieee80211_open
Felix Fietkau (3):
ath9k: another fix for the A-MPDU buffer leak
ath9k_hw: remove initvals for hardware which was never sold
mac80211: fix aggregation action frame handling with AP VLANs
Joe Perches (1):
drivers/net/wireless: Remove unnecessary casts of private_data
Johannes Berg (5):
cfg80211: don't get expired BSSes
mac80211: move QoS-enable to BSS info
mac80211: refuse shared key auth when WEP is unavailable
mac80211: fix IBSS lockdep complaint
mac80211: proper IBSS locking
John W. Linville (16):
libertas: convert new uses of __attribute__ ((packed)) to __packed
iwlwifi: convert new uses of __attribute__ ((packed)) to __packed
mac80211: improve error checking if WEP fails to init
wireless: only use alpha2 regulatory information from country IE
wireless: correct sparse warning in lib80211_crypt_tkip.c
wireless: correct sparse warning in wext-compat.c
wireless: correct sparse warning in generated regdb.c
wireless: mark cfg80211_is_all_idle as static
ath9k: correct sparse identified endian bug in ath_paprd_calibrate
ipw2100: mark ipw2100_pm_qos_req static
libipw: correct sparse warnings and mark some variables static
rt2x00: correct sparse warning in rt2x00debug.c
wireless: remove unnecessary reg_same_country_ie_hint
mwl8k: correct/silence sparse warnings
rtl8180: improve signal reporting for rtl8185 hardware
b43: silence most sparse warnings
Kulikov Vasiliy (1):
wireless: airo: delete netdev from list after it is freed
Larry Finger (1):
b43: silence phy_n sparse warnings
Luis R. Rodriguez (2):
ath9k_htc: make ath9k_htc_tx_aggr_oper() static
ath9k_hw: Fix AR9003 MPDU delimeter CRC check for middle subframes
Maxime Bizon (1):
cfg80211: fix race between sysfs and cfg80211
Pavel Roskin (1):
ath9k: remove unneeded calculation of minimal calibration power
Rajkumar Manoharan (1):
ath9k: fix panic while cleaning up virtaul wifis
Vivek Natarajan (1):
ath9k: Fix the LED behaviour in idle unassociated state.
Wey-Yi Guy (3):
iwlwifi: additional statistic debug counter
iwlwifi: more statistics counter for agn in debugfs
iwlwifi: "recover_from_tx_stall" function for 4965
drivers/net/wireless/airo.c | 24 +-
drivers/net/wireless/ath/ath5k/base.c | 65 +-
drivers/net/wireless/ath/ath5k/base.h | 4 +-
drivers/net/wireless/ath/ath5k/debug.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9002_hw.c | 66 -
drivers/net/wireless/ath/ath9k/ar9002_initvals.h | 4141 ++++++----------------
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 31 +-
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 7 +-
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 4 -
drivers/net/wireless/ath/ath9k/eeprom_def.c | 7 +-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 18 +-
drivers/net/wireless/ath/ath9k/init.c | 2 +-
drivers/net/wireless/ath/ath9k/main.c | 21 +-
drivers/net/wireless/ath/ath9k/xmit.c | 19 +-
drivers/net/wireless/b43/main.c | 2 +-
drivers/net/wireless/b43/phy_g.c | 2 +-
drivers/net/wireless/b43/phy_lp.c | 8 +-
drivers/net/wireless/b43/phy_n.c | 16 +-
drivers/net/wireless/b43/wa.c | 8 +-
drivers/net/wireless/ipw2x00/ipw2100.c | 2 +-
drivers/net/wireless/ipw2x00/libipw_module.c | 4 +-
drivers/net/wireless/ipw2x00/libipw_wx.c | 4 -
drivers/net/wireless/iwlwifi/iwl-4965.c | 1 +
drivers/net/wireless/iwlwifi/iwl-agn-debugfs.c | 7 +
drivers/net/wireless/iwlwifi/iwl-commands.h | 7 +-
drivers/net/wireless/iwlwifi/iwl-core.c | 18 +-
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 10 +-
drivers/net/wireless/libertas/cfg.c | 6 +-
drivers/net/wireless/libertas/debugfs.c | 4 +-
drivers/net/wireless/libertas/host.h | 6 +-
drivers/net/wireless/mwl8k.c | 22 +-
drivers/net/wireless/orinoco/orinoco_usb.c | 10 +-
drivers/net/wireless/rt2x00/rt2x00dump.h | 2 +-
drivers/net/wireless/rtl818x/rtl8180_dev.c | 11 +-
include/net/cfg80211.h | 4 +
include/net/mac80211.h | 11 +-
include/net/regulatory.h | 1 -
net/mac80211/cfg.c | 4 -
net/mac80211/ht.c | 2 +-
net/mac80211/ibss.c | 92 +-
net/mac80211/ieee80211_i.h | 7 +-
net/mac80211/iface.c | 6 +-
net/mac80211/mlme.c | 13 +-
net/mac80211/util.c | 7 +-
net/mac80211/wep.c | 5 +-
net/wireless/core.c | 14 +-
net/wireless/genregdb.awk | 1 +
net/wireless/lib80211_crypt_tkip.c | 2 +-
net/wireless/reg.c | 654 +----
net/wireless/scan.c | 5 +
net/wireless/sme.c | 2 +-
net/wireless/wext-compat.c | 1 +
52 files changed, 1405 insertions(+), 3987 deletions(-)
Omnibus patch available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2010-07-23.patch.bz2
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2010-07-23
From: David Miller @ 2010-07-23 21:03 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100723204029.GD2426-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Fri, 23 Jul 2010 16:40:29 -0400
> Yet another batch intended for 2.6.36... Mostly the usual random lot
> of stuff, mostly driver updates. This batch also includes a flurry
> of Sparse-inspired patches from me -- it is hard to resist once the
> "bug" bites! As usual, all of these have been cooking in linux-next
> for at least several days.
>
> Please let me know if there are problems!
Auto-merging drivers/net/wireless/iwlwifi/iwl-commands.h
CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl-commands.h
I don't even have to look at the file to know that it's
another one of those __packed things.
I'll fix it up again, but I know you can sense how tiring
this has become for me.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2010-07-23
From: John W. Linville @ 2010-07-23 21:39 UTC (permalink / raw)
To: David Miller
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100723.140320.116366019.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Fri, Jul 23, 2010 at 02:03:20PM -0700, David Miller wrote:
> From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
> Date: Fri, 23 Jul 2010 16:40:29 -0400
>
> > Yet another batch intended for 2.6.36... Mostly the usual random lot
> > of stuff, mostly driver updates. This batch also includes a flurry
> > of Sparse-inspired patches from me -- it is hard to resist once the
> > "bug" bites! As usual, all of these have been cooking in linux-next
> > for at least several days.
> >
> > Please let me know if there are problems!
>
> Auto-merging drivers/net/wireless/iwlwifi/iwl-commands.h
> CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl-commands.h
>
> I don't even have to look at the file to know that it's
> another one of those __packed things.
>
> I'll fix it up again, but I know you can sense how tiring
> this has become for me.
I'm sorry, Dave! I should have done a for-davem branch. FWIW,
I intended to do a test merge but it must have slipped my fragile
mind. :-(
John
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: 2.6.34.1: kernel warning at igb_main.c:2080
From: Wyborny, Carolyn @ 2010-07-23 21:48 UTC (permalink / raw)
To: Ben Greear, NetDev
In-Reply-To: <4C3FA03E.9090802@candelatech.com>
Hello Ben,
I'm not exactly sure why this happened and there's not a lot of info from the kernel, unfortunately. I've looked at the location in the code and it doesn't give me much more. Let me know if it is happening regularly and if you have steps to reliably reproduce it and we can look at it further.
We do appreciate the report.
Thanks,
Carolyn
>-----Original Message-----
>From: netdev-owner@vger.kernel.org
>[mailto:netdev-owner@vger.kernel.org] On Behalf Of Ben Greear
>Sent: Thursday, July 15, 2010 4:57 PM
>To: NetDev
>Subject: igb: 2.6.34.1: kernel warning at igb_main.c:2080
>
>We just saw this kernel warning on 2.6.34.1 + a few patches
>from the pending stable queue,
>plus our own hacks (though none to igb).
>
>We were running a modified version of pktgen traffic and at
>the same time
>bounced the port.
>
>This warning didn't seem to cause any real problems.
>
>Please let us know if you would like any additional information.
>
>]# lspci|grep Ethern
>01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit
>Network Connection
>02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit
>Network Connection
>05:00.0 Ethernet controller: Intel Corporation 82575EB Gigabit
>Network Connection (rev 02)
>05:00.1 Ethernet controller: Intel Corporation 82575EB Gigabit
>Network Connection (rev 02)
>06:00.0 Ethernet controller: Intel Corporation 82575EB Gigabit
>Network Connection (rev 02)
>06:00.1 Ethernet controller: Intel Corporation 82575EB Gigabit
>Network Connection (rev 02)
>
>
>Jul 15 16:36:01 localhost kernel: ------------[ cut here ]------------
>Jul 15 16:36:01 localhost kernel: WARNING: at
>/home/greearb/git/linux-2.6.dev.34.y/drivers/net/igb/igb_main.c
>:2080 igb_close+0x28/0x9f [igb]()
>Jul 15 16:36:01 localhost kernel: Hardware name: X8STi
>Jul 15 16:36:01 localhost kernel: Modules linked in: bridge
>arc4 michael_mic wanlink(P) 8021q garp xt_CT iptable_raw
>ipt_addrtype xt_DSCP xt_dscp xt_string
>xt_owner xt_NFQUEUE xt_multiport xt_mark xt_iprange
>xt_hashlimit xt_CONNMARK xt_connmark stp llc veth fuse macvlan
>bpctl_mod pktgen iscsi_tcp libiscsi_tcp
>libiscsi scsi_transport_iscsi nfs lockd fscache nfs_acl
>auth_rpcgss sunrpc ipv6 dm_multipath uinput i2c_i801 iTCO_wdt
>i2c_core ioatdma e1000e igb pcspkr
>iTCO_vendor_support dca ata_generic pata_acpi [last unloaded: nf_nat]
>Jul 15 16:36:01 localhost kernel: Pid: 17516, comm: ip
>Tainted: P 2.6.34.1 #2
>Jul 15 16:36:01 localhost kernel: Call Trace:
>Jul 15 16:36:01 localhost kernel: [<ffffffffa002a37f>] ?
>igb_close+0x28/0x9f [igb]
>Jul 15 16:36:01 localhost kernel: [<ffffffff81041bb6>]
>warn_slowpath_common+0x77/0x8f
>Jul 15 16:36:01 localhost kernel: [<ffffffff81041bdd>]
>warn_slowpath_null+0xf/0x11
>Jul 15 16:36:01 localhost kernel: [<ffffffffa002a37f>]
>igb_close+0x28/0x9f [igb]
>Jul 15 16:36:01 localhost kernel: [<ffffffff8133c626>]
>__dev_close+0x73/0x86
>Jul 15 16:36:01 localhost kernel: [<ffffffff8133a719>]
>__dev_change_flags+0xa8/0x12b
>Jul 15 16:36:01 localhost kernel: [<ffffffff8133c2aa>]
>dev_change_flags+0x1c/0x51
>Jul 15 16:36:01 localhost kernel: [<ffffffff813466bc>]
>do_setlink+0x273/0x482
>Jul 15 16:36:01 localhost kernel: [<ffffffff810ab1bb>] ?
>zone_statistics+0x5e/0x63
>Jul 15 16:36:01 localhost kernel: [<ffffffff8134755e>]
>rtnl_newlink+0x26c/0x422
>Jul 15 16:36:01 localhost kernel: [<ffffffff81345a06>] ?
>nla_nest_start+0x1d/0x31
>Jul 15 16:36:01 localhost kernel: [<ffffffff810ca997>] ?
>virt_to_head_page+0x9/0x2a
>Jul 15 16:36:01 localhost kernel: [<ffffffff813dd1f5>] ?
>__mutex_lock_common+0x38e/0x3ac
>Jul 15 16:36:01 localhost kernel: [<ffffffff81346ffb>]
>rtnetlink_rcv_msg+0x1d9/0x1f7
>Jul 15 16:36:01 localhost kernel: [<ffffffff81346e22>] ?
>rtnetlink_rcv_msg+0x0/0x1f7
>Jul 15 16:36:01 localhost kernel: [<ffffffff81356939>]
>netlink_rcv_skb+0x3e/0x8e
>Jul 15 16:36:01 localhost kernel: [<ffffffff81346cc9>]
>rtnetlink_rcv+0x20/0x29
>Jul 15 16:36:01 localhost kernel: [<ffffffff813567b2>]
>netlink_unicast+0xea/0x151
>Jul 15 16:36:01 localhost kernel: [<ffffffff8133545c>] ?
>memcpy_fromiovec+0x42/0x73
>Jul 15 16:36:01 localhost kernel: [<ffffffff81357bc8>]
>netlink_sendmsg+0x242/0x255
>Jul 15 16:36:01 localhost kernel: [<ffffffff8132a771>] ?
>__sock_recvmsg_nosec+0x29/0x2b
>Jul 15 16:36:01 localhost kernel: [<ffffffff8132bd02>]
>__sock_sendmsg+0x56/0x5f
>Jul 15 16:36:01 localhost kernel: [<ffffffff8132c127>]
>sock_sendmsg+0xa3/0xbc
>Jul 15 16:36:01 localhost kernel: [<ffffffff813351e5>] ?
>copy_from_user+0x28/0x30
>Jul 15 16:36:01 localhost kernel: [<ffffffff8133555e>] ?
>verify_iovec+0x52/0x95
>Jul 15 16:36:01 localhost kernel: [<ffffffff8132c368>]
>sys_sendmsg+0x1c6/0x22a
>Jul 15 16:36:01 localhost kernel: [<ffffffff810a277f>] ?
>lru_cache_add_lru+0x38/0x3d
>Jul 15 16:36:01 localhost kernel: [<ffffffff813de23e>] ?
>_raw_spin_unlock+0x2d/0x38
>Jul 15 16:36:01 localhost kernel: [<ffffffff810ad802>] ?
>spin_unlock+0x9/0xb
>Jul 15 16:36:01 localhost kernel: [<ffffffff810b0138>] ?
>handle_mm_fault+0x6d3/0x6f3
>Jul 15 16:36:01 localhost kernel: [<ffffffff810b3a0a>] ?
>__vma_link_rb+0x2b/0x2d
>Jul 15 16:36:01 localhost kernel: [<ffffffff810b45f7>] ?
>vma_link+0xcd/0xcf
>Jul 15 16:36:01 localhost kernel: [<ffffffff810d9369>] ?
>fget_light+0x39/0x87
>Jul 15 16:36:01 localhost kernel: [<ffffffff81083b91>] ?
>audit_syscall_entry+0xfe/0x12a
>Jul 15 16:36:01 localhost kernel: [<ffffffff81009ac2>]
>system_call_fastpath+0x16/0x1b
>Jul 15 16:36:01 localhost kernel: ---[ end trace 75242fae6dbfdf6d ]---
>
>
>Thanks,
>Ben
>
>--
>Ben Greear <greearb@candelatech.com>
>Candela Technologies Inc http://www.candelatech.com
>
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: 2.6.34.1: kernel warning at igb_main.c:2080
From: Ben Greear @ 2010-07-23 21:57 UTC (permalink / raw)
To: Wyborny, Carolyn; +Cc: NetDev
In-Reply-To: <EDC0E76513226749BFBC9C3FB031318FE1DF9DC1@orsmsx508.amr.corp.intel.com>
On 07/23/2010 02:48 PM, Wyborny, Carolyn wrote:
> Hello Ben,
>
> I'm not exactly sure why this happened and there's not a lot of info from the kernel, unfortunately. I've looked at the location in the code and it doesn't give me much more. Let me know if it is happening regularly and if you have steps to reliably reproduce it and we can look at it further.
>
> We do appreciate the report.
Thanks for looking. We haven't noticed this again.
If we figure out how to reproduce it reliably, I'll
let you know.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* RE: 2.6.34.1: kernel warning at igb_main.c:2080
From: Wyborny, Carolyn @ 2010-07-23 21:59 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev
In-Reply-To: <4C4A1038.5020707@candelatech.com>
>-----Original Message-----
>From: Ben Greear [mailto:greearb@candelatech.com]
>Sent: Friday, July 23, 2010 2:57 PM
>To: Wyborny, Carolyn
>Cc: NetDev
>Subject: Re: 2.6.34.1: kernel warning at igb_main.c:2080
>
>On 07/23/2010 02:48 PM, Wyborny, Carolyn wrote:
>> Hello Ben,
>>
>> I'm not exactly sure why this happened and there's not a lot
>of info from the kernel, unfortunately. I've looked at the
>location in the code and it doesn't give me much more. Let me
>know if it is happening regularly and if you have steps to
>reliably reproduce it and we can look at it further.
>>
>> We do appreciate the report.
>
>Thanks for looking. We haven't noticed this again.
>
>If we figure out how to reproduce it reliably, I'll
>let you know.
>
>Thanks,
>Ben
>
>--
>Ben Greear <greearb@candelatech.com>
>Candela Technologies Inc http://www.candelatech.com
>
>
Thanks Ben,
Sounds good.
Carolyn
^ permalink raw reply
* Re: [patch -next v2] mv643xx_eth: potential null dereference
From: Dan Carpenter @ 2010-07-23 22:15 UTC (permalink / raw)
To: walter harms
Cc: Joe Perches, Lennert Buytenhek, David S. Miller, Jiri Pirko,
Denis Kirjanov, Saeed Bishara, netdev, kernel-janitors
In-Reply-To: <4C49C39E.8020502@bfs.de>
On Fri, Jul 23, 2010 at 06:30:22PM +0200, walter harms wrote:
> this is a bit complicated, IMHO ppl have a bigger chance to discover what is going on
> with this version:
>
> if (!pd ) {
> msp->t_clk = 133000000;
> msp->tx_csum_limit = 9 * 1024;
> }
> else
> {
> msp->t_clk = pd->t_clk ? pd->t_clk : 133000000 ;
> msp->tx_csum_limit = pd->tx_csum_limit ? pd->tx_csum_limit : 9 * 1024;
> }
>
But then instead of 2 magic numbers we would have 4. :/
regards,
dan carpenter
^ permalink raw reply
* pktgen performance hit due to memset.
From: Ben Greear @ 2010-07-23 23:14 UTC (permalink / raw)
To: NetDev
Some time back, someone added some memset() calls to pktgen to
keep from leaking memory contents to the network.
At least in our modified version of pktgen, this caused about 25%
performance degradation when sending 1514 byte pkts (multi-pkt == 0)
on a pair of 10G ports. It was easy enough to comment these memset
calls out of course.
I don't mind if this patch stays in,
but thought I'd post my findings in case anyone else wonders why
their pktgen slowed down...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [net-next-2.6 PATCH] ixgbe: fix ethtool stats
From: Jeff Kirsher @ 2010-07-23 23:44 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, bphilips, Eric Dumazet, Jeff Kirsher
From: Eric Dumazet <eric.dumazet@gmail.com>
In latest changes about 64bit stats on 32bit arches,
[commit 28172739f0a276eb8 (net: fix 64 bit counters on 32 bit arches)],
I missed ixgbe uses a bit of magic in its ixgbe_gstrings_stats
definition.
IXGBE_NETDEV_STAT() must now assume offsets relative to
rtnl_link_stats64, not relative do dev->stats.
As a bonus, we also get 64bit stats on ethtool -S
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_ethtool.c | 42 +++++++++++++++++++------------------
1 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethtool.c b/drivers/net/ixgbe/ixgbe_ethtool.c
index da54b38..dcebc82 100644
--- a/drivers/net/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ixgbe/ixgbe_ethtool.c
@@ -54,14 +54,14 @@ struct ixgbe_stats {
sizeof(((struct ixgbe_adapter *)0)->m), \
offsetof(struct ixgbe_adapter, m)
#define IXGBE_NETDEV_STAT(m) NETDEV_STATS, \
- sizeof(((struct net_device *)0)->m), \
- offsetof(struct net_device, m) - offsetof(struct net_device, stats)
+ sizeof(((struct rtnl_link_stats64 *)0)->m), \
+ offsetof(struct rtnl_link_stats64, m)
static struct ixgbe_stats ixgbe_gstrings_stats[] = {
- {"rx_packets", IXGBE_NETDEV_STAT(stats.rx_packets)},
- {"tx_packets", IXGBE_NETDEV_STAT(stats.tx_packets)},
- {"rx_bytes", IXGBE_NETDEV_STAT(stats.rx_bytes)},
- {"tx_bytes", IXGBE_NETDEV_STAT(stats.tx_bytes)},
+ {"rx_packets", IXGBE_NETDEV_STAT(rx_packets)},
+ {"tx_packets", IXGBE_NETDEV_STAT(tx_packets)},
+ {"rx_bytes", IXGBE_NETDEV_STAT(rx_bytes)},
+ {"tx_bytes", IXGBE_NETDEV_STAT(tx_bytes)},
{"rx_pkts_nic", IXGBE_STAT(stats.gprc)},
{"tx_pkts_nic", IXGBE_STAT(stats.gptc)},
{"rx_bytes_nic", IXGBE_STAT(stats.gorc)},
@@ -69,27 +69,27 @@ static struct ixgbe_stats ixgbe_gstrings_stats[] = {
{"lsc_int", IXGBE_STAT(lsc_int)},
{"tx_busy", IXGBE_STAT(tx_busy)},
{"non_eop_descs", IXGBE_STAT(non_eop_descs)},
- {"rx_errors", IXGBE_NETDEV_STAT(stats.rx_errors)},
- {"tx_errors", IXGBE_NETDEV_STAT(stats.tx_errors)},
- {"rx_dropped", IXGBE_NETDEV_STAT(stats.rx_dropped)},
- {"tx_dropped", IXGBE_NETDEV_STAT(stats.tx_dropped)},
- {"multicast", IXGBE_NETDEV_STAT(stats.multicast)},
+ {"rx_errors", IXGBE_NETDEV_STAT(rx_errors)},
+ {"tx_errors", IXGBE_NETDEV_STAT(tx_errors)},
+ {"rx_dropped", IXGBE_NETDEV_STAT(rx_dropped)},
+ {"tx_dropped", IXGBE_NETDEV_STAT(tx_dropped)},
+ {"multicast", IXGBE_NETDEV_STAT(multicast)},
{"broadcast", IXGBE_STAT(stats.bprc)},
{"rx_no_buffer_count", IXGBE_STAT(stats.rnbc[0]) },
- {"collisions", IXGBE_NETDEV_STAT(stats.collisions)},
- {"rx_over_errors", IXGBE_NETDEV_STAT(stats.rx_over_errors)},
- {"rx_crc_errors", IXGBE_NETDEV_STAT(stats.rx_crc_errors)},
- {"rx_frame_errors", IXGBE_NETDEV_STAT(stats.rx_frame_errors)},
+ {"collisions", IXGBE_NETDEV_STAT(collisions)},
+ {"rx_over_errors", IXGBE_NETDEV_STAT(rx_over_errors)},
+ {"rx_crc_errors", IXGBE_NETDEV_STAT(rx_crc_errors)},
+ {"rx_frame_errors", IXGBE_NETDEV_STAT(rx_frame_errors)},
{"hw_rsc_aggregated", IXGBE_STAT(rsc_total_count)},
{"hw_rsc_flushed", IXGBE_STAT(rsc_total_flush)},
{"fdir_match", IXGBE_STAT(stats.fdirmatch)},
{"fdir_miss", IXGBE_STAT(stats.fdirmiss)},
- {"rx_fifo_errors", IXGBE_NETDEV_STAT(stats.rx_fifo_errors)},
- {"rx_missed_errors", IXGBE_NETDEV_STAT(stats.rx_missed_errors)},
- {"tx_aborted_errors", IXGBE_NETDEV_STAT(stats.tx_aborted_errors)},
- {"tx_carrier_errors", IXGBE_NETDEV_STAT(stats.tx_carrier_errors)},
- {"tx_fifo_errors", IXGBE_NETDEV_STAT(stats.tx_fifo_errors)},
- {"tx_heartbeat_errors", IXGBE_NETDEV_STAT(stats.tx_heartbeat_errors)},
+ {"rx_fifo_errors", IXGBE_NETDEV_STAT(rx_fifo_errors)},
+ {"rx_missed_errors", IXGBE_NETDEV_STAT(rx_missed_errors)},
+ {"tx_aborted_errors", IXGBE_NETDEV_STAT(tx_aborted_errors)},
+ {"tx_carrier_errors", IXGBE_NETDEV_STAT(tx_carrier_errors)},
+ {"tx_fifo_errors", IXGBE_NETDEV_STAT(tx_fifo_errors)},
+ {"tx_heartbeat_errors", IXGBE_NETDEV_STAT(tx_heartbeat_errors)},
{"tx_timeout_count", IXGBE_STAT(tx_timeout_count)},
{"tx_restart_queue", IXGBE_STAT(restart_queue)},
{"rx_long_length_errors", IXGBE_STAT(stats.roc)},
^ permalink raw reply related
* Re: pktgen performance hit due to memset.
From: David Miller @ 2010-07-24 1:51 UTC (permalink / raw)
To: greearb; +Cc: netdev
In-Reply-To: <4C4A224B.8080806@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
Date: Fri, 23 Jul 2010 16:14:19 -0700
> Some time back, someone added some memset() calls to pktgen to
> keep from leaking memory contents to the network.
>
> At least in our modified version of pktgen, this caused about 25%
> performance degradation when sending 1514 byte pkts (multi-pkt == 0)
> on a pair of 10G ports. It was easy enough to comment these memset
> calls out of course.
>
> I don't mind if this patch stays in,
> but thought I'd post my findings in case anyone else wonders why
> their pktgen slowed down...
Thanks for the data point Ben.
^ permalink raw reply
* [PATCH] xt_length: support ipv6 jumbo frames
From: Changli Gao @ 2010-07-24 3:32 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David S. Miller, netfilter-devel, netdev, Changli Gao
In order to support ipv6 jumbo frames, the type of min and max in xt_length_info
is changed to __u32. Since the structure xt_length_info is updated, the revision
is updated to 1 from 0, and the old revision is still reserved to keep binary
compatible with the older version of iptables.
skb->len is used to keep consistency.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
----
include/linux/netfilter/xt_length.h | 2 +-
net/netfilter/xt_length.c | 36 +++++++++++++++++++++++++++---------
2 files changed, 28 insertions(+), 10 deletions(-)
diff --git a/include/linux/netfilter/xt_length.h b/include/linux/netfilter/xt_length.h
index b82ed7c..a12785c 100644
--- a/include/linux/netfilter/xt_length.h
+++ b/include/linux/netfilter/xt_length.h
@@ -4,7 +4,7 @@
#include <linux/types.h>
struct xt_length_info {
- __u16 min, max;
+ __u32 min, max;
__u8 invert;
};
diff --git a/net/netfilter/xt_length.c b/net/netfilter/xt_length.c
index 176e557..579f340 100644
--- a/net/netfilter/xt_length.c
+++ b/net/netfilter/xt_length.c
@@ -20,21 +20,23 @@ MODULE_LICENSE("GPL");
MODULE_ALIAS("ipt_length");
MODULE_ALIAS("ip6t_length");
-static bool
-length_mt(const struct sk_buff *skb, struct xt_action_param *par)
+struct xt_length_info_v0 {
+ __u16 min, max;
+ __u8 invert;
+};
+
+static bool length_mt_v0(const struct sk_buff *skb, struct xt_action_param *par)
{
- const struct xt_length_info *info = par->matchinfo;
- u_int16_t pktlen = ntohs(ip_hdr(skb)->tot_len);
+ const struct xt_length_info_v0 *info = par->matchinfo;
+ u_int16_t pktlen = skb->len;
return (pktlen >= info->min && pktlen <= info->max) ^ info->invert;
}
-static bool
-length_mt6(const struct sk_buff *skb, struct xt_action_param *par)
+static bool length_mt(const struct sk_buff *skb, struct xt_action_param *par)
{
const struct xt_length_info *info = par->matchinfo;
- const u_int16_t pktlen = ntohs(ipv6_hdr(skb)->payload_len) +
- sizeof(struct ipv6hdr);
+ u_int32_t pktlen = skb->len;
return (pktlen >= info->min && pktlen <= info->max) ^ info->invert;
}
@@ -43,16 +45,32 @@ static struct xt_match length_mt_reg[] __read_mostly = {
{
.name = "length",
.family = NFPROTO_IPV4,
+ .match = length_mt_v0,
+ .matchsize = sizeof(struct xt_length_info_v0),
+ .me = THIS_MODULE,
+ },
+ {
+ .name = "length",
+ .family = NFPROTO_IPV6,
+ .match = length_mt_v0,
+ .matchsize = sizeof(struct xt_length_info_v0),
+ .me = THIS_MODULE,
+ },
+ {
+ .name = "length",
+ .family = NFPROTO_IPV4,
.match = length_mt,
.matchsize = sizeof(struct xt_length_info),
.me = THIS_MODULE,
+ .revision = 1,
},
{
.name = "length",
.family = NFPROTO_IPV6,
- .match = length_mt6,
+ .match = length_mt,
.matchsize = sizeof(struct xt_length_info),
.me = THIS_MODULE,
+ .revision = 1,
},
};
^ permalink raw reply related
* [PATCH net-next-2.6] pktgen: Optionally leak kernel memory
From: Eric Dumazet @ 2010-07-24 5:23 UTC (permalink / raw)
To: Ben Greear, David Miller; +Cc: NetDev
In-Reply-To: <4C4A224B.8080806@candelatech.com>
Le vendredi 23 juillet 2010 à 16:14 -0700, Ben Greear a écrit :
> Some time back, someone added some memset() calls to pktgen to
> keep from leaking memory contents to the network.
>
Well, someone might be me ;)
> At least in our modified version of pktgen, this caused about 25%
> performance degradation when sending 1514 byte pkts (multi-pkt == 0)
> on a pair of 10G ports. It was easy enough to comment these memset
> calls out of course.
>
> I don't mind if this patch stays in,
> but thought I'd post my findings in case anyone else wonders why
> their pktgen slowed down...
>
Thanks Ben
Here is a patch adding a new pktgen flag, so that admins can choose
speed if they want to, if they dont use clone_skb to reduce skb setup
costs.
Oc course, admins could change pktgen code themselves, but as you said,
better document it so that admins are aware of this possible speed
increase.
[PATCH net-next-2.6] pktgen: Optionally leak kernel memory
Commit 66ed1e5ec1d979 (pktgen: Dont leak kernel memory)
closed a security hole, by making sure data sent to network was cleared,
instead of using previous content of pages.
As Ben Greear noticed, this can slow down pktgen as much as 25%.
Add a new pktgen flag, UNSAFE, to ask pktgen to not clear data and use
previous content of memory.
Also add documentation for UNSAFE and NODE_ALLOC flags
Reported-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
Documentation/networking/pktgen.txt | 24 ++++++++++++++++++++++-
net/core/pktgen.c | 27 +++++++++++++++++++++-----
2 files changed, 45 insertions(+), 6 deletions(-)
diff --git a/Documentation/networking/pktgen.txt b/Documentation/networking/pktgen.txt
index 75e4fd7..88e2e6f 100644
--- a/Documentation/networking/pktgen.txt
+++ b/Documentation/networking/pktgen.txt
@@ -108,7 +108,10 @@ Examples:
MPLS_RND, VID_RND, SVID_RND
QUEUE_MAP_RND # queue map random
QUEUE_MAP_CPU # queue map mirrors smp_processor_id()
-
+ NODE_ALLOC # NUMA aware skb allocations
+ UNSAFE # Dont clear packets payload
+ (Might be 25% faster, but can leak sensitive
+ data to network. Use at your own risk !)
pgset "udp_src_min 9" set UDP source port min, If < udp_src_max, then
cycle through the port range.
@@ -178,6 +181,18 @@ Note when adding devices to a specific CPU there good idea to also assign
as this reduces cache bouncing when freeing skb's.
+Very fast mode
+==============
+One knob to get very fast pktgen is the UNSAFE flag :
+
+flag UNSAFE
+
+This ask to pktgen to not clear content of packets before sending them.
+Note this is a security problem, and should be used only if really needed.
+If packets are cloned (clone_skb 1000), clearing data cost is amortized so
+this UNSAFE mode is less interesting.
+
+
Current commands and configuration options
==========================================
@@ -225,6 +240,13 @@ flag
UDPDST_RND
MACSRC_RND
MACDST_RND
+ MPLS_RND
+ VID_RND
+ SVID_RND
+ FLOW_SEQ
+ IPSEC
+ NODE_ALLOC
+ UNSAFE
dst_min
dst_max
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 24a19de..01990cb 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -172,7 +172,7 @@
#include <asm/dma.h>
#include <asm/div64.h> /* do_div */
-#define VERSION "2.74"
+#define VERSION "2.75"
#define IP_NAME_SZ 32
#define MAX_MPLS_LABELS 16 /* This is the max label stack depth */
#define MPLS_STACK_BOTTOM htonl(0x00000100)
@@ -196,6 +196,7 @@
#define F_QUEUE_MAP_RND (1<<13) /* queue map Random */
#define F_QUEUE_MAP_CPU (1<<14) /* queue map mirrors smp_processor_id() */
#define F_NODE (1<<15) /* Node memory alloc*/
+#define F_UNSAFE (1<<16) /* Payload of packets is left uninitialized */
/* Thread control flag bits */
#define T_STOP (1<<0) /* Stop run */
@@ -674,6 +675,9 @@ static int pktgen_if_show(struct seq_file *seq, void *v)
if (pkt_dev->flags & F_NODE)
seq_printf(seq, "NODE_ALLOC ");
+ if (pkt_dev->flags & F_UNSAFE)
+ seq_printf(seq, "UNSAFE ");
+
seq_puts(seq, "\n");
/* not really stopped, more like last-running-at */
@@ -1231,12 +1235,20 @@ static ssize_t pktgen_if_write(struct file *file,
else if (strcmp(f, "!NODE_ALLOC") == 0)
pkt_dev->flags &= ~F_NODE;
+ else if (strcmp(f, "UNSAFE") == 0)
+ pkt_dev->flags |= F_UNSAFE;
+
+ else if (strcmp(f, "!UNSAFE") == 0)
+ pkt_dev->flags &= ~F_UNSAFE;
+
else {
sprintf(pg_result,
"Flag -:%s:- unknown\nAvailable flags, (prepend ! to un-set flag):\n%s",
f,
"IPSRC_RND, IPDST_RND, UDPSRC_RND, UDPDST_RND, "
- "MACSRC_RND, MACDST_RND, TXSIZE_RND, IPV6, MPLS_RND, VID_RND, SVID_RND, FLOW_SEQ, IPSEC, NODE_ALLOC\n");
+ "MACSRC_RND, MACDST_RND, TXSIZE_RND, IPV6, "
+ "MPLS_RND, VID_RND, SVID_RND, FLOW_SEQ, IPSEC, "
+ "NODE_ALLOC, UNSAFE\n");
return count;
}
sprintf(pg_result, "OK: flags=0x%x", pkt_dev->flags);
@@ -2723,7 +2735,8 @@ static struct sk_buff *fill_packet_ipv4(struct net_device *odev,
if (pkt_dev->nfrags <= 0) {
pgh = (struct pktgen_hdr *)skb_put(skb, datalen);
- memset(pgh + 1, 0, datalen - sizeof(struct pktgen_hdr));
+ if (!(pkt_dev->flags & F_UNSAFE))
+ memset(pgh + 1, 0, datalen - sizeof(struct pktgen_hdr));
} else {
int frags = pkt_dev->nfrags;
int i, len;
@@ -2734,13 +2747,17 @@ static struct sk_buff *fill_packet_ipv4(struct net_device *odev,
frags = MAX_SKB_FRAGS;
if (datalen > frags * PAGE_SIZE) {
len = datalen - frags * PAGE_SIZE;
- memset(skb_put(skb, len), 0, len);
+ if (!(pkt_dev->flags & F_UNSAFE))
+ memset(skb_put(skb, len), 0, len);
datalen = frags * PAGE_SIZE;
}
i = 0;
while (datalen > 0) {
- struct page *page = alloc_pages(GFP_KERNEL | __GFP_ZERO, 0);
+ struct page *page = alloc_pages((pkt_dev->flags & F_UNSAFE) ?
+ GFP_KERNEL :
+ GFP_KERNEL | __GFP_ZERO,
+ 0);
skb_shinfo(skb)->frags[i].page = page;
skb_shinfo(skb)->frags[i].page_offset = 0;
skb_shinfo(skb)->frags[i].size =
^ permalink raw reply related
* [PATCH NEXT 0/2]qlcnic: bug fixes
From: amit.salecha @ 2010-07-24 7:24 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman
Hi
Sending series of 2 minor fixes.
Apply them on net-next.
-Amit
^ permalink raw reply
* [PATCH NEXT 1/2] qlcnic: fix bandwidth check
From: amit.salecha @ 2010-07-24 7:24 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, Rajesh Borundia, Amit Kumar Salecha
In-Reply-To: <1279956266-23445-1-git-send-email-amit.salecha@qlogic.com>
From: Rajesh Borundia <rajesh.borundia@qlogic.com>
Fix maximum and minmum bandwith value.
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/qlcnic/qlcnic.h | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic.h b/drivers/net/qlcnic/qlcnic.h
index e189477..fad8e9a 100644
--- a/drivers/net/qlcnic/qlcnic.h
+++ b/drivers/net/qlcnic/qlcnic.h
@@ -1074,8 +1074,8 @@ struct qlcnic_eswitch {
/* Return codes for Error handling */
#define QL_STATUS_INVALID_PARAM -1
-#define MAX_BW 10000
-#define MIN_BW 100
+#define MAX_BW 100
+#define MIN_BW 1
#define MAX_VLAN_ID 4095
#define MIN_VLAN_ID 2
#define MAX_TX_QUEUES 1
@@ -1083,8 +1083,7 @@ struct qlcnic_eswitch {
#define DEFAULT_MAC_LEARN 1
#define IS_VALID_VLAN(vlan) (vlan >= MIN_VLAN_ID && vlan <= MAX_VLAN_ID)
-#define IS_VALID_BW(bw) (bw >= MIN_BW && bw <= MAX_BW \
- && (bw % 100) == 0)
+#define IS_VALID_BW(bw) (bw >= MIN_BW && bw <= MAX_BW)
#define IS_VALID_TX_QUEUES(que) (que > 0 && que <= MAX_TX_QUEUES)
#define IS_VALID_RX_QUEUES(que) (que > 0 && que <= MAX_RX_QUEUES)
#define IS_VALID_MODE(mode) (mode == 0 || mode == 1)
--
1.6.0.2
^ permalink raw reply related
* [PATCH NEXT 2/2] qlcnic: diag fixes
From: amit.salecha @ 2010-07-24 7:24 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, Amit Kumar Salecha
In-Reply-To: <1279956266-23445-1-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
o Loopback not supported for virtual function.
o netif_device_attach was missing in error path from
qlcnic_diag_alloc_res
Acked-by: Sony Chacko <sony.chacko@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/qlcnic/qlcnic.h | 2 --
drivers/net/qlcnic/qlcnic_ethtool.c | 10 ++++++++--
drivers/net/qlcnic/qlcnic_main.c | 19 +------------------
3 files changed, 9 insertions(+), 22 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic.h b/drivers/net/qlcnic/qlcnic.h
index fad8e9a..9703893 100644
--- a/drivers/net/qlcnic/qlcnic.h
+++ b/drivers/net/qlcnic/qlcnic.h
@@ -1301,8 +1301,6 @@ struct qlcnic_nic_template {
int (*get_mac_addr) (struct qlcnic_adapter *, u8*);
int (*config_bridged_mode) (struct qlcnic_adapter *, u32);
int (*config_led) (struct qlcnic_adapter *, u32, u32);
- int (*set_ilb_mode) (struct qlcnic_adapter *);
- void (*clear_ilb_mode) (struct qlcnic_adapter *);
int (*start_firmware) (struct qlcnic_adapter *);
};
diff --git a/drivers/net/qlcnic/qlcnic_ethtool.c b/drivers/net/qlcnic/qlcnic_ethtool.c
index 7d6558e..ecce364 100644
--- a/drivers/net/qlcnic/qlcnic_ethtool.c
+++ b/drivers/net/qlcnic/qlcnic_ethtool.c
@@ -678,6 +678,12 @@ static int qlcnic_loopback_test(struct net_device *netdev)
int max_sds_rings = adapter->max_sds_rings;
int ret;
+ if (adapter->op_mode == QLCNIC_NON_PRIV_FUNC) {
+ dev_warn(&adapter->pdev->dev, "Loopback test is not supported"
+ "for non privilege function\n");
+ return 0;
+ }
+
if (test_and_set_bit(__QLCNIC_RESETTING, &adapter->state))
return -EIO;
@@ -685,13 +691,13 @@ static int qlcnic_loopback_test(struct net_device *netdev)
if (ret)
goto clear_it;
- ret = adapter->nic_ops->set_ilb_mode(adapter);
+ ret = qlcnic_set_ilb_mode(adapter);
if (ret)
goto done;
ret = qlcnic_do_ilb_test(adapter);
- adapter->nic_ops->clear_ilb_mode(adapter);
+ qlcnic_clear_ilb_mode(adapter);
done:
qlcnic_diag_free_res(netdev, max_sds_rings);
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index f1f7acf..3002a7f 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -107,8 +107,6 @@ static void qlcnic_config_indev_addr(struct net_device *dev, unsigned long);
static int qlcnic_start_firmware(struct qlcnic_adapter *);
static void qlcnic_dev_set_npar_ready(struct qlcnic_adapter *);
-static void qlcnicvf_clear_ilb_mode(struct qlcnic_adapter *);
-static int qlcnicvf_set_ilb_mode(struct qlcnic_adapter *);
static int qlcnicvf_config_led(struct qlcnic_adapter *, u32, u32);
static int qlcnicvf_config_bridged_mode(struct qlcnic_adapter *, u32);
static int qlcnicvf_start_firmware(struct qlcnic_adapter *);
@@ -381,8 +379,6 @@ static struct qlcnic_nic_template qlcnic_ops = {
.get_mac_addr = qlcnic_get_mac_address,
.config_bridged_mode = qlcnic_config_bridged_mode,
.config_led = qlcnic_config_led,
- .set_ilb_mode = qlcnic_set_ilb_mode,
- .clear_ilb_mode = qlcnic_clear_ilb_mode,
.start_firmware = qlcnic_start_firmware
};
@@ -390,8 +386,6 @@ static struct qlcnic_nic_template qlcnic_vf_ops = {
.get_mac_addr = qlcnic_get_mac_address,
.config_bridged_mode = qlcnicvf_config_bridged_mode,
.config_led = qlcnicvf_config_led,
- .set_ilb_mode = qlcnicvf_set_ilb_mode,
- .clear_ilb_mode = qlcnicvf_clear_ilb_mode,
.start_firmware = qlcnicvf_start_firmware
};
@@ -1181,6 +1175,7 @@ int qlcnic_diag_alloc_res(struct net_device *netdev, int test)
ret = qlcnic_fw_create_ctx(adapter);
if (ret) {
+ netif_device_attach(netdev);
qlcnic_detach(adapter);
return ret;
}
@@ -2841,18 +2836,6 @@ qlcnicvf_config_led(struct qlcnic_adapter *adapter, u32 state, u32 rate)
return -EOPNOTSUPP;
}
-static int
-qlcnicvf_set_ilb_mode(struct qlcnic_adapter *adapter)
-{
- return -EOPNOTSUPP;
-}
-
-static void
-qlcnicvf_clear_ilb_mode(struct qlcnic_adapter *adapter)
-{
- return;
-}
-
static ssize_t
qlcnic_store_bridged_mode(struct device *dev,
struct device_attribute *attr, const char *buf, size_t len)
--
1.6.0.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox