* 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: [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 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] 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-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
* 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
* 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
* 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
* 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: 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 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: [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
* [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
* [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 1/2] amd-xgbe: Free channel/ring structures later
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>
The channel structure is freed before freeing the per channel
interrupts resulting in a kernel oops. Move the call to free
the channel structure to after the freeing of the per channel
interrupts.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
index ced9f52..ec5fff3 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
@@ -1369,9 +1369,6 @@ static int xgbe_close(struct net_device *netdev)
/* Free the ring descriptors and buffers */
desc_if->free_ring_resources(pdata);
- /* Free the channel and ring structures */
- xgbe_free_channels(pdata);
-
/* Release the interrupts */
devm_free_irq(pdata->dev, pdata->dev_irq, pdata);
if (pdata->per_channel_irq) {
@@ -1380,6 +1377,9 @@ static int xgbe_close(struct net_device *netdev)
devm_free_irq(pdata->dev, channel->dma_irq, channel);
}
+ /* Free the channel and ring structures */
+ xgbe_free_channels(pdata);
+
/* Disable the clocks */
clk_disable_unprepare(pdata->ptpclk);
clk_disable_unprepare(pdata->sysclk);
^ permalink raw reply related
* Re: [PATCH] rtlwifi: Add more checks for get_btc_status callback
From: Larry Finger @ 2014-11-06 23:30 UTC (permalink / raw)
To: Murilo Opsfelder Araujo, Mike Galbraith
Cc: linux-kernel, linux-wireless, netdev, Chaoming Li,
John W. Linville, Thadeu Cascardo, troy_tan
In-Reply-To: <545BFBB4.3040005@gmail.com>
On 11/06/2014 04:52 PM, Murilo Opsfelder Araujo wrote:
> 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.
I am happy that it is working now; however, if you had done "sudo make install",
the new drivers would have been in the proper directories, and you would not
have gotten the incorrect symbol errors, or need to use the insmod commands that
you post.
Larry
^ permalink raw reply
* Re: [PATCH net-next v1 0/2] amd-xgbe: AMD XGBE driver updates 2014-11-06
From: David Miller @ 2014-11-07 0:00 UTC (permalink / raw)
To: thomas.lendacky; +Cc: netdev
In-Reply-To: <20141106230207.21973.67338.stgit@tlendack-t1.amdoffice.net>
From: Tom Lendacky <thomas.lendacky@amd.com>
Date: Thu, 6 Nov 2014 17:02:07 -0600
> 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.
Series applied, thanks Tom.
^ permalink raw reply
* Re: [PATCH v2 iproute2 4/5] ip link: Add support for remote checksum offload
From: Stephen Hemminger @ 2014-11-07 0:14 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <1415210788-8058-5-git-send-email-therbert@google.com>
On Wed, 5 Nov 2014 10:06:27 -0800
Tom Herbert <therbert@google.com> wrote:
> This patch adds support to remote checksum checksum offload
> confinguration for IPIP, SIT, and GRE tunnels. This patch
> adds a [no]encap-remcsum to ip link command which applicable
> when configured tunnels that use GUE.
>
> http://tools.ietf.org/html/draft-herbert-remotecsumoffload-00
>
> Example:
>
> ip link add name tun1 type gre remote 192.168.1.1 local 192.168.1.2 \
> ttl 225 encap fou encap-sport auto encap-dport 7777 encap-csum \
> encap-remcsum
>
> This would create an GRE tunnel in GUE encapsulation where the source
> port is automatically selected (based on hash of inner packet),
> checksums in the encapsulating UDP header are enabled (needed.for
> remote checksum offload), and remote checksum is configured to
> be used on the tunnel (affects TX side).
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> include/linux/if_tunnel.h | 1 +
This patch is for net-next not current release
Remote checksum offload flag does not exist in upstream tree (net or linus).
Please don't mix patches for current and future releases together.
^ permalink raw reply
* Re: [PATCH v2 iproute2 0/5] iproute2: Add FOU and GUE configuration in ip
From: Stephen Hemminger @ 2014-11-07 0:21 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <1415210788-8058-1-git-send-email-therbert@google.com>
On Wed, 5 Nov 2014 10:06:23 -0800
Tom Herbert <therbert@google.com> wrote:
> This patch set adds support in iproute2 to configure FOU and GUE ports
> for receive, and using FOU or GUE with ip tunnels (IPIP, GRE, sit) on
> transmit.
Applied 1-3 and 5 (ie not part 4) because those are the only ones
that apply to the current linux release.
^ permalink raw reply
* Re: [PATCH v2 iproute2 4/5] ip link: Add support for remote checksum offload
From: Stephen Hemminger @ 2014-11-07 0:41 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <1415210788-8058-5-git-send-email-therbert@google.com>
On Wed, 5 Nov 2014 10:06:27 -0800
Tom Herbert <therbert@google.com> wrote:
> This patch adds support to remote checksum checksum offload
> confinguration for IPIP, SIT, and GRE tunnels. This patch
> adds a [no]encap-remcsum to ip link command which applicable
> when configured tunnels that use GUE.
>
> http://tools.ietf.org/html/draft-herbert-remotecsumoffload-00
>
> Example:
>
> ip link add name tun1 type gre remote 192.168.1.1 local 192.168.1.2 \
> ttl 225 encap fou encap-sport auto encap-dport 7777 encap-csum \
> encap-remcsum
>
> This would create an GRE tunnel in GUE encapsulation where the source
> port is automatically selected (based on hash of inner packet),
> checksums in the encapsulating UDP header are enabled (needed.for
> remote checksum offload), and remote checksum is configured to
> be used on the tunnel (affects TX side).
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> include/linux/if_tunnel.h | 1 +
This patch is for net-next not current release
Remote checksum offload flag does not exist in upstream tree (net or linus).
Please don't mix patches for current and future releases together
^ permalink raw reply
* Re: [linux-nics] [PATCH net 3/5] fm10k: Implement ndo_gso_check()
From: Joe Stringer @ 2014-11-07 0:55 UTC (permalink / raw)
To: Vick, Matthew
Cc: Kirsher, Jeffrey T, Linux NICS, shahed.shaikh, sathya.perla,
Linux Netdev List, Vadai, Linux Kernel, Tom Herbert,
dept-gelinuxnicdev, Or Gerlitz, Amir@isotope.jf.intel.com
In-Reply-To: <D0814A3F.5EA53%matthew.vick@intel.com>
On Thu, Nov 06, 2014 at 11:58:32PM +0000, Vick, Matthew wrote:
> On 11/5/14, 11:36 AM, "Jeff Kirsher" <jeffrey.t.kirsher@intel.com> wrote:
>
> >On Wed, 2014-11-05 at 10:26 -0800, Joe Stringer wrote:
> >> On 5 November 2014 04:47, Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> >>wrote:
> >> >
> >> > On Wed, 2014-11-05 at 14:44 +0200, Or Gerlitz wrote:
> >> > > On Wed, Nov 5, 2014 at 2:34 PM, Jeff Kirsher
> >> > > <jeffrey.t.kirsher@intel.com> wrote:
> >> > > > On Tue, 2014-11-04 at 13:56 -0800, 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(+)
> >> > > >
> >> > > > Thanks Joe, I will add your patch to my queue.
> >> > >
> >> > > Hi Jeff, please see my comment on patch 0/5, we're essentially
> >> > > replicating the same helper four different times (fm10k, mlx4,
> >>benet,
> >> > > qlgc) - I don't see the point in doing so. I asked Joe to come up
> >>with
> >> > > one generic helper and then to pick it up by the four drivers, makes
> >> > > sense?
> >> >
> >> > Yeah, I just saw your reply Or. Ok, I will await an update to Joe's
> >> > series, thanks!
> >>
> >> Thanks Or/Jeff.
> >>
> >> There is also the question in the commit message above, perhaps fm10k
> >> support is a bit different - wasn't sure who to ask regarding that.
> >
> >Matthew Vick is the fm10k maintainer now and can answer any fm10k
> >questions you may have.
>
> Hi Joe, fm10k's hardware is pretty lax about the header size. As long as
> the total header length (outer+inner) is 184 bytes or less we're golden,
> so if I'm not mistaken that leaves us with a max of 130 bytes beyond the
> tunnel header.
Oh, okay. To be more explicit, in the case of UDP tunnels I take it that
you're talking about L2+L3+(L4+)tunnel+L2+L3+L4 <= 184? (L4 perhaps
optional depending on the tunnel protocol used)
In that case, the fm10k_gso_check would use something closer to
"skb_inner_transport_header(skb) - skb_mac_header(skb) > 184", or
perhaps 164 to allow for inner L4 header (?).
Joe
^ permalink raw reply
* Re: [PATCH net 3/5] fm10k: Implement ndo_gso_check()
From: Vick, Matthew @ 2014-11-07 1:07 UTC (permalink / raw)
To: Joe Stringer, alexander.duyck@gmail.com, netdev@vger.kernel.org,
Dept-GELinuxNICDev@qlogic.com, linux-kernel@vger.kernel.org
Cc: sathya.perla@emulex.com, Kirsher, Jeffrey T, Linux NICS,
amirv@mellanox.com, shahed.shaikh@qlogic.com, therbert@google.com
In-Reply-To: <20141106211522.GA55313@gmail.com>
On 11/6/14, 1:15 PM, "Joe Stringer" <joestringer@nicira.com> wrote:
>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;
>+}
It seems like the skb_shinfo(skb)->gso_type check should be in some more
generic ndo_gso_check that drivers can default to/extend. Then, we could
end up with something like
static bool fm10k_gso_check(struct sk_buff *skb, struct net_device *dev)
{
if (skb_gso_check(skb, dev) && !fm10k_tx_encap_offload(skb))
return false;
return true;
}
This could even be simplified and still legible as
static bool fm10k_gso_check(struct sk_buff *skb, struct net_device *dev)
{
return !(skb_gso_check(skb, dev) && !fm10k_tx_encap_offload(skb));
}
What do you think of this approach?
^ permalink raw reply
* Re: [PATCH 1/4] inet: Add skb_copy_datagram_iter
From: Herbert Xu @ 2014-11-07 1:58 UTC (permalink / raw)
To: Al Viro; +Cc: David Miller, netdev, linux-kernel, bcrl, YOSHIFUJI Hideaki
In-Reply-To: <20141106173012.GY7996@ZenIV.linux.org.uk>
On Thu, Nov 06, 2014 at 05:30:12PM +0000, Al Viro wrote:
> On Thu, Nov 06, 2014 at 04:28:18PM +0800, Herbert Xu wrote:
> > + if (copy_to_iter(skb->data + offset, copy, to))
> > + goto fault;
>
> Sorry, no - copy_to_iter() returns the number of bytes copied, not 0 or -EFAULT.
>
> > + vaddr = kmap(page);
> > + err = copy_to_iter(vaddr + frag->page_offset +
> > + offset - start, copy, to);
> > + kunmap(page);
> > + if (err)
> > + goto fault;
>
> And that one should be
> copied = copy_page_to_iter(page, frag->page_offset +
> offset - start, copy, to);
> if (copied != copy)
> goto fault;
>
> Don't bother with kmap(), vaddr and all that shite. The primitive is
> copy_page_to_iter(page, offset_in_page, nbytes, iter)
> it does all needed kmap itself and it's smart enough to use kmap_atomic
> when it can get away with that. Similar for copy_page_from_iter().
>
> Both of those (as well as copy_{to,from}_iter()) advance iov_iter and return
> the number of bytes actually copied. So the check for EFAULT is "it has copied
> less than you've asked it to copy *and* you haven't run out that iov_iter".
> The second part is guaranteed to be true in this case - your code makes sure
> that 'copy' is no more than the space left in iterator.
>
> In general, this check would be spelled
> if (copied != copy && iov_iter_count(to))
> goto fault;
Thanks, I'll redo the patches.
--
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
* kernel panic receiving flooded VXLAN traffic with OVS
From: Jay Vosburgh @ 2014-11-07 1:58 UTC (permalink / raw)
To: netdev, discuss
I am able to reproduce a kernel panic on an system using
openvswitch when receiving VXLAN traffic under a very specific set of
circumstances. This occurs with a recent net-next as well as an Ubuntu
3.13 kernel. I'm not sure if the error lies in OVS, GRO, or elsewhere.
In summary, when the system receives multiple VXLAN encapsulated
TCP segments for a different system (not intended for local reception)
that are from the middle of an active connection (received due to a switch
flood), and are tagged to a VLAN not configured on the local host, then
the system panics in skb_segment when OVS calls __skb_gso_segment on the
GRO skb prior to performing an upcall to user space.
The panic occurs in skbuff.c:skb_segment(), at the BUG_ON around
line 3036:
struct sk_buff *skb_segment(struct sk_buff *head_skb,
netdev_features_t features)
{
[...]
skb_shinfo(nskb)->tx_flags = skb_shinfo(head_skb)->tx_flags &
SKBTX_SHARED_FRAG;
while (pos < offset + len) {
if (i >= nfrags) {
BUG_ON(skb_headlen(list_skb));
i = 0;
The BUG_ON triggers because the skbs that have been GRO
accumulated are partially or entirely linear, depending upon the receiving
network device (sky2 is partial, enic is entire). The receive buffers end
up being linear evidently because the mtu is set to 9000, and
__netdev_alloc_skb calls __alloc_skb (and thus kmalloc) instead of
__netdev_alloc_frag followed by build_skb.
The foreign-VLAN VXLAN TCP segments are not processed as normal
VXLAN traffic, as there is no listener on the VLAN in question, so once
GRO processes them, they are sent directly to ovs_vport_receive. The
panic stack appears as follows:
[ 6558.812214] kernel BUG at net/core/skbuff.c:3025!
[ 6558.812214] invalid opcode: 0000 [#1] SMP
[ 6558.812214] Modules linked in: veth 8021q garp mrp bonding xt_tcpudp bridge stp llc iptable_filter ip_tables x_tables openvswitch vxlan ip6_udp_tunnel udp_tunnel gre libcrc32c i915 video drm_kms_helper coretemp drm kvm_intel kvm gpio_ich ppdev parport_pc lp lpc_ich serio_raw i2c_algo_bit parport mac_hid hid_generic usbhid hid psmouse r8169 mii sky2
[ 6558.812214] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 3.17.0-rc7-testola+ #5
[ 6558.812214] Hardware name: LENOVO 0829F3U/To be filled by O.E.M., BIOS 90KT15AUS 07/21/2010
[ 6558.812214] task: ffff880139eb3200 ti: ffff880139ed0000 task.ti: ffff880139ed0000
[ 6558.812214] RIP: 0010:[<ffffffff81616bc2>] [<ffffffff81616bc2>] skb_segment+0x9d2/0xa00
[ 6558.812214] RSP: 0018:ffff880139ed3610 EFLAGS: 00010216
[ 6558.812214] RAX: 00000000000002dc RBX: ffff8800a3be5e00 RCX: ffff8800b10a26f0
[ 6558.812214] RDX: 0000000000000074 RSI: ffff8800b10a2600 RDI: ffff8800b10a2000
[ 6558.812214] RBP: ffff880139ed36e0 R08: 0000000000000022 R09: 0000000000000000
[ 6558.812214] R10: ffff8800b11e6000 R11: 00000000000005ca R12: ffff8800b10a20f0
[ 6558.812214] R13: 0000000000000000 R14: ffff8800b116cb00 R15: 0000000000000074
[ 6558.812214] FS: 0000000000000000(0000) GS:ffff88013fc00000(0000) knlGS:0000000000000000
[ 6558.812214] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 6558.812214] CR2: 00007fa906f4f148 CR3: 00000000b2a46000 CR4: 00000000000407f0
[ 6558.812214] Stack:
[ 6558.812214] 00000000000016a0 ffff880031353800 ffffffffffffffde ffff8800000005ca
[ 6558.812214] 0000000000000022 0000000000000040 ffff8800b11e6000 00000001000016a0
[ 6558.812214] 0000000000000000 0000000000000022 00000000000005a8 ffff8800a3be5e00
[ 6558.812214] Call Trace:
[ 6558.812214] [<ffffffff8168c97f>] udp4_ufo_fragment+0x10f/0x1a0
[ 6558.812214] [<ffffffff81695c51>] inet_gso_segment+0x141/0x370
[ 6558.812214] [<ffffffff810aa2c8>] ? __wake_up_common+0x58/0x90
[ 6558.812214] [<ffffffff81624f4f>] skb_mac_gso_segment+0x9f/0x100
[ 6558.812214] [<ffffffff81625016>] __skb_gso_segment+0x66/0xd0
[ 6558.812214] [<ffffffffa01d4c91>] queue_gso_packets+0x41/0x130 [openvswitch]
[ 6558.812214] [<ffffffff8121aa4d>] ? ep_poll_safewake+0x2d/0x30
[ 6558.812214] [<ffffffff8121b03d>] ? ep_poll_callback+0xcd/0x170
[ 6558.812214] [<ffffffff810aa2c8>] ? __wake_up_common+0x58/0x90
[ 6558.812214] [<ffffffff810aa860>] ? __wake_up_sync_key+0x50/0x60
[ 6558.812214] [<ffffffff8161c232>] ? __skb_flow_dissect+0x162/0x4c0
[ 6558.812214] [<ffffffff8172001f>] ? __slab_free+0xfe/0x2c3
[ 6558.812214] [<ffffffff816107af>] ? kfree_skbmem+0x3f/0xa0
[ 6558.812214] [<ffffffff8161c5ba>] ? __skb_get_hash+0x2a/0x160
[ 6558.812214] [<ffffffffa01d609e>] ovs_dp_upcall+0x2e/0x70 [openvswitch]
[ 6558.812214] [<ffffffffa01d6193>] ovs_dp_process_packet+0xb3/0xd0 [openvswitch]
[ 6558.812214] [<ffffffffa01dc860>] ovs_vport_receive+0x60/0x80 [openvswitch]
[ 6558.812214] [<ffffffff811828f1>] ? zone_statistics+0x81/0xa0
[ 6558.812214] [<ffffffff81617819>] ? skb_gro_receive+0x559/0x5f0
[ 6558.812214] [<ffffffff81695ada>] ? inet_gro_receive+0x1da/0x210
[ 6558.812214] [<ffffffffa01dd10a>] netdev_frame_hook+0xca/0x130 [openvswitch]
[ 6558.812214] [<ffffffff816233aa>] __netif_receive_skb_core+0x1ba/0x7a0
[ 6558.812214] [<ffffffff816239a8>] __netif_receive_skb+0x18/0x60
[ 6558.812214] [<ffffffff81623a13>] netif_receive_skb_internal+0x23/0x90
[ 6558.812214] [<ffffffff8168cefa>] ? udp4_gro_complete+0x6a/0x70
[ 6558.812214] [<ffffffff81623b94>] napi_gro_complete+0xa4/0xe0
[ 6558.812214] [<ffffffff81623c3d>] napi_gro_flush+0x6d/0x90
[ 6558.812214] [<ffffffff81623c7e>] napi_complete+0x1e/0x50
[ 6558.812214] [<ffffffffa0006538>] sky2_poll+0xa38/0xd80 [sky2]
[ 6558.812214] [<ffffffff81623e02>] net_rx_action+0x152/0x250
[ 6558.812214] [<ffffffff81070aa5>] __do_softirq+0xf5/0x2e0
[ 6558.812214] [<ffffffff81070cc0>] run_ksoftirqd+0x30/0x50
[ 6558.812214] [<ffffffff8108e0ff>] smpboot_thread_fn+0xff/0x1b0
[ 6558.812214] [<ffffffff8108e000>] ? SyS_setgroups+0x1a0/0x1a0
[ 6558.812214] [<ffffffff8108a5a2>] kthread+0xd2/0xf0
[ 6558.812214] [<ffffffff8108a4d0>] ? kthread_create_on_node+0x180/0x180
[ 6558.812214] [<ffffffff81729e3c>] ret_from_fork+0x7c/0xb0
[ 6558.812214] [<ffffffff8108a4d0>] ? kthread_create_on_node+0x180/0x180
[ 6558.812214] Code: 8b 44 24 70 44 8b 4c 24 30 44 8b 5c 24 18 8b 54 24 08 48 8b 0c 24 0f 85 0f fd ff ff e9 06 fd ff ff 0f 1f 84 00 00 00 00 00 0f 0b <0f> 0b 0f 0b c6 44 24 3b 01 e9 28 f7 ff ff e8 76 db 10 00 0f 0b
[ 6558.812214] RIP [<ffffffff81616bc2>] skb_segment+0x9d2/0xa00
[ 6558.812214] RSP <ffff880139ed3610>
I'm not sure if this is an error on the part of the RX / GRO
processing in assembling the GRO skb, or in how OVS calls skb_segment.
-J
---
-Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* Re: [PATCH 1/4] inet: Add skb_copy_datagram_iter
From: Herbert Xu @ 2014-11-07 1:59 UTC (permalink / raw)
To: David Miller; +Cc: viro, netdev, linux-kernel, bcrl
In-Reply-To: <20141106.122500.4643339498907490.davem@davemloft.net>
On Thu, Nov 06, 2014 at 12:25:00PM -0500, David Miller wrote:
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Thu, 6 Nov 2014 16:23:38 +0800
>
> > On Wed, Nov 05, 2014 at 03:24:10PM -0500, David Miller wrote:
> >>
> >> Herbert, please provide a cover letter for this series, and the most recent
> >> version of patch #2 gets various rejects when I try to apply it to net-next.
> >
> > Sure, I'll regenerate them. However, while doing so I noticed that
> > a number of my patches on tun/macvtap that you have previously set
> > as accepted are missing from net-next. Could this be why you got
> > the rejects?
>
> Those were bug fixes so went into plain 'net', they will show up next
> time I do a merge and I will deal with the conflicts, if any.
I see. In that case it might be best to wait until those fixes hit
net-next first before applying these patches as otherwise Stephen will
get hit with some nasty merge conflicts.
I'll repost them for RFC with the problems that Al pointed out fixed
in the mean time.
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
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