* Re: Null pointer dereference in icmp_send
From: Eric Dumazet @ 2011-05-16 21:27 UTC (permalink / raw)
To: Aristide Fattori; +Cc: netdev, roberto.paleari
In-Reply-To: <BANLkTi=uBDOQOJJMGn6V0Ne7OjQ7kGc-2w@mail.gmail.com>
Le lundi 16 mai 2011 à 23:06 +0200, Aristide Fattori a écrit :
> Hi everybody,
>
> in function icmp_send() (net/ipv4/icmp.c), the parameter passed to
> dev_net() function is not properly validated. This can lead to a NULL
> pointer dereference that crashes the kernel. The bug can be triggered
> remotely, by flooding the target with fragmented IPv4 packets.
> Important fields in the IP packet are:
> * Flags: the MF flag must be set.
> * Fragment ID: using pseudo-random values for this field quickly
> fills fragmented queues in the victim's kernel, as it is unable to
> easily reassemble received packets.
> * TOS: using pseudo-random values for this field triggers the
> creation of more than one route cache entry for the same destination
> address, increasing the chances of incurring in the error condition
> described before.
> Other fields of the packet do not really matter, and they can be set
> to arbitrary values.
>
> If you are interested, we can provide a small and very dirty python
> script that easily triggers the error condition.
>
Hi
You forgot to tell us which linux version you used ?
We had some fixes lately in this area.
Thanks
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2011-05-16
From: David Miller @ 2011-05-16 21:27 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110516211305.GG6551-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Mon, 16 May 2011 17:13:06 -0400
> Still another big batch of wireless LAN stuff intended for 2.6.40 -- the
> wireless folks have really been eating their Wheaties this cycle!
>
> Highlights of this batch include a new driver in the rtlwifi family,
> some new AMBA-like bus infrastructure that is specific to Broadcom
> devices, a Bluetooth pull from Gustavo and friends, a wl12xx pull from
> Luca and friends, some mesh updates from the Cozybit folks, some more
> fixups from the mwifiex team, a collection of mac80211 improvements from
> Johannes, the usual flutter of patches around iwlwifi and ath9k, and a
> spread of other updates.
>
> Please let me know if there are problems!
Wonderful, another strange bus layer :-)
Pulled, thanks John!
--
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: [PATCH V5 4/6 net-next] vhost: vhost TX zero-copy support
From: Michael S. Tsirkin @ 2011-05-16 21:27 UTC (permalink / raw)
To: Shirley Ma
Cc: David Miller, Eric Dumazet, Avi Kivity, Arnd Bergmann, netdev,
kvm, linux-kernel
In-Reply-To: <1305579414.3456.49.camel@localhost.localdomain>
On Mon, May 16, 2011 at 01:56:54PM -0700, Shirley Ma wrote:
> On Mon, 2011-05-16 at 23:45 +0300, Michael S. Tsirkin wrote:
> > > +/* Since we need to keep the order of used_idx as avail_idx, it's
> > possible that
> > > + * DMA done not in order in lower device driver for some reason. To
> > prevent
> > > + * used_idx out of order, upend_idx is used to track avail_idx
> > order, done_idx
> > > + * is used to track used_idx order. Once lower device DMA done,
> > then upend_idx
> > > + * can move to done_idx.
> >
> > Could you clarify this please? virtio explicitly allows out of order
> > completion of requests. Does it simplify code that we try to keep
> > used index updates in-order? Because if not, this is not
> > really a requirement.
>
> Hello Mike,
>
> Based on my testing, vhost_add_used() must be in order from
> vhost_get_vq_desc(). Otherwise, virtio_net ring seems get double
> freed. I didn't spend time on debugging this.
>
> in virtqueue_get_buf
>
> if (unlikely(!vq->data[i])) {
> BAD_RING(vq, "id %u is not a head!\n", i);
> return NULL;
> }
>
> That's the reason I created the upend_idx and done_idx.
>
> Thanks
> Shirley
One thing of note: it's possible that this actually works
better than trying to complete out of order, as the
ring just keeps going which should be good for cache
utilization. OTOH, this might explain why
you are over-running the TX ring much more with this patch.
So I don't say this should block merging the patch,
but I very much would like to understand the issue,
and it's interesting to experiment with fixing it
and seeing what it does to performance and to code size.
--
MST
^ permalink raw reply
* Re: [PATCH V5 4/6 net-next] vhost: vhost TX zero-copy support
From: Shirley Ma @ 2011-05-16 21:30 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: David Miller, Eric Dumazet, Avi Kivity, Arnd Bergmann, netdev,
kvm, linux-kernel
In-Reply-To: <20110516212401.GF18148@redhat.com>
On Tue, 2011-05-17 at 00:24 +0300, Michael S. Tsirkin wrote:
> Very strange, it sounds like a bug, but I can't tell where: in
> host or in guest. If it's in the guest, we must fix it.
> If in host, we should only fix it if it makes life simpler for us.
> Could you try to nail it down pls? Another question: will code get
> simpler or more complex if that restriction's removed?
It should be similar. We still need to maintain the pending list, and
mark the DMA done ids.
I can make a try to narrow this issue down.
Thanks
Shirley
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv4: more compliant RFC 3168 support
From: Hagen Paul Pfeifer @ 2011-05-16 21:33 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Stefanos Harhalakis, David Miller, netdev
In-Reply-To: <1305475310.3120.146.camel@edumazet-laptop>
* Eric Dumazet | 2011-05-15 18:01:50 [+0200]:
>Problem of this version is that common frames in the Internet (NOT_ECT
>or ECT_X or ECT_X) will take the longest path to come to "return 0;"
>
>a switch() version is fast because gcc emits a table based jump
Sure? Is the table access not an dCache miss? E.g.
4003dc: ff 24 fd 58 06 40 00 jmpq *0x400658(,%rdi,8)
Not sure if jump table access is superior these days ...
Hagen
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv4: more compliant RFC 3168 support
From: Eric Dumazet @ 2011-05-16 21:38 UTC (permalink / raw)
To: Hagen Paul Pfeifer; +Cc: Stefanos Harhalakis, David Miller, netdev
In-Reply-To: <20110516213336.GD3290@nuttenaction>
Le lundi 16 mai 2011 à 23:33 +0200, Hagen Paul Pfeifer a écrit :
> * Eric Dumazet | 2011-05-15 18:01:50 [+0200]:
>
> >Problem of this version is that common frames in the Internet (NOT_ECT
> >or ECT_X or ECT_X) will take the longest path to come to "return 0;"
> >
> >a switch() version is fast because gcc emits a table based jump
>
> Sure? Is the table access not an dCache miss? E.g.
>
> 4003dc: ff 24 fd 58 06 40 00 jmpq *0x400658(,%rdi,8)
>
> Not sure if jump table access is superior these days ...
>
Check v2 of patch, it is fine, small, fast ;)
By the way, you dont want to know how many cpu cycles we spend in IP
defrag functions... Really its insane.
^ permalink raw reply
* Re: Null pointer dereference in icmp_send
From: Eric Dumazet @ 2011-05-16 21:38 UTC (permalink / raw)
To: Aristide Fattori; +Cc: netdev, roberto.paleari
In-Reply-To: <1305581236.9466.4.camel@edumazet-laptop>
Le lundi 16 mai 2011 à 23:27 +0200, Eric Dumazet a écrit :
> Le lundi 16 mai 2011 à 23:06 +0200, Aristide Fattori a écrit :
> > Hi everybody,
> >
> > in function icmp_send() (net/ipv4/icmp.c), the parameter passed to
> > dev_net() function is not properly validated. This can lead to a NULL
> > pointer dereference that crashes the kernel. The bug can be triggered
> > remotely, by flooding the target with fragmented IPv4 packets.
> > Important fields in the IP packet are:
> > * Flags: the MF flag must be set.
> > * Fragment ID: using pseudo-random values for this field quickly
> > fills fragmented queues in the victim's kernel, as it is unable to
> > easily reassemble received packets.
> > * TOS: using pseudo-random values for this field triggers the
> > creation of more than one route cache entry for the same destination
> > address, increasing the chances of incurring in the error condition
> > described before.
> > Other fields of the packet do not really matter, and they can be set
> > to arbitrary values.
> >
> > If you are interested, we can provide a small and very dirty python
> > script that easily triggers the error condition.
> >
>
> Hi
>
> You forgot to tell us which linux version you used ?
>
> We had some fixes lately in this area.
>
Since its late here I should give more information :)
We fixed a problem 12 days ago, please check following patch
http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commit;h=64f3b9e203bd06855072e295557dca1485a2ecba
It is scheduled for linux-2.6.38 stable tree as well
net: ip_expire() must revalidate route
Commit 4a94445c9a5c (net: Use ip_route_input_noref() in input path)
added a bug in IP defragmentation handling, in case timeout is fired.
When a frame is defragmented, we use last skb dst field when building
final skb. Its dst is valid, since we are in rcu read section.
But if a timeout occurs, we take first queued fragment to build one ICMP
TIME EXCEEDED message. Problem is all queued skb have weak dst pointers,
since we escaped RCU critical section after their queueing. icmp_send()
might dereference a now freed (and possibly reused) part of memory.
Calling skb_dst_drop() and ip_route_input_noref() to revalidate route is
the only possible choice.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv4: more compliant RFC 3168 support
From: Hagen Paul Pfeifer @ 2011-05-16 21:49 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Stefanos Harhalakis, David Miller, netdev
In-Reply-To: <1305581918.9466.10.camel@edumazet-laptop>
* Eric Dumazet | 2011-05-16 23:38:38 [+0200]:
>Check v2 of patch, it is fine, small, fast ;)
Eric, I trust you! ;-)
>By the way, you dont want to know how many cpu cycles we spend in IP
>defrag functions... Really its insane.
I can image it! I wanted to point out to the fact that gcc's (and other compiler
too) jump table optimizations are not advantageous than a few years ago.
Maybe jump table optimizations are a relict some decades ago ...
Hagen
^ permalink raw reply
* Re: [PATCH] ethtool: ETHTOOL_SFEATURES: remove NETIF_F_COMPAT return
From: Michał Mirosław @ 2011-05-16 21:50 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, David Miller
In-Reply-To: <1305580139.2885.47.camel@bwh-desktop>
On Mon, May 16, 2011 at 10:08:59PM +0100, Ben Hutchings wrote:
> On Mon, 2011-05-16 at 22:51 +0200, Michał Mirosław wrote:
> > On Mon, May 16, 2011 at 03:53:17PM +0100, Ben Hutchings wrote:
> > > On Mon, 2011-05-16 at 16:23 +0200, Michał Mirosław wrote:
> > > > On Mon, May 16, 2011 at 02:37:46PM +0100, Ben Hutchings wrote:
> > > > > On Mon, 2011-05-16 at 15:28 +0200, Michał Mirosław wrote:
> > > > > > Remove NETIF_F_COMPAT since it's redundant and will be unused after
> > > > > > all drivers are converted to fix/set_features.
> > > > > >
> > > > > > Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> > > > > > ---
> > > > > >
> > > > > > For net as we don't want to have ETHTOOL_F_COMPAT hit stable release.
> > > > > [...]
> > > > > ETHTOOL_F_WISH means that the requested features could not all be
> > > > > enabled, *but are remembered*. ETHTOOL_F_COMPAT means they were not
> > > > > remembered.
> > > > Hmm. So, lets just revert 39fc0ce5710c53bad14aaba1a789eec810c556f9
> > > > (net: Implement SFEATURES compatibility for not updated drivers).
> > > That's also problematic because it means we can't make any use of the
> > > 'available' masks from ETHTOOL_GFEATURES.
> > >
> > > The patch I sent is actually tested with a modified ethtool. The
> > > fallback works. I don't think you've tested whether any of your
> > > proposals can actually practically be used by ethtool.
> >
> > While reading your patches I noted some differences in the way we see
> > the new [GS]FEATURES ops.
> >
> > First, you make NETIF_F_* flags part of the ethtool ABI. In my approach
> > feature names become an ABI instead. That's what ETH_SS_FEATURES string
> > set is for, and that's what comments in kernel's <linux/ethtool.h>
> > include say.
>
> We've been through this before. I can't use those names in ethtool
> because they aren't the same as ethtool used previously. I could make
> it map strings to strings, but I don't see the point.
>
> > dev->features are exposed directly by kernel only in two ways:
> > 1. /sys/class/net/*/features - since NETIF_F_* flags are not exported
> > in headers for userspace, this should be treated like a debugging
> > facility and not an ABI
> > 2. ETHTOOL_[GS]FLAGS - these export 5 flags (LRO, VLAN offload, NTuple,
> > and RX hashing) that are renamed to ETH_FLAG_* - only those constants
> > are in the ABI and only in relation with ETHTOOL_[GS]FLAGS
> >
> > Second, you reimplement 'ethtool -K' using ETHTOOL_SFEATURES. Does this mean
> > that we want to get rid of ETHTOOL_[GS]{FLAGS,SG,...} from kernel?
> We must not.
So what's the point in reimplementing old options via ETHTOOL_SFEATURES?
> > The
> > assumptions in those calls are a bit different from ETHTOOL_[GS]FEATURES
> > but there is an conversion layer in kernel that allows old binaries to
> > work correctly in the common case. (-EOPNOTSUPP is still returned for
> > drivers which can't change particular feature. The difference is seen
> > only in that disabling and enabling e.g. checksumming won't disable other
> > dependent features in the result.)
> >
> > Right now we already agree that NETIF_F_COMPAT should go.
> >
> > I'll send my idea of the ethtool code using ETHTOOL_[GS]FEATURES and
> > keeping NETIF_F_* flags internal to the kernel. It adds new modes (-w/-W).
> > This might be made even more useful by adding simple wildcard matching.
> I've explained before that I do not want to add new options to do
> (mostly) the same thing. Users should have not have to use a different
> command depending on the kernel version.
We can avoid new option by checking feature-strings for unrecognised
arguments to -K. This way, we will have the old options which work
regardless of kernel version ('tx', 'rx', 'sg', etc.) and new options
which need recent kernel anyway (separated 'tx-checksum-*', 'loopback',
others coming in for 2.6.40). Also, this way fallbacks in userspace
are avoided.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH net-2.6] net: Keep TX queues stopped as long as the physical device is absent
From: Ben Hutchings @ 2011-05-16 21:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1305579891.2885.44.camel@bwh-desktop>
On Mon, 2011-05-16 at 22:04 +0100, Ben Hutchings wrote:
> netif_device_detach() stops all TX queues, but there is nothing to
> prevent them from being restarted. In fact, netif_tx_unlock() may now
rescheduled
> do this. Add another queue state flag that is set while the device is
> absent, and make netif_tx_queue_frozen_or_stopped() test it. Rename the
> function to netif_tx_queue_blocked() since it makes little sense to keep
> adding flags to its name.
[...]
So I suspect this isn't a real problem - as long as the device remains
detached then the driver won't (or shouldn't) start the queues again.
Although the queues may be scheduled (which this patch doesn't change),
ndo_start_xmit() will not be called.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] ethtool: ETHTOOL_SFEATURES: remove NETIF_F_COMPAT return
From: Ben Hutchings @ 2011-05-16 22:09 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev, David Miller
In-Reply-To: <20110516215034.GA8463@rere.qmqm.pl>
On Mon, 2011-05-16 at 23:50 +0200, Michał Mirosław wrote:
> On Mon, May 16, 2011 at 10:08:59PM +0100, Ben Hutchings wrote:
> > On Mon, 2011-05-16 at 22:51 +0200, Michał Mirosław wrote:
> > > On Mon, May 16, 2011 at 03:53:17PM +0100, Ben Hutchings wrote:
> > > > On Mon, 2011-05-16 at 16:23 +0200, Michał Mirosław wrote:
> > > > > On Mon, May 16, 2011 at 02:37:46PM +0100, Ben Hutchings wrote:
> > > > > > On Mon, 2011-05-16 at 15:28 +0200, Michał Mirosław wrote:
> > > > > > > Remove NETIF_F_COMPAT since it's redundant and will be unused after
> > > > > > > all drivers are converted to fix/set_features.
> > > > > > >
> > > > > > > Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> > > > > > > ---
> > > > > > >
> > > > > > > For net as we don't want to have ETHTOOL_F_COMPAT hit stable release.
> > > > > > [...]
> > > > > > ETHTOOL_F_WISH means that the requested features could not all be
> > > > > > enabled, *but are remembered*. ETHTOOL_F_COMPAT means they were not
> > > > > > remembered.
> > > > > Hmm. So, lets just revert 39fc0ce5710c53bad14aaba1a789eec810c556f9
> > > > > (net: Implement SFEATURES compatibility for not updated drivers).
> > > > That's also problematic because it means we can't make any use of the
> > > > 'available' masks from ETHTOOL_GFEATURES.
> > > >
> > > > The patch I sent is actually tested with a modified ethtool. The
> > > > fallback works. I don't think you've tested whether any of your
> > > > proposals can actually practically be used by ethtool.
> > >
> > > While reading your patches I noted some differences in the way we see
> > > the new [GS]FEATURES ops.
> > >
> > > First, you make NETIF_F_* flags part of the ethtool ABI. In my approach
> > > feature names become an ABI instead. That's what ETH_SS_FEATURES string
> > > set is for, and that's what comments in kernel's <linux/ethtool.h>
> > > include say.
> >
> > We've been through this before. I can't use those names in ethtool
> > because they aren't the same as ethtool used previously. I could make
> > it map strings to strings, but I don't see the point.
> >
> > > dev->features are exposed directly by kernel only in two ways:
> > > 1. /sys/class/net/*/features - since NETIF_F_* flags are not exported
> > > in headers for userspace, this should be treated like a debugging
> > > facility and not an ABI
> > > 2. ETHTOOL_[GS]FLAGS - these export 5 flags (LRO, VLAN offload, NTuple,
> > > and RX hashing) that are renamed to ETH_FLAG_* - only those constants
> > > are in the ABI and only in relation with ETHTOOL_[GS]FLAGS
> > >
> > > Second, you reimplement 'ethtool -K' using ETHTOOL_SFEATURES. Does this mean
> > > that we want to get rid of ETHTOOL_[GS]{FLAGS,SG,...} from kernel?
> > We must not.
>
> So what's the point in reimplementing old options via ETHTOOL_SFEATURES?
Where, in ethtool? The benefits include:
- Kernel remembers all the features the user wants on, even if the
combination is impossible. Turning TX checksumming off and on no longer
forces TSO off.
- ethtool can distinguish and report whether a feature is unsupported or
its dependencies are not met.
> > > The
> > > assumptions in those calls are a bit different from ETHTOOL_[GS]FEATURES
> > > but there is an conversion layer in kernel that allows old binaries to
> > > work correctly in the common case. (-EOPNOTSUPP is still returned for
> > > drivers which can't change particular feature. The difference is seen
> > > only in that disabling and enabling e.g. checksumming won't disable other
> > > dependent features in the result.)
> > >
> > > Right now we already agree that NETIF_F_COMPAT should go.
> > >
> > > I'll send my idea of the ethtool code using ETHTOOL_[GS]FEATURES and
> > > keeping NETIF_F_* flags internal to the kernel. It adds new modes (-w/-W).
> > > This might be made even more useful by adding simple wildcard matching.
> > I've explained before that I do not want to add new options to do
> > (mostly) the same thing. Users should have not have to use a different
> > command depending on the kernel version.
>
> We can avoid new option by checking feature-strings for unrecognised
> arguments to -K. This way, we will have the old options which work
> regardless of kernel version ('tx', 'rx', 'sg', etc.) and new options
> which need recent kernel anyway (separated 'tx-checksum-*', 'loopback',
> others coming in for 2.6.40).
This is just too subtle a distinction. It will mostly confuse users.
> Also, this way fallbacks in userspace are avoided.
No, ethtool will be supporting kernels <2.6.40 for many years yet.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Herbert Xu @ 2011-05-16 22:46 UTC (permalink / raw)
To: Michał Mirosław
Cc: Michael S. Tsirkin, Shan Wei, Michał Mirosław, netdev,
Ben Hutchings
In-Reply-To: <BANLkTi=7i=AQfPNBEGcLFieaO9wXgBk6rg@mail.gmail.com>
On Mon, May 16, 2011 at 02:24:19PM +0200, Michał Mirosław wrote:
>
> In this case - no. Those messages inform that driver supports more
> feature combinations than network core and the feature set is reduced
> because of that.
The driver should never even claim to support SG/TSO/UFO if it
does not support checksum. That is the point of the warning.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] net: recvmmsg: Strip MSG_WAITFORONE when calling recvmsg
From: Anton Blanchard @ 2011-05-16 22:59 UTC (permalink / raw)
To: acme, davem; +Cc: netdev
recvmmsg fails on a raw socket with EINVAL. The reason for this is
packet_recvmsg checks the incoming flags:
err = -EINVAL;
if (flags & ~(MSG_PEEK|MSG_DONTWAIT|MSG_TRUNC|MSG_CMSG_COMPAT|MSG_ERRQUEUE))
goto out;
This patch strips out MSG_WAITFORONE when calling recvmmsg which
fixes the issue.
Signed-off-by: Anton Blanchard <anton@samba.org>
Cc: stable@kernel.org [2.6.34+]
---
We could also add MSG_WAITFORONE to the raw socket recvmsg check, or
just remove the check completely. Thoughts?
Index: linux-net/net/socket.c
===================================================================
--- linux-net.orig/net/socket.c 2011-05-09 08:59:22.757767314 +1000
+++ linux-net/net/socket.c 2011-05-16 17:14:52.501268819 +1000
@@ -2232,14 +2232,16 @@ int __sys_recvmmsg(int fd, struct mmsghd
*/
if (MSG_CMSG_COMPAT & flags) {
err = __sys_recvmsg(sock, (struct msghdr __user *)compat_entry,
- &msg_sys, flags, datagrams);
+ &msg_sys, flags & ~MSG_WAITFORONE,
+ datagrams);
if (err < 0)
break;
err = __put_user(err, &compat_entry->msg_len);
++compat_entry;
} else {
err = __sys_recvmsg(sock, (struct msghdr __user *)entry,
- &msg_sys, flags, datagrams);
+ &msg_sys, flags & ~MSG_WAITFORONE,
+ datagrams);
if (err < 0)
break;
err = put_user(err, &entry->msg_len);
^ permalink raw reply
* Re: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: David Miller @ 2011-05-16 23:06 UTC (permalink / raw)
To: herbert; +Cc: mirqus, mst, shanwei, mirq-linux, netdev, bhutchings
In-Reply-To: <20110516224658.GA11157@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.hengli.com.au>
Date: Tue, 17 May 2011 08:46:58 +1000
> On Mon, May 16, 2011 at 02:24:19PM +0200, Michał Mirosław wrote:
>>
>> In this case - no. Those messages inform that driver supports more
>> feature combinations than network core and the feature set is reduced
>> because of that.
>
> The driver should never even claim to support SG/TSO/UFO if it
> does not support checksum. That is the point of the warning.
Well the check has to exist somewhere.
Currently userspace can configure tun/tap into whatever set
of offloads it likes.
We're warning when the user asks for something that needs to be
corrected. So the only thing you can suggest is to duplicate these
changes in the tun/tap driver.
But if we do that, and error on bad combinations instead of fixing
them up, we know from this discussion that existing virtualization
setups and tools are going to stop working.
^ permalink raw reply
* Re: [PATCH V5 2/6 net-next] netdevice.h: Add zero-copy flag in netdevice
From: Shirley Ma @ 2011-05-16 23:32 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Ben Hutchings, David Miller, Eric Dumazet, Avi Kivity,
Arnd Bergmann, netdev, kvm, linux-kernel
In-Reply-To: <20110516211459.GE18148@redhat.com>
Hello Michael,
Looks like to use a new flag requires more time/work. I am thinking
whether we can just use HIGHDMA flag to enable zero-copy in macvtap to
avoid the new flag for now since mavctap uses real NICs as lower device?
Thanks
Shirley
^ permalink raw reply
* Re: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Herbert Xu @ 2011-05-16 23:45 UTC (permalink / raw)
To: David Miller; +Cc: mirqus, mst, shanwei, mirq-linux, netdev, bhutchings
In-Reply-To: <20110516.190615.2121423692228640268.davem@davemloft.net>
On Mon, May 16, 2011 at 07:06:15PM -0400, David Miller wrote:
>
> Well the check has to exist somewhere.
>
> Currently userspace can configure tun/tap into whatever set
> of offloads it likes.
>
> We're warning when the user asks for something that needs to be
> corrected. So the only thing you can suggest is to duplicate these
> changes in the tun/tap driver.
>
> But if we do that, and error on bad combinations instead of fixing
> them up, we know from this discussion that existing virtualization
> setups and tools are going to stop working.
Yeah the tun driver is simply busted. We should never have allowed
user-space to tweak the feature bits like this. Instead they should
have gone through the ethtool interface like everyone else, or at
least use the same underlying calls as ethtool.
Actually, I think we can still do that, and apply the same rules
as ethtool with respect to automatically turning things on/off.
AFAICS the current set_offload in tun.c does not call anything
that verifies/fixes up the settings. If you change the feature
bits after registering the tun device it may never get fixed up
at all.
Allowing an unprivileged user to tweak feature bits directly with
no verification is just wrong.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] net: Change netdev_fix_features messages loglevel
From: Herbert Xu @ 2011-05-16 23:48 UTC (permalink / raw)
To: David Miller; +Cc: mirq-linux, netdev, mst, bhutchings
In-Reply-To: <20110516.151434.829498612745581899.davem@davemloft.net>
On Mon, May 16, 2011 at 03:14:34PM -0400, David Miller wrote:
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> Date: Mon, 16 May 2011 15:17:57 +0200 (CEST)
>
> > Those reduced to DEBUG can possibly be triggered by unprivileged processes
> > and are nothing exceptional. Illegal checksum combinations can only be
> > caused by driver bug, so promote those messages to WARN.
> >
> > Since GSO without SG will now only cause DEBUG message from
> > netdev_fix_features(), remove the workaround from register_netdevice().
> >
> > Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>
> Applied, thanks.
I think this patch is not a good idea. The only problem here
is the tun driver which should just fix up the feature bits
silently (we need to do that anyway as right now it doesn't
verify the feature bits at all, those warnings are only trigger
on registering the tun device).
With this patch future buggy drivers will instead trigger hard-
to-debug warnings further down the stack in the TSO code path,
like they have before (or silent packet drops if those warnings
aren't there anymore).
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* pull request: wireless-next-2.6 2011-05-16-v2
From: John W. Linville @ 2011-05-17 0:08 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
In-Reply-To: <20110516211305.GG6551@tuxdriver.com>
I'm sorry, Dave! In my defense, I am on the verge of sickness and got
very little sleep last night... :-(
I have corrected the problem and was sure to perform the correct build
test this time! :-)
John
---
Original pull request message follows:
Dave,
Still another big batch of wireless LAN stuff intended for 2.6.40 -- the
wireless folks have really been eating their Wheaties this cycle!
Highlights of this batch include a new driver in the rtlwifi family,
some new AMBA-like bus infrastructure that is specific to Broadcom
devices, a Bluetooth pull from Gustavo and friends, a wl12xx pull from
Luca and friends, some mesh updates from the Cozybit folks, some more
fixups from the mwifiex team, a collection of mac80211 improvements from
Johannes, the usual flutter of patches around iwlwifi and ath9k, and a
spread of other updates.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 1a8218e96271790a07dd7065a2ef173e0f67e328:
net: ping: dont call udp_ioctl() (2011-05-16 11:49:39 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git for-davem
Amitkumar Karwar (4):
mwifiex: fix simultaneous assoc and scan issue
mwifiex: remove unnecessary struct mwifiex_opt_sleep_confirm_buffer
mwifiex: remove redundant local structures
mwifiex: remove mwifiex_recv_complete function
Andy Ross (1):
Bluetooth: Device ids for ath3k on Pegatron Lucid tablets
Arik Nemtsov (13):
wl12xx: implement the tx_frames_pending mac80211 callback
wl12xx: discard corrupted packets in RX
wl12xx: add BT-coexistance for AP
wl12xx: use wiphy values for setting rts, frag thresholds on init
wl12xx: AP-mode - disable beacon filtering on start up
wl12xx: schedule recovery on command timeout
wl12xx: print firmware program counter during recovery
wl12xx: AP-mode - overhaul rate policy configuration
wl12xx: AP-mode - reconfigure templates after basic rates change
wl12xx: add debugfs entry for starting recovery
wl12xx: fix race condition during recovery in AP mode
wl12xx: export driver state to debugfs
mac80211: set TID of internal mgmt packets to 7
Ben Greear (1):
ath5k: Fix lockup due to un-init spinlock.
Bing Zhao (1):
mwifiex: cleanup ioctl.h
Chaoming Li (13):
rtlwifi: rtl8192se: Merge def.h
rtlwifi: rtl8192se: Merge dynamic management routines
rtlwifi: rtl8192se: Merge firmware routines
rtlwifi: rtl8192se: Merge hardware routines
rtlwifi: rtl8192se: Merge led routines
rtlwifi: rtl8192se: Merge phy routines
rtlwifi: rtl8192se: Merge register definitions
rtlwifi: rtl8192se: Merge rf routines
rtlwifi: rtl8192se: Merge main (sw) routines
rtlwifi: rtl8192se: Merge table routines
rtlwifi: rtl8192se: Merge TX and RX routines
rtlwifi: rtl8192se: Modify Kconfig and Makefile routines for new driver
rtlwifi: rtl8192se: Remove need to disable ASPM
Christian Lamparter (2):
carl9170: fix -Wunused-but-set-variable warnings
p54pci: fix -Wunused-but-set-variable warnings
Christoph Fritz (1):
mwifiex: fix null derefs, mem leaks and trivia
Cindy H. Kao (1):
iwlwifi: support the svtool messages interactions through nl80211 test mode
Daniel Drake (1):
libertas: remove tx_timeout handler
Daniel Halperin (1):
mac80211: fix contention time computation in minstrel, minstrel_ht
Eliad Peller (13):
wl12xx: sleep instead of wakeup after tx work
wl12xx: avoid premature elp entrance
wl12xx: print actual rx packet size (without padding)
wl12xx: avoid redundant join on interface reconfiguration
wl12xx: configure rates when working in ibss mode
wl12xx: add debugfs entries for dtim_interval and beacon_interval
wl12xx: simplify wl1271_ssid_set()
wl12xx_sdio: set interrupt as wake_up interrupt
wl12xx: declare suspend/resume callbacks (for wowlan)
wl12xx_sdio: set MMC_PM_KEEP_POWER flag on suspend
wl12xx: prevent scheduling while suspending (WoW enabled)
wl12xx_sdio: declare support for NL80211_WOW_TRIGGER_ANYTHING trigger
wl12xx: enter/exit psm on wowlan suspend/resume
Fabrice Deyber (1):
mac80211: Only process mesh PREPs with equal seq number if metric is better.
Felix Fietkau (1):
ath9k: fix a regression in PS frame filter handling
Gertjan van Wingerde (2):
rt2x00: Initial support for RT5370 USB devices.
rt2x00: Fix rmmod hang of rt2800pci
Gustavo F. Padovan (4):
Bluetooth: Add l2cap_add_psm() and l2cap_add_scid()
Bluetooth: Handle psm == 0 case inside l2cap_add_psm()
Bluetooth: Remove l2cap_sk_list
Bluetooth: Remove leftover debug messages
Hauke Mehrtens (1):
wl12xx: do not set queue_mapping directly
Ido Yariv (3):
wl12xx: Modify memory configuration for 128x/AP
wl12xx: Restart TX when TX descriptors are available
wl12xx: Enable dynamic memory for 127x
Ivo van Doorn (1):
rt2x00: Fix transfer speed regression for USB hardware
Javier Cardona (12):
nl80211: Introduce NL80211_MESH_SETUP_USERSPACE_AMPE
mac80211: Let userspace send action frames over mesh interfaces
mac80211: Drop MESH_PLINK category and use new ANA-approved MESH_ACTION
open80211s: Stop using zero for address 3 in mesh plink mgmt frames
cfg80211: Use capability info to detect mesh beacons.
nl80211: Let userspace drive the peer link management states.
mac80211: Check size of a new mesh path table for changes since allocation.
mac80211: Fix locking bug on mesh path table access
mac80211: Move call to mpp_path_lookup inside RCU-read section
mac80211: allow setting supported rates on mesh peers
ath9k: fix beaconing for mesh interfaces
nl80211: Move peer link state definition to nl80211
Joe Perches (3):
rtlwifi: rtl8192cu: Fix memset/memcpy using sizeof(ptr) not sizeof(*ptr)
libertas: Convert lbs_pr_<level> to pr_<level>
libertas: Use netdev_<level> or dev_<level> where possible
Johannes Berg (18):
nl80211/cfg80211: WoWLAN support
mac80211: add basic support for WoWLAN
iwlagn: remove get_hcmd_size indirection
iwlagn: remove frame pre-allocation
iwlagn: remove unused variable
iwlagn: dont update bytecount table for command queue
iwlagn: remove bytecount indirection
iwlagn: check DMA mapping errors
iwlagn: fix iwl_is_any_associated
cfg80211: restrict AP beacon intervals
mac80211: remove pointless mesh path timer RCU code
mac80211: make key locking clearer
mac80211: fix another key non-race
mac80211: fix a few RCU issues
mac80211: mesh: move some code to make it static
cfg80211: advertise possible interface combinations
mac80211: fix TX a-MPDU locking
mac80211: sparse RCU annotations
John W. Linville (6):
Merge branch 'for-linville' of git://git.kernel.org/.../luca/wl12xx
Merge branch 'wireless-next-2.6' of git://git.kernel.org/.../iwlwifi/iwlwifi-2.6
Merge branch 'master' of git://git.kernel.org/.../padovan/bluetooth-next-2.6
ssb: fix pcicore build breakage
Merge branch 'for-linville' of git://git.kernel.org/.../luca/wl12xx
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-next-2.6 into for-davem
Jouni Malinen (2):
nl80211: Fix set_key regression with some drivers
cfg80211: Remove unused wiphy flag
Julia Lawall (1):
net/rfkill/core.c: Avoid leaving freed data in a list
Larry Finger (2):
mac80211: Fix build error when CONFIG_PM is not defined
rtlwifi: Move 2 large arrays off stack
Luciano Coelho (15):
wl12xx: strict_stroul introduced converted to kstrtoul
Revert "wl12xx: support FW TX inactivity triggers"
mac80211: don't drop frames where skb->len < 24 in ieee80211_scan_rx()
mac80211: add a couple of trace event classes to reduce duplicated code
cfg80211/nl80211: add support for scheduled scans
mac80211: add support for HW scheduled scan
cfg80211/nl80211: add interval attribute for scheduled scans
cfg80211/mac80211: avoid bounce back mac->cfg->mac on sched_scan_stopped
wl12xx: add configuration values for scheduled scan
wl12xx: listen to scheduled scan events
wl12xx: add scheduled scan structures and commands
wl12xx: implement scheduled scan driver operations and reporting
wl12xx: export scheduled scan state in debugfs
wl12xx: prevent sched_scan when not idle or not in station mode
wl12xx: remove unused flag WL1271_FLAG_IDLE_REQUESTED
Luis R. Rodriguez (2):
ath9k_hw: fix power for the HT40 duplicate frames
ath9k_hw: fix dual band assumption for XB113
Mohammed Shafi Shajakhan (12):
ath9k_hw: remove aggregation protection mode
ath9k_hw: remove get_channel_noise function
ath9k_hw: make antenna diversity modules chip specific
ath9k_hw: enable Antenna diversity for AR9485
ath9k_hw: define registers/macros to support Antenna diversity
ath9k_hw: config diversity based on eeprom contents
ath9k_hw: define modules to get/set Antenna diversity paramaters
ath9k_hw: define antenna diversity group
ath9k: Implement an API to swap main/ALT LNA's
ath9k: configure fast_div_bias based on diversity group
ath9k: make sure main_rssi is positive
ath9k: make npending frames check as bool
Nicolas Cavallari (1):
carl9170: fix allmulticast mode
Rafał Miłecki (13):
b43: drop invalid IMCFGLO workaround
b43legacy: drop invalid IMCFGLO workaround
b43: drop ssb-duplicated workaround for dangling cores
b43legacy: drop ssb-duplicated workaround for dangling cores
b43: trivial: include ssb word in ssb specific functions
bcma: add Broadcom specific AMBA bus driver
ssb: update list of devices supporting multiple 80211 cores
b43legacy: trivial: use TMSLOW def instead of magic value
b43: move MAC PHY clock controling function
bcma: add missing GPIO defines, use PULL register only when available
ssb: move ssb_commit_settings and export it
b43: implement timeouts workaround
bcma: pci: trivial: correct amount of maximum retries
Rajkumar Manoharan (11):
ath9k: Fix drain txq failure in flush
mac80211: use wake_queue to restart trasmit
mac80211: Postpond ps timer if tx is stopped by others
ath9k_hw: do noise floor calibration only on required chains
wireless: Fix warnings due to -Wunused-but-set-variable
ath9k: avoid enabling interrupts while processing rx
ath9k: process TSF out of range before RX
ath9k_hw: Corrected xpabiaslevel register settings for AR9340
ath9k_hw: Change DCU backoff thresh for AR9340
ath9k: Fix rssi update in ad-hoc mode
ath9k: Failed to set default beacon rssi in AP/IBSS mode
Sascha Silbe (1):
libertas: Add libertas_disablemesh module parameter to disable mesh interface
Senthil Balasubramanian (1):
ath9k_hw: Fix STA connection issues with AR9380 (XB113).
Shahar Levi (6):
wl12xx: Set End-of-transaction Flag at Wl127x AP Mode
wl12xx: Set correct REF CLK and TCXO CLK values to the FW
wl12xx: FM WLAN coexistence
wl12xx: Update Power Save Exit Retries Packets
wl12xx: Don't filter beacons that include changed HT IEs
wl12xx: add IEEE80211_HW_SPECTRUM_MGMT bit to the hw flags
Stephen Boyd (2):
iwlegacy: Silence DEBUG_STRICT_USER_COPY_CHECKS=y warning
iwlwifi: Silence DEBUG_STRICT_USER_COPY_CHECKS=y warning
Thomas Pedersen (3):
nl80211: allow installing keys for a meshif
nl80211: allow setting MFP flag for a meshif
mac80211: Self-protected management frames are not robust
Vinicius Costa Gomes (2):
Bluetooth: Add support for sending connection events for LE links
Bluetooth: Add support for disconnecting LE links via mgmt
Waldemar Rymarkiewicz (1):
Bluetooth: Double check sec req for pre 2.1 device
Wey-Yi Guy (1):
iwlagn: led stay solid on when no traffic
Yogesh Ashok Powar (6):
mwifiex: remove unnecessary variable initialization
mwl8k: Fix broken WEP
mwl8k: Do not ask mac80211 to generate IV for crypto keys
mac80211: Fix mesh-related build breakage...
cfg80211: make stripping of 802.11 header optional from AMSDU
mwifiex: use ieee80211_amsdu_to_8023s routine
Documentation/ABI/testing/sysfs-bus-bcma | 31 +
MAINTAINERS | 7 +
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/bcma/Kconfig | 33 +
drivers/bcma/Makefile | 7 +
drivers/bcma/README | 19 +
drivers/bcma/TODO | 3 +
drivers/bcma/bcma_private.h | 28 +
drivers/bcma/core.c | 51 +
drivers/bcma/driver_chipcommon.c | 89 +
drivers/bcma/driver_chipcommon_pmu.c | 134 ++
drivers/bcma/driver_pci.c | 163 ++
drivers/bcma/host_pci.c | 196 ++
drivers/bcma/main.c | 247 +++
drivers/bcma/scan.c | 360 ++++
drivers/bcma/scan.h | 56 +
drivers/bluetooth/ath3k.c | 1 +
drivers/bluetooth/btusb.c | 1 +
drivers/net/wireless/ath/ath5k/base.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9002_mac.c | 10 -
drivers/net/wireless/ath/ath9k/ar9002_phy.c | 44 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 78 +-
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 11 -
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 46 +
drivers/net/wireless/ath/ath9k/ar9003_phy.h | 22 +
drivers/net/wireless/ath/ath9k/ath9k.h | 3 +-
drivers/net/wireless/ath/ath9k/beacon.c | 15 +-
drivers/net/wireless/ath/ath9k/calib.c | 21 +-
drivers/net/wireless/ath/ath9k/calib.h | 1 -
drivers/net/wireless/ath/ath9k/hw-ops.h | 16 +-
drivers/net/wireless/ath/ath9k/hw.c | 16 +
drivers/net/wireless/ath/ath9k/hw.h | 15 +-
drivers/net/wireless/ath/ath9k/mac.c | 9 +-
drivers/net/wireless/ath/ath9k/main.c | 47 +-
drivers/net/wireless/ath/ath9k/recv.c | 215 ++-
drivers/net/wireless/ath/ath9k/xmit.c | 11 +-
drivers/net/wireless/ath/carl9170/main.c | 2 +-
drivers/net/wireless/ath/carl9170/tx.c | 9 -
drivers/net/wireless/b43/main.c | 69 +-
drivers/net/wireless/b43/main.h | 1 +
drivers/net/wireless/b43/phy_n.c | 13 +-
drivers/net/wireless/b43legacy/main.c | 52 +-
drivers/net/wireless/iwlegacy/iwl-4965-rs.c | 2 +-
drivers/net/wireless/iwlwifi/Kconfig | 10 +
drivers/net/wireless/iwlwifi/Makefile | 1 +
drivers/net/wireless/iwlwifi/iwl-1000.c | 2 -
drivers/net/wireless/iwlwifi/iwl-2000.c | 2 -
drivers/net/wireless/iwlwifi/iwl-5000.c | 4 -
drivers/net/wireless/iwlwifi/iwl-6000.c | 4 -
drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c | 7 -
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 105 +-
drivers/net/wireless/iwlwifi/iwl-agn-ucode.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-agn.c | 143 +-
drivers/net/wireless/iwlwifi/iwl-agn.h | 22 +-
drivers/net/wireless/iwlwifi/iwl-core.h | 6 -
drivers/net/wireless/iwlwifi/iwl-dev.h | 34 +-
drivers/net/wireless/iwlwifi/iwl-led.c | 20 +-
drivers/net/wireless/iwlwifi/iwl-sv-open.c | 469 +++++
drivers/net/wireless/iwlwifi/iwl-testmode.h | 151 ++
drivers/net/wireless/iwlwifi/iwl-tx.c | 22 +-
drivers/net/wireless/iwmc3200wifi/rx.c | 3 +-
drivers/net/wireless/libertas/cfg.c | 16 +-
drivers/net/wireless/libertas/cmd.c | 40 +-
drivers/net/wireless/libertas/cmdresp.c | 27 +-
drivers/net/wireless/libertas/debugfs.c | 5 +-
drivers/net/wireless/libertas/defs.h | 7 -
drivers/net/wireless/libertas/if_cs.c | 57 +-
drivers/net/wireless/libertas/if_sdio.c | 37 +-
drivers/net/wireless/libertas/if_spi.c | 83 +-
drivers/net/wireless/libertas/if_usb.c | 44 +-
drivers/net/wireless/libertas/main.c | 72 +-
drivers/net/wireless/libertas/mesh.c | 8 +-
drivers/net/wireless/libertas/rx.c | 7 +-
drivers/net/wireless/mwifiex/11n.c | 7 +-
drivers/net/wireless/mwifiex/11n_aggr.c | 136 +--
drivers/net/wireless/mwifiex/11n_rxreorder.c | 15 +-
drivers/net/wireless/mwifiex/cfg80211.c | 48 +-
drivers/net/wireless/mwifiex/cmdevt.c | 51 +-
drivers/net/wireless/mwifiex/debugfs.c | 10 +-
drivers/net/wireless/mwifiex/fw.h | 21 +-
drivers/net/wireless/mwifiex/init.c | 59 +-
drivers/net/wireless/mwifiex/ioctl.h | 81 +-
drivers/net/wireless/mwifiex/join.c | 9 +-
drivers/net/wireless/mwifiex/main.c | 27 +-
drivers/net/wireless/mwifiex/main.h | 8 +-
drivers/net/wireless/mwifiex/scan.c | 30 +-
drivers/net/wireless/mwifiex/sdio.c | 35 +-
drivers/net/wireless/mwifiex/sta_cmd.c | 8 +-
drivers/net/wireless/mwifiex/sta_cmdresp.c | 28 +-
drivers/net/wireless/mwifiex/sta_ioctl.c | 80 +-
drivers/net/wireless/mwifiex/sta_rx.c | 26 +-
drivers/net/wireless/mwifiex/sta_tx.c | 4 +-
drivers/net/wireless/mwifiex/txrx.c | 10 +-
drivers/net/wireless/mwifiex/util.c | 29 +-
drivers/net/wireless/mwifiex/wmm.c | 2 +-
drivers/net/wireless/mwl8k.c | 18 +-
drivers/net/wireless/p54/p54pci.c | 3 +-
drivers/net/wireless/rt2x00/Kconfig | 11 +-
drivers/net/wireless/rt2x00/rt2800.h | 2 +
drivers/net/wireless/rt2x00/rt2800lib.c | 5 +-
drivers/net/wireless/rt2x00/rt2800usb.c | 8 +
drivers/net/wireless/rt2x00/rt2x00dev.c | 2 +-
drivers/net/wireless/rt2x00/rt2x00usb.c | 6 +-
drivers/net/wireless/rtlwifi/Kconfig | 15 +-
drivers/net/wireless/rtlwifi/Makefile | 1 +
drivers/net/wireless/rtlwifi/efuse.c | 35 +-
drivers/net/wireless/rtlwifi/pci.c | 1 +
drivers/net/wireless/rtlwifi/rtl8192cu/trx.c | 4 +-
drivers/net/wireless/rtlwifi/rtl8192se/Makefile | 15 +
drivers/net/wireless/rtlwifi/rtl8192se/def.h | 598 ++++++
drivers/net/wireless/rtlwifi/rtl8192se/dm.c | 733 +++++++
drivers/net/wireless/rtlwifi/rtl8192se/dm.h | 164 ++
drivers/net/wireless/rtlwifi/rtl8192se/fw.c | 654 ++++++
drivers/net/wireless/rtlwifi/rtl8192se/fw.h | 375 ++++
drivers/net/wireless/rtlwifi/rtl8192se/hw.c | 2512 +++++++++++++++++++++++
drivers/net/wireless/rtlwifi/rtl8192se/hw.h | 79 +
drivers/net/wireless/rtlwifi/rtl8192se/led.c | 149 ++
drivers/net/wireless/rtlwifi/rtl8192se/led.h | 37 +
drivers/net/wireless/rtlwifi/rtl8192se/phy.c | 1740 ++++++++++++++++
drivers/net/wireless/rtlwifi/rtl8192se/phy.h | 101 +
drivers/net/wireless/rtlwifi/rtl8192se/reg.h | 1188 +++++++++++
drivers/net/wireless/rtlwifi/rtl8192se/rf.c | 546 +++++
drivers/net/wireless/rtlwifi/rtl8192se/rf.h | 43 +
drivers/net/wireless/rtlwifi/rtl8192se/sw.c | 423 ++++
drivers/net/wireless/rtlwifi/rtl8192se/sw.h | 36 +
drivers/net/wireless/rtlwifi/rtl8192se/table.c | 634 ++++++
drivers/net/wireless/rtlwifi/rtl8192se/table.h | 49 +
drivers/net/wireless/rtlwifi/rtl8192se/trx.c | 976 +++++++++
drivers/net/wireless/rtlwifi/rtl8192se/trx.h | 45 +
drivers/net/wireless/wl12xx/acx.c | 190 ++-
drivers/net/wireless/wl12xx/acx.h | 103 +-
drivers/net/wireless/wl12xx/boot.c | 6 +-
drivers/net/wireless/wl12xx/cmd.c | 18 +-
drivers/net/wireless/wl12xx/conf.h | 111 +-
drivers/net/wireless/wl12xx/debugfs.c | 240 +++
drivers/net/wireless/wl12xx/event.c | 70 +-
drivers/net/wireless/wl12xx/event.h | 12 +-
drivers/net/wireless/wl12xx/init.c | 110 +-
drivers/net/wireless/wl12xx/init.h | 2 +
drivers/net/wireless/wl12xx/main.c | 492 ++++-
drivers/net/wireless/wl12xx/ps.c | 30 +-
drivers/net/wireless/wl12xx/ps.h | 2 +
drivers/net/wireless/wl12xx/rx.c | 36 +-
drivers/net/wireless/wl12xx/scan.c | 243 +++
drivers/net/wireless/wl12xx/scan.h | 114 +
drivers/net/wireless/wl12xx/sdio.c | 64 +-
drivers/net/wireless/wl12xx/tx.c | 13 +-
drivers/net/wireless/wl12xx/tx.h | 2 +-
drivers/net/wireless/wl12xx/wl12xx.h | 14 +-
drivers/ssb/driver_pcicore.c | 26 -
drivers/ssb/main.c | 31 +
drivers/ssb/scan.c | 5 +-
include/linux/bcma/bcma.h | 224 ++
include/linux/bcma/bcma_driver_chipcommon.h | 302 +++
include/linux/bcma/bcma_driver_pci.h | 89 +
include/linux/bcma/bcma_regs.h | 34 +
include/linux/ieee80211.h | 11 +-
include/linux/mod_devicetable.h | 17 +
include/linux/nl80211.h | 302 +++-
include/linux/ssb/ssb.h | 1 +
include/net/bluetooth/hci_core.h | 1 +
include/net/bluetooth/l2cap.h | 9 +-
include/net/cfg80211.h | 237 +++-
include/net/mac80211.h | 66 +
net/bluetooth/hci_conn.c | 17 +
net/bluetooth/hci_event.c | 5 +-
net/bluetooth/l2cap_core.c | 193 ++-
net/bluetooth/l2cap_sock.c | 72 +-
net/bluetooth/mgmt.c | 3 +
net/bluetooth/rfcomm/core.c | 2 +-
net/mac80211/agg-rx.c | 3 +-
net/mac80211/agg-tx.c | 59 +-
net/mac80211/cfg.c | 135 +-
net/mac80211/debugfs.c | 2 +-
net/mac80211/debugfs_key.c | 21 +-
net/mac80211/driver-ops.h | 56 +-
net/mac80211/driver-trace.h | 228 ++-
net/mac80211/ht.c | 27 +-
net/mac80211/ibss.c | 11 +-
net/mac80211/ieee80211_i.h | 41 +-
net/mac80211/iface.c | 3 +-
net/mac80211/key.c | 30 +-
net/mac80211/key.h | 4 +
net/mac80211/main.c | 37 +-
net/mac80211/mesh.c | 47 +-
net/mac80211/mesh.h | 6 +-
net/mac80211/mesh_hwmp.c | 38 +-
net/mac80211/mesh_pathtbl.c | 123 +-
net/mac80211/mesh_plink.c | 83 +-
net/mac80211/mlme.c | 22 +-
net/mac80211/pm.c | 13 +-
net/mac80211/rc80211_minstrel.c | 4 +-
net/mac80211/rc80211_minstrel_ht.c | 27 +-
net/mac80211/rx.c | 17 +-
net/mac80211/scan.c | 122 ++-
net/mac80211/sta_info.c | 19 +-
net/mac80211/sta_info.h | 50 +-
net/mac80211/tx.c | 10 +-
net/mac80211/util.c | 19 +
net/rfkill/core.c | 2 +-
net/wireless/core.c | 89 +-
net/wireless/core.h | 33 +
net/wireless/lib80211_crypt_wep.c | 3 +-
net/wireless/mlme.c | 10 +
net/wireless/nl80211.c | 670 ++++++-
net/wireless/nl80211.h | 4 +
net/wireless/reg.c | 2 -
net/wireless/scan.c | 77 +-
net/wireless/sysfs.c | 2 +-
net/wireless/util.c | 126 ++-
scripts/mod/file2alias.c | 22 +
213 files changed, 19165 insertions(+), 2154 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-bcma
create mode 100644 drivers/bcma/Kconfig
create mode 100644 drivers/bcma/Makefile
create mode 100644 drivers/bcma/README
create mode 100644 drivers/bcma/TODO
create mode 100644 drivers/bcma/bcma_private.h
create mode 100644 drivers/bcma/core.c
create mode 100644 drivers/bcma/driver_chipcommon.c
create mode 100644 drivers/bcma/driver_chipcommon_pmu.c
create mode 100644 drivers/bcma/driver_pci.c
create mode 100644 drivers/bcma/host_pci.c
create mode 100644 drivers/bcma/main.c
create mode 100644 drivers/bcma/scan.c
create mode 100644 drivers/bcma/scan.h
create mode 100644 drivers/net/wireless/iwlwifi/iwl-sv-open.c
create mode 100644 drivers/net/wireless/iwlwifi/iwl-testmode.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192se/Makefile
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192se/def.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192se/dm.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192se/dm.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192se/fw.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192se/fw.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192se/hw.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192se/hw.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192se/led.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192se/led.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192se/phy.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192se/phy.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192se/reg.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192se/rf.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192se/rf.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192se/sw.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192se/sw.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192se/table.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192se/table.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192se/trx.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192se/trx.h
create mode 100644 include/linux/bcma/bcma.h
create mode 100644 include/linux/bcma/bcma_driver_chipcommon.h
create mode 100644 include/linux/bcma/bcma_driver_pci.h
create mode 100644 include/linux/bcma/bcma_regs.h
Omnibus patch available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2011-05-16-v2.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: [PATCH] CDC NCM: release interfaces fix in unbind()
From: Alexey ORISHKO @ 2011-05-17 0:52 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
gregkh-l3A5Bk7waGM@public.gmane.org,
oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org
In-Reply-To: <20110516.151302.89070822321885499.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> The usb_set_intfdata() calls at cdc_ncm_bind() time are unconditional,
> and are performed regardless of whether ->data_claimed or
> ->control_claimed are set.
>
> So conditionalizing the setting of them to NULL here doesn't seem
> right at all.
>
> I'm not applying this patch.
Looks like I have to pay more attention to bind/unbind code as it was
copy-paste to some extent. Looking at cdc-acm and cdc_ether drivers,
there is no need to claim control (master) interface neither release it
in unbind().
Some confusion was added by other driver code that handles crippled
devices, which mix ctrl and data interfaces... Shall not be the case here.
I see, that some clean up can be done and "xxx_claimed" fields in context
structure can be removed, so will post a new version of patch shortly.
Regards,
Alexey
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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: [PATCHv1 (Repost)] bnx2x: Allow ethtool to enable/disable loopback.
From: David Miller @ 2011-05-17 1:42 UTC (permalink / raw)
To: maheshb; +Cc: eilong, netdev, therbert
In-Reply-To: <1305335329-32700-1-git-send-email-maheshb@google.com>
From: Mahesh Bandewar <maheshb@google.com>
Date: Fri, 13 May 2011 18:08:49 -0700
> This patch updates the bnx2x_set_features() to handle loopback mode.
> When enabled; it sets internal-MAC loopback.
>
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
I forgot to mention that I've applied this to net-next-2.6, thanks.
^ permalink raw reply
* linux-next: manual merge of the net tree with the net-current tree
From: Stephen Rothwell @ 2011-05-17 2:01 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Thomas Jarosch,
"Michał Mirosław"
[-- Attachment #1: Type: text/plain, Size: 493 bytes --]
Hi all,
Today's linux-next merge of the net tree got a conflict in
drivers/net/vmxnet3/vmxnet3_ethtool.c between commit ebde6f8acba9
("vmxnet3: Fix inconsistent LRO state after initialization") from the
net-current tree and commit a0d2730c9571 ("net: vmxnet3: convert to
hw_features") from the net tree.
I fixed it up (by removing the lines added by the net-current patch) and
can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* RE: [PATCH 1/2] linux-firmware: update firmware for RTL8111E
From: Ben Hutchings @ 2011-05-17 2:39 UTC (permalink / raw)
To: hayeswang; +Cc: 'Francois Romieu', 'David Woodhouse', netdev
In-Reply-To: <883AEB89D11D495A9666E2F73C2CD95F@realtek.com.tw>
[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]
On Tue, 2011-05-10 at 10:09 +0800, hayeswang wrote:
>
> Francois Romieu [mailto:romieu@fr.zoreil.com]
> > Sent: Tuesday, May 10, 2011 3:23 AM
> > To: David Woodhouse
> > Cc: Hayeswang; netdev@vger.kernel.org
> > Subject: Re: [PATCH 1/2] linux-firmware: update firmware for RTL8111E
> >
> > David Woodhouse <dwmw2@infradead.org> :
> > [...]
> > > I'd be a lot happier if the WHENCE file contained version numbers.
> > > Does the *driver* print a version string for the firmware
> > after loading it?
> >
> > No.
> >
> > Hayes, do we agree that the firmware needs to embed a version
> > identifier (and some checksum to identify the current
> > firmware that don't embed one).
> >
>
> I agree that. However, I have no idea about making it compatible with previous
> parser and firmware. Let me think if there is a good way to do this.
A PHY_DATA_AND at the beginning of a firmware blob instruction is a
no-op, so you could use that to add version information in a compatible
way. For RTL8168D, however, you are right that this would break
compatibility with the earlier driver versions that only handled
PHY_WRITE.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2011-05-16-v2
From: David Miller @ 2011-05-17 3:08 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110517000809.GA2119-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: Text/Plain; charset=iso-8859-7, Size: 1885 bytes --]
From: "John W. Linville" <linville@tuxdriver.com>
Date: Mon, 16 May 2011 20:08:09 -0400
> I'm sorry, Dave! In my defense, I am on the verge of sickness and got
> very little sleep last night... :-(
>
> I have corrected the problem and was sure to perform the correct build
> test this time! :-)
So these hunks made to net/bluetooth/l2cap_core.c:
@@ -3745,11 +3758,14 @@ done:
static inline int l2cap_conless_channel(struct l2cap_conn *conn, __le16 psm, struct sk_buff *skb)
{
struct sock *sk;
+ struct l2cap_chan *chan;
- sk = l2cap_get_sock_by_psm(0, psm, conn->src);
- if (!sk)
+ chan = l2cap_global_chan_by_psm(0, psm, conn->src);
+ if (!chan)
goto drop;
+ sk = chan->sk;
+
bh_lock_sock(sk);
BT_DBG("sk %p, len %d", sk, skb->len);
@@ -3745,11 +3758,14 @@ done:
static inline int l2cap_conless_channel(struct l2cap_conn *conn, __le16 psm, struct sk_buff *skb)
{
struct sock *sk;
+ struct l2cap_chan *chan;
- sk = l2cap_get_sock_by_psm(0, psm, conn->src);
- if (!sk)
+ chan = l2cap_global_chan_by_psm(0, psm, conn->src);
+ if (!chan)
goto drop;
+ sk = chan->sk;
+
bh_lock_sock(sk);
BT_DBG("sk %p, len %d", sk, skb->len);
Doesn't generate the following warnings on your compiler?
net/bluetooth/l2cap_core.c: In function ¡l2cap_recv_frame¢:
net/bluetooth/l2cap_core.c:3758:15: warning: ¡sk¢ may be used uninitialized in this function
net/bluetooth/l2cap_core.c:3758:15: note: ¡sk¢ was declared here
net/bluetooth/l2cap_core.c:3791:15: warning: ¡sk¢ may be used uninitialized in this function
net/bluetooth/l2cap_core.c:3791:15: note: ¡sk¢ was declared here
I'll fix these up with the obvious fixes, but please be more careful
in the future.
Thanks.
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±Â*Þ•ë,Š{ayº\x1dʇڙë,j\a¢f£¢·hš‹»öì\x17/oSc¾™Ú³9˜uÀ¦æå‰È&jw¨®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿïêäz¹Þ–Šàþf£¢·hšˆ§~ˆmš
^ permalink raw reply
* Re: [PATCH V5 4/6 net-next] vhost: vhost TX zero-copy support
From: Shirley Ma @ 2011-05-17 4:31 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: David Miller, Eric Dumazet, Avi Kivity, Arnd Bergmann, netdev,
kvm, linux-kernel
In-Reply-To: <20110516212401.GF18148@redhat.com>
On Tue, 2011-05-17 at 00:24 +0300, Michael S. Tsirkin wrote:
> On Mon, May 16, 2011 at 01:56:54PM -0700, Shirley Ma wrote:
> > On Mon, 2011-05-16 at 23:45 +0300, Michael S. Tsirkin wrote:
> > > > +/* Since we need to keep the order of used_idx as avail_idx,
> it's
> > > possible that
> > > > + * DMA done not in order in lower device driver for some
> reason. To
> > > prevent
> > > > + * used_idx out of order, upend_idx is used to track avail_idx
> > > order, done_idx
> > > > + * is used to track used_idx order. Once lower device DMA done,
> > > then upend_idx
> > > > + * can move to done_idx.
> > >
> > > Could you clarify this please? virtio explicitly allows out of
> order
> > > completion of requests. Does it simplify code that we try to keep
> > > used index updates in-order? Because if not, this is not
> > > really a requirement.
> >
> > Hello Mike,
> >
> > Based on my testing, vhost_add_used() must be in order from
> > vhost_get_vq_desc(). Otherwise, virtio_net ring seems get double
> > freed.
>
> Double-freed or you get NULL below?
More likely is NULL.
> > I didn't spend time on debugging this.
> >
> > in virtqueue_get_buf
> >
> > if (unlikely(!vq->data[i])) {
> > BAD_RING(vq, "id %u is not a head!\n", i);
> > return NULL;
> > }
>
> Yes but i used here is the head that we read from the
> ring, not the ring index itself.
> i = vq->vring.used->ring[vq->last_used_idx%vq->vring.num].id
> we must complete any id only once, but in any order.
It is in any order of ring id, but must be in the order of "head"
returns from vhost_get_vq_desc(), any clue?
Thanks
Shirley
^ permalink raw reply
* Re: [PATCH] 2.6.38 ENC28J60 works with half-duplex DMA
From: Davide Rizzo @ 2011-05-17 5:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110516.114855.1523183530208158354.davem@davemloft.net>
I'm sorry for that, initially It was refused by your system for format
problems (html?), then I didn't see them in the archives, so I though
some problem happened and resent it. I didn't receive it back from the
list.
Where can I see a message list to have a confirmation that it was received ?
2011/5/16 David Miller <davem@davemloft.net>:
>
> You've sent this patch 3 times, we've noticed and seen them all,
> our silence doesn't mean it hasn't been received.
>
> What new thing do you hope to accomplish on each subsequent
> submission?
>
--
All difficult problems have a simple solution. That is wrong. [A. Einstein]
^ 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