* [PATCH v4 5/8] net: can: c_can: Add support for START pulse in RAMINIT sequence
From: Roger Quadros @ 2014-11-07 14:49 UTC (permalink / raw)
To: wg, mkl
Cc: wsa, tony, tglx, mugunthanvnm, george.cherian, balbi, nsekhar, nm,
sergei.shtylyov, linux-omap, linux-can, netdev, Roger Quadros
In-Reply-To: <1415371762-29885-1-git-send-email-rogerq@ti.com>
Some SoCs e.g. (TI DRA7xx) need a START pulse to start the
RAMINIT sequence i.e. START bit must be set and cleared before
checking for the DONE bit status.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/net/can/c_can/c_can.h | 1 +
drivers/net/can/c_can/c_can_platform.c | 7 +++++++
2 files changed, 8 insertions(+)
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index 0e17c7b..c6715ca 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -185,6 +185,7 @@ struct c_can_raminit {
unsigned int reg; /* register index within syscon */
u8 start_bit;
u8 done_bit;
+ bool needs_pulse;
};
/* c_can private data structure */
diff --git a/drivers/net/can/c_can/c_can_platform.c b/drivers/net/can/c_can/c_can_platform.c
index 3776483..b838c6b 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -124,6 +124,12 @@ static void c_can_hw_raminit_syscon(const struct c_can_priv *priv, bool enable)
ctrl |= 1 << start_bit;
regmap_write(raminit->syscon, raminit->reg, ctrl);
+ /* clear START bit if start pulse is needed */
+ if (raminit->needs_pulse) {
+ ctrl &= ~(1 << start_bit);
+ regmap_write(raminit->syscon, raminit->reg, ctrl);
+ }
+
ctrl |= 1 << done_bit;
c_can_hw_raminit_wait_syscon(priv, mask, ctrl);
}
@@ -330,6 +336,7 @@ static int c_can_plat_probe(struct platform_device *pdev)
raminit->start_bit = drvdata->raminit_start_bits[id];
raminit->done_bit = drvdata->raminit_done_bits[id];
+ raminit->needs_pulse = drvdata->raminit_pulse;
priv->raminit = c_can_hw_raminit_syscon;
} else {
--
1.8.3.2
^ permalink raw reply related
* [PATCH v4 7/8] net: can: c_can: Add support for TI DRA7 DCAN
From: Roger Quadros @ 2014-11-07 14:49 UTC (permalink / raw)
To: wg, mkl
Cc: wsa, tony, tglx, mugunthanvnm, george.cherian, balbi, nsekhar, nm,
sergei.shtylyov, linux-omap, linux-can, netdev, Roger Quadros
In-Reply-To: <1415371762-29885-1-git-send-email-rogerq@ti.com>
DRA7 SoC has 2 CAN IPs. Provide compatible IDs and RAMINIT
register data for both.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
Documentation/devicetree/bindings/net/can/c_can.txt | 1 +
drivers/net/can/c_can/c_can_platform.c | 11 +++++++++++
2 files changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt b/Documentation/devicetree/bindings/net/can/c_can.txt
index a3ca3ee..f682fdb 100644
--- a/Documentation/devicetree/bindings/net/can/c_can.txt
+++ b/Documentation/devicetree/bindings/net/can/c_can.txt
@@ -4,6 +4,7 @@ Bosch C_CAN/D_CAN controller Device Tree Bindings
Required properties:
- compatible : Should be "bosch,c_can" for C_CAN controllers and
"bosch,d_can" for D_CAN controllers.
+ Can be "ti,dra7-d_can".
- reg : physical base address and size of the C_CAN/D_CAN
registers map
- interrupts : property with a value describing the interrupt
diff --git a/drivers/net/can/c_can/c_can_platform.c b/drivers/net/can/c_can/c_can_platform.c
index 71b9063..7a81db4 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -195,6 +195,16 @@ static struct c_can_driver_data d_can_drvdata = {
.id = BOSCH_D_CAN,
};
+static u8 dra7_raminit_start_bits[] = {3, 5};
+static u8 dra7_raminit_done_bits[] = {1, 2};
+static struct c_can_driver_data dra7_dcan_drvdata = {
+ .id = BOSCH_D_CAN,
+ .num_can = 2,
+ .raminit_start_bits = dra7_raminit_start_bits,
+ .raminit_done_bits = dra7_raminit_done_bits,
+ .raminit_pulse = true,
+};
+
static struct platform_device_id c_can_id_table[] = {
{
.name = KBUILD_MODNAME,
@@ -215,6 +225,7 @@ MODULE_DEVICE_TABLE(platform, c_can_id_table);
static const struct of_device_id c_can_of_table[] = {
{ .compatible = "bosch,c_can", .data = &c_can_drvdata },
{ .compatible = "bosch,d_can", .data = &d_can_drvdata },
+ { .compatible = "ti,dra7-d_can", .data = &dra7_dcan_drvdata },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, c_can_of_table);
--
1.8.3.2
^ permalink raw reply related
* [PATCH v4 8/8] net: can: c_can: Add support for TI am3352 DCAN
From: Roger Quadros @ 2014-11-07 14:49 UTC (permalink / raw)
To: wg, mkl
Cc: wsa, tony, tglx, mugunthanvnm, george.cherian, balbi, nsekhar, nm,
sergei.shtylyov, linux-omap, linux-can, netdev, Roger Quadros
In-Reply-To: <1415371762-29885-1-git-send-email-rogerq@ti.com>
AM3352 SoC has 2 DCAN modules. Add compatible id and
raminit driver data for am3352 DCAN.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
Documentation/devicetree/bindings/net/can/c_can.txt | 2 +-
drivers/net/can/c_can/c_can_platform.c | 10 ++++++++++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt b/Documentation/devicetree/bindings/net/can/c_can.txt
index f682fdb..6731730 100644
--- a/Documentation/devicetree/bindings/net/can/c_can.txt
+++ b/Documentation/devicetree/bindings/net/can/c_can.txt
@@ -4,7 +4,7 @@ Bosch C_CAN/D_CAN controller Device Tree Bindings
Required properties:
- compatible : Should be "bosch,c_can" for C_CAN controllers and
"bosch,d_can" for D_CAN controllers.
- Can be "ti,dra7-d_can".
+ Can be "ti,dra7-d_can" or "ti,am3352-d_can".
- reg : physical base address and size of the C_CAN/D_CAN
registers map
- interrupts : property with a value describing the interrupt
diff --git a/drivers/net/can/c_can/c_can_platform.c b/drivers/net/can/c_can/c_can_platform.c
index 7a81db4..eb09068 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -205,6 +205,15 @@ static struct c_can_driver_data dra7_dcan_drvdata = {
.raminit_pulse = true,
};
+static u8 am3352_raminit_start_bits[] = {0, 1};
+static u8 am3352_raminit_done_bits[] = {8, 9};
+static struct c_can_driver_data am3352_dcan_drvdata = {
+ .id = BOSCH_D_CAN,
+ .num_can = 2,
+ .raminit_start_bits = am3352_raminit_start_bits,
+ .raminit_done_bits = am3352_raminit_done_bits,
+};
+
static struct platform_device_id c_can_id_table[] = {
{
.name = KBUILD_MODNAME,
@@ -226,6 +235,7 @@ static const struct of_device_id c_can_of_table[] = {
{ .compatible = "bosch,c_can", .data = &c_can_drvdata },
{ .compatible = "bosch,d_can", .data = &d_can_drvdata },
{ .compatible = "ti,dra7-d_can", .data = &dra7_dcan_drvdata },
+ { .compatible = "ti,am3352-d_can", .data = &am3352_dcan_drvdata },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, c_can_of_table);
--
1.8.3.2
^ permalink raw reply related
* Re: [Xen-devel] BUG in xennet_make_frags with paged skb data
From: Zoltan Kiss @ 2014-11-07 14:51 UTC (permalink / raw)
To: Stefan Bader, David Vrabel, netdev, David S. Miller,
Konrad Rzeszutek Wilk, Boris Ostrovsky, Jay Vosburgh,
linux-kernel, xen-devel
In-Reply-To: <545CA823.2080307@canonical.com>
Hi,
On 07/11/14 11:08, Stefan Bader wrote:
> On 07.11.2014 11:44, David Vrabel wrote:
>> On 06/11/14 21:49, Seth Forshee wrote:
>>> 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.
>>
>> netfront will safely handle this case so you can remove this BUG_ON()
>> (and the one later on). But it would be better to find out were these
>> funny-looking skbs are coming from and (if necessary) fixing the bug there.
>
> Right, in fact it does ignore pages from the start of a compound page in case
> the offset is big enough. So there is no difference between that case and the
> one where the page pointer from the frag is adjusted the way it was observed.
>
> It really boils down to the question what the real rules for the frags are. If
> it is "only" that data may not cross the boundary of a hw or compound page this
> leaves room for interpretation. The odd skb does not violate that but a check
> for conformance would become a lot more complex. And netfront is not the only
> place that expects the frag page to be pointing to the compound head (there is
> igb for example, though it does only a warn_on upon failing).
>
> On the other hand the __skb_fill_page_desc is written in a way that seems to
> assume the frag page pointer may be pointing to a tail page. So before "blaming"
> one piece of code or the other we need an authoritative answer to what we are
> supposed to expect.
Looking at skb_copy_bits and kmap_atomic it looks confusing indeed. It
seems kmap_atomic maps only the actual page, not the whole compound, and
it doesn't matter whether you gave a head or a tail page to it.
Therefore if skb_copy_bits comes over a frag where the buffer exceeds
the page the pointer points to, it shouldn't work.
This raises a few question in me:
- I assume frags are allowed to have compound pages, where page.p points
to the head, and the buffer can be anywhere in the compound, e.g. offset
= 9000 and len = 4000 is allowed (if the compound is more than four 4k
pages, of course). Is this assumption correct?
- Is it then allowed to have page.p pointed to a tail page of the
compound? To use the above example: page.p points to the third page, and
offset is 808. Or pointer points to the second page, and offset is 4904.
(the answer to the above two question should be documented somewhere, or
codified)
- how does it works with skb_copy_bits? kmap_atomic seems to map only
the actual page, not the whole compound.
Zoli
^ permalink raw reply
* [PATCH v2] stmmac: remove custom implementation of print_hex_dump()
From: Andy Shevchenko @ 2014-11-07 14:53 UTC (permalink / raw)
To: Joe Perches, Giuseppe Cavallaro, netdev, David S . Miller,
Vince Bridgers
Cc: Andy Shevchenko
There is a kernel helper to dump buffers in a hexdecimal format. This patch
substitutes the open coded function by calling that helper.
The output is slightly changed:
- no lead space
- ASCII part will be printed along with the dump
- offset is longer than 3 characters (now 8)
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
Since v1:
- address Joe's comments
- describe output change
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index fa598b9..53db11b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -191,14 +191,8 @@ static void stmmac_clk_csr_set(struct stmmac_priv *priv)
static void print_pkt(unsigned char *buf, int len)
{
- int j;
- pr_debug("len = %d byte, buf addr: 0x%p", len, buf);
- for (j = 0; j < len; j++) {
- if ((j % 16) == 0)
- pr_debug("\n %03x:", j);
- pr_debug(" %02x", buf[j]);
- }
- pr_debug("\n");
+ pr_debug("len = %d byte, buf addr: 0x%p\n", len, buf);
+ print_hex_dump_bytes("", DUMP_PREFIX_OFFSET, buf, len);
}
/* minimum number of free TX descriptors required to wake up TX process */
--
2.1.3
^ permalink raw reply related
* Re: [PATCH v4 6/8] net: can: c_can: Disable pins when CAN interface is down
From: Marc Kleine-Budde @ 2014-11-07 14:54 UTC (permalink / raw)
To: Roger Quadros, wg
Cc: wsa, tony, tglx, mugunthanvnm, george.cherian, balbi, nsekhar, nm,
sergei.shtylyov, linux-omap, linux-can, netdev
In-Reply-To: <1415371762-29885-7-git-send-email-rogerq@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1817 bytes --]
On 11/07/2014 03:49 PM, Roger Quadros wrote:
> DRA7 CAN IP suffers from a problem which causes it to be prevented
> from fully turning OFF (i.e. stuck in transition) if the module was
> disabled while there was traffic on the CAN_RX line.
>
> To work around this issue we select the SLEEP pin state by default
> on probe and use the DEFAULT pin state on CAN up and back to the
> SLEEP pin state on CAN down.
>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
> drivers/net/can/c_can/c_can.c | 20 ++++++++++++++++++++
> drivers/net/can/c_can/c_can.h | 1 +
> drivers/net/can/c_can/c_can_platform.c | 20 ++++++++++++++++++++
> 3 files changed, 41 insertions(+)
>
> diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
> index 8e78bb4..4dfc3ce 100644
> --- a/drivers/net/can/c_can/c_can.c
> +++ b/drivers/net/can/c_can/c_can.c
> @@ -35,6 +35,7 @@
> #include <linux/list.h>
> #include <linux/io.h>
> #include <linux/pm_runtime.h>
> +#include <linux/pinctrl/consumer.h>
>
> #include <linux/can.h>
> #include <linux/can/dev.h>
> @@ -603,6 +604,15 @@ static int c_can_start(struct net_device *dev)
>
> priv->can.state = CAN_STATE_ERROR_ACTIVE;
>
> + /* activate pins */
> + if (!IS_ERR(priv->pinctrl)) {
> + struct pinctrl_state *s;
> +
> + s = pinctrl_lookup_state(priv->pinctrl, PINCTRL_STATE_DEFAULT);
> + if (!IS_ERR(s))
> + pinctrl_select_state(priv->pinctrl, s);
> + }
Please put this common code into a seperate function.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [REGRESSION] in 3.18-rc1: ppp crashes kernel
From: Stefan Seyfried @ 2014-11-07 15:08 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Paul Mackerras, linux-ppp, netdev, LKML
In-Reply-To: <s5hioirqh6m.wl-tiwai@suse.de>
Hi Takashi,
yes, this no longer crashes. No real-world test yet, but the obvious
crash is gone. Thanks!
Am 07.11.2014 um 14:22 schrieb Takashi Iwai:
> At Fri, 07 Nov 2014 12:10:46 +0100,
> Stefan Seyfried wrote:
>>
>> Hi all,
>>
>> since 3.18-rc1, setting up a PPP interface kills my kernel with
>>
>> [ 163.433251] PPP generic driver version 2.4.2
>> [ 164.452474] ------------[ cut here ]------------
>> [ 164.453327] kernel BUG at ../mm/vmalloc.c:1316!
>> [ 164.453327] invalid opcode: 0000 [#1] PREEMPT SMP
>> [ 164.453327] Modules linked in: ppp_async crc_ccitt ppp_generic slhc af_packet xfs libcrc32c coretemp kvm_intel
>> snd_hda_codec_conexant iTCO_wdt snd_hda_codec_generic iTCO_vendor_support uvcvideo snd_hda_intel snd_hda_controller mac80211 videobuf2_vmalloc snd_hda_codec kvm e1000e videobuf2_memops cfg80211 videobuf2_core v4l2_common snd_hwdep i2c_i801 videodev snd_pcm pcspkr thinkpad_acpi serio_raw wmi lpc_ich snd_timer thermal snd rfkill mfd_core tpm_tis shpchp mei_me soundcore ptp mei pps_core acpi_cpufreq tpm battery processor ac dm_mod btrfs xor raid6_pq i915 i2c_algo_bit drm_kms_helper drm video button sg
>> [ 164.453327] CPU: 0 PID: 6927 Comm: pppd Not tainted 3.18.0-rc3-3.ge706e91-desktop #1
>> [ 164.453327] Hardware name: LENOVO 7470E36/7470E36, BIOS 6DET61WW (3.11 ) 11/10/2009
>>
>> This is easy to reproduce with:
>>
>> linux:~ # cat bin/crashme.sh
>> ----
>> #!/bin/bash -x
>> pppd local pty "netcat -l 1234" &
>> sleep 1
>> pppd local pty "netcat localhost 1234" &
>> sleep 1
>> ----
>>
>> 3.17 works fine.
>> I bisected the issue multiple times and always arrived at
>>
>> # first bad commit: [d6dd50e07c5bec00db2005969b1a01f8ca3d25ef] Merge branch 'core-rcu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>>
>> which is a merge commit unfortunately.
>>
>> The BUG encountered above is in:
>>
>> 1309 static struct vm_struct *__get_vm_area_node(unsigned long size,
>> 1310 unsigned long align, unsigned long flags, unsigned long start,
>> 1311 unsigned long end, int node, gfp_t gfp_mask, const void *caller)
>> 1312 {
>> 1313 struct vmap_area *va;
>> 1314 struct vm_struct *area;
>> 1315
>> 1316 BUG_ON(in_interrupt());
>> 1317 if (flags & VM_IOREMAP)
>> 1318 align = 1ul << clamp(fls(size), PAGE_SHIFT, IOREMAP_MAX_ORDER);
>> 1319
>>
>> the call trace is:
>> [ 164.453327] Call Trace:
>> [ 164.453327] [<ffffffff811974bd>] __vmalloc_node_range+0x6d/0x290
>> [ 164.453327] [<ffffffff8119771e>] __vmalloc+0x3e/0x50
>> [ 164.453327] [<ffffffff81146950>] bpf_prog_alloc+0x30/0xa0
>> [ 164.453327] [<ffffffff8157b716>] bpf_prog_create+0x46/0xb0
>> [ 164.453327] [<ffffffffa07ecb90>] ppp_ioctl+0x420/0xe9a [ppp_generic]
>> [ 164.453327] [<ffffffff811df1c7>] do_vfs_ioctl+0x2e7/0x4c0
>> [ 164.453327] [<ffffffff811df421>] SyS_ioctl+0x81/0xa0
>> [ 164.453327] [<ffffffff8165ee2d>] system_call_fastpath+0x16/0x1b
>> [ 164.453327] [<00007f4502d87397>] 0x7f4502d87397
>
> bpf_prog_create() is called inside spin_lock_bh(), and the BUG_ON()
> hits. Below is a quick fix.
>
>
> Takashi
>
> -- 8< --
> From: Takashi Iwai <tiwai@suse.de>
> Subject: [PATCH] net: ppp: Don't call bpf_prog_create() in ppp_lock
>
> In ppp_ioctl(), bpf_prog_create() is called inside ppp_lock, which
> eventually calls vmalloc() and hits BUG_ON() in vmalloc.c. This patch
> works around the problem by moving the allocation outside the lock.
>
> Reported-by: Stefan Seyfried <stefan.seyfried@googlemail.com>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
FWIW :-)
Tested-by: Stefan Seyfried <stefan.seyfried@googlemail.com>
> ---
> drivers/net/ppp/ppp_generic.c | 40 ++++++++++++++++++++--------------------
> 1 file changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
> index 68c3a3f4e0ab..794a47329368 100644
> --- a/drivers/net/ppp/ppp_generic.c
> +++ b/drivers/net/ppp/ppp_generic.c
> @@ -755,23 +755,23 @@ static long ppp_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
>
> err = get_filter(argp, &code);
> if (err >= 0) {
> + struct bpf_prog *pass_filter = NULL;
> struct sock_fprog_kern fprog = {
> .len = err,
> .filter = code,
> };
>
> - ppp_lock(ppp);
> - if (ppp->pass_filter) {
> - bpf_prog_destroy(ppp->pass_filter);
> - ppp->pass_filter = NULL;
> + err = 0;
> + if (fprog.filter)
> + err = bpf_prog_create(&pass_filter, &fprog);
> + if (!err) {
> + ppp_lock(ppp);
> + if (ppp->pass_filter)
> + bpf_prog_destroy(ppp->pass_filter);
> + ppp->pass_filter = pass_filter;
> + ppp_unlock(ppp);
> }
> - if (fprog.filter != NULL)
> - err = bpf_prog_create(&ppp->pass_filter,
> - &fprog);
> - else
> - err = 0;
> kfree(code);
> - ppp_unlock(ppp);
> }
> break;
> }
> @@ -781,23 +781,23 @@ static long ppp_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
>
> err = get_filter(argp, &code);
> if (err >= 0) {
> + struct bpf_prog *active_filter = NULL;
> struct sock_fprog_kern fprog = {
> .len = err,
> .filter = code,
> };
>
> - ppp_lock(ppp);
> - if (ppp->active_filter) {
> - bpf_prog_destroy(ppp->active_filter);
> - ppp->active_filter = NULL;
> + err = 0;
> + if (fprog.filter)
> + err = bpf_prog_create(&active_filter, &fprog);
> + if (!err) {
> + ppp_lock(ppp);
> + if (ppp->active_filter)
> + bpf_prog_destroy(ppp->active_filter);
> + ppp->active_filter = active_filter;
> + ppp_unlock(ppp);
> }
> - if (fprog.filter != NULL)
> - err = bpf_prog_create(&ppp->active_filter,
> - &fprog);
> - else
> - err = 0;
> kfree(code);
> - ppp_unlock(ppp);
> }
> break;
> }
>
--
Stefan Seyfried
Linux Consultant & Developer -- GPG Key: 0x731B665B
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
^ permalink raw reply
* Re: [PATCH 3/3 3.18] rtlwifi: rtl8192se: Fix connection problems
From: John W. Linville @ 2014-11-07 15:19 UTC (permalink / raw)
To: Larry Finger
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <545BFA52.6000309-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
On Thu, Nov 06, 2014 at 04:46:42PM -0600, Larry Finger wrote:
> 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-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?
>
> 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.
That sounds better, at least. :-) Thanks, Larry!
John
--
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
* [PATCH V2 3.18] rtlwifi: rtl8192se: Fix connection problems
From: Larry Finger @ 2014-11-07 16:05 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, troy_tan, Larry Finger, netdev
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 fix the basic functionality.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
V2 - As requested by John Linville, the patch was reduced to its bare essentials
as the first version was too large to be a fix.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
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(-)
diff --git a/drivers/net/wireless/rtlwifi/pci.c b/drivers/net/wireless/rtlwifi/pci.c
index 25daa87..2487eee 100644
--- a/drivers/net/wireless/rtlwifi/pci.c
+++ b/drivers/net/wireless/rtlwifi/pci.c
@@ -842,7 +842,8 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
break;
}
/* handle command packet here */
- if (rtlpriv->cfg->ops->rx_command_packet(hw, stats, skb)) {
+ if (rtlpriv->cfg->ops->rx_command_packet &&
+ rtlpriv->cfg->ops->rx_command_packet(hw, stats, skb)) {
dev_kfree_skb_any(skb);
goto end;
}
diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/hw.c b/drivers/net/wireless/rtlwifi/rtl8192se/hw.c
index 00e0670..5761d5b 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/hw.c
@@ -1201,6 +1201,9 @@ static int _rtl92se_set_media_status(struct ieee80211_hw *hw,
}
+ if (type != NL80211_IFTYPE_AP &&
+ rtlpriv->mac80211.link_state < MAC80211_LINKED)
+ bt_msr = rtl_read_byte(rtlpriv, MSR) & ~MSR_LINK_MASK;
rtl_write_byte(rtlpriv, (MSR), bt_msr);
temp = rtl_read_dword(rtlpriv, TCR);
@@ -1262,6 +1265,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 +1280,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)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/phy.c b/drivers/net/wireless/rtlwifi/rtl8192se/phy.c
index 77c5b5f..4b4612f 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/phy.c
@@ -399,6 +399,8 @@ static bool _rtl92s_phy_sw_chnl_step_by_step(struct ieee80211_hw *hw,
case 2:
currentcmd = &postcommoncmd[*step];
break;
+ default:
+ return true;
}
if (currentcmd->cmdid == CMDID_END) {
diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/sw.c b/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
index aadba29..fb00386 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
@@ -236,6 +236,19 @@ static void rtl92s_deinit_sw_vars(struct ieee80211_hw *hw)
}
}
+static 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);
+
+ if (own)
+ return false;
+ return true;
+}
+
static struct rtl_hal_ops rtl8192se_hal_ops = {
.init_sw_vars = rtl92s_init_sw_vars,
.deinit_sw_vars = rtl92s_deinit_sw_vars,
@@ -269,6 +282,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,
@@ -306,6 +320,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,
--
2.1.2
^ permalink raw reply related
* [PATCH iproute2] vxlan: Add support for enabling UDP checksums
From: Tom Herbert @ 2014-11-07 16:05 UTC (permalink / raw)
To: stephen, davem, netdev
Add udpcsum option to enable transmitting UDP checksums when doing
VXLAN/IPv4. Add udp6zerocsumtx, and udp6zerocsumrx options to enable
sending zero checksums and receiving zero checksums in VXLAN/IPv6.
Signed-off-by: Tom Herbert <therbert@google.com>
---
ip/iplink_vxlan.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/ip/iplink_vxlan.c b/ip/iplink_vxlan.c
index f410423..9cc3ec3 100644
--- a/ip/iplink_vxlan.c
+++ b/ip/iplink_vxlan.c
@@ -29,6 +29,7 @@ static void print_explain(FILE *f)
fprintf(f, " [ [no]learning ] [ [no]proxy ] [ [no]rsc ]\n");
fprintf(f, " [ [no]l2miss ] [ [no]l3miss ]\n");
fprintf(f, " [ ageing SECONDS ] [ maxaddress NUMBER ]\n");
+ fprintf(f, " [ [no]udpcsum ] [ [no]udp6zerocsumtx ] [ [no]udp6zerocsumrx ]\n");
fprintf(f, "\n");
fprintf(f, "Where: VNI := 0-16777215\n");
fprintf(f, " ADDR := { IP_ADDRESS | any }\n");
@@ -64,6 +65,9 @@ static int vxlan_parse_opt(struct link_util *lu, int argc, char **argv,
__u32 age = 0;
__u32 maxaddr = 0;
__u16 dstport = 0;
+ __u8 udpcsum = 0;
+ __u8 udp6zerocsumtx = 0;
+ __u8 udp6zerocsumrx = 0;
int dst_port_set = 0;
struct ifla_vxlan_port_range range = { 0, 0 };
@@ -181,6 +185,18 @@ static int vxlan_parse_opt(struct link_util *lu, int argc, char **argv,
l3miss = 0;
} else if (!matches(*argv, "l3miss")) {
l3miss = 1;
+ } else if (!matches(*argv, "udpcsum")) {
+ udpcsum = 1;
+ } else if (!matches(*argv, "noudpcsum")) {
+ udpcsum = 0;
+ } else if (!matches(*argv, "udp6zerocsumtx")) {
+ udp6zerocsumtx = 1;
+ } else if (!matches(*argv, "noudp6zerocsumtx")) {
+ udp6zerocsumtx = 0;
+ } else if (!matches(*argv, "udp6zerocsumrx")) {
+ udp6zerocsumrx = 1;
+ } else if (!matches(*argv, "noudp6zerocsumrx")) {
+ udp6zerocsumrx = 0;
} else if (matches(*argv, "help") == 0) {
explain();
return -1;
@@ -236,6 +252,9 @@ static int vxlan_parse_opt(struct link_util *lu, int argc, char **argv,
addattr8(n, 1024, IFLA_VXLAN_RSC, rsc);
addattr8(n, 1024, IFLA_VXLAN_L2MISS, l2miss);
addattr8(n, 1024, IFLA_VXLAN_L3MISS, l3miss);
+ addattr8(n, 1024, IFLA_VXLAN_UDP_CSUM, udpcsum);
+ addattr8(n, 1024, IFLA_VXLAN_UDP_ZERO_CSUM6_TX, udp6zerocsumtx);
+ addattr8(n, 1024, IFLA_VXLAN_UDP_ZERO_CSUM6_RX, udp6zerocsumrx);
if (noage)
addattr32(n, 1024, IFLA_VXLAN_AGEING, 0);
@@ -368,6 +387,17 @@ static void vxlan_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[])
if (tb[IFLA_VXLAN_LIMIT] &&
((maxaddr = rta_getattr_u32(tb[IFLA_VXLAN_LIMIT])) != 0))
fprintf(f, "maxaddr %u ", maxaddr);
+
+ if (tb[IFLA_VXLAN_UDP_CSUM] && rta_getattr_u8(tb[IFLA_VXLAN_UDP_CSUM]))
+ fputs("udpcsum ", f);
+
+ if (tb[IFLA_VXLAN_UDP_ZERO_CSUM6_TX] &&
+ rta_getattr_u8(tb[IFLA_VXLAN_UDP_ZERO_CSUM6_TX]))
+ fputs("udp6zerocsumtx ", f);
+
+ if (tb[IFLA_VXLAN_UDP_ZERO_CSUM6_RX] &&
+ rta_getattr_u8(tb[IFLA_VXLAN_UDP_ZERO_CSUM6_RX]))
+ fputs("udp6zerocsumrx ", f);
}
static void vxlan_print_help(struct link_util *lu, int argc, char **argv,
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* Re: am335x: cpsw: phy ignores max-speed setting
From: Mugunthan V N @ 2014-11-07 16:11 UTC (permalink / raw)
To: Yegor Yefremov, Florian Fainelli; +Cc: netdev, mpa, lsorense, Daniel Mack
In-Reply-To: <CAGm1_ktReQ5aOJGbvyEB3xQDanCnj_XkwUEWLtB=+sMseZX_pA@mail.gmail.com>
On Friday 07 November 2014 12:41 PM, Yegor Yefremov wrote:
> On Thu, Nov 6, 2014 at 5:58 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>> On 11/06/2014 08:25 AM, Yegor Yefremov wrote:
>>> I' m trying to override max-speed setting for both CPSW connected
>>> PHYs. This is my DTS section for configuring CPSW:
>>>
>>> &mac {
>>> pinctrl-names = "default", "sleep";
>>> pinctrl-0 = <&cpsw_default>;
>>> pinctrl-1 = <&cpsw_sleep>;
>>> dual_emac = <1>;
>>>
>>> status = "okay";
>>> };
>>>
>>> &davinci_mdio {
>>> pinctrl-names = "default", "sleep";
>>> pinctrl-0 = <&davinci_mdio_default>;
>>> pinctrl-1 = <&davinci_mdio_sleep>;
>>>
>>> status = "okay";
>>> };
>>>
>>> &cpsw_emac0 {
>>> phy_id = <&davinci_mdio>, <0>;
>>> phy-mode = "rgmii-id";
>>> dual_emac_res_vlan = <1>;
>>> max-speed = <100>;
>>> };
>>>
>>> &cpsw_emac1 {
>>> phy_id = <&davinci_mdio>, <1>;
>>> phy-mode = "rgmii-id";
>>> dual_emac_res_vlan = <2>;
>>> max-speed = <100>;
>>> };
>>>
>>> But in drivers/net/phy/phy_device.c->of_set_phy_supported() routine I
>>> don't get through node check, i.e. node == NULL. Any idea why?
>>
>> Yes, because the 'max-speed' property is placed at the Ethernet MAC node
>> level, not the PHY node as of_set_phy_supported() expect its.
>>
>> This driver does not appear to use the standard Ethernet PHY device tree
>> node, so I am not sure what are your options here.
>
> The SoC has a complex structure, i.e. Ethernet controller has a switch
> inside with two slaves.
>
> A workaround would be perhaps to handle this option in cpsw driver.
>
> Mugunthan, what do you think about this?
Yes, CPSW is different from what linux networking is designed for, it
has two ethernet slave and acts as a Layer 2 switch.
* If you need on a run time basis you can change the supported speed via
ethtool advertise interface
* If needed on boot for nfs then need to think of how it can be achieved
in cpsw driver. Will have a look and update this thread.
Regards
Mugunthan V N
^ permalink raw reply
* Re: am335x: cpsw: phy ignores max-speed setting
From: Yegor Yefremov @ 2014-11-07 16:27 UTC (permalink / raw)
To: Mugunthan V N; +Cc: Florian Fainelli, netdev, mpa, lsorense, Daniel Mack
In-Reply-To: <545CEF35.9080405@ti.com>
On Fri, Nov 7, 2014 at 5:11 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
> On Friday 07 November 2014 12:41 PM, Yegor Yefremov wrote:
>> On Thu, Nov 6, 2014 at 5:58 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>> On 11/06/2014 08:25 AM, Yegor Yefremov wrote:
>>>> I' m trying to override max-speed setting for both CPSW connected
>>>> PHYs. This is my DTS section for configuring CPSW:
>>>>
>>>> &mac {
>>>> pinctrl-names = "default", "sleep";
>>>> pinctrl-0 = <&cpsw_default>;
>>>> pinctrl-1 = <&cpsw_sleep>;
>>>> dual_emac = <1>;
>>>>
>>>> status = "okay";
>>>> };
>>>>
>>>> &davinci_mdio {
>>>> pinctrl-names = "default", "sleep";
>>>> pinctrl-0 = <&davinci_mdio_default>;
>>>> pinctrl-1 = <&davinci_mdio_sleep>;
>>>>
>>>> status = "okay";
>>>> };
>>>>
>>>> &cpsw_emac0 {
>>>> phy_id = <&davinci_mdio>, <0>;
>>>> phy-mode = "rgmii-id";
>>>> dual_emac_res_vlan = <1>;
>>>> max-speed = <100>;
>>>> };
>>>>
>>>> &cpsw_emac1 {
>>>> phy_id = <&davinci_mdio>, <1>;
>>>> phy-mode = "rgmii-id";
>>>> dual_emac_res_vlan = <2>;
>>>> max-speed = <100>;
>>>> };
>>>>
>>>> But in drivers/net/phy/phy_device.c->of_set_phy_supported() routine I
>>>> don't get through node check, i.e. node == NULL. Any idea why?
>>>
>>> Yes, because the 'max-speed' property is placed at the Ethernet MAC node
>>> level, not the PHY node as of_set_phy_supported() expect its.
>>>
>>> This driver does not appear to use the standard Ethernet PHY device tree
>>> node, so I am not sure what are your options here.
>>
>> The SoC has a complex structure, i.e. Ethernet controller has a switch
>> inside with two slaves.
>>
>> A workaround would be perhaps to handle this option in cpsw driver.
>>
>> Mugunthan, what do you think about this?
>
> Yes, CPSW is different from what linux networking is designed for, it
> has two ethernet slave and acts as a Layer 2 switch.
>
> * If you need on a run time basis you can change the supported speed via
> ethtool advertise interface
> * If needed on boot for nfs then need to think of how it can be achieved
> in cpsw driver. Will have a look and update this thread.
ethtool is working, but requires a custom script, so DTS solution
would suite better.
Thanks.
Yegor
^ permalink raw reply
* Re: [PATCH] asix: Do full reset during ax88772_bind
From: David Miller @ 2014-11-07 16:32 UTC (permalink / raw)
To: M.Stam
Cc: ckeepax, jeffrey.t.kirsher, emilgoode, linux-usb, netdev,
linux-kernel
In-Reply-To: <C89EFD3CD56F64468D3D206D683A8D22039FFEDE@ldam-msx2.fugro-nl.local>
From: "Stam, Michel [FINT]" <M.Stam@fugro.nl>
Date: Fri, 7 Nov 2014 09:27:26 +0100
> Please add;
>
> Tested-by: Michel Stam <m.stam@fugro.nl>
You're making two critical mistakes here in how you are replying to
this patch.
First, do not top post. Quote the commit message, then add your
Tested-by or other tag afterwards.
And most importantly, do not provide the entire patch again. That
makes a brand new entry in patchwork, rather than adding your
Tested-by to the original patch.
These mistakes make more work for everyone trying to get this
change into the tree, including me. So please respond and
discuss patches like everyone else does by not top-posting and
not posting the entire patch in your response.
Thanks.
^ permalink raw reply
* [PATCH iproute2] ip netns: Identify netns for the current process
From: Vadim Kochan @ 2014-11-07 16:25 UTC (permalink / raw)
To: netdev; +Cc: Vadim Kochan
As 'ip' util will share the same netns from the caller
process then we can just look at /proc/self/.. to show
the netns of the current process by:
ip netns id
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
---
ip/ipnetns.c | 22 ++++++++++------------
man/man8/ip-netns.8 | 7 ++++---
2 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/ip/ipnetns.c b/ip/ipnetns.c
index 90a496f..1c8aa02 100644
--- a/ip/ipnetns.c
+++ b/ip/ipnetns.c
@@ -59,7 +59,7 @@ static int usage(void)
fprintf(stderr, "Usage: ip netns list\n");
fprintf(stderr, " ip netns add NAME\n");
fprintf(stderr, " ip netns delete NAME\n");
- fprintf(stderr, " ip netns identify PID\n");
+ fprintf(stderr, " ip netns identify [PID]\n");
fprintf(stderr, " ip netns pids NAME\n");
fprintf(stderr, " ip netns exec NAME cmd ...\n");
fprintf(stderr, " ip netns monitor\n");
@@ -299,19 +299,17 @@ static int netns_identify(int argc, char **argv)
struct dirent *entry;
if (argc < 1) {
- fprintf(stderr, "No pid specified\n");
- return -1;
- }
- if (argc > 1) {
+ pidstr = "self";
+ } else if (argc > 1) {
fprintf(stderr, "extra arguments specified\n");
return -1;
- }
- pidstr = argv[0];
-
- if (!is_pid(pidstr)) {
- fprintf(stderr, "Specified string '%s' is not a pid\n",
- pidstr);
- return -1;
+ } else {
+ pidstr = argv[0];
+ if (!is_pid(pidstr)) {
+ fprintf(stderr, "Specified string '%s' is not a pid\n",
+ pidstr);
+ return -1;
+ }
}
snprintf(net_path, sizeof(net_path), "/proc/%s/ns/net", pidstr);
diff --git a/man/man8/ip-netns.8 b/man/man8/ip-netns.8
index 6aa6e93..74343ed 100644
--- a/man/man8/ip-netns.8
+++ b/man/man8/ip-netns.8
@@ -21,7 +21,7 @@ ip-netns \- process network namespace management
.ti -8
.BR "ip netns identify"
-.I PID
+.RI "[ " PID " ]"
.ti -8
.BR "ip netns pids"
@@ -85,10 +85,11 @@ persists until it has no more users. ip netns delete may fail if
the mount point is in use in another mount namespace.
.TP
-.B ip netns identify PID - Report network namespaces names for process
+.B ip netns identify [PID] - Report network namespaces names for process
.sp
This command walks through /var/run/netns and finds all the network
-namespace names for network namespace of the specified process.
+namespace names for network namespace of the specified process, if PID is
+not specified then the current process will be used.
.TP
.B ip netns pids NAME - Report processes in the named network namespace
--
2.1.3
^ permalink raw reply related
* Re: [PATCH net-next 2/2] r8152: adjust rtl_start_rx
From: David Miller @ 2014-11-07 16:35 UTC (permalink / raw)
To: hayeswang-Rasf1IRRPZFBDgjK7y7TUQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, nic_swsd-Rasf1IRRPZFBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1394712342-15778-90-Taiwan-albertk-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>
From: Hayes Wang <hayeswang-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>
Date: Fri, 7 Nov 2014 17:55:11 +0800
> Submit all the rx buffers, even though a error occurs. Otherwise
> the buffers which are not submitted would be lost until next
> rtl_start_rx() is called. Besides, the fail buffer could be
> re-submitted later.
>
> Signed-off-by: Hayes Wang <hayeswang-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>
Does this even work?
If you leave a hole in the ring, the device is going to stop there
anyways.
So better to replenish the next time you call into this function
rather than leaving gaps in your receive ring.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [net-next 6/9] ixgbe: fix X540 Completion timeout
From: Skidmore, Donald C @ 2014-11-07 17:06 UTC (permalink / raw)
To: Sergei Shtylyov, Kirsher, Jeffrey T, davem@davemloft.net
Cc: netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
jogreene@redhat.com
In-Reply-To: <545CD898.7060403@cogentembedded.com>
> -----Original Message-----
> From: Sergei Shtylyov [mailto:sergei.shtylyov@cogentembedded.com]
> Sent: Friday, November 07, 2014 6:35 AM
> To: Kirsher, Jeffrey T; davem@davemloft.net
> Cc: Skidmore, Donald C; netdev@vger.kernel.org; nhorman@redhat.com;
> sassmann@redhat.com; jogreene@redhat.com
> Subject: Re: [net-next 6/9] ixgbe: fix X540 Completion timeout
>
> Hello.
>
> On 11/7/2014 11:57 AM, Jeff Kirsher wrote:
>
> > From: Don Skidmore <donald.c.skidmore@intel.com>
>
> > On topologies including few levels of PCIe switching X540 can run into
> > an unexpected completion error. We get around this by waiting after
> > enabling loopback a sufficient amount of time until Tx Data Fetch is
> > sent. We then poll the pending transaction bit to ensure we received
> > the completion. Only then do we go on to clear the buffers.
>
> > Signed-of-by: Don Skidmore <donald.c.skidmore@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
> > ---
> > drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 21
> ++++++++++++++++++++-
> > 1 file changed, 20 insertions(+), 1 deletion(-)
>
> > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
> > b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
> > index b5f484b..e314b53 100644
> > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
> > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
> [...]
> > @@ -3600,6 +3601,24 @@ void ixgbe_clear_tx_pending(struct ixgbe_hw
> *hw)
> > hlreg0 = IXGBE_READ_REG(hw, IXGBE_HLREG0);
> > IXGBE_WRITE_REG(hw, IXGBE_HLREG0, hlreg0 |
> IXGBE_HLREG0_LPBK);
> >
> > + /* wait for a last completion before clearing buffers */
> > + IXGBE_WRITE_FLUSH(hw);
> > + usleep_range(3000, 6000);
> > +
> > + /* Before proceeding, make sure that the PCIe block does not have
> > + * transactions pending.
> > + */
> > + poll = ixgbe_pcie_timeout_poll(hw);
> > + for (i = 0; i < poll; i++) {
> > + usleep_range(100, 200);
> > + value = ixgbe_read_pci_cfg_word(hw,
> IXGBE_PCI_DEVICE_STATUS);
> > + if (ixgbe_removed(hw->hw_addr))
> > + goto out;
>
> Why not just *break*?
>
> > + if (!(value &
> IXGBE_PCI_DEVICE_STATUS_TRANSACTION_PENDING))
> > + goto out;
>
> Likewise.
>
> > + }
> > +
> > +out:
> > /* initiate cleaning flow for buffers in the PCIe transaction layer */
> > gcr_ext = IXGBE_READ_REG(hw, IXGBE_GCR_EXT);
> > IXGBE_WRITE_REG(hw, IXGBE_GCR_EXT,
>
> WBR, Sergei
Your right the breaks would be much cleaner, thanks for pointing it out. :) I can resubmit the patch threw Jeff or send a new one, whatever is preferred.
- Don Skidmore <donald.c.skidmore@intel.com>
^ permalink raw reply
* Re: [PATCHv4 1/1] net: fec: fix regression on i.MX28 introduced by rx_copybreak support
From: David Miller @ 2014-11-07 17:09 UTC (permalink / raw)
To: festevam
Cc: LW, netdev, fabio.estevam, Frank.Li, linux-kernel, rmk+kernel,
linux-arm-kernel, stefan.wahren
In-Reply-To: <CAOMZO5Cb1=Nvzu8EHqmV+K+W+ZJxzL1=5MnK6hDSstwh9ruweA@mail.gmail.com>
From: Fabio Estevam <festevam@gmail.com>
Date: Fri, 7 Nov 2014 10:26:15 -0200
> On Fri, Nov 7, 2014 at 7:02 AM, Lothar Waßmann <LW@karo-electronics.de> wrote:
>> commit 1b7bde6d659d ("net: fec: implement rx_copybreak to improve rx performance")
>> introduced a regression for i.MX28. The swap_buffer() function doing
>> the endian conversion of the received data on i.MX28 may access memory
>> beyond the actual packet size in the DMA buffer. fec_enet_copybreak()
>> does not copy those bytes, so that the last bytes of a packet may be
>> filled with invalid data after swapping.
>> This will likely lead to checksum errors on received packets.
>> E.g. when trying to mount an NFS rootfs:
>> UDP: bad checksum. From 192.168.1.225:111 to 192.168.100.73:44662 ulen 36
>>
>> Do the byte swapping and copying to the new skb in one go if
>> necessary.
>>
>> Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
>
> With this patch I am able to NFS mount on mx28 again. Thanks, Lothar!
>
> Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH v2] stmmac: remove custom implementation of print_hex_dump()
From: David Miller @ 2014-11-07 17:20 UTC (permalink / raw)
To: andriy.shevchenko; +Cc: joe, peppe.cavallaro, netdev, vbridgers2013
In-Reply-To: <1415371992-12915-1-git-send-email-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Fri, 7 Nov 2014 16:53:12 +0200
> There is a kernel helper to dump buffers in a hexdecimal format. This patch
> substitutes the open coded function by calling that helper.
>
> The output is slightly changed:
> - no lead space
> - ASCII part will be printed along with the dump
> - offset is longer than 3 characters (now 8)
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> Since v1:
> - address Joe's comments
> - describe output change
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 10 ++--------
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] stmmac: platform: fix sparse warnings
From: David Miller @ 2014-11-07 17:25 UTC (permalink / raw)
To: andriy.shevchenko; +Cc: peppe.cavallaro, netdev, vbridgers2013
In-Reply-To: <1415371602-12049-1-git-send-email-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Fri, 7 Nov 2014 16:46:42 +0200
> This patch fixes the following sparse warnings. One is fixed by casting return
> value to a return type of the function. The others by creating a specific
> stmmac_platform.h which provides the bits related to the platform driver.
>
> drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c:59:29: warning: incorrect type in return expression (different address spaces)
> drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c:59:29: expected void *
> drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c:59:29: got void [noderef] <asn:2>*reg
>
> drivers/net/ethernet/stmicro/stmmac/dwmac-meson.c:64:29: warning: symbol 'meson6_dwmac_data' was not declared. Should it be static?
> drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c:354:29: warning: symbol 'stih4xx_dwmac_data' was not declared. Should it be static?
> drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c:361:29: warning: symbol 'stid127_dwmac_data' was not declared. Should it be static?
> drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c:133:29: warning: symbol 'sun7i_gmac_data' was not declared. Should it be static?
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Applied, thanks.
^ permalink raw reply
* Re: kernel panic receiving flooded VXLAN traffic with OVS
From: Pravin Shelar @ 2014-11-07 17:40 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev, discuss@openvswitch.org
In-Reply-To: <19014.1415325508@famine>
On Thu, Nov 6, 2014 at 5:58 PM, Jay Vosburgh <jay.vosburgh@canonical.com> wrote:
>
> 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.
>
I think this is related skb_segment() issue where it is not able to
handle this type of skb geometry. We need to fix skb-segmentation. I
will investigate it more.
> -J
>
> ---
> -Jay Vosburgh, jay.vosburgh@canonical.com
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: kernel panic receiving flooded VXLAN traffic with OVS
From: Jesse Gross @ 2014-11-07 18:34 UTC (permalink / raw)
To: Pravin Shelar; +Cc: Jay Vosburgh, netdev, discuss@openvswitch.org
In-Reply-To: <CALnjE+r-s-usJoHq0E74QdorKX2H2cx429xwmsQ2kh+tzp1Y-g@mail.gmail.com>
On Fri, Nov 7, 2014 at 9:40 AM, Pravin Shelar <pshelar@nicira.com> wrote:
> On Thu, Nov 6, 2014 at 5:58 PM, Jay Vosburgh <jay.vosburgh@canonical.com> wrote:
>>
>> 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.
>>
>
> I think this is related skb_segment() issue where it is not able to
> handle this type of skb geometry. We need to fix skb-segmentation. I
> will investigate it more.
One problem that I see is that vxlan_gro_complete() doesn't add
SKB_GSO_UDP_TUNNEL to gso_type. This causes us to attempt
fragmentation as UDP rather than continuing down to do TCP
segmentation. That probably screws up the skb geometry.
^ permalink raw reply
* Re: [PATCH net 3/5] fm10k: Implement ndo_gso_check()
From: Vick, Matthew @ 2014-11-07 19:49 UTC (permalink / raw)
To: Joe Stringer
Cc: alexander.duyck@gmail.com, netdev@vger.kernel.org,
Dept-GELinuxNICDev@qlogic.com, linux-kernel@vger.kernel.org,
sathya.perla@emulex.com, Kirsher, Jeffrey T, Linux NICS,
amirv@mellanox.com, shahed.shaikh@qlogic.com, therbert@google.com,
Or Gerlitz
In-Reply-To: <201411071805.18119.joestringer@nicira.com>
On 11/6/14, 9:05 PM, "Joe Stringer" <joestringer@nicira.com> wrote:
>Let's merge both discussions into one thread (pick here or there). We
>have
>this suggestion or the one which simply checks for tunnels and
>inner+outer
>header lengths. Do you have a preference between them?
Agreed with merging the thread--consider it merged!
Reflecting on this some more, I prefer the latter option (checking tunnels
and header lengths). I'm leaning towards pushing the header length check
into fm10k_tx_encap_offload and then making fm10k_gso_check call that with
the gso_type. So, it's really the most recent version of the patch you
proposed:
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;
}
plus the header length being checked in fm10k_tx_encap_offload. The only
nit would be that I'd just return the conditional instead of having
"return true" or "return false" lines.
The tunnel length check really should be there in fm10k_tx_encap_offload
anyway, so I'll get a patch together for that one.
>We could introduce an "skb_is_gso_encap()" or similar for this purpose.
>Checking for SKB_GSO_UDP_TUNNEL or SKB_GSO_GRE is pretty closely tied to
>what
>fm10k_tx_encap_offload() checks for though; it might not even make sense
>to call
>it if some of the other SKB_GSO_* flags are raised.
A fair point. On the other hand, we have to check the header length both
in the GSO and non-GSO cases anyway, so only having the check in
fm10k_tx_encap_offload and calling it from fm10k_gso_check wouldn't be as
duplicative. What do you think about that approach?
As an aside: the more I think about this, the more I think Tom's right and
that each driver really should have it's own ndo_gso_check() for this.
With fm10k and i40e being different, we're already at 40% of the current
drivers being different. I'll leave it to Or to comment on whether the
other drivers could share the check in some manner.
Cheers,
Matthew
^ permalink raw reply
* Re: [PATCH net-next] PPC: bpf_jit_comp: add SKF_AD_HATYPE instruction
From: David Miller @ 2014-11-07 19:50 UTC (permalink / raw)
To: kda; +Cc: netdev, linuxppc-dev, alexei.starovoitov, dborkman, felix
In-Reply-To: <1415253755-4001-1-git-send-email-kda@linux-powerpc.org>
From: Denis Kirjanov <kda@linux-powerpc.org>
Date: Thu, 6 Nov 2014 09:02:35 +0300
> Add BPF extension SKF_AD_HATYPE to ppc JIT to check
> the hw type of the interface
>
> JIT off:
> [ 69.106783] test_bpf: #20 LD_HATYPE 48 48 PASS
> JIT on:
> [ 64.721757] test_bpf: #20 LD_HATYPE 7 6 PASS
>
> CC: Alexei Starovoitov<alexei.starovoitov@gmail.com>
> CC: Daniel Borkmann<dborkman@redhat.com>
> CC: Philippe Bergheaud<felix@linux.vnet.ibm.com>
> Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
Can I get some reviews please?
Thanks.
^ permalink raw reply
* Re: [patch net-next 05/10] rocker: introduce rocker switch driver
From: David Miller @ 2014-11-07 20:08 UTC (permalink / raw)
To: jiri
Cc: netdev, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl
In-Reply-To: <1415265610-9338-6-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 6 Nov 2014 10:20:05 +0100
> +#include <generated/utsrelease.h>
The version of this driver is not the version of the kernel, please do not
pretend that it is.
Define a proper DRV_MODULE_VERSION and MODULE_VERSION() like other drivers
do rather than using UTS_RELEASE or whatever.
> +static u32 rocker_msix_vector(struct rocker *rocker, unsigned vector)
Please do not use plain "unsigned", always say "unsigned int".
> +#ifdef CONFIG_NET_SWITCHDEV
> + .ndo_sw_parent_id_get = rocker_port_sw_parent_id_get,
> +#endif
Maybe better to just make the driver depend upon NET_SWITCHDEV?
> +struct rocker_desc {
> + u64 buf_addr;
> + u64 cookie;
> + u16 buf_size;
> + u16 tlv_size;
> + u16 resv[5];
> + u16 comp_err;
> +} __packed __aligned(8);
This __packed seems unnecessary, and __packed should always be avoided
when possible because it generates terrible code on some cpus.
> +/* Rocker DMA TLV struct */
> +struct rocker_tlv {
> + u32 type;
> + u16 len;
> +} __packed __aligned(8);
Likewise.
^ permalink raw reply
* Re: [patch net-next 06/10] bridge: introduce fdb offloading via switchdev
From: David Miller @ 2014-11-07 20:12 UTC (permalink / raw)
To: jiri
Cc: netdev, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl
In-Reply-To: <1415265610-9338-7-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 6 Nov 2014 10:20:06 +0100
> @@ -132,8 +133,12 @@ static void fdb_del_hw(struct net_bridge *br, const unsigned char *addr)
>
> static void fdb_delete(struct net_bridge *br, struct net_bridge_fdb_entry *f)
> {
> - if (f->is_static)
> + if (f->is_static) {
> fdb_del_hw(br, f->addr.addr);
> + if (f->dst)
> + netdev_sw_port_fdb_del(f->dst->dev,
> + f->addr.addr, f->vlan_id);
> + }
>
> hlist_del_rcu(&f->hlist);
> fdb_notify(br, f, RTM_DELNEIGH);
I think we should now adjust the name of fdb_*_hw() because
fdb_del_hw() sounds like a function that would do what
netdev_sw_port_fdb_del() actually does, remove the fdb entry from the
hardware. But it just removes an address from the device's unicast
filter.
Rename them to something like fdb_*_hw_address() of fdb_*_hw_addr().
Thanks.
^ 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