* Re: [PATCH v3] netfilter: Xtables: idletimer target implementation
From: Luciano Coelho @ 2010-06-09 17:48 UTC (permalink / raw)
To: ext Jan Engelhardt
Cc: ext Patrick McHardy, netfilter-devel@vger.kernel.org,
netdev@vger.kernel.org, Timo Teras
In-Reply-To: <alpine.LSU.2.01.1006091716170.30265@obet.zrqbmnf.qr>
Hi Jan,
On Wed, 2010-06-09 at 17:18 +0200, ext Jan Engelhardt wrote:
> On Wednesday 2010-06-09 17:11, Luciano Coelho wrote:
> >Do you think it's okay to leave it like this for now and extend it for
> >multiple namespace support with a future patch?
>
> Yes. Least thing we need is one humongous patch. :)
Thanks! That was my concern too. One huge and very complex patch is not
a nice thing to have. ;)
> >> > + timer = __idletimer_tg_find_by_label(info->label);
> >> > + if (!timer) {
> >> > + spin_unlock(&list_lock);
> >> > + timer = idletimer_tg_create(info);
> >> >
> >>
> >> How does this prevent creating the same timer twice?
> >
> >The timer will only be created if __idletimer_tg_find_by_label() returns
> >NULL, which means that no timer with that label has been found. "info"
> >won't be the same if info->label is different, right? Or can it change
> >on the fly?
>
> One thing to be generally aware about is that things could potentially
> be instantiated by another entity between the time a label was looked up
> with negative result and the time one tries to add it.
> It may thus be required to extend keeping the lock until after
> idletimer_tg_create, in other words, lookup and create must be atomic
> to the rest of the world.
Ahh, sure! I missed the actual point of Patrick's question. I had the
idletimer_tg_create() inside the lock, but when I added the
sysfs_create_file() there (which can sleep), I screwed up with the
locking.
I'll move the sysfs file creation to outside that function so I can keep
the lock until after the timer is added to the list. Thanks for
clarifying!
--
Cheers,
Luca.
^ permalink raw reply
* Re: 2.6.35-rc2-git1 - include/linux/cgroup.h:534 invoked rcu_dereference_check() without protection!
From: Peter Zijlstra @ 2010-06-09 17:57 UTC (permalink / raw)
To: Miles Lane
Cc: paulmck, Vivek Goyal, Eric Paris, Lai Jiangshan, Ingo Molnar,
LKML, nauman, eric.dumazet, netdev, Jens Axboe, Gui Jianfeng,
Li Zefan, Johannes Berg
In-Reply-To: <AANLkTilpM9O373rA0cw_wTYVfTiDPbjaKHScAGlt7IAr@mail.gmail.com>
On Wed, 2010-06-09 at 13:00 -0400, Miles Lane wrote:
> ACPI: Core revision 20100428
> [ 0.061088]
> [ 0.061090] ===================================================
> [ 0.062009] [ INFO: suspicious rcu_dereference_check() usage. ]
> [ 0.062138] ---------------------------------------------------
> [ 0.062268] kernel/sched.c:616 invoked rcu_dereference_check()
> without protection!
> [ 0.062470]
> [ 0.062471] other info that might help us debug this:
> [ 0.062472]
> [ 0.062835]
> [ 0.062836] rcu_scheduler_active = 1, debug_locks = 1
> [ 0.063009] no locks held by swapper/0.
> [ 0.063134]
> [ 0.063135] stack backtrace:
> [ 0.063378] Pid: 0, comm: swapper Not tainted 2.6.35-rc2-git3 #3
> [ 0.063507] Call Trace:
> [ 0.063638] [<ffffffff81072205>] lockdep_rcu_dereference+0x9d/0xa5
> [ 0.063773] [<ffffffff810379f9>] task_group+0x7b/0x8a
> [ 0.064012] [<ffffffff81037a1d>] set_task_rq+0x15/0x6e
> [ 0.064143] [<ffffffff8103e50f>] set_task_cpu+0xa9/0xba
> [ 0.064274] [<ffffffff81042dbb>] sched_fork+0x10a/0x1b3
> [ 0.064405] [<ffffffff810446f9>] copy_process+0x617/0x10e6
> [ 0.064537] [<ffffffff8104533d>] do_fork+0x175/0x39b
> [ 0.064670] [<ffffffff8106589b>] ? up+0xf/0x39
> [ 0.064800] [<ffffffff8106589b>] ? up+0xf/0x39
> [ 0.065013] [<ffffffff811dbf73>] ? do_raw_spin_lock+0x79/0x13e
> [ 0.065148] [<ffffffff81011526>] kernel_thread+0x70/0x72
> [ 0.065279] [<ffffffff816cc5e4>] ? kernel_init+0x0/0x1ce
> [ 0.065411] [<ffffffff8100aba0>] ? kernel_thread_helper+0x0/0x10
> [ 0.065545] [<ffffffff81096bea>] ? rcu_scheduler_starting+0x2a/0x4c
> [ 0.065679] [<ffffffff813a8a4d>] rest_init+0x21/0xde
> [ 0.065810] [<ffffffff816cce28>] start_kernel+0x448/0x453
> [ 0.066013] [<ffffffff816cc2c8>] x86_64_start_reservations+0xb3/0xb7
> [ 0.066148] [<ffffffff816cc418>] x86_64_start_kernel+0x14c/0x15b
> [ 0.066499] Setting APIC routing to flat
Argh, moar funkeh stuff..
Either we do something like the below, or add something like (p->flags &
PF_STARTING) to the task_subsys_state_check(), opinions?
---
kernel/sched.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/kernel/sched.c b/kernel/sched.c
index 19b3c5d..bfd3128 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -2564,7 +2564,15 @@ void sched_fork(struct task_struct *p, int clone_flags)
if (p->sched_class->task_fork)
p->sched_class->task_fork(p);
+ /*
+ * We're not in the pid-hash yet so no cgroup attach races, and the
+ * cgroup is pinned by the parent running this.
+ *
+ * Silence PROVE_RCU.
+ */
+ rcu_read_lock();
set_task_cpu(p, cpu);
+ rcu_read_unlock();
#if defined(CONFIG_SCHEDSTATS) || defined(CONFIG_TASK_DELAY_ACCT)
if (likely(sched_info_on()))
^ permalink raw reply related
* Re: linux-next: Tree for June 9 (niu)
From: David Miller @ 2010-06-09 18:06 UTC (permalink / raw)
To: randy.dunlap; +Cc: sfr, netdev, linux-next, linux-kernel
In-Reply-To: <20100609103657.66252a27.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Wed, 9 Jun 2010 10:36:57 -0700
> On Wed, 9 Jun 2010 13:34:43 +1000 Stephen Rothwell wrote:
>
>> Changes since 20100608:
>>
>> My fixes tree contains:
>> v4l-dvb: update gfp/slab.h includes
>> arm: update gfp/slab.h includes
>> davinci: update gfp/slab.h includes
>> ocfs2: update gfp/slab.h includes
>> acpi: update gfp/slab.h includes
>
>
>
> on x86_64 or i386, CONFIG_OF_DEVICE is not enabled:
>
> drivers/net/niu.c:9700: warning: 'struct of_device' declared inside parameter list
> drivers/net/niu.c:9700: warning: its scope is only this definition or declaration, which is probably not what you want
> drivers/net/niu.c:9716: warning: assignment from incompatible pointer type
Hmmm, I'm confused why this never happened before :-)
We conditionalize linux/of_device.h inclusion with CONFIG_SPARC64, yet
we unconditionally use "struct of_device *" pointers in the driver
with no such ifdef protection.
Even if we unconditionally included linux/of_device.h, that file does
nothing unless CONFIG_OF_DEVICE is defined so it should have always
produced these warnings since I can't see from where else it could
have gotten even a "struct of_device;" somewhere.
Do you have any idea Randy? Pease try analyze this further so we can
fix it properly.
THanks!
^ permalink raw reply
* Re: [PATCH][RFC] Check sk_buff states
From: David VomLehn @ 2010-06-09 18:07 UTC (permalink / raw)
To: Andi Kleen; +Cc: netdev
In-Reply-To: <878w6o65kx.fsf@basil.nowhere.org>
On Wed, Jun 09, 2010 at 02:14:06AM -0500, Andi Kleen wrote:
> David VomLehn <dvomlehn@cisco.com> writes:
> >
> > Some of the errors that can be detected are:
> > o Double-freeing an skb_buff
>
> slab debugging should already catch that (although at higher cost)
There is a sublety here--if skb_clone() is used, skb_free() isn't
necessarily called until both parts of the cloned sk_buff are no longer
used. But it's not just that the double free is called, it's that you
also know where the first free is located. This turns out to be very
valuable.
> I would say the big question is how many bugs such a new infrastructure
> find. Did you find any?
Definitely. I've heard back about two cases. One of them was especially
gratifying because it has a control case. Two people were looking for the
same bug and found it within hours of each other. One person, who didn't
have the code enabled, took three weeks. The other person enabled the code.
It took him three hours to find the problem. So, our networking people
have been very happy to have this.
> -Andi
--
David VL
^ permalink raw reply
* Re: linux-next: Tree for June 9 (niu)
From: Randy Dunlap @ 2010-06-09 18:08 UTC (permalink / raw)
To: David Miller; +Cc: sfr, netdev, linux-next, linux-kernel
In-Reply-To: <20100609.110638.112605100.davem@davemloft.net>
On 06/09/10 11:06, David Miller wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
> Date: Wed, 9 Jun 2010 10:36:57 -0700
>
>> On Wed, 9 Jun 2010 13:34:43 +1000 Stephen Rothwell wrote:
>>
>>> Changes since 20100608:
>>>
>>> My fixes tree contains:
>>> v4l-dvb: update gfp/slab.h includes
>>> arm: update gfp/slab.h includes
>>> davinci: update gfp/slab.h includes
>>> ocfs2: update gfp/slab.h includes
>>> acpi: update gfp/slab.h includes
>>
>>
>>
>> on x86_64 or i386, CONFIG_OF_DEVICE is not enabled:
>>
>> drivers/net/niu.c:9700: warning: 'struct of_device' declared inside parameter list
>> drivers/net/niu.c:9700: warning: its scope is only this definition or declaration, which is probably not what you want
>> drivers/net/niu.c:9716: warning: assignment from incompatible pointer type
>
> Hmmm, I'm confused why this never happened before :-)
>
> We conditionalize linux/of_device.h inclusion with CONFIG_SPARC64, yet
> we unconditionally use "struct of_device *" pointers in the driver
> with no such ifdef protection.
>
> Even if we unconditionally included linux/of_device.h, that file does
> nothing unless CONFIG_OF_DEVICE is defined so it should have always
> produced these warnings since I can't see from where else it could
> have gotten even a "struct of_device;" somewhere.
>
> Do you have any idea Randy? Pease try analyze this further so we can
> fix it properly.
I looked and was confuzed, but I'll look again.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH][RFC] Infrastructure for compact call location representation
From: David VomLehn @ 2010-06-09 18:13 UTC (permalink / raw)
To: Andi Kleen; +Cc: netdev
In-Reply-To: <874ohc65es.fsf@basil.nowhere.org>
On Wed, Jun 09, 2010 at 02:17:47AM -0500, Andi Kleen wrote:
> David VomLehn <dvomlehn@cisco.com> writes:
>
> First your mailer generates broken cc addresses like
> "netdev@vger.kernel.org"@cisco.com
>
> > This patch allows the location of a call to be recorded as a small integer,
> > with each call location ("callsite") assigned a new value the first time
> > the code in that location is executed. Locations can be recorded as a
> > an address or as a __FILE__/__LINE__ pair. The later is easier to read, but
> > requires significantly more space.
>
> Seems overly complicated.
>
> How about using a hash of __FILE__, __LINE__ instead?
> With some care you can write it in a way that it gets completely
> evaluated by gcc at compile time, so it's just a constant then.
>
> That may use a few more bits then, but that's far better
> than having so much runtime overhead for this.
The same indexing scheme is employed whether it is configured for reporting
an address or the __FILE__/__LINE__ pair. The __FILE__/__LINE__ data is
stored statically at compile time, but since the __FILE__ values are strings
and may be pretty long, it can use a significant amount of space in the
string table. Performance wise, the key difference is that reporting an
address means that, the first time you go through a callsite, it stores
the return address. This doesn't need to be repeated during subsequent
calls, so the performance difference is miniscule.
--
David VL
^ permalink raw reply
* Re: 2.6.35-rc2-git1 - include/linux/cgroup.h:534 invoked rcu_dereference_check() without protection!
From: Peter Zijlstra @ 2010-06-09 18:15 UTC (permalink / raw)
To: Miles Lane
Cc: paulmck, Vivek Goyal, Eric Paris, Lai Jiangshan, Ingo Molnar,
LKML, nauman, eric.dumazet, netdev, Jens Axboe, Gui Jianfeng,
Li Zefan, Johannes Berg
In-Reply-To: <1276106229.1745.65.camel@laptop>
On Wed, 2010-06-09 at 19:57 +0200, Peter Zijlstra wrote:
> + /*
> + * We're not in the pid-hash yet so no cgroup attach races, and the
> + * cgroup is pinned by the parent running this.
> + *
> + * Silence PROVE_RCU.
> + */
Hum,.. not sure that's actually true though, the parent itself is still
susceptible to races afaict..
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-06-08
From: David Miller @ 2010-06-09 18:17 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20100608190214.GD2422@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 8 Jun 2010 15:02:14 -0400
> Dave,
>
> Here is a flurry of fixes intended for 2.6.35. Most of them are small
> and obvious, but there are a few exceptions...I'll include some text from
> the iwlwifi pull request:
...
> The iwlwifi bits are bigger than I would like to see, but the fixes
> seem worthwhile. Also included is a revert of a hostap patch that
> introduced failures with some devices, a NULL pointer dereference fix,
> a memory leak fix, a fix for an incorrect check of function pointer,
> a USB ID for p54, and a fix for an association failure 'corner case'
> from Johannes.
Pulled, thanks John.
Please try to keep things a lot smaller from here on out, thank you.
^ permalink raw reply
* Re: [PATCH][RFC] Infrastructure for compact call location representation
From: David VomLehn @ 2010-06-09 18:22 UTC (permalink / raw)
To: Nick Piggin; +Cc: Stephen Hemminger, to, netdev
In-Reply-To: <20100609084417.GW26335@laptop>
On Wed, Jun 09, 2010 at 03:44:17AM -0500, Nick Piggin wrote:
> On Tue, Jun 08, 2010 at 08:44:56AM -0700, Stephen Hemminger wrote:
> > On Mon, 7 Jun 2010 17:30:52 -0700
> > David VomLehn <dvomlehn@cisco.com> wrote:
> > > History
> > > v2 Support small callsite IDs and split out out-of-band parameter
> > > parsing.
> > > V1 Initial release
> > >
> > > Signed-off-by: David VomLehn <dvomlehn@cisco.com>
> >
> > This is really Linux Kernel Mailing List material (not just netdev). And it will
> > be a hard sell to get it accepted, because it is basically an alternative call
> > tracing mechanism, and there are already several of these in use or under development
> > (see perf and ftrace).
>
> What about a generic extension or layer on top of stacktrace that
> does caching and unique IDs for stack traces. This way you can get
> callsites or _full_ stack traces if required, and it shouldn't require
> any extra magic in the net functions.
Since the code calls BUG() when it detects an error, you already get the
full stack trace of the location where the problem is detected. The question
is the relative cost and benefits of a full stack trace of the previous
sk_buff state modification. Since I'm working in a MIPS processor
environment, I am rather prejudiced against doing any stack trace I don't
have to; for now, at least, they are *very* expensive on MIPS.
The two times this code (or its ancestor) has found problems in a deployed
software stack, the engineers reported they there were able to immediately
find and fix the problem. This suggests that we don't need to take on the
complexity of the stack backtrace, at least for now. If this gets added to
the mainline and people find they need the extra information, I'd be all
for it.
> You would need a hash for stack traces to check for an existing trace,
> and an idr to assign ids to traces.
Once you have the trace, it should be pretty easy to do this. In theory there
could be a huge number of unique stack traces, but I don't that this would
be the case in practice.
--
David VL
^ permalink raw reply
* Re: [PATCH v3] netfilter: Xtables: idletimer target implementation
From: Luciano Coelho @ 2010-06-09 18:42 UTC (permalink / raw)
To: ext Jan Engelhardt
Cc: ext Patrick McHardy, netfilter-devel@vger.kernel.org,
netdev@vger.kernel.org, Timo Teras
In-Reply-To: <1276105707.11199.12.camel@powerslave>
On Wed, 2010-06-09 at 19:48 +0200, Coelho Luciano (Nokia-D/Helsinki)
wrote:
> On Wed, 2010-06-09 at 17:18 +0200, ext Jan Engelhardt wrote:
> > >> > + timer = __idletimer_tg_find_by_label(info->label);
> > >> > + if (!timer) {
> > >> > + spin_unlock(&list_lock);
> > >> > + timer = idletimer_tg_create(info);
> > >> >
> > >>
> > >> How does this prevent creating the same timer twice?
> > >
> > >The timer will only be created if __idletimer_tg_find_by_label() returns
> > >NULL, which means that no timer with that label has been found. "info"
> > >won't be the same if info->label is different, right? Or can it change
> > >on the fly?
> >
> > One thing to be generally aware about is that things could potentially
> > be instantiated by another entity between the time a label was looked up
> > with negative result and the time one tries to add it.
> > It may thus be required to extend keeping the lock until after
> > idletimer_tg_create, in other words, lookup and create must be atomic
> > to the rest of the world.
>
> Ahh, sure! I missed the actual point of Patrick's question. I had the
> idletimer_tg_create() inside the lock, but when I added the
> sysfs_create_file() there (which can sleep), I screwed up with the
> locking.
>
> I'll move the sysfs file creation to outside that function so I can keep
> the lock until after the timer is added to the list. Thanks for
> clarifying!
Hmmm... after struggling with this for a while, I think it's not really
possible to simply create the sysfs file outside of the lock, because if
the sysfs creation fails, we will again risk a race condition.
I think the only way is to delay the sysfs file creation and do it in a
workqueue.
--
Cheers,
Luca.
^ permalink raw reply
* ss -p is much too slow
From: Steve Fink @ 2010-06-09 18:42 UTC (permalink / raw)
To: netdev
I was recently working with a monitoring system, and one check
involved displaying what process(es) were listening on specific ports.
I was using a single call to ss -lntp and processing the output, but
it would often take several minutes to respond. netstat -lntp, on the
other hand, was immediate. I had a few thousand processes running on
the machine, and it could take 7 minutes or so.
On closer inspection, it appears that ss -p does a quadratic scan. It
rescans every entry in /proc/*/fd/* repeatedly (once per listening
port? per process? I don't remember what I figured out.)
I humbly suggest that this is not a good idea.
I am currently running iproute-2.6.27-2.fc10.i386, though my real test
case was on a different machine. I don't have a newer version to check
right now.
% strace ss -lntp |& fgrep /proc/3768/fd/10
readlink("/proc/3768/fd/10", "socket:[16214]"..., 63) = 14
readlink("/proc/3768/fd/10", "socket:[16214]"..., 63) = 14
readlink("/proc/3768/fd/10", "socket:[16214]"..., 63) = 14
readlink("/proc/3768/fd/10", "socket:[16214]"..., 63) = 14
readlink("/proc/3768/fd/10", "socket:[16214]"..., 63) = 14
readlink("/proc/3768/fd/10", "socket:[16214]"..., 63) = 14
readlink("/proc/3768/fd/10", "socket:[16214]"..., 63) = 14
readlink("/proc/3768/fd/10", "socket:[16214]"..., 63) = 14
readlink("/proc/3768/fd/10", "socket:[16214]"..., 63) = 14
readlink("/proc/3768/fd/10", "socket:[16214]"..., 63) = 14
readlink("/proc/3768/fd/10", "socket:[16214]"..., 63) = 14
readlink("/proc/3768/fd/10", "socket:[16214]"..., 63) = 14
readlink("/proc/3768/fd/10", "socket:[16214]"..., 63) = 14
readlink("/proc/3768/fd/10", "socket:[16214]"..., 63) = 14
readlink("/proc/3768/fd/10", "socket:[16214]"..., 63) = 14
readlink("/proc/3768/fd/10", "socket:[16214]"..., 63) = 14
readlink("/proc/3768/fd/10", "socket:[16214]"..., 63) = 14
readlink("/proc/3768/fd/10", "socket:[16214]"..., 63) = 14
^ permalink raw reply
* RE: [v2 Patch 1/2] s2io: add dynamic LRO disable support
From: Ramkrishna Vepa @ 2010-06-09 18:52 UTC (permalink / raw)
To: Ben Hutchings, Amerigo Wang
Cc: netdev@vger.kernel.org, nhorman@redhat.com, sgruszka@redhat.com,
herbert.xu@redhat.com, davem@davemloft.net
In-Reply-To: <1276092058.2093.1.camel@achroite.uk.solarflarecom.com>
> On Wed, 2010-06-09 at 06:05 -0400, Amerigo Wang wrote:
> [...]
> > +static int s2io_ethtool_set_flags(struct net_device *dev, u32 data)
> > +{
> > + struct s2io_nic *sp = netdev_priv(dev);
> > + int rc = 0;
> > + int changed = 0;
> > +
> > + if (data & ETH_FLAG_LRO) {
> > + if (lro_enable) {
> > + if (!(dev->features & NETIF_F_LRO)) {
> > + dev->features |= NETIF_F_LRO;
> > + changed = 1;
> > + }
> > + } else
> > + rc = -EINVAL;
> > + } else if (dev->features & NETIF_F_LRO) {
> > + dev->features &= ~NETIF_F_LRO;
> > + changed = 1;
> > + }
> > +
> > + if (changed && netif_running(dev)) {
> > + s2io_stop_all_tx_queue(sp);
> > + s2io_card_down(sp);
> > + sp->lro = dev->features & NETIF_F_LRO;
> > + rc = s2io_card_up(sp);
> > + s2io_start_all_tx_queue(sp);
> [...]
>
> Is it safe to call s2io_start_all_tx_queue() if s2io_card_up() failed?
Ben,
Good point. If s2io_card_up() fails the chip will not be accessed, so it's safe but all transmit skbs will be freed without the user knowing the reason for failing to transmit or receive for that matter. The other option is to return with a failure and get the watchdog timer reset the adapter.
Ram
>
> Ben.
>
> --
> Ben Hutchings, Senior Software Engineer, Solarflare Communications
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
The information and any attached documents contained in this message
may be confidential and/or legally privileged. The message is
intended solely for the addressee(s). If you are not the intended
recipient, you are hereby notified that any use, dissemination, or
reproduction is strictly prohibited and may be unlawful. If you are
not the intended recipient, please contact the sender immediately by
return e-mail and destroy all copies of the original message.
^ permalink raw reply
* [PATCH] gianfar: Revive the driver for eTSEC devices (disable timestamping)
From: Anton Vorontsov @ 2010-06-09 19:32 UTC (permalink / raw)
To: David Miller; +Cc: Manfred Rudigier, netdev, linuxppc-dev
Since commit cc772ab7cdcaa24d1fae332d92a1602788644f7a ("gianfar: Add
hardware RX timestamping support"), the driver no longer works on
at least MPC8313ERDB and MPC8568EMDS boards (and possibly much more
boards as well).
That's how MPC8313 Reference Manual describes RCTRL_TS_ENABLE bit:
Timestamp incoming packets as padding bytes. PAL field is set
to 8 if the PAL field is programmed to less than 8. Must be set
to zero if TMR_CTRL[TE]=0.
I see that the commit above sets this bit, but it doesn't handle
TMR_CTRL. Manfred probably had this bit set by the firmware for
his boards. But obviously this isn't true for all boards in the
wild.
Also, I recall that Freescale BSPs were explicitly disabling the
timestamping because of a performance drop.
For now, the best way to deal with this is just disable the
timestamping, and later we can discuss proper device tree bindings
and implement enabling this feature via some property.
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
drivers/net/gianfar.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 1830f31..46c69cd 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -747,8 +747,7 @@ static int gfar_of_init(struct of_device *ofdev, struct net_device **pdev)
FSL_GIANFAR_DEV_HAS_CSUM |
FSL_GIANFAR_DEV_HAS_VLAN |
FSL_GIANFAR_DEV_HAS_MAGIC_PACKET |
- FSL_GIANFAR_DEV_HAS_EXTENDED_HASH |
- FSL_GIANFAR_DEV_HAS_TIMER;
+ FSL_GIANFAR_DEV_HAS_EXTENDED_HASH;
ctype = of_get_property(np, "phy-connection-type", NULL);
--
1.7.0.5
^ permalink raw reply related
* [GIT] Networking
From: David Miller @ 2010-06-09 19:35 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) hostap irq handler commit revert, breaks bringup of certain
cards. From John W. Linville.
2) mac80211 does "if (foo->ops->x) foo->ops->y();", fix to
"if (foo->opx->y) foo->ops->y();" :-) From Holger Schurig
3) Fix lockdep warning wrt. sysfs_create_group and requesting firmware
in iwlwifi. Otherwise ABBA deadlock is possible due to the mutex
grab ordering these two code paths need. From Emmanuel Grumbach.
4) rtl8139_init_board() leaves 'i' past end of table index, then
indexes into the table using 'i'. Fix from Denis Kirjanov.
5) We erroneously can process blockack frames before association
responses, this causes the connection to get into a state where
no traffic can pass. This problem tends to eminate with iwlagn
chipsets.
A more complicated and complete fix is possible, but here we
make a smaller fix wherein we process aggregation action frames
from the managed interface skb queue which provides the proper
serialization with association responses.
Fix from Johannes Berg.
6) ath5k needs PM_SLEEP dependencies, from Tobias Doerffel.
7) We have several backtraces (forward to us by Andrew Morton) in the
ipv6 multicast code due to unecessary high-order allocations
happening when the MTU is set to handle jumbo frames or similar on
a device and we try to send out ipv6 multicast reports.
We don't need such a huge SKB here, the code knows how to chop up a
report into multiple frames if the number of entries to report is
larger than we can fit in a single frame, so keep the allocation
PAGE_SIZE or smaller to make these allocations more reliable. Fix
from Eric Dumazet.
8) iwl3945 devices can suffer from stuck command queues just like other
chip revisions, so hook up the iwl_bg_monitor_recover handler for
them too. From Reinette Chatre.
9) iwl3945 needs a special handler for short scans, fixes bug
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2208,
from Abhijeet Kolekar.
10) ip6mr_for_each_table() macro has a typo in one of it's variable
names. Fix from Eric Dumazet.
11) Many users report that the R8169 PHY doesn't come up cleanly. It
was tracked down to a recent commit adding full initialization of
the PHY for 8169scd chips. But the actual problem is more
general in nature and not related to that commit.
Timo Teräs did some excellent debugging and found that MDIO writes
were often failing in these new PHY init routines.
Comparing the vendor driver with our's he found that the vendor
driver makes extra delays after MDIO writes complete.
The hardware engineers have confirmed the necessity of these
extra delays and they fix the problems for everyone.
Fix from Timo Teräs, and there may be some small tweaks in the
future here as the hardware designers indicate that reads
probably need this treatment too.
12) ASIX USB network device doesn't handle VLAN packets properly due
to a mis-coded RX packet size verification check. Fix from Jussi
Kivilinna.
13) IPMR table lists get corrupted because we free list members before
unlinking. Fix from Eric Dumazet, and this fixes the regression
list entry that was under discussion in the past day.
14) wl1251_sdio_probe() leaks memory in error path, from Grazvydas
Ignotas.
15) New device ID in p54usb for Dell chip, from Jason Dravet.
16) Some MAINTAINER list tweaks for Intel wireless drivers.
17) Missing RCU locking in iwlagn_tx_status(), which is required
for calling ieee80211_find_sta(). Fix from Johannes Berg.
Please pull, thanks a lot!
The following changes since commit 3975d16760d4be7402d1067c548c30c427971331:
Linus Torvalds (1):
Merge git://git.infradead.org/~dwmw2/mtd-2.6.35
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Abhijeet Kolekar (1):
iwl3945: fix internal scan
Bob Copeland (1):
ath5k: retain promiscuous setting
Bruno Randolf (1):
ath5k: fix NULL pointer in antenna configuration
David S. Miller (1):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
Denis Kirjanov (1):
8139too: fix buffer overrun in rtl8139_init_board
Emmanuel Grumbach (1):
iwlwifi: move sysfs_create_group to post request firmware
Eric Dumazet (3):
ipv6: avoid high order allocations
ip6mr: fix a typo in ip6mr_for_each_table()
ipmr: dont corrupt lists
Grazvydas Ignotas (1):
wl1251: fix a memory leak in probe
Holger Schurig (1):
mac80211: fix function pointer check
Jason Dravet (1):
p54usb: Add device ID for Dell WLA3310 USB
Johannes Berg (3):
mac80211: process station blockack action frames from work
iwlwifi: add missing rcu_read_lock
mac80211: fix deauth before assoc
John W. Linville (1):
Revert "wireless: hostap, fix oops due to early probing interrupt"
Jussi Kivilinna (1):
asix: check packet size against mtu+ETH_HLEN instead of ETH_FRAME_LEN
Reinette Chatre (1):
iwl3945: enable stuck queue detection on 3945
Timo Teräs (1):
r8169: fix random mdio_write failures
Tobias Doerffel (1):
ath5k: depend on CONFIG_PM_SLEEP for suspend/resume functions
Wey-Yi Guy (1):
iwlwifi: add name to Maintainers list
Zhu Yi (1):
wireless: remove my name from the maintainer list
MAINTAINERS | 5 +-
drivers/net/8139too.c | 1 +
drivers/net/r8169.c | 5 +
drivers/net/usb/asix.c | 2 +-
drivers/net/wireless/ath/ath5k/base.c | 12 +-
drivers/net/wireless/ath/ath5k/phy.c | 7 +
drivers/net/wireless/hostap/hostap_hw.c | 9 -
drivers/net/wireless/iwlwifi/iwl-3945.c | 1 +
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 30 +---
drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 2 +
drivers/net/wireless/iwlwifi/iwl-agn.c | 318 +++++++++++++-------------
drivers/net/wireless/iwlwifi/iwl-core.c | 39 ++++
drivers/net/wireless/iwlwifi/iwl-core.h | 2 +
drivers/net/wireless/iwlwifi/iwl3945-base.c | 56 +++++-
drivers/net/wireless/p54/p54usb.c | 1 +
drivers/net/wireless/wl12xx/wl1251_sdio.c | 1 +
net/ipv4/ipmr.c | 4 +-
net/ipv6/ip6mr.c | 6 +-
net/ipv6/mcast.c | 5 +-
net/mac80211/driver-ops.h | 2 +-
net/mac80211/mlme.c | 92 +++++++-
net/mac80211/rx.c | 3 +
22 files changed, 380 insertions(+), 223 deletions(-)
^ permalink raw reply
* 2.6.25-rc2 pull request, stop log noise from CONFIG_RPS
From: Tim Gardner @ 2010-06-09 19:51 UTC (permalink / raw)
To: davem; +Cc: eric.dumazet, netdev
Dave,
Please consider applying this patch in order to stop
log noise under certain configurations.
rtg
---------------
The following changes since commit 327723edebbbd621ed35b0d63073685eb225563e:
David S. Miller (1):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
are available in the git repository at:
git://kernel.ubuntu.com/rtg/net-2.6 num_rx_queues
Tim Gardner (1):
net: Print num_rx_queues imbalance warning only when there are allocated queues
net/core/dev.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
>From 08c801f8d45387a1b46066aad1789a9bb9c4b645 Mon Sep 17 00:00:00 2001
From: Tim Gardner <tim.gardner@canonical.com>
Date: Tue, 8 Jun 2010 17:51:27 -0600
Subject: [PATCH] net: Print num_rx_queues imbalance warning only when there are allocated queues
BugLink: http://bugs.launchpad.net/bugs/591416
There are a number of network drivers (bridge, bonding, etc) that are not yet
receive multi-queue enabled and use alloc_netdev(), so don't print a
num_rx_queues imbalance warning in that case.
Also, only print the warning once for those drivers that _are_ multi-queue
enabled.
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/core/dev.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index d03470f..14a8568 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2253,11 +2253,9 @@ static int get_rps_cpu(struct net_device *dev, struct sk_buff *skb,
if (skb_rx_queue_recorded(skb)) {
u16 index = skb_get_rx_queue(skb);
if (unlikely(index >= dev->num_rx_queues)) {
- if (net_ratelimit()) {
- pr_warning("%s received packet on queue "
- "%u, but number of RX queues is %u\n",
- dev->name, index, dev->num_rx_queues);
- }
+ WARN_ONCE(dev->num_rx_queues > 1, "%s received packet "
+ "on queue %u, but number of RX queues is %u\n",
+ dev->name, index, dev->num_rx_queues);
goto done;
}
rxqueue = dev->_rx + index;
--
1.7.0.4
^ permalink raw reply related
* Re: 2.6.25-rc2 pull request, stop log noise from CONFIG_RPS
From: David Miller @ 2010-06-09 19:57 UTC (permalink / raw)
To: timg; +Cc: eric.dumazet, netdev
In-Reply-To: <20100609195110.02FEAF89E9@sepang.rtg.net>
From: timg@tpi.com (Tim Gardner)
Date: Wed, 9 Jun 2010 13:51:09 -0600 (MDT)
> Please consider applying this patch in order to stop
> log noise under certain configurations.
Yes, dealing with this is in my queue. I would have integrated this
sooner but I was travelling yesterday. :)
^ permalink raw reply
* Business Offer, Call Me
From: Alexander Schell @ 2010-06-09 19:26 UTC (permalink / raw)
Dear,
I know it will be of much interest to you, this is the reason I contacted you.
I want to transfer a certain amount of money from my bank here in England to
any country you may suggest and I would required your full co-operation to
transfer the money.
Call me on +44 701 11 64380, or contact via e-mail alexschell0011@yahoo.cn to
discuss about this proposal with you.
If you are interesting, I will discuss with you about the details and
procedures of the transaction.
Look forward to discussing this opportunity further with you in more detail
shortly.
Sincerely,
Alexander Schell.
Tel: +44 701 11 64380
^ permalink raw reply
* Re: 2.6.25-rc2 pull request, stop log noise from CONFIG_RPS
From: Tim Gardner @ 2010-06-09 20:12 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20100609.125752.71103958.davem@davemloft.net>
On 06/09/2010 01:57 PM, David Miller wrote:
> From: timg@tpi.com (Tim Gardner)
> Date: Wed, 9 Jun 2010 13:51:09 -0600 (MDT)
>
>> Please consider applying this patch in order to stop
>> log noise under certain configurations.
>
> Yes, dealing with this is in my queue. I would have integrated this
> sooner but I was travelling yesterday. :)
>
No problem, thanks for the note. I was unsure of the protocol since you
were not directly addressed in the previous discussion.
rtg
--
Tim Gardner tim.gardner@canonical.com
^ permalink raw reply
* Re: [PATCH 1/2] pktgen: increasing transmission granularity
From: David Miller @ 2010-06-09 20:50 UTC (permalink / raw)
To: daniel.turull; +Cc: netdev, robert, jens.laas
In-Reply-To: <4C064533.6070709@gmail.com>
From: Daniel Turull <daniel.turull@gmail.com>
Date: Wed, 02 Jun 2010 13:49:07 +0200
> This patch increases the granularity of the rate generated by pktgen.
> The previous version of pktgen uses micro seconds (udelay) resolution when it
> was delayed causing gaps in the rates. It is changed to nanosecond (ndelay).
> Now any rate is possible.
>
> Also it allows to set, the desired rate in Mb/s or packets per second.
>
> The documentation has been updated.
>
> Signed-off-by: Daniel Turull <daniel.turull@gmail.com>
I like this, however although most of this is adding a new
feature, this part:
> @@ -2170,7 +2204,7 @@ static void spin(struct pktgen_dev *pkt_dev, ktime_t spin_until)
> end_time = ktime_now();
>
> pkt_dev->idle_acc += ktime_to_ns(ktime_sub(end_time, start_time));
> - pkt_dev->next_tx = ktime_add_ns(end_time, pkt_dev->delay);
> + pkt_dev->next_tx = ktime_add_ns(spin_until, pkt_dev->delay);
> }
>
> static inline void set_pkt_overhead(struct pktgen_dev *pkt_dev)
Is a bug fix, since it makes sure the inter-packet interval is
accurate.
Can you please submit this part seperately, so I can apply it to
net-2.6 Then you can submit the nanosecond feature parts
relative to this, which I'll apply to net-next-2.6
Thanks!
^ permalink raw reply
* Re: [PATCH v3] netfilter: Xtables: idletimer target implementation
From: Jan Engelhardt @ 2010-06-09 21:05 UTC (permalink / raw)
To: Luciano Coelho
Cc: ext Patrick McHardy, netfilter-devel@vger.kernel.org,
netdev@vger.kernel.org, Timo Teras
In-Reply-To: <1276108939.11199.23.camel@powerslave>
On Wednesday 2010-06-09 20:42, Luciano Coelho wrote:
>
>> I'll move the sysfs file creation to outside that function so I can keep
>> the lock until after the timer is added to the list. Thanks for
>> clarifying!
>
>Hmmm... after struggling with this for a while, I think it's not really
>possible to simply create the sysfs file outside of the lock, because if
>the sysfs creation fails, we will again risk a race condition.
Well if sysfs_add can return an error code when a file already
exists (instead of adding it again), it's much easier. Try checking.
^ permalink raw reply
* Re: [PATCH v3] netfilter: Xtables: idletimer target implementation
From: Luciano Coelho @ 2010-06-09 21:00 UTC (permalink / raw)
To: ext Jan Engelhardt
Cc: ext Patrick McHardy, netfilter-devel@vger.kernel.org,
netdev@vger.kernel.org, Timo Teras
In-Reply-To: <1276108939.11199.23.camel@powerslave>
On Wed, 2010-06-09 at 20:42 +0200, Coelho Luciano (Nokia-D/Helsinki)
wrote:
> On Wed, 2010-06-09 at 19:48 +0200, Coelho Luciano (Nokia-D/Helsinki)
> wrote:
> > On Wed, 2010-06-09 at 17:18 +0200, ext Jan Engelhardt wrote:
> > > >> > + timer = __idletimer_tg_find_by_label(info->label);
> > > >> > + if (!timer) {
> > > >> > + spin_unlock(&list_lock);
> > > >> > + timer = idletimer_tg_create(info);
> > > >> >
> > > >>
> > > >> How does this prevent creating the same timer twice?
> > > >
> > > >The timer will only be created if __idletimer_tg_find_by_label() returns
> > > >NULL, which means that no timer with that label has been found. "info"
> > > >won't be the same if info->label is different, right? Or can it change
> > > >on the fly?
> > >
> > > One thing to be generally aware about is that things could potentially
> > > be instantiated by another entity between the time a label was looked up
> > > with negative result and the time one tries to add it.
> > > It may thus be required to extend keeping the lock until after
> > > idletimer_tg_create, in other words, lookup and create must be atomic
> > > to the rest of the world.
> >
> > Ahh, sure! I missed the actual point of Patrick's question. I had the
> > idletimer_tg_create() inside the lock, but when I added the
> > sysfs_create_file() there (which can sleep), I screwed up with the
> > locking.
> >
> > I'll move the sysfs file creation to outside that function so I can keep
> > the lock until after the timer is added to the list. Thanks for
> > clarifying!
>
> Hmmm... after struggling with this for a while, I think it's not really
> possible to simply create the sysfs file outside of the lock, because if
> the sysfs creation fails, we will again risk a race condition.
>
> I think the only way is to delay the sysfs file creation and do it in a
> workqueue.
Okay, I think I found a way to do it without using an extra workqueue.
The patch is ready, but I still want to run some tests before sending it
out.
--
Cheers,
Luca.
^ permalink raw reply
* pull request: wireless-next-2.6 2010-06-09
From: John W. Linville @ 2010-06-09 21:12 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
Dave,
Here is the usual, frightening, monstrous post-window pull request...
Along with the usual batch of driver updates, there are also some DMA
state API conversions from FUJITA Tomonori, some cleanups from Julia
Lawall and Joe Perches, some SSB changes from Larry Finger and Rafał
Miłecki, and a number of mac80211 changes from Johannes Berg. All of it
has had at least one cycle through linux-next and most of it has been
there for several days. This also includes the same wireless-2.6 pull I
sent you previously so as to resolve some merge conflicts.
Please let me know if there are problems!
John
---
The following changes since commit bb69ae049fcc986fcd742eb90ca0d44a7a49c9f1:
Eric Dumazet (1):
anycast: Some RCU conversions
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git master
Abhijeet Kolekar (1):
iwl3945: fix internal scan
Amitkumar Karwar (1):
libertas: Added callback functions to support SDIO suspend/resume.
Bob Copeland (1):
ath5k: retain promiscuous setting
Bruno Randolf (15):
ath5k: initialize calibration timers
ath5k: move noise floor calibration into tasklet
ath5k: Stop queues only for NF calibration
ath5k: run NF calibration only every 60 seconds
ath5k: remove ATH_TRACE macro
ath5k: clarify logic when to enable spur mitigation filter
ath5k: use ath5k_softc as driver data
ath5k: add sysfs files for ANI parameters
ath5k: always calculate ANI listen time
ath5k: print error message if ANI levels are out of range
ath5k: fix NULL pointer in antenna configuration
ath5k: update AR5K_PHY_RESTART_DIV_GC values to match masks
ath5k: new function for setting the antenna switch table
ath5k: no need to save/restore the default antenna
ath5k: add debugfs file for queue debugging
Dan Carpenter (3):
ath9k/debug: improve the snprintf() handling
ath9k/debug: fixup the return codes
ath9k: cleanup: remove unneeded null check
Daniel Halperin (2):
iwlwifi: parse block ack responses correctly
iwlwifi: fix wrapping when handling aggregated batches
Emmanuel Grumbach (1):
iwlwifi: move sysfs_create_group to post request firmware
FUJITA Tomonori (7):
mwl8k: use the dma state API instead of the pci equivalents
iwlwifi: use the DMA state API instead of the pci equivalents
ssb: add dma_dev to ssb_device structure
b43legacy: replace the ssb_dma API with the generic DMA API
b43: replace the ssb_dma API with the generic DMA API
b44: replace the ssb_dma API with the generic DMA API
ssb: remove the ssb DMA API
Felix Fietkau (6):
mac80211: add the minstrel_ht rate control algorithm
ath9k_hw: add multicast key search support
ath9k_common: use allocated key cache entries for multi BSS crypto support
ath9k: use the key handling code from ath9k_common instead of duplicating it
ath9k: fix queue stop/start based on the number of pending frames
mac80211: reduce debugfs code size
Gertjan van Wingerde (14):
rt2x00: Move rt2x00debug_dump_frame declaration to rt2x00.h.
rt2x00: Push beacon TX descriptor writing to drivers.
rt2x00: Reverse calling order of bus write_tx_desc and driver write_tx_desc.
rt2x00: Properly reserve room for descriptors in skbs.
rt2x00: Fix rt2800usb TX descriptor writing.
rt2x00: Clean up USB vendor request buffer functions.
rt2x00: Centralize rt2800 beacon writing.
rt2x00: Remove RT2870 chipset identification.
rt2x00: Move all register definitions for rt2800 to rt2800.h.
rt2x00: Introduce separate interface type for PCI-express.
rt2x00: Simplify check for external LNA in rt2800_init_rfcsr.
rt2x00: Move PCI/USB specific register initializations to rt2800{pci,usb}.
rt2x00: Sync rt2800 MCU boot signal with Ralink driver.
rt2x00: Fix HT40 operation in rt2800.
Grazvydas Ignotas (2):
wl1251: fix a memory leak in probe
wl1251: fix ELP_CTRL register reads
Helmut Schaa (5):
cfg80211: don't refuse HT20 channels on devices that don't support HT40
rt2x00: rt2800: disable TX STBC for 1 stream devices
rt2x00: Update TX_SW_CFG initvals for 305x SoC
rt2x00: fix use of mcs rates
rt2x00: Remove suspicious register write
Holger Schurig (1):
mac80211: fix function pointer check
Ivo van Doorn (1):
rt2x00: Use IEEE80211_TX_CTL_STBC flag
Jason Dravet (1):
p54usb: Add device ID for Dell WLA3310 USB
Joe Perches (1):
drivers/net/wireless/ipw2x00/ipw2100.c: Remove unnecessary kmalloc casts
Johannes Berg (33):
iwlwifi: introduce iwl_sta_id_or_broadcast
iwlwifi: don't crash on firmware file missing info
iwl3945: remove sequence number assignment
iwlwifi: move iwl_free_tfds_in_queue to iwlagn
iwlwifi: improve station debugfs
iwlwifi: remove IWL_MULTICAST_ID
iwlagn: use firmware event/error log information
iwlwifi: split debug and debugfs options
iwlwifi: use proper short slot/preamble settings
cfg80211: make action channel type optional
mac80211: remove bogus mod_timer() call
mac80211: remove tx status ampdu_ack_map
mac80211: clean up ieee80211_stop_tx_ba_session
mac80211: move WEP weak IV check
mac80211: remove useless work starting
mac80211: drop control frames after processing
mac80211: move plink state
mac80211: simplify key locking
mac80211: process station blockack action frames from work
iwlwifi: remove useless node_addr assignments
iwlwifi: remove unused wlap_bssid_addr assignment
iwlwifi: remove mac_addr assignment
iwlwifi: set MAC address in RXON from interface
iwlwifi: use virtual interface address for scan
iwlwifi: remove debug frame dumping
iwlwifi: remove priv->mac_addr
iwl3945: fix bugs in txq freeing
iwlagn: fix bug in txq freeing
iwlwifi: kzalloc txb array
iwlwifi: reduce memory allocation
iwlwifi: generic scan TX antenna forcing
iwlwifi: queue user-initiated scan when doing internal scan
wireless: fix kernel-doc
John W. Linville (8):
Merge branch 'wireless-next-2.6' of git://git.kernel.org/.../iwlwifi/iwlwifi-2.6
ath9k_htc: fix build error when ATH9K_HTC_DEBUGFS not enabled
Revert "iwlwifi: move _agn statistics related structure"
mac80211: make ARP filtering depend on CONFIG_INET
Revert "wireless: hostap, fix oops due to early probing interrupt"
iwlwifi: fix-up botched revert
mac80211: fix lock leak w/ ARP filtering and w/o CONFIG_INET
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
Julia Lawall (11):
drivers/net/wireless/orinoco: Use kzalloc
drivers/net/wireless/libertas: Use kmemdup
drivers/net/wireless/wl12xx: Use kmemdup
drivers/net/wireless/libertas_tf: Use kmemdup
drivers/net/wireless/iwmc3200wifi: Use kmemdup
drivers/net/wireless/ath/ath9k: Use kmemdup
drivers/net/wireless/b43: Use kmemdup
drivers/net/wireless/ipw2x00: Use kmemdup
drivers/net/wireless/p54: Use kmemdup
drivers/net/wireless/orinoco: Use kmemdup
drivers/net/wireless/prism54: Use memdup_user
Jussi Kivilinna (1):
rndis_wlan: increase assocbuf size and validate association info offsets from driver
Juuso Oikarinen (9):
wl1271: Update handling of the NVS file / INI parameters
wl1271: Add support for NVS files with 5GHz band parameters
wl1271: Prevent dropping of TX frames in joins
wl1271: Idle handling into own function
wl1271: Flush TX buffers to air before going to idle
wl1271: Use proper rates for PSM entry/exit null-funcs for 5GHz
wl1271: Fix scan parameter handling for 5GHz
mac80211: Add support for hardware ARP query filtering
mac80211: Add netif state checking to ieee80211_ifa_changed
Larry Finger (1):
ssb: Handle alternate SSPROM location
Luciano Coelho (1):
wl1271: the core wl1271 module shouldn't depend on SPI_MASTER
Luis R. Rodriguez (5):
ath9k_hw: add support for the AR9003 2.2
ath9k_hw: rename the ar9003_initvals.h to ar9003_2p0_initvals.h
ath9k_hw: add support for the AR9003 baseband watchdog
ath9k: enable the baseband watchdog events for AR9003
ath9k_hw: Enable TX IQ calibration on AR9003
Luke-Jr (1):
p54spi: replace internal "cx3110x" name with "p54spi"
Ming Lei (2):
ath9k: fix dma direction for map/unmap in ath_rx_tasklet
ath9k: fix dma sync in rx path
Ohad Ben-Cohen (1):
wl1271: remove sdio ARM dependency
Prarit Bhargava (1):
ath: Fix uninitialized variable warnings
Rafał Miłecki (2):
ssb: update PMU init to match specs
ssb: fast powerup delay calculation for PMU capable devices
Reinette Chatre (2):
iwlwifi: fix and add missing sta_lock usage
iwl3945: enable stuck queue detection on 3945
Sascha Silbe (1):
libertas: Fix ethtool reporting no WOL options supported if WOL is not already active
Shanyu Zhao (3):
iwlwifi: enable remaining 6000 Gen2 devices
iwlwifi: add new PCI IDs for 6000g2 devices
iwlwifi: do not clear data after chain noise calib
Sujith (34):
ath9k_htc: Add queue statistics to xmit debugfs file
ath9k_htc: Initialize beacon/CAB queues
ath9k_htc: Remove HW queue translation
ath9k_htc: Increase credit size
ath9k_htc: Initvals update for AR9271
ath9k_htc: Cleanup rate initialization
ath9k_htc: Update HT configuration properly
ath9k_htc: Enable SGI in HT20 for AR9271
ath9k_htc: Enable RX STBC for AR9271
ath9k: Move ath9k specific RX code to driver
ath9k: Move driver specific structures
ath9k_hw: Cleanup eeprom_9287.c
ath9k_hw: Optimize ath9k_hw_ar9287_set_board_values
ath9k_hw: Cleanup TX power calculation for AR9287
ath9k_hw: Update the PCI WAR register
ath9k_hw: Fix async fifo for AR9287
ath9k_htc: Revamp CONF_IDLE handling
ath9k_htc: Add PS wrappers
ath9k_htc: Fix bug in handling CONF_IDLE
ath9k_htc: Remove useless cancel_work_sync
ath9k_htc: Fix locking for ps_idle
ath9k_htc: Handle monitor interface removal
ath9k_htc: Handle host RX disable
ath9k_htc: Fix fair beacon distribution
ath9k_htc: Use proper station add/remove callbacks
mac80211: Remove deprecated sta_notify commands
ath9k: Determine Firmware on probe
ath9k_hw: Configure byte swap for non AR9271 chips
ath9k_htc: Add support for AR7010
ath9k_common: Move count_streams to common module
ath9k_htc: Setup HT capabilites for 2-stream devices
ath9k_htc: Configure dual stream rates
ath9k_htc: Setup 5GHz channels
ath9k_htc: Configure credit size for AR7010
Tobias Doerffel (1):
ath5k: depend on CONFIG_PM_SLEEP for suspend/resume functions
Tobias Klauser (1):
drivers/net/wireless: Storage class should be before const qualifier
Vasanthakumar Thiagarajan (8):
ath9k: Enable Short GI in 20 Mhz for ar9287 and later chips
ath9k: Make sure null func frame is acked before going into PS for ar9003
ath9k: Fix power save with auto sleeping
ath9k_hw: Enable auto sleep for ar9003
ath9k: Clean up few function parameters in recv.c
ath9k: Fix bug in accessing skb->data of rx frame for edma
ath9k: Fix bug in validating received data length for edma
ath9k: Fix bug in rate table
Walter Goldens (1):
wireless: fix several minor description typos
Wey-Yi Guy (13):
iwlwifi: move _agn statistics related structure
iwlwifi: separate statistics flag function for agn & 3945
iwlwifi: code cleanup for _agn devices
iwlwifi: modify out-dated comments
iwlwifi: move ucode related function to iwl-agn-ucode.c
iwlwifi: add name to Maintainers list
iwlwifi: remove unused parameter in iwl_priv
iwlwifi: beacon format related helper function
iwlwifi: support channel switch offload in driver
iwlwifi: beacon internal time unit
iwlwifi: remove inaccurate comment
iwlwifi: do not use huge command buffer for channel switch
iwlwifi: remove unused parameter
Zhu Yi (1):
wireless: remove my name from the maintainer list
MAINTAINERS | 5 +-
drivers/net/b44.c | 144 ++--
drivers/net/wireless/ath/ath5k/Makefile | 1 +
drivers/net/wireless/ath/ath5k/ani.c | 20 +-
drivers/net/wireless/ath/ath5k/ath5k.h | 7 +
drivers/net/wireless/ath/ath5k/attach.c | 2 -
drivers/net/wireless/ath/ath5k/base.c | 50 +-
drivers/net/wireless/ath/ath5k/caps.c | 7 -
drivers/net/wireless/ath/ath5k/debug.c | 74 ++-
drivers/net/wireless/ath/ath5k/debug.h | 9 +-
drivers/net/wireless/ath/ath5k/desc.c | 7 -
drivers/net/wireless/ath/ath5k/dma.c | 13 -
drivers/net/wireless/ath/ath5k/eeprom.c | 3 +-
drivers/net/wireless/ath/ath5k/gpio.c | 7 -
drivers/net/wireless/ath/ath5k/pcu.c | 24 -
drivers/net/wireless/ath/ath5k/phy.c | 89 ++-
drivers/net/wireless/ath/ath5k/qcu.c | 9 -
drivers/net/wireless/ath/ath5k/reset.c | 64 +--
drivers/net/wireless/ath/ath5k/sysfs.c | 116 +++
drivers/net/wireless/ath/ath9k/ani.c | 1 +
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 11 -
drivers/net/wireless/ath/ath9k/ar9002_hw.c | 109 ++-
drivers/net/wireless/ath/ath9k/ar9002_initvals.h | 6 +-
.../{ar9003_initvals.h => ar9003_2p0_initvals.h} | 6 +-
.../{ar9003_initvals.h => ar9003_2p2_initvals.h} | 185 +++---
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 10 +-
drivers/net/wireless/ath/ath9k/ar9003_hw.c | 163 ++++-
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 5 +
drivers/net/wireless/ath/ath9k/ar9003_mac.h | 1 +
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 119 +++
drivers/net/wireless/ath/ath9k/ar9003_phy.h | 66 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 68 ++-
drivers/net/wireless/ath/ath9k/common.c | 314 +-------
drivers/net/wireless/ath/ath9k/common.h | 77 +--
drivers/net/wireless/ath/ath9k/debug.c | 56 +-
drivers/net/wireless/ath/ath9k/debug.h | 2 +
drivers/net/wireless/ath/ath9k/eeprom.c | 29 +
drivers/net/wireless/ath/ath9k/eeprom.h | 2 +
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 1 +
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 618 ++++++++--------
drivers/net/wireless/ath/ath9k/eeprom_def.c | 1 +
drivers/net/wireless/ath/ath9k/hif_usb.c | 58 +-
drivers/net/wireless/ath/ath9k/hif_usb.h | 2 +
drivers/net/wireless/ath/ath9k/htc.h | 12 +-
drivers/net/wireless/ath/ath9k/htc_drv_beacon.c | 23 +
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 127 +++-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 397 ++++++----
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 47 +-
drivers/net/wireless/ath/ath9k/htc_hst.c | 3 +-
drivers/net/wireless/ath/ath9k/hw.c | 41 +-
drivers/net/wireless/ath/ath9k/hw.h | 14 +-
drivers/net/wireless/ath/ath9k/init.c | 19 +-
drivers/net/wireless/ath/ath9k/main.c | 255 +------
drivers/net/wireless/ath/ath9k/rc.c | 177 +++--
drivers/net/wireless/ath/ath9k/recv.c | 278 +++++++-
drivers/net/wireless/ath/ath9k/reg.h | 62 +-
drivers/net/wireless/ath/ath9k/wmi.c | 3 -
drivers/net/wireless/ath/ath9k/xmit.c | 60 +-
drivers/net/wireless/b43/dma.c | 69 +-
drivers/net/wireless/b43legacy/dma.c | 49 +-
drivers/net/wireless/hostap/hostap_hw.c | 9 -
drivers/net/wireless/ipw2x00/ipw2100.c | 18 +-
drivers/net/wireless/ipw2x00/ipw2200.c | 3 +-
drivers/net/wireless/iwlwifi/Kconfig | 6 +-
drivers/net/wireless/iwlwifi/iwl-1000.c | 2 +
drivers/net/wireless/iwlwifi/iwl-3945-debugfs.c | 28 +-
drivers/net/wireless/iwlwifi/iwl-3945.c | 202 +-----
drivers/net/wireless/iwlwifi/iwl-4965.c | 83 ++-
drivers/net/wireless/iwlwifi/iwl-5000.c | 58 ++-
drivers/net/wireless/iwlwifi/iwl-6000.c | 345 ++++++++-
drivers/net/wireless/iwlwifi/iwl-agn-debugfs.c | 27 +-
drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c | 26 +-
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 252 ++----
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 3 +-
drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 77 ++-
drivers/net/wireless/iwlwifi/iwl-agn-ucode.c | 123 +++
drivers/net/wireless/iwlwifi/iwl-agn.c | 609 ++++++++++-----
drivers/net/wireless/iwlwifi/iwl-agn.h | 34 +
drivers/net/wireless/iwlwifi/iwl-commands.h | 3 +-
drivers/net/wireless/iwlwifi/iwl-core.c | 305 ++++----
drivers/net/wireless/iwlwifi/iwl-core.h | 25 +-
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 81 +--
drivers/net/wireless/iwlwifi/iwl-dev.h | 76 +-
drivers/net/wireless/iwlwifi/iwl-helpers.h | 27 +
drivers/net/wireless/iwlwifi/iwl-rx.c | 6 +-
drivers/net/wireless/iwlwifi/iwl-scan.c | 40 +-
drivers/net/wireless/iwlwifi/iwl-sta.c | 72 +-
drivers/net/wireless/iwlwifi/iwl-sta.h | 29 +
drivers/net/wireless/iwlwifi/iwl-tx.c | 33 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 183 ++---
drivers/net/wireless/iwmc3200wifi/hal.c | 2 +-
drivers/net/wireless/iwmc3200wifi/rx.c | 4 +-
drivers/net/wireless/libertas/cmd.c | 37 +-
drivers/net/wireless/libertas/cmdresp.c | 30 +-
drivers/net/wireless/libertas/decl.h | 2 +-
drivers/net/wireless/libertas/dev.h | 6 +
drivers/net/wireless/libertas/ethtool.c | 24 +-
drivers/net/wireless/libertas/if_sdio.c | 58 ++
drivers/net/wireless/libertas/if_usb.c | 12 +-
drivers/net/wireless/libertas/main.c | 79 ++-
drivers/net/wireless/libertas/scan.c | 2 +-
drivers/net/wireless/libertas_tf/if_usb.c | 5 +-
drivers/net/wireless/mwl8k.c | 12 +-
drivers/net/wireless/orinoco/hermes_dld.c | 2 +-
drivers/net/wireless/orinoco/orinoco_usb.c | 4 +-
drivers/net/wireless/orinoco/wext.c | 4 +-
drivers/net/wireless/p54/eeprom.c | 4 +-
drivers/net/wireless/p54/p54spi.c | 5 +-
drivers/net/wireless/p54/p54usb.c | 4 +-
drivers/net/wireless/prism54/isl_ioctl.c | 11 +-
drivers/net/wireless/rndis_wlan.c | 36 +-
drivers/net/wireless/rt2x00/rt2400pci.c | 17 +-
drivers/net/wireless/rt2x00/rt2500pci.c | 17 +-
drivers/net/wireless/rt2x00/rt2500usb.c | 31 +-
drivers/net/wireless/rt2x00/rt2800.h | 49 ++-
drivers/net/wireless/rt2x00/rt2800lib.c | 154 ++--
drivers/net/wireless/rt2x00/rt2800lib.h | 13 +-
drivers/net/wireless/rt2x00/rt2800pci.c | 103 +--
drivers/net/wireless/rt2x00/rt2800pci.h | 19 -
drivers/net/wireless/rt2x00/rt2800usb.c | 104 ++--
drivers/net/wireless/rt2x00/rt2800usb.h | 37 -
drivers/net/wireless/rt2x00/rt2x00.h | 42 +-
drivers/net/wireless/rt2x00/rt2x00config.c | 12 +-
drivers/net/wireless/rt2x00/rt2x00debug.c | 1 +
drivers/net/wireless/rt2x00/rt2x00dev.c | 7 +-
drivers/net/wireless/rt2x00/rt2x00dump.h | 7 +-
drivers/net/wireless/rt2x00/rt2x00ht.c | 47 +-
drivers/net/wireless/rt2x00/rt2x00lib.h | 26 +-
drivers/net/wireless/rt2x00/rt2x00pci.c | 51 ++-
drivers/net/wireless/rt2x00/rt2x00pci.h | 8 +
drivers/net/wireless/rt2x00/rt2x00queue.c | 34 +-
drivers/net/wireless/rt2x00/rt2x00usb.c | 33 +-
drivers/net/wireless/rt2x00/rt2x00usb.h | 19 -
drivers/net/wireless/rt2x00/rt61pci.c | 14 +-
drivers/net/wireless/rt2x00/rt73usb.c | 48 +-
drivers/net/wireless/wl12xx/Kconfig | 4 +-
drivers/net/wireless/wl12xx/wl1251_main.c | 4 +-
drivers/net/wireless/wl12xx/wl1251_sdio.c | 41 +-
drivers/net/wireless/wl12xx/wl1271.h | 31 +-
drivers/net/wireless/wl12xx/wl1271_cmd.c | 41 +-
drivers/net/wireless/wl12xx/wl1271_cmd.h | 28 +-
drivers/net/wireless/wl12xx/wl1271_event.c | 10 +-
drivers/net/wireless/wl12xx/wl1271_ini.h | 123 +++
drivers/net/wireless/wl12xx/wl1271_main.c | 95 ++-
drivers/net/wireless/wl12xx/wl1271_sdio.c | 2 +-
drivers/net/wireless/wl12xx/wl1271_testmode.c | 11 +-
drivers/net/wireless/wl12xx/wl1271_tx.c | 36 +-
drivers/net/wireless/wl12xx/wl1271_tx.h | 1 +
drivers/net/wireless/zd1211rw/zd_mac.c | 2 +-
drivers/net/wireless/zd1211rw/zd_usb.c | 2 +-
drivers/ssb/driver_chipcommon.c | 25 +
drivers/ssb/driver_chipcommon_pmu.c | 17 +-
drivers/ssb/main.c | 76 +--
drivers/ssb/pci.c | 15 +-
include/linux/nl80211.h | 2 +-
include/linux/ssb/ssb.h | 159 +----
include/net/cfg80211.h | 120 +++-
include/net/mac80211.h | 35 +-
net/mac80211/Kconfig | 7 +
net/mac80211/Makefile | 4 +
net/mac80211/agg-tx.c | 7 +-
net/mac80211/cfg.c | 22 +-
net/mac80211/debugfs.c | 154 ++---
net/mac80211/debugfs_sta.c | 48 +-
net/mac80211/driver-ops.h | 25 +-
net/mac80211/driver-trace.h | 35 +-
net/mac80211/ibss.c | 14 +-
net/mac80211/ieee80211_i.h | 7 +-
net/mac80211/iface.c | 14 +-
net/mac80211/key.c | 288 ++------
net/mac80211/key.h | 22 +-
net/mac80211/main.c | 81 ++-
net/mac80211/mlme.c | 75 ++-
net/mac80211/rate.h | 13 +
net/mac80211/rc80211_minstrel_ht.c | 824 ++++++++++++++++++++
net/mac80211/rc80211_minstrel_ht.h | 128 +++
net/mac80211/rc80211_minstrel_ht_debugfs.c | 120 +++
net/mac80211/rx.c | 41 +-
net/mac80211/sta_info.c | 8 -
net/mac80211/sta_info.h | 44 +-
net/mac80211/status.c | 2 +-
net/mac80211/work.c | 2 +-
net/wireless/chan.c | 5 +-
net/wireless/core.h | 1 +
net/wireless/mlme.c | 3 +-
net/wireless/nl80211.c | 3 +
186 files changed, 6755 insertions(+), 4340 deletions(-)
create mode 100644 drivers/net/wireless/ath/ath5k/sysfs.c
copy drivers/net/wireless/ath/ath9k/{ar9003_initvals.h => ar9003_2p0_initvals.h} (99%)
rename drivers/net/wireless/ath/ath9k/{ar9003_initvals.h => ar9003_2p2_initvals.h} (91%)
create mode 100644 drivers/net/wireless/wl12xx/wl1271_ini.h
create mode 100644 net/mac80211/rc80211_minstrel_ht.c
create mode 100644 net/mac80211/rc80211_minstrel_ht.h
create mode 100644 net/mac80211/rc80211_minstrel_ht_debugfs.c
Omnibus patch is available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2010-06-09.patch.bz2
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: 2.6.35-rc2-git1 - include/linux/cgroup.h:534 invoked rcu_dereference_check() without protection!
From: Miles Lane @ 2010-06-09 21:15 UTC (permalink / raw)
To: Peter Zijlstra
Cc: paulmck, Vivek Goyal, Eric Paris, Lai Jiangshan, Ingo Molnar,
LKML, nauman, eric.dumazet, netdev, Jens Axboe, Gui Jianfeng,
Li Zefan, Johannes Berg
In-Reply-To: <1276107311.1745.66.camel@laptop>
On Wed, Jun 9, 2010 at 2:15 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, 2010-06-09 at 19:57 +0200, Peter Zijlstra wrote:
>> + /*
>> + * We're not in the pid-hash yet so no cgroup attach races, and the
>> + * cgroup is pinned by the parent running this.
>> + *
>> + * Silence PROVE_RCU.
>> + */
>
> Hum,.. not sure that's actually true though, the parent itself is still
> susceptible to races afaict..
Do you want what you sent earlier tested, or should I wait for another patch?
^ permalink raw reply
* Re: 2.6.35-rc2-git1 - include/linux/cgroup.h:534 invoked rcu_dereference_check() without protection!
From: Peter Zijlstra @ 2010-06-09 21:20 UTC (permalink / raw)
To: Miles Lane
Cc: paulmck, Vivek Goyal, Eric Paris, Lai Jiangshan, Ingo Molnar,
LKML, nauman, eric.dumazet, netdev, Jens Axboe, Gui Jianfeng,
Li Zefan, Johannes Berg
In-Reply-To: <AANLkTilG5bjN5QaOChmuVN6vT7kMK4eGaV-DvPynBn_t@mail.gmail.com>
On Wed, 2010-06-09 at 17:15 -0400, Miles Lane wrote:
> On Wed, Jun 9, 2010 at 2:15 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Wed, 2010-06-09 at 19:57 +0200, Peter Zijlstra wrote:
> >> + /*
> >> + * We're not in the pid-hash yet so no cgroup attach races, and the
> >> + * cgroup is pinned by the parent running this.
> >> + *
> >> + * Silence PROVE_RCU.
> >> + */
> >
> > Hum,.. not sure that's actually true though, the parent itself is still
> > susceptible to races afaict..
>
> Do you want what you sent earlier tested, or should I wait for another patch?
please wait, I need to sit down and sort out that code.
^ permalink raw reply
* Packet capture and Bonding asymmetries
From: Paul LeoNerd Evans @ 2010-06-09 21:27 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 1614 bytes --]
We use ethernet bonding to bond eth0 + eth1 into bond0, in an
active/standby failover pair. Given this is for redundancy, we put the
two physical ethernet links into different switches that follow
different paths in the data centre.
Given this topology, it can be really useful to know which physical
interface packets are received on. It seems the bonding driver doesn't
make this happen:
# uname -r
2.6.31.12
# head -1 /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008)
# pktdump -f icmp
[15:27:12] RX(bond0): ICMP| 192.168.57.6->192.168.57.1 echo-request seq=1
[15:27:12] TX(bond0): ICMP| 192.168.57.1->192.168.57.6 echo-reply seq=1
[15:27:12] TX(eth0): ICMP| 192.168.57.1->192.168.57.6 echo-reply seq=1
I.e. when we transmit we see both the virtual bond0 interface and the
physical eth0 doing so; but when we receive only the virtual bond0
appears to do so.
I believe this should be fixable with a one-line patch; just adding a
call to netif_nit_deliver(skb) from within the bonding driver... though
just offhand I'm unable to find exactly the line where packets received
on slaves gets passed up to the master. :)
Can anyone advise on the sensibility or otherwise of this plan? I really
would like the behaviour where I can see how packets are received - is
this a good plan to acheive it?
I may sometime have a hack at writing a patch for this anyway, presuming
no major objections...
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
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