<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/net, branch v2.6.32.22</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>SUNRPC: Fix race corrupting rpc upcall</title>
<updated>2010-09-20T20:18:14+00:00</updated>
<author>
<name>Trond Myklebust</name>
<email>Trond.Myklebust@netapp.com</email>
</author>
<published>2010-09-12T23:55:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f7f040a6b088a9380a640b181687f7c79fface7b'/>
<id>f7f040a6b088a9380a640b181687f7c79fface7b</id>
<content type='text'>
commit 5a67657a2e90c9e4a48518f95d4ba7777aa20fbb upstream.

If rpc_queue_upcall() adds a new upcall to the rpci-&gt;pipe list just
after rpc_pipe_release calls rpc_purge_list(), but before it calls
gss_pipe_release (as rpci-&gt;ops-&gt;release_pipe(inode)), then the latter
will free a message without deleting it from the rpci-&gt;pipe list.

We will be left with a freed object on the rpc-&gt;pipe list.  Most
frequent symptoms are kernel crashes in rpc.gssd system calls on the
pipe in question.

Reported-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5a67657a2e90c9e4a48518f95d4ba7777aa20fbb upstream.

If rpc_queue_upcall() adds a new upcall to the rpci-&gt;pipe list just
after rpc_pipe_release calls rpc_purge_list(), but before it calls
gss_pipe_release (as rpci-&gt;ops-&gt;release_pipe(inode)), then the latter
will free a message without deleting it from the rpci-&gt;pipe list.

We will be left with a freed object on the rpc-&gt;pipe list.  Most
frequent symptoms are kernel crashes in rpc.gssd system calls on the
pipe in question.

Reported-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>wireless extensions: fix kernel heap content leak</title>
<updated>2010-09-20T20:17:56+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2010-08-30T10:24:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=444ba62c397038dc01eef78f9b754b6b8c2fd0a4'/>
<id>444ba62c397038dc01eef78f9b754b6b8c2fd0a4</id>
<content type='text'>
commit 42da2f948d949efd0111309f5827bf0298bcc9a4 upstream.

Wireless extensions have an unfortunate, undocumented
requirement which requires drivers to always fill
iwp-&gt;length when returning a successful status. When
a driver doesn't do this, it leads to a kernel heap
content leak when userspace offers a larger buffer
than would have been necessary.

Arguably, this is a driver bug, as it should, if it
returns 0, fill iwp-&gt;length, even if it separately
indicated that the buffer contents was not valid.

However, we can also at least avoid the memory content
leak if the driver doesn't do this by setting the iwp
length to max_tokens, which then reflects how big the
buffer is that the driver may fill, regardless of how
big the userspace buffer is.

To illustrate the point, this patch also fixes a
corresponding cfg80211 bug (since this requirement
isn't documented nor was ever pointed out by anyone
during code review, I don't trust all drivers nor
all cfg80211 handlers to implement it correctly).

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 42da2f948d949efd0111309f5827bf0298bcc9a4 upstream.

Wireless extensions have an unfortunate, undocumented
requirement which requires drivers to always fill
iwp-&gt;length when returning a successful status. When
a driver doesn't do this, it leads to a kernel heap
content leak when userspace offers a larger buffer
than would have been necessary.

Arguably, this is a driver bug, as it should, if it
returns 0, fill iwp-&gt;length, even if it separately
indicated that the buffer contents was not valid.

However, we can also at least avoid the memory content
leak if the driver doesn't do this by setting the iwp
length to max_tokens, which then reflects how big the
buffer is that the driver may fill, regardless of how
big the userspace buffer is.

To illustrate the point, this patch also fixes a
corresponding cfg80211 bug (since this requirement
isn't documented nor was ever pointed out by anyone
during code review, I don't trust all drivers nor
all cfg80211 handlers to implement it correctly).

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>irda: off by one</title>
<updated>2010-09-20T20:17:52+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>error27@gmail.com</email>
</author>
<published>2010-09-04T03:14:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f4ee150ede7f8ff1a1d8992579c2e1a7e2520815'/>
<id>f4ee150ede7f8ff1a1d8992579c2e1a7e2520815</id>
<content type='text'>
commit cf9b94f88bdbe8a02015fc30d7c232b2d262d4ad upstream.

This is an off by one.  We would go past the end when we NUL terminate
the "value" string at end of the function.  The "value" buffer is
allocated in irlan_client_parse_response() or
irlan_provider_parse_command().

CC: stable@kernel.org
Signed-off-by: Dan Carpenter &lt;error27@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit cf9b94f88bdbe8a02015fc30d7c232b2d262d4ad upstream.

This is an off by one.  We would go past the end when we NUL terminate
the "value" string at end of the function.  The "value" buffer is
allocated in irlan_client_parse_response() or
irlan_provider_parse_command().

CC: stable@kernel.org
Signed-off-by: Dan Carpenter &lt;error27@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>netlink: fix compat recvmsg</title>
<updated>2010-08-26T23:41:55+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2010-08-15T21:20:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=521f4161abe50f2a1d43d6f0f942ea0d316809bb'/>
<id>521f4161abe50f2a1d43d6f0f942ea0d316809bb</id>
<content type='text'>
commit 68d6ac6d2740b6a55f3ae92a4e0be6d881904b32 upstream.

Since
commit 1dacc76d0014a034b8aca14237c127d7c19d7726
Author: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Date:   Wed Jul 1 11:26:02 2009 +0000

    net/compat/wext: send different messages to compat tasks

we had a race condition when setting and then
restoring frag_list. Eric attempted to fix it,
but the fix created even worse problems.

However, the original motivation I had when I
added the code that turned out to be racy is
no longer clear to me, since we only copy up
to skb-&gt;len to userspace, which doesn't include
the frag_list length. As a result, not doing
any frag_list clearing and restoring avoids
the race condition, while not introducing any
other problems.

Additionally, while preparing this patch I found
that since none of the remaining netlink code is
really aware of the frag_list, we need to use the
original skb's information for packet information
and credentials. This fixes, for example, the
group information received by compat tasks.

Cc: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Acked-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 68d6ac6d2740b6a55f3ae92a4e0be6d881904b32 upstream.

Since
commit 1dacc76d0014a034b8aca14237c127d7c19d7726
Author: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Date:   Wed Jul 1 11:26:02 2009 +0000

    net/compat/wext: send different messages to compat tasks

we had a race condition when setting and then
restoring frag_list. Eric attempted to fix it,
but the fix created even worse problems.

However, the original motivation I had when I
added the code that turned out to be racy is
no longer clear to me, since we only copy up
to skb-&gt;len to userspace, which doesn't include
the frag_list length. As a result, not doing
any frag_list clearing and restoring avoids
the race condition, while not introducing any
other problems.

Additionally, while preparing this patch I found
that since none of the remaining netlink code is
really aware of the frag_list, we need to use the
original skb's information for packet information
and credentials. This fixes, for example, the
group information received by compat tasks.

Cc: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Acked-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>act_nat: the checksum of ICMP doesn't have pseudo header</title>
<updated>2010-08-26T23:41:52+00:00</updated>
<author>
<name>Changli Gao</name>
<email>xiaosuo@gmail.com</email>
</author>
<published>2010-07-29T14:04:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=65412a7bcdc5b0ff3b5a9ced6747e834276d0605'/>
<id>65412a7bcdc5b0ff3b5a9ced6747e834276d0605</id>
<content type='text'>
[ Upstream commit 3a3dfb062c2e086c202d34f09ce29634515ad256 ]

after updating the value of the ICMP payload, inet_proto_csum_replace4() should
be called with zero pseudohdr.

Signed-off-by: Changli Gao &lt;xiaosuo@gmail.com&gt;
Acked-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 3a3dfb062c2e086c202d34f09ce29634515ad256 ]

after updating the value of the ICMP payload, inet_proto_csum_replace4() should
be called with zero pseudohdr.

Signed-off-by: Changli Gao &lt;xiaosuo@gmail.com&gt;
Acked-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>can: add limit for nframes and clean up signed/unsigned variables</title>
<updated>2010-08-26T23:41:51+00:00</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2010-08-11T23:12:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c99204b3a44cdd29cffa5193b5bc462d4deadc7e'/>
<id>c99204b3a44cdd29cffa5193b5bc462d4deadc7e</id>
<content type='text'>
[ Upstream commit 5b75c4973ce779520b9d1e392483207d6f842cde ]

This patch adds a limit for nframes as the number of frames in TX_SETUP and
RX_SETUP are derived from a single byte multiplex value by default.
Use-cases that would require to send/filter more than 256 CAN frames should
be implemented in userspace for complexity reasons anyway.

Additionally the assignments of unsigned values from userspace to signed
values in kernelspace and vice versa are fixed by using unsigned values in
kernelspace consistently.

Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Reported-by: Ben Hawkes &lt;hawkes@google.com&gt;
Acked-by: Urs Thuermann &lt;urs.thuermann@volkswagen.de&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 5b75c4973ce779520b9d1e392483207d6f842cde ]

This patch adds a limit for nframes as the number of frames in TX_SETUP and
RX_SETUP are derived from a single byte multiplex value by default.
Use-cases that would require to send/filter more than 256 CAN frames should
be implemented in userspace for complexity reasons anyway.

Additionally the assignments of unsigned values from userspace to signed
values in kernelspace and vice versa are fixed by using unsigned values in
kernelspace consistently.

Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Reported-by: Ben Hawkes &lt;hawkes@google.com&gt;
Acked-by: Urs Thuermann &lt;urs.thuermann@volkswagen.de&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: Fix a memmove bug in dev_gro_receive()</title>
<updated>2010-08-26T23:41:50+00:00</updated>
<author>
<name>Jarek Poplawski</name>
<email>jarkao2@gmail.com</email>
</author>
<published>2010-08-11T02:02:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=28917a028093cb576b65bcce852b2d9477c2eb7c'/>
<id>28917a028093cb576b65bcce852b2d9477c2eb7c</id>
<content type='text'>
[ Upstream commit e5093aec2e6b60c3df2420057ffab9ed4a6d2792 ]

&gt;Xin Xiaohui wrote:
&gt; I looked into the code dev_gro_receive(), found the code here:
&gt; if the frags[0] is pulled to 0, then the page will be released,
&gt; and memmove() frags left.
&gt; Is that right? I'm not sure if memmove do right or not, but
&gt; frags[0].size is never set after memove at least. what I think
&gt; a simple way is not to do anything if we found frags[0].size == 0.
&gt; The patch is as followed.
...

This version of the patch fixes the bug directly in memmove.

Reported-by: "Xin, Xiaohui" &lt;xiaohui.xin@intel.com&gt;
Signed-off-by: Jarek Poplawski &lt;jarkao2@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit e5093aec2e6b60c3df2420057ffab9ed4a6d2792 ]

&gt;Xin Xiaohui wrote:
&gt; I looked into the code dev_gro_receive(), found the code here:
&gt; if the frags[0] is pulled to 0, then the page will be released,
&gt; and memmove() frags left.
&gt; Is that right? I'm not sure if memmove do right or not, but
&gt; frags[0].size is never set after memove at least. what I think
&gt; a simple way is not to do anything if we found frags[0].size == 0.
&gt; The patch is as followed.
...

This version of the patch fixes the bug directly in memmove.

Reported-by: "Xin, Xiaohui" &lt;xiaohui.xin@intel.com&gt;
Signed-off-by: Jarek Poplawski &lt;jarkao2@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arp_notify: allow drivers to explicitly request a notification event.</title>
<updated>2010-08-13T20:19:49+00:00</updated>
<author>
<name>Ian Campbell</name>
<email>Ian.Campbell@citrix.com</email>
</author>
<published>2010-05-26T00:09:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ac33b999caed81edf848948cde358920dff3f31f'/>
<id>ac33b999caed81edf848948cde358920dff3f31f</id>
<content type='text'>
commit 06c4648d46d1b757d6b9591a86810be79818b60c upstream.

Currently such notifications are only generated when the device comes up or the
address changes. However one use case for these notifications is to enable
faster network recovery after a virtual machine migration (by causing switches
to relearn their MAC tables). A migration appears to the network stack as a
temporary loss of carrier and therefore does not trigger either of the current
conditions. Rather than adding carrier up as a trigger (which can cause issues
when interfaces a flapping) simply add an interface which the driver can use
to explicitly trigger the notification.

Signed-off-by: Ian Campbell &lt;ian.campbell@citrix.com&gt;
Cc: Stephen Hemminger &lt;shemminger@linux-foundation.org&gt;
Cc: Jeremy Fitzhardinge &lt;jeremy@goop.org&gt;
Cc: David S. Miller &lt;davem@davemloft.net&gt;
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 06c4648d46d1b757d6b9591a86810be79818b60c upstream.

Currently such notifications are only generated when the device comes up or the
address changes. However one use case for these notifications is to enable
faster network recovery after a virtual machine migration (by causing switches
to relearn their MAC tables). A migration appears to the network stack as a
temporary loss of carrier and therefore does not trigger either of the current
conditions. Rather than adding carrier up as a trigger (which can cause issues
when interfaces a flapping) simply add an interface which the driver can use
to explicitly trigger the notification.

Signed-off-by: Ian Campbell &lt;ian.campbell@citrix.com&gt;
Cc: Stephen Hemminger &lt;shemminger@linux-foundation.org&gt;
Cc: Jeremy Fitzhardinge &lt;jeremy@goop.org&gt;
Cc: David S. Miller &lt;davem@davemloft.net&gt;
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: don't get expired BSSes</title>
<updated>2010-08-10T17:20:43+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2010-07-13T08:55:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=001632030b5d98ac56c65416a884a90a33a40097'/>
<id>001632030b5d98ac56c65416a884a90a33a40097</id>
<content type='text'>
commit ccb6c1360f8dd43303c659db718e7e0b24175db5 upstream.

When kernel-internal users use cfg80211_get_bss()
to get a reference to a BSS struct, they may end
up getting one that would have been removed from
the list if there had been any userspace access
to the list. This leads to inconsistencies and
problems.

Fix it by making cfg80211_get_bss() ignore BSSes
that cfg80211_bss_expire() would remove.

Fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2180

Reported-by: Jiajia Zheng &lt;jiajia.zheng@intel.com&gt;
Tested-by: Jiajia Zheng &lt;jiajia.zheng@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ccb6c1360f8dd43303c659db718e7e0b24175db5 upstream.

When kernel-internal users use cfg80211_get_bss()
to get a reference to a BSS struct, they may end
up getting one that would have been removed from
the list if there had been any userspace access
to the list. This leads to inconsistencies and
problems.

Fix it by making cfg80211_get_bss() ignore BSSes
that cfg80211_bss_expire() would remove.

Fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2180

Reported-by: Jiajia Zheng &lt;jiajia.zheng@intel.com&gt;
Tested-by: Jiajia Zheng &lt;jiajia.zheng@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: ignore spurious deauth</title>
<updated>2010-08-10T17:20:42+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2010-07-12T12:46:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=e876eab4b7f0f5afd1e2a33272c52e8687081fd8'/>
<id>e876eab4b7f0f5afd1e2a33272c52e8687081fd8</id>
<content type='text'>
commit 643f82e32f14faf0d0944c804203a6681b6b0a1e upstream.

Ever since mac80211/drivers are no longer
fully in charge of keeping track of the
auth status, trying to make them do so will
fail. Instead of warning and reporting the
deauthentication to userspace, cfg80211 must
simply ignore it so that spurious
deauthentications, e.g. before starting
authentication, aren't seen by userspace as
actual deauthentications.

Reported-by: Paul Stewart &lt;pstew@google.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 643f82e32f14faf0d0944c804203a6681b6b0a1e upstream.

Ever since mac80211/drivers are no longer
fully in charge of keeping track of the
auth status, trying to make them do so will
fail. Instead of warning and reporting the
deauthentication to userspace, cfg80211 must
simply ignore it so that spurious
deauthentications, e.g. before starting
authentication, aren't seen by userspace as
actual deauthentications.

Reported-by: Paul Stewart &lt;pstew@google.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
</feed>
