* [PATCH net-next v1 2/2] amd-xgbe: Check for complete packet on skb allocation error
From: Tom Lendacky @ 2014-11-06 23:02 UTC (permalink / raw)
To: netdev; +Cc: davem
In-Reply-To: <20141106230207.21973.67338.stgit@tlendack-t1.amdoffice.net>
If the skb allocation fails during receive processing, the driver would
continue reading descriptors without first determining if there were
any more descriptors for the current packet. Update the code to check
whether more descriptors are associated with the current packet or
whether to move on to the next descriptor as a new packet.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
index ec5fff3..0544931 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
@@ -1908,7 +1908,7 @@ read_again:
skb = xgbe_create_skb(pdata, rdata, &put_len);
if (!skb) {
error = 1;
- goto read_again;
+ goto skip_data;
}
}
@@ -1926,10 +1926,10 @@ read_again:
}
}
+skip_data:
if (incomplete || context_next)
goto read_again;
- /* Stray Context Descriptor? */
if (!skb)
goto next_packet;
^ permalink raw reply related
* [PATCH net-next v1 0/2] amd-xgbe: AMD XGBE driver updates 2014-11-06
From: Tom Lendacky @ 2014-11-06 23:02 UTC (permalink / raw)
To: netdev; +Cc: davem
The following series of patches fixes a couple of bugs that slipped
through my last series.
- Free channel structure after freeing the per channel interrupts
- If an skb error allocation occurs during receive processing check
whether more descriptors are associated with the packet or whether
to start on a new packet
This patch series is based on net-next.
---
Tom Lendacky (2):
amd-xgbe: Free channel/ring structures later
amd-xgbe: Check for complete packet on skb allocation error
drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--
Tom Lendacky
^ permalink raw reply
* Re: [PATCH] rtlwifi: Add more checks for get_btc_status callback
From: Murilo Opsfelder Araujo @ 2014-11-06 22:52 UTC (permalink / raw)
To: Larry Finger, Mike Galbraith
Cc: linux-kernel, linux-wireless, netdev, Chaoming Li,
John W. Linville, Thadeu Cascardo, troy_tan
In-Reply-To: <545B5E19.7030704@gmail.com>
On 11/06/2014 09:40 AM, Murilo Opsfelder Araujo wrote:
> On 11/05/2014 04:12 PM, Larry Finger wrote:
>> On 11/05/2014 03:16 AM, Mike Galbraith wrote:
>>> On Wed, 2014-10-29 at 23:30 -0500, Larry Finger wrote:
>>>> On 10/29/2014 06:28 PM, Murilo Opsfelder Araujo wrote:
>>>>> This is a complement of commit 08054200117a95afc14c3d2ed3a38bf4e345bf78
>>>>> "rtlwifi: Add check for get_btc_status callback".
>>>>>
>>>>> With this patch, next-20141029 at least does not panic with rtl8192se
>>>>> device.
>>>>>
>>>>
>>>> This patch is OK, but as noted it is not complete.
>>>>
>>>> I have patches to fix all the kernel panics for rtl8192se AND
>>>> rtl8192ce. There
>>>> are missing parts, but I would prefer submitting mine, which would
>>>> conflict with
>>>> this one. For that reason, NACK for this one, and please apply the
>>>> set I am
>>>> submitting now.
>>>
>>> It's all in there now, but my RTL8191SEvB is still dead. Squabbling
>>> with it isn't going all that well either.
>>>
>>> As soon as 38506ece rtlwifi: rtl_pci: Start modification for new drivers
>>> is applied, explosions appear. Subsequently applying...
>>>
>>> 08054200 rtlwifi: Add check for get_btc_status callback
>>> c0386f15 rtlwifi: rtl8192ce: rtl8192de: rtl8192se: Fix handling for
>>> missing get_btc_status
>>> 50147969 rtlwifi: rtl8192se: Fix duplicate calls to
>>> ieee80211_register_hw()
>>> 30c5ccc6 rtlwifi: rtl8192se: Add missing section to read descriptor
>>> setting
>>> 75a916e1 rtlwifi: rtl8192se: Fix firmware loading
>>>
>>> ...fixes that mess up, but leaves the interface dead in the same manner
>>> as if nothing has been reverted. So it _seems_ the bustage lurks in
>>> 38506ece somewhere. Too bad it's non-dinky, and written in wifi-ese :)
>>
>> Yes, I am aware that rtl8192se is failing, and now that I am back from
>> vacation, I am working on the problem. If you want to use the driver
>> with kernel 3.18, clone the repo at
>> http://github.com/lwfinger/rtlwifi_new.git and build and install either
>> the master or kernel_version branches. Both work.
>>
>> I am in the process of trying to find what the crucial difference is
>> between that repo and the kernel version.
>>
>> Larry
>>
>>
> I'm sending to everyone so others can jump in as well.
>
> Here are the steps I've followed.
>
> Installed and booted my kernel:
>
> $ sudo dpkg -i linux-image-3.18.0-rc3-next-20141105-panda_3.18.0-rc3-next-20141105-panda-1_amd64.deb linux-headers-3.18.0-rc3-next-20141105-panda_3.18.0-rc3-next-20141105-panda-1_amd64.deb
>
> Built modules from Larry's github repository.
>
> $ cd rtlwifi_new
> $ make
> $ sudo make install
>
> $ sudo modprobe -rv rtl8192se
> rmmod rtl8192se
> rmmod rtl_pci
> rmmod rtlwifi
> rmmod mac80211
> rmmod cfg80211
>
> The module does not load:
>
> $ sudo modprobe -v rtl8192se
> insmod /lib/modules/3.18.0-rc3-next-20141105-panda/kernel/net/wireless/cfg80211.ko
> insmod /lib/modules/3.18.0-rc3-next-20141105-panda/kernel/net/mac80211/mac80211.ko
> insmod /lib/modules/3.18.0-rc3-next-20141105-panda/kernel/drivers/net/wireless/rtlwifi/rtlwifi.ko
> insmod /lib/modules/3.18.0-rc3-next-20141105-panda/kernel/drivers/net/wireless/rtlwifi/rtl_pci.ko
> insmod /lib/modules/3.18.0-rc3-next-20141105-panda/extra/rtl8192se.ko
> ERROR: could not insert 'rtl8192se': Invalid argument
>
> And /var/log/messages showed:
>
> Nov 5 22:28:01 laptop kernel: [ 301.276806] rtl8192se: disagrees about version of symbol rtl_process_phyinfo
> Nov 5 22:28:01 laptop kernel: [ 301.276812] rtl8192se: Unknown symbol rtl_process_phyinfo (err -22)
> Nov 5 22:28:01 laptop kernel: [ 301.276864] rtl8192se: disagrees about version of symbol rtl_get_tcb_desc
> Nov 5 22:28:01 laptop kernel: [ 301.276866] rtl8192se: Unknown symbol rtl_get_tcb_desc (err -22)
>
Here is what I did in order to get the rtl8192se from Larry's repo to
work:
$ cd rtlwifi_new
$ make
$ sudo modprobe -rv rtl8192se
rmmod rtl8192se
rmmod rtl_pci
rmmod rtlwifi
rmmod mac80211
rmmod cfg80211
$ sudo modprobe -v cfg80211
insmod /lib/modules/3.18.0-rc3-next-20141106-panda/kernel/net/wireless/cfg80211.ko
$ sudo modprobe -v mac80211
insmod /lib/modules/3.18.0-rc3-next-20141106-panda/kernel/net/mac80211/mac80211.ko
$ sudo insmod ./rtlwifi.ko
$ sudo insmod ./rtl_pci.ko
$ sudo insmod ./rtl8192se/rtl8192se.ko
Cascardo helped me to investigate this and the issue was that modprobe
was loading the core rtl drivers from the next-20141105 and the
rtl8192se from Larry's repo. Thus, rtl8192se didn't have all its
required symbols at loading time.
Loading the drivers in reverse order using insmod did the trick.
Larry, your rtl8192se from rtlwifi_new repository is working pretty
fine on my hardware. I'm looking forward to see that code landing
linux 3.18.
Thanks everyone for the help and support. At least now, I have a
workaround.
Apreciated!
--
Murilo
^ permalink raw reply
* Re: [PATCH 3/3 3.18] rtlwifi: rtl8192se: Fix connection problems
From: Larry Finger @ 2014-11-06 22:46 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, netdev
In-Reply-To: <20141106204549.GD4440@tuxdriver.com>
On 11/06/2014 02:45 PM, John W. Linville wrote:
> On Wed, Nov 05, 2014 at 07:10:54PM -0600, Larry Finger wrote:
>> Changes in the vendor driver were added to rtlwifi, but some updates
>> to rtl8192se were missed.
>>
>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>> ---
>> drivers/net/wireless/rtlwifi/rtl8192se/hw.c | 129 +++++++++++++--------------
>> drivers/net/wireless/rtlwifi/rtl8192se/phy.c | 8 +-
>> drivers/net/wireless/rtlwifi/rtl8192se/sw.c | 4 +
>> drivers/net/wireless/rtlwifi/rtl8192se/trx.c | 23 +++++
>> drivers/net/wireless/rtlwifi/rtl8192se/trx.h | 4 +
>> 5 files changed, 100 insertions(+), 68 deletions(-)
>
> This looks a bit big for a fix. Could this be broken-up a bit more?
> Perhaps you could enhance the changelog a bit more?
I had used a scatter-gun approach to finding the missing parts, and I did not
take the time to see which changes were crucial, and which were not.
Now that I knew what it took, I was able to eliminate a lot of the patch that
can be deferred for 3.19.
The commit message and the changelog for the new version are
Changes in the vendor driver were added to rtlwifi, but some updates
to rtl8192se were missed, and the driver could neither scan nor connect.
There are other changes that will enhance performance, but this minimal
set fixes the basic functionality.
drivers/net/wireless/rtlwifi/pci.c | 3 ++-
drivers/net/wireless/rtlwifi/rtl8192se/hw.c | 7 +++++--
drivers/net/wireless/rtlwifi/rtl8192se/phy.c | 2 ++
drivers/net/wireless/rtlwifi/rtl8192se/sw.c | 16 ++++++++++++++++
4 files changed, 25 insertions(+), 3 deletions(-)
Will that be OK? I need to do more testing, but V2 of the patch should be ready
for submission by tomorrow.
Thanks,
Larry
^ permalink raw reply
* Re: ipv4: Use standard iovec primitive in raw_probe_proto_opt
From: Al Viro @ 2014-11-06 22:16 UTC (permalink / raw)
To: Jon Maloy
Cc: Herbert Xu, David Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, bcrl@kvack.org, Masahide Nakamura,
Hideaki YOSHIFUJI
In-Reply-To: <A2BAEFC30C8FD34388F02C9B3121859D1C3087CA@eusaamb103.ericsson.se>
On Thu, Nov 06, 2014 at 09:55:31AM +0000, Jon Maloy wrote:
> > Point, but that might very well be a pattern to watch for - there's at least one
> > more instance in TIPC (also not exploitable, according to TIPC folks) and such
>
> I don't recall this, and I can't see where it would be either. Can you please
> point to where it is?
The same dest_name_check() thing. This
if (copy_from_user(&hdr, m->msg_iov[0].iov_base, sizeof(hdr)))
return -EFAULT;
if ((ntohs(hdr.tcm_type) & 0xC000) && (!capable(CAP_NET_ADMIN)))
return -EACCES;
is easily bypassed. Suppose you want to send a packet with these two
bits in ->tcm_type not being 00, and you don't have CAP_NET_ADMIN.
Not a problem - spawn two threads sharing memory, have one trying to
call sendmsg() while another keeps flipping these two bits. Sooner
of later you'll get the timing right and have these bits observed as 00
in dest_name_check() and 11 when it comes to memcpy_fromiovecend() actually
copying the whole thing. And considering that the interval between those
two is much longer than the loop in the second thread would take on
each iteration, I'd expect the odds around 25% per attempted sendmsg().
IOW, this test is either pointless and can be removed completely, or there's
an exploitable race. As far as I understand from your replies both back then
and in another branch of this thread, it's the former and the proper fix is
to remove at least that part of dest_name_check(). So this case is also
not something exploitable, but it certainly matches the same pattern.
My point was simply that this pattern is worth watching for - recurrent bug
classes like that have a good chance to spawn an instance that will be
exploitable.
^ permalink raw reply
* Re: [PATCH net-next] net: gro: add a per device gro flush timer
From: Eric Dumazet @ 2014-11-06 22:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev, ogerlitz, willemb
In-Reply-To: <20141106.162516.1083429539800319166.davem@davemloft.net>
On Thu, 2014-11-06 at 16:25 -0500, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 05 Nov 2014 16:55:20 -0800
>
> > @@ -4430,8 +4432,19 @@ void napi_complete(struct napi_struct *n)
> > if (unlikely(test_bit(NAPI_STATE_NPSVC, &n->state)))
> > return;
> >
> > - napi_gro_flush(n, false);
> > + if (n->gro_list) {
> > + unsigned long timeout = 0;
> > +
> > + if (n->napi_rx_count)
> > + timeout = n->dev->gro_flush_timeout;
>
> Under what circumstances would we see n->gro_list non-NULL yet
> n->napi_rx_count == 0?
>
> I'm not so sure it can happen.
>
> Said another way, it looks to me like you could implement this
> using less state.
My goal was to not change any driver, doing a generic change.
Drivers call napi_complete() in their rx napi handler without giving us
the 'work_done' value which tells us if a packet was processed.
So I added a counter that is increased for every packet given to GRO
engine (napi_rx_count), so that napi_complete() has a clue if a packet
was received in _this_ NAPI run.
If at least one packet was received (and we still have packets in
gro_list) -> We ream the 'timer'
If not, we flush packets in GRO engine.
In order to avoid this state, I would have to add a new method, like
napi_complete_done(napi, work_done), and change drivers. I am not sure
its worth the effort ?
^ permalink raw reply
* Re: [PATCHv2 net-next 0/3] RDMA/cxgb4,cxgb4vf,cxgb4i,csiostor: Cleanup macros
From: David Miller @ 2014-11-06 21:57 UTC (permalink / raw)
To: hariprasad-ut6Up61K2wZBDgjK7y7TUQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA, roland-BHEL68pLQRGGvPXPguhicg,
JBottomley-bzQdu9zFT3WakBO8gow8eQ, hch-wEGCiKHe2LqWVfeAwA7xHQ,
swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW,
leedom-ut6Up61K2wZBDgjK7y7TUQ, praveenm-ut6Up61K2wZBDgjK7y7TUQ,
anish-ut6Up61K2wZBDgjK7y7TUQ, nirranjan-ut6Up61K2wZBDgjK7y7TUQ,
kumaras-ut6Up61K2wZBDgjK7y7TUQ
In-Reply-To: <20141106161444.GA8954@hariprasad-pc>
From: Hariprasad S <hariprasad@chelsio.com>
Date: Thu, 6 Nov 2014 21:45:10 +0530
> On Wed, Nov 05, 2014 at 14:54:43 -0500, David Miller wrote:
>> From: Hariprasad Shenai <hariprasad@chelsio.com>
>> Date: Tue, 4 Nov 2014 08:20:54 +0530
>>
>> > It's not really the "hardware" which generates these hardware constant symbolic
>> > macros/register defines of course, it's scripts developed by the hardware team.
>> > Various patches have ended up changing the style of the symbolic macros/register
>> > defines and some of them used the macros/register defines that matches the
>> > output of the script from the hardware team.
>>
>> We've told you that we don't care what format your internal whatever uses
>> for these macros.
>>
>> We have standards, tastes, and desires and reasons for naming macros
>> in a certain way in upstream kernel code.
>>
>> I consider it flat out unacceptable to use macros with one letter
>> prefixes like "S_". You simply should not do this.
>>
>
> Okay. We’ll clean up all of the macros to match the files' original style. We
> do need to change the sense of the *_MASK macros since they don’t match how we
> use them as field tokens. Also the *_SHIFT, *_MASK and *_GET names are
> sucking up space and making lines wrap unnecessarily, creating readability
> problems. Can we change these to *_S, *_M and *_G? E.g.:
That's fine.
^ permalink raw reply
* I Contacted You Independently
From: Frank Wong @ 2014-11-06 21:17 UTC (permalink / raw)
To: Recipients
I am Mr Frank Wong,Chairman of DBS Bank in (Hong Kong).I have a secured business proposal for you,get back to me for more details wongfrank4@gmail.com OR wongfrank49@yahoo.com.hk
Regards,
Frank Wong.
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
^ permalink raw reply
* BUG in xennet_make_frags with paged skb data
From: Seth Forshee @ 2014-11-06 21:49 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Konrad Rzeszutek Wilk, Boris Ostrovsky,
David Vrabel, Stefan Bader, Jay Vosburgh, linux-kernel, xen-devel,
seth.forshee
We've had several reports of hitting the following BUG_ON in
xennet_make_frags with 3.2 and 3.13 kernels (I'm currently awaiting
results of testing with 3.17):
/* Grant backend access to each skb fragment page. */
for (i = 0; i < frags; i++) {
skb_frag_t *frag = skb_shinfo(skb)->frags + i;
struct page *page = skb_frag_page(frag);
len = skb_frag_size(frag);
offset = frag->page_offset;
/* Data must not cross a page boundary. */
BUG_ON(len + offset > PAGE_SIZE<<compound_order(page));
When this happens the page in question is a "middle" page in a compound
page (i.e. it's a tail page but not the last tail page), and the data is
fully contained within the compound page. The data does however cross
the hardware page boundary, and since compound_order evaluates to 0 for
tail pages the check fails.
In going over this I've been unable to determine whether the BUG_ON in
xennet_make_frags is incorrect or the paged skb data is wrong. I can't
find that it's documented anywhere, and the networking code itself is a
bit ambiguous when it comes to compound pages. On the one hand
__skb_fill_page_desc specifically handles adding tail pages as paged
data, but on the other hand skb_copy_bits kmaps frag->page.p which could
fail with data that extends into another page.
Can anyone explain what the rules are here? My best guess based on
skb_copy_bits is that paged data should never cross the hardware page
boundary, but I'm not really sure how all of this works out when dealing
with compound pages.
Thanks,
Seth
^ permalink raw reply
* Re: [PATCH net-next] net/fm10k: Avoid double setting of NETIF_F_SG for the HW encapsulation feature mask
From: David Miller @ 2014-11-06 21:44 UTC (permalink / raw)
To: ogerlitz; +Cc: jeffrey.t.kirsher, netdev
In-Reply-To: <1415265664-10738-1-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Thu, 6 Nov 2014 11:21:04 +0200
> The networking core does it for the driver during registration time.
>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
I assume Jeff will pick this up and send it to me via his tree.
^ permalink raw reply
* Re: [PATCH net] netxen: Fix link event handling.
From: David Miller @ 2014-11-06 21:43 UTC (permalink / raw)
To: manish.chopra; +Cc: netdev, mkubecek, Dept-GELinuxNICDev
In-Reply-To: <1415278731-26404-1-git-send-email-manish.chopra@qlogic.com>
From: Manish Chopra <manish.chopra@qlogic.com>
Date: Thu, 6 Nov 2014 07:58:51 -0500
> o Poll for the link events only if firmware doesn't have capability
> to notify the driver for the link events.
>
> Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net 2/2] enic: update desc properly in rx_copybreak
From: David Miller @ 2014-11-06 21:42 UTC (permalink / raw)
To: _govind; +Cc: ssujith, netdev
In-Reply-To: <1415267499-25955-2-git-send-email-_govind@gmx.com>
From: Govindarajulu Varadarajan <_govind@gmx.com>
Date: Thu, 6 Nov 2014 15:21:39 +0530
> When we reuse the rx buffer, we need to update the desc. If not hardware sees
> stale value.
>
> In the following crash, when mtu is changed, hardware sees old rx buffer value
> and crashes on skb_put.
>
> Fix this by using enic_queue_rq_desc helper function which updates the necessary
> desc.
...
> fixes: a03bb56e67c357980dae886683733dab5583dc14 ("enic: implement rx_copybreak")
> Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
Also applied, thanks.
^ permalink raw reply
* Re: [PATCH net 1/2] enic: handle error condition properly in enic_rq_indicate_buf
From: David Miller @ 2014-11-06 21:42 UTC (permalink / raw)
To: _govind; +Cc: ssujith, netdev
In-Reply-To: <1415267499-25955-1-git-send-email-_govind@gmx.com>
From: Govindarajulu Varadarajan <_govind@gmx.com>
Date: Thu, 6 Nov 2014 15:21:38 +0530
> In case of error in rx path, we free the buf->os_buf but we do not make it NULL.
> In next iteration we use the skb which is already freed. This causes the
> following crash.
...
> fixes: a03bb56e67c357980dae886683733dab5583dc14 ("enic: implement rx_copybreak")
> Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 0/2] mlx5_core fixes for 3.18
From: David Miller @ 2014-11-06 21:41 UTC (permalink / raw)
To: eli-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
ogerlitz-VPRAkNaXOzVWk0Htik3J/w, eli-VPRAkNaXOzVWk0Htik3J/w
In-Reply-To: <1415271082-7644-1-git-send-email-eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
From: Eli Cohen <eli-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
Date: Thu, 6 Nov 2014 12:51:20 +0200
> the following two patches fix races to could lead to kernel panic in some cases.
Series applied, thanks Eli.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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: [GIT net-next v2] Open vSwitch
From: David Miller @ 2014-11-06 21:33 UTC (permalink / raw)
To: pshelar; +Cc: netdev
In-Reply-To: <1415265526-1524-1-git-send-email-pshelar@nicira.com>
From: Pravin B Shelar <pshelar@nicira.com>
Date: Thu, 6 Nov 2014 01:18:46 -0800
> First two patches are related to OVS MPLS support. Rest of patches
> are mostly refactoring and minor improvements to openvswitch.
>
> v1-v2:
> - Fix conflicts due to "gue: Remote checksum offload"
Pulled, thanks Pravin.
^ permalink raw reply
* Re: ipv4: Use standard iovec primitive in raw_probe_proto_opt
From: David Miller @ 2014-11-06 21:28 UTC (permalink / raw)
To: herbert; +Cc: viro, netdev, linux-kernel, bcrl, nakam, yoshfuji
In-Reply-To: <20141106064629.GA29321@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 6 Nov 2014 14:46:29 +0800
> On Thu, Nov 06, 2014 at 06:43:18AM +0000, Al Viro wrote:
>> On Thu, Nov 06, 2014 at 01:50:23PM +0800, Herbert Xu wrote:
>> > + /* We only need the first two bytes. */
>> > + err = memcpy_fromiovecend((void *)&icmph, msg->msg_iov, 0, 2);
>> > + if (err)
>> > + return err;
>> > +
>> > + fl4->fl4_icmp_type = icmph.type;
>> > + fl4->fl4_icmp_code = icmph.code;
>>
>> That's more readable, but that exposes another problem in there - we read
>> the same piece of userland data twice, with no promise whatsoever that we'll
>> get the same value both times...
>
> Sure, but you have to be root anyway to write to raw sockets.
>
> Patches are welcome :)
I'd agree with this root-only argument maybe 15 years ago, but with
containers and stuff like that we want to prevent root X from messing
up the machine for root Y.
This is a recurring topic, and I'd strongly like to avoid adding new
ways that these kinds of problems can happen.
For example, I'm still on the hook to address the AF_NETLINK mmap TX
code, which has a similarly abusable issue.
^ permalink raw reply
* Re: [PATCH net-next] net: gro: add a per device gro flush timer
From: David Miller @ 2014-11-06 21:25 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ogerlitz, willemb
In-Reply-To: <1415235320.13896.51.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 05 Nov 2014 16:55:20 -0800
> @@ -4430,8 +4432,19 @@ void napi_complete(struct napi_struct *n)
> if (unlikely(test_bit(NAPI_STATE_NPSVC, &n->state)))
> return;
>
> - napi_gro_flush(n, false);
> + if (n->gro_list) {
> + unsigned long timeout = 0;
> +
> + if (n->napi_rx_count)
> + timeout = n->dev->gro_flush_timeout;
Under what circumstances would we see n->gro_list non-NULL yet
n->napi_rx_count == 0?
I'm not so sure it can happen.
Said another way, it looks to me like you could implement this
using less state.
^ permalink raw reply
* [PATCH iproute2 next] ip route: enable per-route ecn settings via 'features' option
From: Florian Westphal @ 2014-11-06 21:15 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
This permits to selectively enable explicit congestion notification via
the routing table.
If this ecn feature is not set, the kernel will use the tcp_ecn sysctl
to decide wheter to use ECN when establising a TCP connection.
At the time of this writing, the kernel supports ecn and allfrags, but
allfrags is of dubious value and not implemented here.
Example:
ip route change 192.168.2.0/24 dev eth0 features ecn
Signed-off-by: Florian Westphal <fw@strlen.de>
---
ip/iproute.c | 32 ++++++++++++++++++++++++++++++++
man/man8/ip-route.8.in | 18 ++++++++++++++++++
2 files changed, 50 insertions(+)
diff --git a/ip/iproute.c b/ip/iproute.c
index d77b1e3..ad1cbab 100644
--- a/ip/iproute.c
+++ b/ip/iproute.c
@@ -80,6 +80,7 @@ static void usage(void)
fprintf(stderr, " [ window NUMBER] [ cwnd NUMBER ] [ initcwnd NUMBER ]\n");
fprintf(stderr, " [ ssthresh NUMBER ] [ realms REALM ] [ src ADDRESS ]\n");
fprintf(stderr, " [ rto_min TIME ] [ hoplimit NUMBER ] [ initrwnd NUMBER ]\n");
+ fprintf(stderr, " [ features FEATURES ]\n");
fprintf(stderr, " [ quickack BOOL ]\n");
fprintf(stderr, "TYPE := [ unicast | local | broadcast | multicast | throw |\n");
fprintf(stderr, " unreachable | prohibit | blackhole | nat ]\n");
@@ -89,6 +90,7 @@ static void usage(void)
fprintf(stderr, "RTPROTO := [ kernel | boot | static | NUMBER ]\n");
fprintf(stderr, "TIME := NUMBER[s|ms]\n");
fprintf(stderr, "BOOL := [1|0]\n");
+ fprintf(stderr, "FEATURES := ecn\n");
exit(-1);
}
@@ -280,6 +282,19 @@ static int calc_host_len(const struct rtmsg *r)
return -1;
}
+static void print_rtax_features(FILE *fp, unsigned int features)
+{
+ unsigned int of = features;
+
+ if (features & RTAX_FEATURE_ECN) {
+ fprintf(fp, " ecn");
+ features &= ~RTAX_FEATURE_ECN;
+ }
+
+ if (features)
+ fprintf(fp, " 0x%x", of);
+}
+
int print_route(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
{
FILE *fp = (FILE*)arg;
@@ -535,6 +550,9 @@ int print_route(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
val = *(unsigned*)RTA_DATA(mxrta[i]);
switch (i) {
+ case RTAX_FEATURES:
+ print_rtax_features(fp, val);
+ break;
case RTAX_HOPLIMIT:
if ((int)val == -1)
val = 0;
@@ -885,6 +903,20 @@ static int iproute_modify(int cmd, unsigned flags, int argc, char **argv)
if (get_unsigned(&win, *argv, 0))
invarg("\"initrwnd\" value is invalid\n", *argv);
rta_addattr32(mxrta, sizeof(mxbuf), RTAX_INITRWND, win);
+ } else if (matches(*argv, "features") == 0) {
+ unsigned int features = 0;
+
+ while (argc > 0) {
+ NEXT_ARG();
+
+ if (strcmp(*argv, "ecn") == 0)
+ features |= RTAX_FEATURE_ECN;
+ else
+ invarg("\"features\" value not valid\n", *argv);
+ break;
+ }
+
+ rta_addattr32(mxrta, sizeof(mxbuf), RTAX_FEATURES, features);
} else if (matches(*argv, "quickack") == 0) {
unsigned quickack;
NEXT_ARG();
diff --git a/man/man8/ip-route.8.in b/man/man8/ip-route.8.in
index 79bc7f1..89960c1 100644
--- a/man/man8/ip-route.8.in
+++ b/man/man8/ip-route.8.in
@@ -113,6 +113,8 @@ replace " } "
.IR NUMBER " ] [ "
.B initrwnd
.IR NUMBER " ] [ "
+.B features
+.IR FEATURES " ] [ "
.B quickack
.IR BOOL " ]"
@@ -140,6 +142,10 @@ throw " | " unreachable " | " prohibit " | " blackhole " | " nat " ]"
.BR kernel " | " boot " | " static " |"
.IR NUMBER " ]"
+.ti -8
+.IR FEATURES " := [ "
+.BR ecn " | ]"
+
.SH DESCRIPTION
.B ip route
@@ -411,6 +417,18 @@ Actual window size is this value multiplied by the MSS of the connection.
The default value is zero, meaning to use Slow Start value.
.TP
+.BI features " FEATURES " (3.18+ only)
+Enable or disable per-route features. Only available feature at this
+time is
+.B ecn
+to enable explicit congestion notification when initiating connections to the
+given destination network.
+When responding to a connection request from the given network, ecn will
+also be used even if the
+.B net.ipv4.tcp_ecn
+sysctl is set to 0.
+
+.TP
.BI quickack " BOOL " "(3.11+ only)"
Enable or disable quick ack for connections to this destination.
--
2.0.4
^ permalink raw reply related
* Re: [PATCH net 3/5] fm10k: Implement ndo_gso_check()
From: Joe Stringer @ 2014-11-06 21:15 UTC (permalink / raw)
To: alexander.duyck, netdev, Dept-GELinuxNICDev, linux-kernel
Cc: Alexander Duyck, sathya.perla, jeffrey.t.kirsher, linux.nics,
amirv, shahed.shaikh, therbert
In-Reply-To: <20141106184115.GB18339@gmail.com>
On Thu, Nov 06, 2014 at 10:41:15AM -0800, Joe Stringer wrote:
> On Wed, Nov 05, 2014 at 06:54:00PM -0800, Alexander Duyck wrote:
> > On 11/04/2014 01:56 PM, Joe Stringer wrote:
> > > ndo_gso_check() was recently introduced to allow NICs to report the
> > > offloading support that they have on a per-skb basis. Add an
> > > implementation for this driver which checks for something that looks
> > > like VXLAN.
> > >
> > > Implementation shamelessly stolen from Tom Herbert:
> > > http://thread.gmane.org/gmane.linux.network/332428/focus=333111
> > >
> > > Signed-off-by: Joe Stringer <joestringer@nicira.com>
> > > ---
> > > Should this driver report support for GSO on packets with tunnel headers
> > > up to 64B like the i40e driver does?
> > > ---
> > > drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 12 ++++++++++++
> > > 1 file changed, 12 insertions(+)
> > >
> > > diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c b/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
> > > index 8811364..b9ef622 100644
> > > --- a/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
> > > +++ b/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
> > > @@ -1350,6 +1350,17 @@ static void fm10k_dfwd_del_station(struct net_device *dev, void *priv)
> > > }
> > > }
> > >
> > > +static bool fm10k_gso_check(struct sk_buff *skb, struct net_device *dev)
> > > +{
> > > + if ((skb_shinfo(skb)->gso_type & SKB_GSO_UDP_TUNNEL) &&
> > > + (skb->inner_protocol_type != ENCAP_TYPE_ETHER ||
> > > + skb->inner_protocol != htons(ETH_P_TEB) ||
> > > + skb_inner_mac_header(skb) - skb_transport_header(skb) != 16))
> > > + return false;
> > > +
> > > + return true;
> > > +}
> > > +
> > > static const struct net_device_ops fm10k_netdev_ops = {
> > > .ndo_open = fm10k_open,
> > > .ndo_stop = fm10k_close,
> > > @@ -1372,6 +1383,7 @@ static const struct net_device_ops fm10k_netdev_ops = {
> > > .ndo_do_ioctl = fm10k_ioctl,
> > > .ndo_dfwd_add_station = fm10k_dfwd_add_station,
> > > .ndo_dfwd_del_station = fm10k_dfwd_del_station,
> > > + .ndo_gso_check = fm10k_gso_check,
> > > };
> > >
> > > #define DEFAULT_DEBUG_LEVEL_SHIFT 3
> >
> > I'm thinking this check is far too simplistic. If you look the fm10k
> > driver already has fm10k_tx_encap_offload() in the TSO function for
> > verifying if it can support offloading tunnels or not. I would
> > recommend starting there or possibly even just adapting that function to
> > suit your purpose.
> >
> > Thanks,
> >
> > Alex
>
> Would it be enough to just call fm10k_tx_encap_offload() in a way that echoes fm10k_tso()?
>
> +static bool fm10k_gso_check(struct sk_buff *skb, struct net_device *dev)
> +{
> + if (skb->encapsulation && !fm10k_tx_encap_offload(skb))
> + return false;
> +
> + return true;
> +}
Oh, I suppose we need to check the gso_type too. More like this?
+static bool fm10k_gso_check(struct sk_buff *skb, struct net_device *dev)
+{
+ if ((skb_shinfo(skb)->gso_type & (SKB_GSO_UDP_TUNNEL | SKB_GSO_GRE)) &&
+ !fm10k_tx_encap_offload(skb))
+ return false;
+
+ return true;
+}
^ permalink raw reply
* pull request: wireless 2014-11-06
From: John W. Linville @ 2014-11-06 20:52 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 16636 bytes --]
Dave,
Please pull this batch of fixes intended for the 3.18 stream...
For the mac80211 bits, Johannes says:
"This contains another small set of fixes for 3.18, these are all
over the place and most of the bugs are old, one even dates back
to the original mac80211 we merged into the kernel."
For the iwlwifi bits, Emmanuel says:
"I fix here two issues that are related to the firmware
loading flow. A user reported that he couldn't load the
driver because the rfkill line was pulled up while we
were running the calibrations. This was happening while
booting the system: systemd was restoring the "disable
wifi settings" and that raised an RFKILL interrupt during
the calibration. Our driver didn't handle that properly
and this is now fixed."
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 75a916e1944fea8347d2245c62567187e4eff9dd:
rtlwifi: rtl8192se: Fix firmware loading (2014-10-30 15:00:23 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git tags/master-2014-11-04
for you to fetch changes up to 0c9a67c8f1d2b71a89f66349362412e9bf6becab:
Merge tag 'mac80211-for-john-2014-11-04' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 (2014-11-04 15:56:33 -0500)
----------------------------------------------------------------
Emmanuel Grumbach (2):
iwlwifi: mvm: initialize the cur_ucode upon boot
iwlwifi: fix RFkill while calibrating
Felix Fietkau (1):
mac80211: flush keys for AP mode on ieee80211_do_stop
Johannes Berg (2):
mac80211: properly flush delayed scan work on interface removal
mac80211: fix use-after-free in defragmentation
John W. Linville (2):
Merge tag 'iwlwifi-for-john-2014-11-03' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Merge tag 'mac80211-for-john-2014-11-04' of git://git.kernel.org/.../jberg/mac80211
Junjie Mao (1):
mac80211_hwsim: release driver when ieee80211_register_hw fails
Luciano Coelho (2):
mac80211: use secondary channel offset IE also beacons during CSA
mac80211: schedule the actual switch of the station before CSA count 0
drivers/net/wireless/iwlwifi/mvm/fw.c | 10 +++++++++-
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 1 +
drivers/net/wireless/iwlwifi/mvm/mvm.h | 1 +
drivers/net/wireless/iwlwifi/mvm/ops.c | 12 +++++++++++-
drivers/net/wireless/iwlwifi/pcie/trans.c | 4 ++--
drivers/net/wireless/mac80211_hwsim.c | 4 +++-
net/mac80211/ibss.c | 2 +-
net/mac80211/ieee80211_i.h | 3 +--
net/mac80211/iface.c | 18 ++++++++++++------
net/mac80211/mesh.c | 2 +-
net/mac80211/mlme.c | 5 +++--
net/mac80211/rx.c | 14 +++++++-------
net/mac80211/spectmgmt.c | 18 ++++++------------
13 files changed, 58 insertions(+), 36 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/mvm/fw.c b/drivers/net/wireless/iwlwifi/mvm/fw.c
index e0d9f19650b0..eb03943f8463 100644
--- a/drivers/net/wireless/iwlwifi/mvm/fw.c
+++ b/drivers/net/wireless/iwlwifi/mvm/fw.c
@@ -284,7 +284,7 @@ int iwl_run_init_mvm_ucode(struct iwl_mvm *mvm, bool read_nvm)
lockdep_assert_held(&mvm->mutex);
- if (WARN_ON_ONCE(mvm->init_ucode_complete))
+ if (WARN_ON_ONCE(mvm->init_ucode_complete || mvm->calibrating))
return 0;
iwl_init_notification_wait(&mvm->notif_wait,
@@ -334,6 +334,8 @@ int iwl_run_init_mvm_ucode(struct iwl_mvm *mvm, bool read_nvm)
goto out;
}
+ mvm->calibrating = true;
+
/* Send TX valid antennas before triggering calibrations */
ret = iwl_send_tx_ant_cfg(mvm, mvm->fw->valid_tx_ant);
if (ret)
@@ -358,11 +360,17 @@ int iwl_run_init_mvm_ucode(struct iwl_mvm *mvm, bool read_nvm)
MVM_UCODE_CALIB_TIMEOUT);
if (!ret)
mvm->init_ucode_complete = true;
+
+ if (ret && iwl_mvm_is_radio_killed(mvm)) {
+ IWL_DEBUG_RF_KILL(mvm, "RFKILL while calibrating.\n");
+ ret = 1;
+ }
goto out;
error:
iwl_remove_notification(&mvm->notif_wait, &calib_wait);
out:
+ mvm->calibrating = false;
if (iwlmvm_mod_params.init_dbg && !mvm->nvm_data) {
/* we want to debug INIT and we have no NVM - fake */
mvm->nvm_data = kzalloc(sizeof(struct iwl_nvm_data) +
diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
index 585fe5b7100f..b62405865b25 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
@@ -788,6 +788,7 @@ static void iwl_mvm_restart_cleanup(struct iwl_mvm *mvm)
mvm->scan_status = IWL_MVM_SCAN_NONE;
mvm->ps_disabled = false;
+ mvm->calibrating = false;
/* just in case one was running */
ieee80211_remain_on_channel_expired(mvm->hw);
diff --git a/drivers/net/wireless/iwlwifi/mvm/mvm.h b/drivers/net/wireless/iwlwifi/mvm/mvm.h
index b153ced7015b..845429c88cf4 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/iwlwifi/mvm/mvm.h
@@ -548,6 +548,7 @@ struct iwl_mvm {
enum iwl_ucode_type cur_ucode;
bool ucode_loaded;
bool init_ucode_complete;
+ bool calibrating;
u32 error_event_table;
u32 log_event_table;
u32 umac_error_event_table;
diff --git a/drivers/net/wireless/iwlwifi/mvm/ops.c b/drivers/net/wireless/iwlwifi/mvm/ops.c
index 48cb25a93591..5b719ee8e789 100644
--- a/drivers/net/wireless/iwlwifi/mvm/ops.c
+++ b/drivers/net/wireless/iwlwifi/mvm/ops.c
@@ -424,6 +424,7 @@ iwl_op_mode_mvm_start(struct iwl_trans *trans, const struct iwl_cfg *cfg,
}
mvm->sf_state = SF_UNINIT;
mvm->low_latency_agg_frame_limit = 6;
+ mvm->cur_ucode = IWL_UCODE_INIT;
mutex_init(&mvm->mutex);
mutex_init(&mvm->d0i3_suspend_mutex);
@@ -752,6 +753,7 @@ void iwl_mvm_set_hw_ctkill_state(struct iwl_mvm *mvm, bool state)
static bool iwl_mvm_set_hw_rfkill_state(struct iwl_op_mode *op_mode, bool state)
{
struct iwl_mvm *mvm = IWL_OP_MODE_GET_MVM(op_mode);
+ bool calibrating = ACCESS_ONCE(mvm->calibrating);
if (state)
set_bit(IWL_MVM_STATUS_HW_RFKILL, &mvm->status);
@@ -760,7 +762,15 @@ static bool iwl_mvm_set_hw_rfkill_state(struct iwl_op_mode *op_mode, bool state)
wiphy_rfkill_set_hw_state(mvm->hw->wiphy, iwl_mvm_is_radio_killed(mvm));
- return state && mvm->cur_ucode != IWL_UCODE_INIT;
+ /* iwl_run_init_mvm_ucode is waiting for results, abort it */
+ if (calibrating)
+ iwl_abort_notification_waits(&mvm->notif_wait);
+
+ /*
+ * Stop the device if we run OPERATIONAL firmware or if we are in the
+ * middle of the calibrations.
+ */
+ return state && (mvm->cur_ucode != IWL_UCODE_INIT || calibrating);
}
static void iwl_mvm_free_skb(struct iwl_op_mode *op_mode, struct sk_buff *skb)
diff --git a/drivers/net/wireless/iwlwifi/pcie/trans.c b/drivers/net/wireless/iwlwifi/pcie/trans.c
index 3781b029e54a..160c3ebc48d0 100644
--- a/drivers/net/wireless/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/iwlwifi/pcie/trans.c
@@ -915,7 +915,8 @@ static void iwl_trans_pcie_stop_device(struct iwl_trans *trans)
* restart. So don't process again if the device is
* already dead.
*/
- if (test_bit(STATUS_DEVICE_ENABLED, &trans->status)) {
+ if (test_and_clear_bit(STATUS_DEVICE_ENABLED, &trans->status)) {
+ IWL_DEBUG_INFO(trans, "DEVICE_ENABLED bit was set and is now cleared\n");
iwl_pcie_tx_stop(trans);
iwl_pcie_rx_stop(trans);
@@ -945,7 +946,6 @@ static void iwl_trans_pcie_stop_device(struct iwl_trans *trans)
/* clear all status bits */
clear_bit(STATUS_SYNC_HCMD_ACTIVE, &trans->status);
clear_bit(STATUS_INT_ENABLED, &trans->status);
- clear_bit(STATUS_DEVICE_ENABLED, &trans->status);
clear_bit(STATUS_TPOWER_PMI, &trans->status);
clear_bit(STATUS_RFKILL, &trans->status);
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index babbdc1ce741..c9ad4cf1adfb 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -1987,7 +1987,7 @@ static int mac80211_hwsim_create_radio(int channels, const char *reg_alpha2,
if (err != 0) {
printk(KERN_DEBUG "mac80211_hwsim: device_bind_driver failed (%d)\n",
err);
- goto failed_hw;
+ goto failed_bind;
}
skb_queue_head_init(&data->pending);
@@ -2183,6 +2183,8 @@ static int mac80211_hwsim_create_radio(int channels, const char *reg_alpha2,
return idx;
failed_hw:
+ device_release_driver(data->dev);
+failed_bind:
device_unregister(data->dev);
failed_drvdata:
ieee80211_free_hw(hw);
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 56b53571c807..509bc157ce55 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -805,7 +805,7 @@ ieee80211_ibss_process_chanswitch(struct ieee80211_sub_if_data *sdata,
memset(¶ms, 0, sizeof(params));
memset(&csa_ie, 0, sizeof(csa_ie));
- err = ieee80211_parse_ch_switch_ie(sdata, elems, beacon,
+ err = ieee80211_parse_ch_switch_ie(sdata, elems,
ifibss->chandef.chan->band,
sta_flags, ifibss->bssid, &csa_ie);
/* can't switch to destination channel, fail */
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index c2aaec4dfcf0..8c68da30595d 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1642,7 +1642,6 @@ void ieee80211_process_measurement_req(struct ieee80211_sub_if_data *sdata,
* ieee80211_parse_ch_switch_ie - parses channel switch IEs
* @sdata: the sdata of the interface which has received the frame
* @elems: parsed 802.11 elements received with the frame
- * @beacon: indicates if the frame was a beacon or probe response
* @current_band: indicates the current band
* @sta_flags: contains information about own capabilities and restrictions
* to decide which channel switch announcements can be accepted. Only the
@@ -1656,7 +1655,7 @@ void ieee80211_process_measurement_req(struct ieee80211_sub_if_data *sdata,
* Return: 0 on success, <0 on error and >0 if there is nothing to parse.
*/
int ieee80211_parse_ch_switch_ie(struct ieee80211_sub_if_data *sdata,
- struct ieee802_11_elems *elems, bool beacon,
+ struct ieee802_11_elems *elems,
enum ieee80211_band current_band,
u32 sta_flags, u8 *bssid,
struct ieee80211_csa_ie *csa_ie);
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index af237223a8cd..653f5eb07a27 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -766,10 +766,12 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata,
int i, flushed;
struct ps_data *ps;
struct cfg80211_chan_def chandef;
+ bool cancel_scan;
clear_bit(SDATA_STATE_RUNNING, &sdata->state);
- if (rcu_access_pointer(local->scan_sdata) == sdata)
+ cancel_scan = rcu_access_pointer(local->scan_sdata) == sdata;
+ if (cancel_scan)
ieee80211_scan_cancel(local);
/*
@@ -898,6 +900,8 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata,
list_del(&sdata->u.vlan.list);
mutex_unlock(&local->mtx);
RCU_INIT_POINTER(sdata->vif.chanctx_conf, NULL);
+ /* see comment in the default case below */
+ ieee80211_free_keys(sdata, true);
/* no need to tell driver */
break;
case NL80211_IFTYPE_MONITOR:
@@ -923,17 +927,16 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata,
/*
* When we get here, the interface is marked down.
* Free the remaining keys, if there are any
- * (shouldn't be, except maybe in WDS mode?)
+ * (which can happen in AP mode if userspace sets
+ * keys before the interface is operating, and maybe
+ * also in WDS mode)
*
* Force the key freeing to always synchronize_net()
* to wait for the RX path in case it is using this
- * interface enqueuing frames * at this very time on
+ * interface enqueuing frames at this very time on
* another CPU.
*/
ieee80211_free_keys(sdata, true);
-
- /* fall through */
- case NL80211_IFTYPE_AP:
skb_queue_purge(&sdata->skb_queue);
}
@@ -991,6 +994,9 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata,
ieee80211_recalc_ps(local, -1);
+ if (cancel_scan)
+ flush_delayed_work(&local->scan_work);
+
if (local->open_count == 0) {
ieee80211_stop_device(local);
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index e9f99c1e3fad..0c8b2a77d312 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -874,7 +874,7 @@ ieee80211_mesh_process_chnswitch(struct ieee80211_sub_if_data *sdata,
memset(¶ms, 0, sizeof(params));
memset(&csa_ie, 0, sizeof(csa_ie));
- err = ieee80211_parse_ch_switch_ie(sdata, elems, beacon, band,
+ err = ieee80211_parse_ch_switch_ie(sdata, elems, band,
sta_flags, sdata->vif.addr,
&csa_ie);
if (err < 0)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 2de88704278b..93af0f1c9d99 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1072,7 +1072,7 @@ ieee80211_sta_process_chanswitch(struct ieee80211_sub_if_data *sdata,
current_band = cbss->channel->band;
memset(&csa_ie, 0, sizeof(csa_ie));
- res = ieee80211_parse_ch_switch_ie(sdata, elems, beacon, current_band,
+ res = ieee80211_parse_ch_switch_ie(sdata, elems, current_band,
ifmgd->flags,
ifmgd->associated->bssid, &csa_ie);
if (res < 0)
@@ -1168,7 +1168,8 @@ ieee80211_sta_process_chanswitch(struct ieee80211_sub_if_data *sdata,
ieee80211_queue_work(&local->hw, &ifmgd->chswitch_work);
else
mod_timer(&ifmgd->chswitch_timer,
- TU_TO_EXP_TIME(csa_ie.count * cbss->beacon_interval));
+ TU_TO_EXP_TIME((csa_ie.count - 1) *
+ cbss->beacon_interval));
}
static bool
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index b04ca4049c95..a37f9af634cb 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1678,11 +1678,14 @@ ieee80211_rx_h_defragment(struct ieee80211_rx_data *rx)
sc = le16_to_cpu(hdr->seq_ctrl);
frag = sc & IEEE80211_SCTL_FRAG;
- if (likely((!ieee80211_has_morefrags(fc) && frag == 0) ||
- is_multicast_ether_addr(hdr->addr1))) {
- /* not fragmented */
+ if (likely(!ieee80211_has_morefrags(fc) && frag == 0))
+ goto out;
+
+ if (is_multicast_ether_addr(hdr->addr1)) {
+ rx->local->dot11MulticastReceivedFrameCount++;
goto out;
}
+
I802_DEBUG_INC(rx->local->rx_handlers_fragments);
if (skb_linearize(rx->skb))
@@ -1775,10 +1778,7 @@ ieee80211_rx_h_defragment(struct ieee80211_rx_data *rx)
out:
if (rx->sta)
rx->sta->rx_packets++;
- if (is_multicast_ether_addr(hdr->addr1))
- rx->local->dot11MulticastReceivedFrameCount++;
- else
- ieee80211_led_rx(rx->local);
+ ieee80211_led_rx(rx->local);
return RX_CONTINUE;
}
diff --git a/net/mac80211/spectmgmt.c b/net/mac80211/spectmgmt.c
index 6ab009070084..efeba56c913b 100644
--- a/net/mac80211/spectmgmt.c
+++ b/net/mac80211/spectmgmt.c
@@ -22,7 +22,7 @@
#include "wme.h"
int ieee80211_parse_ch_switch_ie(struct ieee80211_sub_if_data *sdata,
- struct ieee802_11_elems *elems, bool beacon,
+ struct ieee802_11_elems *elems,
enum ieee80211_band current_band,
u32 sta_flags, u8 *bssid,
struct ieee80211_csa_ie *csa_ie)
@@ -91,19 +91,13 @@ int ieee80211_parse_ch_switch_ie(struct ieee80211_sub_if_data *sdata,
return -EINVAL;
}
- if (!beacon && sec_chan_offs) {
+ if (sec_chan_offs) {
secondary_channel_offset = sec_chan_offs->sec_chan_offs;
- } else if (beacon && ht_oper) {
- secondary_channel_offset =
- ht_oper->ht_param & IEEE80211_HT_PARAM_CHA_SEC_OFFSET;
} else if (!(sta_flags & IEEE80211_STA_DISABLE_HT)) {
- /* If it's not a beacon, HT is enabled and the IE not present,
- * it's 20 MHz, 802.11-2012 8.5.2.6:
- * This element [the Secondary Channel Offset Element] is
- * present when switching to a 40 MHz channel. It may be
- * present when switching to a 20 MHz channel (in which
- * case the secondary channel offset is set to SCN).
- */
+ /* If the secondary channel offset IE is not present,
+ * we can't know what's the post-CSA offset, so the
+ * best we can do is use 20MHz.
+ */
secondary_channel_offset = IEEE80211_HT_PARAM_CHA_SEC_NONE;
}
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply related
* [PATCH net-next] dccp: Convert DCCP_WARN to net_warn_ratelimited
From: Joe Perches @ 2014-11-06 20:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel, Gerrit Renker
In-Reply-To: <20141106.151149.1321164537677873976.davem@davemloft.net>
Remove the dependency on the "warning" sysctl (net_msg_warn)
which is only used by the LIMIT_NETDEBUG macro.
Convert the LIMIT_NETDEBUG use in DCCP_WARN to the more
common net_warn_ratelimited mechanism.
This still ratelimits based on the net_ratelimit()
function, but removes the check for the sysctl.
Signed-off-by: Joe Perches <joe@perches.com>
---
On Thu, 2014-11-06 at 15:11 -0500, David Miller wrote:
> Applied, thanks for doing this work Joe.
No worries.
What about the LIMIT_NETDEBUG stuff now?
Maybe all of them might as well be net_dbg_ratelimited
even if it changes some of the logging levels.
Probably DCCP_WARN should be net_warn_ratelimited
so let's start there...
net/dccp/dccp.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/dccp/dccp.h b/net/dccp/dccp.h
index c678166..e4c144f 100644
--- a/net/dccp/dccp.h
+++ b/net/dccp/dccp.h
@@ -22,8 +22,8 @@
/*
* DCCP - specific warning and debugging macros.
*/
-#define DCCP_WARN(fmt, a...) LIMIT_NETDEBUG(KERN_WARNING "%s: " fmt, \
- __func__, ##a)
+#define DCCP_WARN(fmt, ...) \
+ net_warn_ratelimited("%s: " fmt, __func__, ##__VA_ARGS__)
#define DCCP_CRIT(fmt, a...) printk(KERN_CRIT fmt " at %s:%d/%s()\n", ##a, \
__FILE__, __LINE__, __func__)
#define DCCP_BUG(a...) do { DCCP_CRIT("BUG: " a); dump_stack(); } while(0)
^ permalink raw reply related
* Re: [PATCH 3/3 3.18] rtlwifi: rtl8192se: Fix connection problems
From: John W. Linville @ 2014-11-06 20:45 UTC (permalink / raw)
To: Larry Finger
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1415236254-12274-4-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
On Wed, Nov 05, 2014 at 07:10:54PM -0600, Larry Finger wrote:
> Changes in the vendor driver were added to rtlwifi, but some updates
> to rtl8192se were missed.
>
> Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> ---
> drivers/net/wireless/rtlwifi/rtl8192se/hw.c | 129 +++++++++++++--------------
> drivers/net/wireless/rtlwifi/rtl8192se/phy.c | 8 +-
> drivers/net/wireless/rtlwifi/rtl8192se/sw.c | 4 +
> drivers/net/wireless/rtlwifi/rtl8192se/trx.c | 23 +++++
> drivers/net/wireless/rtlwifi/rtl8192se/trx.h | 4 +
> 5 files changed, 100 insertions(+), 68 deletions(-)
This looks a bit big for a fix. Could this be broken-up a bit more?
Perhaps you could enhance the changelog a bit more?
> diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/hw.c b/drivers/net/wireless/rtlwifi/rtl8192se/hw.c
> index 00e0670..4626203 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8192se/hw.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8192se/hw.c
> @@ -1170,27 +1170,32 @@ static int _rtl92se_set_media_status(struct ieee80211_hw *hw,
> {
> struct rtl_priv *rtlpriv = rtl_priv(hw);
> u8 bt_msr = rtl_read_byte(rtlpriv, MSR);
> + enum led_ctl_mode ledaction = LED_CTL_NO_LINK;
> u32 temp;
> + u8 mode = MSR_NOLINK;
> +
> bt_msr &= ~MSR_LINK_MASK;
>
> switch (type) {
> case NL80211_IFTYPE_UNSPECIFIED:
> - bt_msr |= (MSR_LINK_NONE << MSR_LINK_SHIFT);
> + mode = MSR_NOLINK;
> RT_TRACE(rtlpriv, COMP_INIT, DBG_TRACE,
> "Set Network type to NO LINK!\n");
> break;
> case NL80211_IFTYPE_ADHOC:
> - bt_msr |= (MSR_LINK_ADHOC << MSR_LINK_SHIFT);
> + mode = MSR_ADHOC;
> RT_TRACE(rtlpriv, COMP_INIT, DBG_TRACE,
> "Set Network type to Ad Hoc!\n");
> break;
> case NL80211_IFTYPE_STATION:
> - bt_msr |= (MSR_LINK_MANAGED << MSR_LINK_SHIFT);
> + mode = MSR_INFRA;
> + ledaction = LED_CTL_LINK;
> RT_TRACE(rtlpriv, COMP_INIT, DBG_TRACE,
> "Set Network type to STA!\n");
> break;
> case NL80211_IFTYPE_AP:
> - bt_msr |= (MSR_LINK_MASTER << MSR_LINK_SHIFT);
> + mode = MSR_AP;
> + ledaction = LED_CTL_LINK;
> RT_TRACE(rtlpriv, COMP_INIT, DBG_TRACE,
> "Set Network type to AP!\n");
> break;
> @@ -1201,7 +1206,17 @@ static int _rtl92se_set_media_status(struct ieee80211_hw *hw,
>
> }
>
> - rtl_write_byte(rtlpriv, (MSR), bt_msr);
> + /* MSR_INFRA == Link in infrastructure network;
> + * MSR_ADHOC == Link in ad hoc network;
> + * Therefore, check link state is necessary.
> + *
> + * MSR_AP == AP mode; link state is not cared here.
> + */
> + if (mode != MSR_AP && rtlpriv->mac80211.link_state < MAC80211_LINKED) {
> + mode = MSR_NOLINK;
> + ledaction = LED_CTL_NO_LINK;
> +}
> + rtl_write_byte(rtlpriv, (MSR), bt_msr | mode);
>
> temp = rtl_read_dword(rtlpriv, TCR);
> rtl_write_dword(rtlpriv, TCR, temp & (~BIT(8)));
> @@ -1262,6 +1277,7 @@ void rtl92se_enable_interrupt(struct ieee80211_hw *hw)
> rtl_write_dword(rtlpriv, INTA_MASK, rtlpci->irq_mask[0]);
> /* Support Bit 32-37(Assign as Bit 0-5) interrupt setting now */
> rtl_write_dword(rtlpriv, INTA_MASK + 4, rtlpci->irq_mask[1] & 0x3F);
> + rtlpci->irq_enabled = true;
> }
>
> void rtl92se_disable_interrupt(struct ieee80211_hw *hw)
> @@ -1276,8 +1292,7 @@ void rtl92se_disable_interrupt(struct ieee80211_hw *hw)
> rtlpci = rtl_pcidev(rtl_pcipriv(hw));
> rtl_write_dword(rtlpriv, INTA_MASK, 0);
> rtl_write_dword(rtlpriv, INTA_MASK + 4, 0);
> -
> - synchronize_irq(rtlpci->pdev->irq);
> + rtlpci->irq_enabled = false;
> }
>
> static u8 _rtl92s_set_sysclk(struct ieee80211_hw *hw, u8 data)
> @@ -2035,9 +2050,9 @@ static void rtl92se_update_hal_rate_table(struct ieee80211_hw *hw,
> u32 ratr_value;
> u8 ratr_index = 0;
> u8 nmode = mac->ht_enable;
> - u8 mimo_ps = IEEE80211_SMPS_OFF;
> u16 shortgi_rate = 0;
> u32 tmp_ratr_value = 0;
> + u32 ratr_mask;
> u8 curtxbw_40mhz = mac->bw_40;
> u8 curshortgi_40mhz = (sta->ht_cap.cap & IEEE80211_HT_CAP_SGI_40) ?
> 1 : 0;
> @@ -2063,26 +2078,21 @@ static void rtl92se_update_hal_rate_table(struct ieee80211_hw *hw,
> case WIRELESS_MODE_N_24G:
> case WIRELESS_MODE_N_5G:
> nmode = 1;
> - if (mimo_ps == IEEE80211_SMPS_STATIC) {
> - ratr_value &= 0x0007F005;
> - } else {
> - u32 ratr_mask;
>
> - if (get_rf_type(rtlphy) == RF_1T2R ||
> - get_rf_type(rtlphy) == RF_1T1R) {
> - if (curtxbw_40mhz)
> - ratr_mask = 0x000ff015;
> - else
> - ratr_mask = 0x000ff005;
> - } else {
> - if (curtxbw_40mhz)
> - ratr_mask = 0x0f0ff015;
> - else
> - ratr_mask = 0x0f0ff005;
> - }
> -
> - ratr_value &= ratr_mask;
> + if (get_rf_type(rtlphy) == RF_1T2R ||
> + get_rf_type(rtlphy) == RF_1T1R) {
> + if (curtxbw_40mhz)
> + ratr_mask = 0x000ff015;
> + else
> + ratr_mask = 0x000ff005;
> + } else {
> + if (curtxbw_40mhz)
> + ratr_mask = 0x0f0ff015;
> + else
> + ratr_mask = 0x0f0ff005;
> }
> +
> + ratr_value &= ratr_mask;
> break;
> default:
> if (rtlphy->rf_type == RF_1T2R)
> @@ -2137,7 +2147,8 @@ static void rtl92se_update_hal_rate_mask(struct ieee80211_hw *hw,
> struct rtl_sta_info *sta_entry = NULL;
> u32 ratr_bitmap;
> u8 ratr_index = 0;
> - u8 curtxbw_40mhz = (sta->bandwidth >= IEEE80211_STA_RX_BW_40) ? 1 : 0;
> + u8 curtxbw_40mhz = (sta->ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40)
> + ? 1 : 0;
> u8 curshortgi_40mhz = (sta->ht_cap.cap & IEEE80211_HT_CAP_SGI_40) ?
> 1 : 0;
> u8 curshortgi_20mhz = (sta->ht_cap.cap & IEEE80211_HT_CAP_SGI_20) ?
> @@ -2148,9 +2159,7 @@ static void rtl92se_update_hal_rate_mask(struct ieee80211_hw *hw,
> u8 shortgi_rate = 0;
> u32 mask = 0;
> u32 band = 0;
> - bool bmulticast = false;
> u8 macid = 0;
> - u8 mimo_ps = IEEE80211_SMPS_OFF;
>
> sta_entry = (struct rtl_sta_info *) sta->drv_priv;
> wirelessmode = sta_entry->wireless_mode;
> @@ -2198,41 +2207,32 @@ static void rtl92se_update_hal_rate_mask(struct ieee80211_hw *hw,
> band |= (WIRELESS_11N | WIRELESS_11G | WIRELESS_11B);
> ratr_index = RATR_INX_WIRELESS_NGB;
>
> - if (mimo_ps == IEEE80211_SMPS_STATIC) {
> - if (rssi_level == 1)
> - ratr_bitmap &= 0x00070000;
> - else if (rssi_level == 2)
> - ratr_bitmap &= 0x0007f000;
> - else
> - ratr_bitmap &= 0x0007f005;
> + if (rtlphy->rf_type == RF_1T2R ||
> + rtlphy->rf_type == RF_1T1R) {
> + if (rssi_level == 1) {
> + ratr_bitmap &= 0x000f0000;
> + } else if (rssi_level == 3) {
> + ratr_bitmap &= 0x000fc000;
> + } else if (rssi_level == 5) {
> + ratr_bitmap &= 0x000ff000;
> + } else {
> + if (curtxbw_40mhz)
> + ratr_bitmap &= 0x000ff015;
> + else
> + ratr_bitmap &= 0x000ff005;
> + }
> } else {
> - if (rtlphy->rf_type == RF_1T2R ||
> - rtlphy->rf_type == RF_1T1R) {
> - if (rssi_level == 1) {
> - ratr_bitmap &= 0x000f0000;
> - } else if (rssi_level == 3) {
> - ratr_bitmap &= 0x000fc000;
> - } else if (rssi_level == 5) {
> - ratr_bitmap &= 0x000ff000;
> - } else {
> - if (curtxbw_40mhz)
> - ratr_bitmap &= 0x000ff015;
> - else
> - ratr_bitmap &= 0x000ff005;
> - }
> + if (rssi_level == 1) {
> + ratr_bitmap &= 0x0f8f0000;
> + } else if (rssi_level == 3) {
> + ratr_bitmap &= 0x0f8fc000;
> + } else if (rssi_level == 5) {
> + ratr_bitmap &= 0x0f8ff000;
> } else {
> - if (rssi_level == 1) {
> - ratr_bitmap &= 0x0f8f0000;
> - } else if (rssi_level == 3) {
> - ratr_bitmap &= 0x0f8fc000;
> - } else if (rssi_level == 5) {
> - ratr_bitmap &= 0x0f8ff000;
> - } else {
> - if (curtxbw_40mhz)
> - ratr_bitmap &= 0x0f8ff015;
> - else
> - ratr_bitmap &= 0x0f8ff005;
> - }
> + if (curtxbw_40mhz)
> + ratr_bitmap &= 0x0f8ff015;
> + else
> + ratr_bitmap &= 0x0f8ff005;
> }
> }
>
> @@ -2275,15 +2275,12 @@ static void rtl92se_update_hal_rate_mask(struct ieee80211_hw *hw,
> rtl_write_byte(rtlpriv, SG_RATE, shortgi_rate);
> }
>
> - mask |= (bmulticast ? 1 : 0) << 9 | (macid & 0x1f) << 4 | (band & 0xf);
> + mask |= (macid & 0x1f) << 4 | (band & 0xf);
>
> RT_TRACE(rtlpriv, COMP_RATR, DBG_TRACE, "mask = %x, bitmap = %x\n",
> mask, ratr_bitmap);
> rtl_write_dword(rtlpriv, 0x2c4, ratr_bitmap);
> rtl_write_dword(rtlpriv, WFM5, (FW_RA_UPDATE_MASK | (mask << 8)));
> -
> - if (macid != 0)
> - sta_entry->ratr_index = ratr_index;
> }
>
> void rtl92se_update_hal_rate_tbl(struct ieee80211_hw *hw,
> diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/phy.c b/drivers/net/wireless/rtlwifi/rtl8192se/phy.c
> index 77c5b5f..e382cef 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8192se/phy.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8192se/phy.c
> @@ -399,6 +399,11 @@ static bool _rtl92s_phy_sw_chnl_step_by_step(struct ieee80211_hw *hw,
> case 2:
> currentcmd = &postcommoncmd[*step];
> break;
> + default:
> + RT_TRACE(rtlpriv, COMP_ERR, DBG_LOUD,
> + "Invalid 'stage' = %d, Check it!\n",
> + *stage);
> + return true;
> }
>
> if (currentcmd->cmdid == CMDID_END) {
> @@ -602,7 +607,7 @@ bool rtl92s_phy_set_rf_power_state(struct ieee80211_hw *hw,
> }
> case ERFSLEEP:
> if (ppsc->rfpwr_state == ERFOFF)
> - return false;
> + break;
>
> for (queue_id = 0, i = 0;
> queue_id < RTL_PCI_MAX_TX_QUEUE_COUNT;) {
> @@ -1064,7 +1069,6 @@ bool rtl92s_phy_bb_config(struct ieee80211_hw *hw)
> /* Check BB/RF confiuration setting. */
> /* We only need to configure RF which is turned on. */
> path1 = (u8)(rtl92s_phy_query_bb_reg(hw, RFPGA0_TXINFO, 0xf));
> - mdelay(10);
> path2 = (u8)(rtl92s_phy_query_bb_reg(hw, ROFDM0_TRXPATHENABLE, 0xf));
> pathmap = path1 | path2;
>
> diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/sw.c b/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
> index aadba29..3c4238e 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
> @@ -269,6 +269,7 @@ static struct rtl_hal_ops rtl8192se_hal_ops = {
> .led_control = rtl92se_led_control,
> .set_desc = rtl92se_set_desc,
> .get_desc = rtl92se_get_desc,
> + .is_tx_desc_closed = rtl92se_is_tx_desc_closed,
> .tx_polling = rtl92se_tx_polling,
> .enable_hw_sec = rtl92se_enable_hw_security_config,
> .set_key = rtl92se_set_key,
> @@ -278,6 +279,7 @@ static struct rtl_hal_ops rtl8192se_hal_ops = {
> .get_rfreg = rtl92s_phy_query_rf_reg,
> .set_rfreg = rtl92s_phy_set_rf_reg,
> .get_btc_status = rtl_btc_status_false,
> + .rx_command_packet = rtl92se_rx_command_packet,
> };
>
> static struct rtl_mod_params rtl92se_mod_params = {
> @@ -306,6 +308,8 @@ static struct rtl_hal_cfg rtl92se_hal_cfg = {
> .maps[MAC_RCR_ACRC32] = RCR_ACRC32,
> .maps[MAC_RCR_ACF] = RCR_ACF,
> .maps[MAC_RCR_AAP] = RCR_AAP,
> + .maps[MAC_HIMR] = INTA_MASK,
> + .maps[MAC_HIMRE] = INTA_MASK + 4,
>
> .maps[EFUSE_TEST] = REG_EFUSE_TEST,
> .maps[EFUSE_CTRL] = REG_EFUSE_CTRL,
> diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/trx.c b/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
> index 672fd3b..2014b18 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
> @@ -652,8 +652,31 @@ u32 rtl92se_get_desc(u8 *desc, bool istx, u8 desc_name)
> return ret;
> }
>
> +bool rtl92se_is_tx_desc_closed(struct ieee80211_hw *hw, u8 hw_queue, u16 index)
> +{
> + struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
> + struct rtl8192_tx_ring *ring = &rtlpci->tx_ring[hw_queue];
> + u8 *entry = (u8 *)(&ring->desc[ring->idx]);
> + u8 own = (u8)rtl92se_get_desc(entry, true, HW_DESC_OWN);
> +
> + /* beacon packet will only use the first
> + * descriptor iby default, and the own bit may not
> + * be cleared by the hardware
> + */
> + if (own)
> + return false;
> + return true;
> +}
> +
> void rtl92se_tx_polling(struct ieee80211_hw *hw, u8 hw_queue)
> {
> struct rtl_priv *rtlpriv = rtl_priv(hw);
> rtl_write_word(rtlpriv, TP_POLL, BIT(0) << (hw_queue));
> }
> +
> +u32 rtl92se_rx_command_packet(struct ieee80211_hw *hw,
> + struct rtl_stats status,
> + struct sk_buff *skb)
> +{
> + return 0;
> +}
> diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/trx.h b/drivers/net/wireless/rtlwifi/rtl8192se/trx.h
> index 5a13f17..bd9f4bf 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8192se/trx.h
> +++ b/drivers/net/wireless/rtlwifi/rtl8192se/trx.h
> @@ -43,6 +43,10 @@ bool rtl92se_rx_query_desc(struct ieee80211_hw *hw, struct rtl_stats *stats,
> void rtl92se_set_desc(struct ieee80211_hw *hw, u8 *pdesc, bool istx,
> u8 desc_name, u8 *val);
> u32 rtl92se_get_desc(u8 *pdesc, bool istx, u8 desc_name);
> +bool rtl92se_is_tx_desc_closed(struct ieee80211_hw *hw, u8 hw_queue, u16 index);
> void rtl92se_tx_polling(struct ieee80211_hw *hw, u8 hw_queue);
> +u32 rtl92se_rx_command_packet(struct ieee80211_hw *hw,
> + struct rtl_stats status,
> + struct sk_buff *skb);
>
> #endif
> --
> 2.1.2
>
>
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH net] dcbnl : Fix lock initialization
From: Anish Bhatt @ 2014-11-06 20:19 UTC (permalink / raw)
To: John Fastabend
Cc: netdev@vger.kernel.org, davem@davemloft.net,
john.r.fastabend@intel.com, ying.xue@windriver.com,
jeffrey.t.kirsher@intel.com, ebiederm@xmission.com
In-Reply-To: <545BD720.6050008@gmail.com>
Dave,
Please do not apply this patch then.
John,
I will try to recreate this again and investigate. My setup is currently being used for other purposes so might take a few days.
-Anish
________________________________________
From: John Fastabend [john.fastabend@gmail.com]
Sent: Thursday, November 06, 2014 12:16 PM
To: Anish Bhatt
Cc: netdev@vger.kernel.org; davem@davemloft.net; john.r.fastabend@intel.com; ying.xue@windriver.com; jeffrey.t.kirsher@intel.com; ebiederm@xmission.com
Subject: Re: [PATCH net] dcbnl : Fix lock initialization
On 11/06/2014 11:12 AM, Anish Bhatt wrote:
> Yes, without this kernel is complaining about inconsitent lock state
> when lock debugging is enabled. Unfortunately I do not have the trace
> lying around right now.
>
If you have the trace that might help. I can't recall seeing any splats
in these code paths. Also as far as I can tell you shouldn't need to do
an init after the define. There are lots of examples in ./net/core where
this is done.
So we need to sort out why the init resolves the issue.
> If you wish, you can reject this patch, I'll resend it when I get the trace again, with trace included.
> -Anish
> ________________________________________
> From: John Fastabend [john.fastabend@gmail.com]
> Sent: Thursday, November 06, 2014 11:03 AM
> To: Anish Bhatt
> Cc: netdev@vger.kernel.org; davem@davemloft.net; john.r.fastabend@intel.com; ying.xue@windriver.com; jeffrey.t.kirsher@intel.com; ebiederm@xmission.com
> Subject: Re: [PATCH net] dcbnl : Fix lock initialization
>
> On 11/06/2014 10:09 AM, Anish Bhatt wrote:
>> dcb_lock was being used uninitialized in dcbnl and is infact missing
>> initialization code. Fixed
>>
>
> Are you trying to resolve a bug? It is initialized with
>
> static DEFINE_SPINLOCK(dcb_lock);
>
> and if you follow the code far enough you get to this in
> spinlock_types.h:
>
>
> #ifdef CONFIG_DEBUG_SPINLOCK
> # define SPIN_DEBUG_INIT(lockname) \
> .magic = SPINLOCK_MAGIC, \
> .owner_cpu = -1, \
> .owner = SPINLOCK_OWNER_INIT,
> #else
> # define SPIN_DEBUG_INIT(lockname)
> #endif
>
> #define __RAW_SPIN_LOCK_INITIALIZER(lockname) \
> { \
> .raw_lock = __ARCH_SPIN_LOCK_UNLOCKED, \
> SPIN_DEBUG_INIT(lockname) \
> SPIN_DEP_MAP_INIT(lockname) }
>
> [...]
>
>
>
> --
> John Fastabend Intel Corporation
>
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [PATCH 0/2 net-next] sunvnet: bug fixes
From: David Miller @ 2014-11-06 20:17 UTC (permalink / raw)
To: sowmini.varadhan; +Cc: david.stevens, ben, netdev
In-Reply-To: <20141106195054.GD6238@oracle.com>
From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Date: Thu, 6 Nov 2014 14:50:54 -0500
> This patch series has a coding-style fix and a bug fix.
>
> The coding style fix (patch 1) is the extra indentation flagged by
> Ben Hutchings:
> http://marc.info/?l=linux-netdev&m=141529243409594&w=2
>
> The bugfix (patch 2) is the following:
> when vnet_event_napi() is called as part of napi_resume
> (i.e., continuation of a previous NAPI read that was truncated
> due to budget constraints), and then finds no more packets to read,
> the code was trying to avoid an additional trip through ldc_rx
> as an optimization. However, when this corner case happens, we would
> need to reset a number of dring state bits such as rcv_nxt carefully,
> which quickly becomes complex and hacky. The cleaner solution
> is to just roll back to vnet_poll, re-enable interrupts and set up
> dring state as was done in the pre-NAPI version of the driver.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net] dcbnl : Fix lock initialization
From: John Fastabend @ 2014-11-06 20:16 UTC (permalink / raw)
To: Anish Bhatt
Cc: netdev@vger.kernel.org, davem@davemloft.net,
john.r.fastabend@intel.com, ying.xue@windriver.com,
jeffrey.t.kirsher@intel.com, ebiederm@xmission.com
In-Reply-To: <525DB349B3FB5444AE057A887CB2A8D8935DCF@nice.asicdesigners.com>
On 11/06/2014 11:12 AM, Anish Bhatt wrote:
> Yes, without this kernel is complaining about inconsitent lock state
> when lock debugging is enabled. Unfortunately I do not have the trace
> lying around right now.
>
If you have the trace that might help. I can't recall seeing any splats
in these code paths. Also as far as I can tell you shouldn't need to do
an init after the define. There are lots of examples in ./net/core where
this is done.
So we need to sort out why the init resolves the issue.
> If you wish, you can reject this patch, I'll resend it when I get the trace again, with trace included.
> -Anish
> ________________________________________
> From: John Fastabend [john.fastabend@gmail.com]
> Sent: Thursday, November 06, 2014 11:03 AM
> To: Anish Bhatt
> Cc: netdev@vger.kernel.org; davem@davemloft.net; john.r.fastabend@intel.com; ying.xue@windriver.com; jeffrey.t.kirsher@intel.com; ebiederm@xmission.com
> Subject: Re: [PATCH net] dcbnl : Fix lock initialization
>
> On 11/06/2014 10:09 AM, Anish Bhatt wrote:
>> dcb_lock was being used uninitialized in dcbnl and is infact missing
>> initialization code. Fixed
>>
>
> Are you trying to resolve a bug? It is initialized with
>
> static DEFINE_SPINLOCK(dcb_lock);
>
> and if you follow the code far enough you get to this in
> spinlock_types.h:
>
>
> #ifdef CONFIG_DEBUG_SPINLOCK
> # define SPIN_DEBUG_INIT(lockname) \
> .magic = SPINLOCK_MAGIC, \
> .owner_cpu = -1, \
> .owner = SPINLOCK_OWNER_INIT,
> #else
> # define SPIN_DEBUG_INIT(lockname)
> #endif
>
> #define __RAW_SPIN_LOCK_INITIALIZER(lockname) \
> { \
> .raw_lock = __ARCH_SPIN_LOCK_UNLOCKED, \
> SPIN_DEBUG_INIT(lockname) \
> SPIN_DEP_MAP_INIT(lockname) }
>
> [...]
>
>
>
> --
> John Fastabend Intel Corporation
>
--
John Fastabend Intel Corporation
^ 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