* Re: [PATCH] PPC: bpf_jit_comp: add SKF_AD_PKTTYPE instruction
From: Denis Kirjanov @ 2014-10-29 9:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Denis Kirjanov, Matt Evans, netdev
In-Reply-To: <1414351406-4122-1-git-send-email-kda@linux-powerpc.org>
Any feedback from PPC folks?
On 10/26/14, Denis Kirjanov <kda@linux-powerpc.org> wrote:
> Cc: Matt Evans <matt@ozlabs.org>
> Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
> ---
> arch/powerpc/include/asm/ppc-opcode.h | 1 +
> arch/powerpc/net/bpf_jit.h | 7 +++++++
> arch/powerpc/net/bpf_jit_comp.c | 5 +++++
> 3 files changed, 13 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/ppc-opcode.h
> b/arch/powerpc/include/asm/ppc-opcode.h
> index 6f85362..1a52877 100644
> --- a/arch/powerpc/include/asm/ppc-opcode.h
> +++ b/arch/powerpc/include/asm/ppc-opcode.h
> @@ -204,6 +204,7 @@
> #define PPC_INST_ERATSX_DOT 0x7c000127
>
> /* Misc instructions for BPF compiler */
> +#define PPC_INST_LBZ 0x88000000
> #define PPC_INST_LD 0xe8000000
> #define PPC_INST_LHZ 0xa0000000
> #define PPC_INST_LHBRX 0x7c00062c
> diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h
> index 9aee27c..c406aa9 100644
> --- a/arch/powerpc/net/bpf_jit.h
> +++ b/arch/powerpc/net/bpf_jit.h
> @@ -87,6 +87,9 @@ DECLARE_LOAD_FUNC(sk_load_byte_msh);
> #define PPC_STD(r, base, i) EMIT(PPC_INST_STD | ___PPC_RS(r) | \
> ___PPC_RA(base) | ((i) & 0xfffc))
>
> +
> +#define PPC_LBZ(r, base, i) EMIT(PPC_INST_LBZ | ___PPC_RT(r) | \
> + ___PPC_RA(base) | IMM_L(i))
> #define PPC_LD(r, base, i) EMIT(PPC_INST_LD | ___PPC_RT(r) | \
> ___PPC_RA(base) | IMM_L(i))
> #define PPC_LWZ(r, base, i) EMIT(PPC_INST_LWZ | ___PPC_RT(r) | \
> @@ -96,6 +99,10 @@ DECLARE_LOAD_FUNC(sk_load_byte_msh);
> #define PPC_LHBRX(r, base, b) EMIT(PPC_INST_LHBRX | ___PPC_RT(r) | \
> ___PPC_RA(base) | ___PPC_RB(b))
> /* Convenience helpers for the above with 'far' offsets: */
> +#define PPC_LBZ_OFFS(r, base, i) do { if ((i) < 32768) PPC_LBZ(r, base, i);
> \
> + else { PPC_ADDIS(r, base, IMM_HA(i)); \
> + PPC_LBZ(r, r, IMM_L(i)); } } while(0)
> +
> #define PPC_LD_OFFS(r, base, i) do { if ((i) < 32768) PPC_LD(r, base, i);
> \
> else { PPC_ADDIS(r, base, IMM_HA(i)); \
> PPC_LD(r, r, IMM_L(i)); } } while(0)
> diff --git a/arch/powerpc/net/bpf_jit_comp.c
> b/arch/powerpc/net/bpf_jit_comp.c
> index cbae2df..d110e28 100644
> --- a/arch/powerpc/net/bpf_jit_comp.c
> +++ b/arch/powerpc/net/bpf_jit_comp.c
> @@ -407,6 +407,11 @@ static int bpf_jit_build_body(struct bpf_prog *fp, u32
> *image,
> PPC_LHZ_OFFS(r_A, r_skb, offsetof(struct sk_buff,
> queue_mapping));
> break;
> + case BPF_ANC | SKF_AD_PKTTYPE:
> + PPC_LBZ_OFFS(r_A, r_skb, PKT_TYPE_OFFSET());
> + PPC_ANDI(r_A, r_A, PKT_TYPE_MAX);
> + PPC_SRWI(r_A, r_A, 5);
> + break;
> case BPF_ANC | SKF_AD_CPU:
> #ifdef CONFIG_SMP
> /*
> --
> 2.1.0
>
>
^ permalink raw reply
* spin lock held between 2 process
From: Chetan C R @ 2014-10-29 9:02 UTC (permalink / raw)
To: netdev
Hi,
In 3.4 kernel facing this issue.
[58762.332116] PID: 23472, Name: wlanconfig
[58762.337490] Backtrace:
[58762.339926] [<c001256c>] (dump_backtrace+0x0/0x10c) from
[<c0012894>] (show_stack+0x18/0x1c)
[58762.348330] r6:36b4a597 r5:c0744258 r4:d7dc1600 r3:c07003c4
[58762.353984] [<c001287c>] (show_stack+0x0/0x1c) from [<c0046828>]
(wdog_handler+0x16c/0x1b4)
[58762.362763] [<c00466bc>] (wdog_handler+0x0/0x1b4) from [<c00a0af0>]
(handle_percpu_devid_irq+0x88/0xa8)
[58762.372572] [<c00a0a68>] (handle_percpu_devid_irq+0x0/0xa8) from
[<c009d234>] (generic_handle_irq+0x34/0x48)
[58762.382382] r8:00000000 r7:c0741df0 r6:c0700f20 r5:00000014 r4:d2630000
[58762.388880] r3:c00a0a68
[58762.391473] [<c009d200>] (generic_handle_irq+0x0/0x48) from
[<c000f6d8>] (handle_IRQ+0x84/0xb0)
[58762.400157] [<c000f654>] (handle_IRQ+0x0/0xb0) from [<c000861c>]
(gic_handle_irq+0x70/0xc4)
[58762.408499] r8:d2631be8 r7:fa003000 r6:00000014 r5:c07410e4 r4:00000014
[58762.414997] r3:00000004
[58762.417621] [<c00085ac>] (gic_handle_irq+0x0/0xc4) from
[<c000ea00>] (__irq_svc+0x40/0x70)
[58762.425868] Exception stack(0xd2631be8 to 0xd2631c30)
[58762.430898] 1be0: c07f1430 0000c5db 00000001 00000000 c5dac5dc d860840c
[58762.439052] 1c00: d792c000 d7557800 d7557800 d2630000 d8608400
d2631c44 20000013 d2631c34
[58762.447205] 1c20: c0123228 c03614f4 60000013 ffffffff
[58762.452266] [<c0361498>] (_raw_spin_lock+0x0/0x9c) from
[<c0123228>] (unregister_sysctl_table+0x64/0x7c)
[58762.461701] r4:d460f400
[58762.464231] [<c01231c4>] (unregister_sysctl_table+0x0/0x7c) from
[<c0347e9c>] (unregister_net_sysctl_table+0x10/0x14)
[58762.474822] r7:d7557800 r6:d7557800 r5:d860840c r4:d460f400
[58762.480476] [<c0347e8c>] (unregister_net_sysctl_table+0x0/0x14)
from [<c0317710>] (__devinet_sysctl_unregister+0x28/0x3c)
[58762.491410] [<c03176e8>] (__devinet_sysctl_unregister+0x0/0x3c)
from [<c0317c9c>] (inetdev_event+0x2e8/0x454)
[58762.501282] r4:00000000 r3:d7dc1600
[58762.504875] [<c03179b4>] (inetdev_event+0x0/0x454) from
[<c007aebc>] (notifier_call_chain+0x34/0x74)
[58762.513966] [<c007ae88>] (notifier_call_chain+0x0/0x74) from
[<c007afd0>] (raw_notifier_call_chain+0x20/0x28)
[58762.523869] r8:00200200 r7:c0824e40 r6:d2631d68 r5:d7557800 r4:00000006
[58762.530367] r3:ffffffff
[58762.532991] [<c007afb0>] (raw_notifier_call_chain+0x0/0x28) from
[<c02c2390>] (call_netdevice_notifiers+0x44/0x54)
[58762.543300] [<c02c234c>] (call_netdevice_notifiers+0x0/0x54) from
[<c02c2770>] (rollback_registered_many+0x1d0/0x2e0)
[58762.553891] r5:0000029e r4:d7557800
[58762.557452] [<c02c25a0>] (rollback_registered_many+0x0/0x2e0) from
[<c02c2918>] (rollback_registered+0x30/0x48)
[58762.567543] [<c02c28e8>] (rollback_registered+0x0/0x48) from
[<c02c4024>] (unregister_netdevice_queue+0x70/0xa0)
[58762.577821] [<c02c3fb4>] (unregister_netdevice_queue+0x0/0xa0) from
[<bf36a768>] (mac-driver_ioctl_delete_vap+0x188/0x1a0 [mac-driver])
[58762.588786] r5:d25b4000 r4:00000000
[58762.592504] [<bf36a5e0>] (mac-driver_ioctl_delete_vap+0x0/0x1a0
[mac-driver]) from [<bf361e88>] (ieee80211_ioctl+0x180/0x1400
[mac-driver])
[58762.603375] [<bf361d08>] (ieee80211_ioctl+0x0/0x1400 [mac-driver])
from [<c02c5d34>] (dev_ifsioc+0x314/0x334)
[58762.612654] [<c02c5a20>] (dev_ifsioc+0x0/0x334) from [<c02c64f8>]
(dev_ioctl+0x7a4/0x86c)
[58762.620839] r7:00000000 r6:c0824e40 r5:000089f8 r4:00000000
[58762.626462] [<c02c5d54>] (dev_ioctl+0x0/0x86c) from [<c02b0b88>]
(sock_ioctl+0x3c/0x288)
[58762.634553] [<c02b0b4c>] (sock_ioctl+0x0/0x288) from [<c00e8eb8>]
(do_vfs_ioctl+0x5a8/0x608)
[58762.642957] r6:be8900a8 r5:db248000 r4:d4f08aa0 r3:c02b0b4c
[58762.648611] [<c00e8910>] (do_vfs_ioctl+0x0/0x608) from [<c00e8f58>]
(sys_ioctl+0x40/0x64)
[58762.656765] r8:c000ef84 r7:db248000 r6:be8900a8 r5:000089f8 r4:00000003
[58762.663450] [<c00e8f18>] (sys_ioctl+0x0/0x64) from [<c000ee00>]
(ret_fast_syscall+0x0/0x30)
[58762.671791] r7:00000036 r6:00000003 r5:000089f8 r4:be8900a8
…
[58763.810779] PID: 26771, Name: lua
[58763.815528] Backtrace: no frame pointer
[58763.819370] Kernel panic - not syncing:
[58763.825712] CPU1: stopping
[58763.828399] Backtrace:
[58763.830835] [<c001256c>] (dump_backtrace+0x0/0x10c) from
[<c0359d8c>] (dump_stack+0x18/0x1c)
[58763.839239] r6:d789a000 r5:c07410e4 r4:00000001 r3:c07003c4
[58763.844894] [<c0359d74>] (dump_stack+0x0/0x1c) from [<c00145b0>]
(handle_IPI+0x100/0x1c4)
[58763.853047] [<c00144b0>] (handle_IPI+0x0/0x1c4) from [<c0008664>]
(gic_handle_irq+0xb8/0xc4)
[58763.861451] [<c00085ac>] (gic_handle_irq+0x0/0xc4) from
[<c000ea00>] (__irq_svc+0x40/0x70)
[58763.869698] Exception stack(0xd789bcc0 to 0xd789bd08)
[58763.874728] bcc0: c07f1430 0000c5dc 00000001 00000000 c5dac5dd
ddb22890 00000081 ddb22890
[58763.882913] bce0: 00000000 d789a000 d789a000 d789bd1c 20000013
d789bd0c c0122a80 c03614f4
[58763.891067] bd00: 60000013 ffffffff
[58763.894534] [<c0361498>] (_raw_spin_lock+0x0/0x9c) from
[<c0122a80>] (sysctl_head_grab+0x20/0x4c)
[58763.903375] r4:c0767c54
[58763.905906] [<c0122a60>] (sysctl_head_grab+0x0/0x4c) from
[<c0122acc>] (grab_header+0x20/0x28)
[58763.914497] r4:ddb22890 r3:c0767c54
[58763.918058] [<c0122aac>] (grab_header+0x0/0x28) from [<c0123cb4>]
(proc_sys_permission+0x38/0x80)
[58763.926930] [<c0123c7c>] (proc_sys_permission+0x0/0x80) from
[<c00e399c>] (inode_permission+0x7c/0xc0)
[58763.936209] r6:00000081 r5:ddb22890 r4:d24fc00a r3:c0123c7c
[58763.941832] [<c00e3920>] (inode_permission+0x0/0xc0) from
[<c00e3f8c>] (link_path_walk+0x5c/0x7e0)
[58763.950767] r6:ddb22890 r5:d789be70 r4:d24fc00a r3:00000051
[58763.956421] [<c00e3f30>] (link_path_walk+0x0/0x7e0) from
[<c00e4cc0>] (path_lookupat+0x5c/0x6c4)
[58763.965200] [<c00e4c64>] (path_lookupat+0x0/0x6c4) from
[<c00e534c>] (do_path_lookup+0x24/0x60)
[58763.973884] [<c00e5328>] (do_path_lookup+0x0/0x60) from
[<c00e698c>] (user_path_at_empty+0x60/0x90)
[58763.982913] r7:ffffff9c r6:d789be70 r5:d24fc000 r4:00000001
[58763.988536] [<c00e692c>] (user_path_at_empty+0x0/0x90) from
[<c00e69d8>] (user_path_at+0x1c/0x24)
[58763.997408] r8:c000ef84 r7:000000c3 r6:00000000 r5:d789bf40 r4:beaf1cb8
[58764.004094] [<c00e69bc>] (user_path_at+0x0/0x24) from [<c00dd8b4>]
(vfs_fstatat+0x3c/0x6c)
[58764.012341] [<c00dd878>] (vfs_fstatat+0x0/0x6c) from [<c00dd930>]
(vfs_stat+0x24/0x28)
[58764.020214] r5:00e2f438 r4:beaf1cb8
[58764.023775] [<c00dd90c>] (vfs_stat+0x0/0x28) from [<c00ddb0c>]
(sys_stat64+0x1c/0x38)
[58764.031616] [<c00ddaf0>] (sys_stat64+0x0/0x38) from [<c000ee00>]
(ret_fast_syscall+0x0/0x30)
Facing this look up issue in 3.4.0 kernel. Any pointers to resolve this issue?
Thanks,
^ permalink raw reply
* [PATCH/TRIVIAL 1/1 net-next] ipv6: spelling s/incomming/incoming
From: Fabian Frederick @ 2014-10-29 9:00 UTC (permalink / raw)
To: linux-kernel
Cc: Fabian Frederick, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Jiri Kosina, netdev
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
net/ipv6/ip6mr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 0171f08..467f310 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -2090,7 +2090,7 @@ static void ip6_mr_forward(struct net *net, struct mr6_table *mrt,
if (ipv6_addr_any(&cache->mf6c_origin) && true_vifi >= 0) {
struct mfc6_cache *cache_proxy;
- /* For an (*,G) entry, we only check that the incomming
+ /* For an (*,G) entry, we only check that the incoming
* interface is part of the static tree.
*/
cache_proxy = ip6mr_cache_find_any_parent(mrt, vif);
--
1.9.3
^ permalink raw reply related
* Re: ipv6 mld: packets are not looped back to/from kernel/querier
From: Pierre Pfister @ 2014-10-29 8:49 UTC (permalink / raw)
To: Pierre Pfister; +Cc: Daniel Borkmann, netdev, liuhangbin
In-Reply-To: <4F039FC5-0FE5-4944-8371-75F927B185C6@darou.fr>
It doesn’t work with 3.16 neither.
Cheers,
- Pierre
Le 29 oct. 2014 à 09:14, Pierre Pfister <pierre@darou.fr> a écrit :
> Thanks for the quick answer,
>
> See inline,
>
> Le 28 oct. 2014 à 19:17, Daniel Borkmann <dborkman@redhat.com> a écrit :
>
>> On 10/28/2014 05:32 PM, Pierre Pfister wrote:
>>> Hello,
>>>
>>> I’m implementing a dual-stack multicast querier (IGMPv3 and MLDv2) along with the PIM protocol.
>>> So I’ve got two multicast sockets, one for each protocol.
>>>
>>> I open the two sockets like this:
>>>
>>> ——————————————————
>>> fd = socket(AF_INET, SOCK_RAW, IPPROTO_IGMP);
>>> val = 1;
>>> setsockopt(fd, IPPROTO_IP, MRT_INIT, &val, sizeof(val));
>>> setsockopt(fd, IPPROTO_IP, IP_PKTINFO, &val, sizeof(val));
>>> setsockopt(fd, IPPROTO_IP, IP_MULTICAST_TTL, &val, sizeof(val));
>>> val = 0xc0;
>>> setsockopt(fd, IPPROTO_IP, IP_TOS, &val, sizeof(val));
>>> setsockopt(fd, IPPROTO_IP, IP_OPTIONS, &ipv4_rtr_alert, sizeof(ipv4_rtr_alert))
>>>
>>> fd = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6);
>>> val = 1;
>>> setsockopt(fd, IPPROTO_IPV6, MRT6_INIT, &val, sizeof(val));
>>> setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPOPTS, &val, sizeof(val));
>>> setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &val, sizeof(val));
>>> setsockopt(fd, IPPROTO_IPV6, IPV6_MULTICAST_HOPS, &val, sizeof(val));
>>> val = 2;
>>> setsockopt(fd, IPPROTO_RAW, IPV6_CHECKSUM, &val, sizeof(val));
>>> setsockopt(fd, IPPROTO_IPV6, IPV6_HOPOPTS, &ipv6_rtr_alert, sizeof(ipv6_rtr_alert));
>>
>> What kernel are you using? How do you setup ipv6_rtr_alert here?
>>
>> For inbound queries in IPv6, the kernel might be more picky after
>> [correct] commit e940f5d6ba6a ("ipv6: Fix MLD Query message check"),
>> so you need to make sure you have hop limit of 1 and a proper set
>> up RA option …
>
> I can reproduce the problem with both 3.10.28 and 3.14-0. I will try to try a later version.
> I don’t think the packet itself can be a problem as other routers correctly receive it.
> The problem comes with loopbacking to kernel and userspace (Depending whether the kernel or querier sent it).
>
> Here is the router alert struct.
> static struct {
> struct ip6_hbh hdr;
> struct ip6_opt_router rt;
> uint8_t pad[2];
> } ipv6_rtr_alert = {
> .hdr = {0, 0},
> .rt = {IP6OPT_ROUTER_ALERT, 2, {0, IP6_ALERT_MLD}},
> .pad = {0, 0}
> }
>
> I also checked what that commit checks (wiresharked), and everything seems correct.
>
> Thanks,
>
> - Pierre
>
>
>
>>
>>> struct icmp6_filter flt;
>>> ICMP6_FILTER_SETBLOCKALL(&flt);
>>> ICMP6_FILTER_SETPASS(ICMPV6_MGM_QUERY, &flt);
>>> ICMP6_FILTER_SETPASS(ICMPV6_MGM_REPORT, &flt);
>>> ICMP6_FILTER_SETPASS(ICMPV6_MGM_REDUCTION, &flt);
>>> ICMP6_FILTER_SETPASS(ICMPV6_MLD2_REPORT, &flt);
>>> setsockopt(fd, IPPROTO_ICMPV6, ICMP6_FILTER, &flt, sizeof(flt));
>>> ——————————————————————
>>>
>>> I’ve got two issues with the IPv6 socket.
>>> When I send an MLD query, it is sent on the wire, but the kernel doesn’t interpret it (It doesn’t send MLD Reports as reply).
>>> Similarly, when the kernel sends a Report, my MLD Querier socket doesn’t receive the message.
>>>
>>> The resulting problem is that everything works fine as long as the router doesn’t want to join a group. When it does, my Querier can’t know it, and the kernel doesn’t reply to Querier’s requests.
>>>
>>> It works well in IPv4.
>>>
>>> I tried removing the ICMPV6 filter as well as using IPV6_MULTICAST_LOOP.
>>>
>>> Am I doing something wrong or is it an actual bug ?
>>> If you need more information, please ask.
>>>
>>> Thanks,
>>>
>>>
>>> Pierre
>>>
>>>
>>> --
>>> 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
>>>
>> --
>> 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
>
> --
> 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
* [patch] SUNRPC: off by one in BUG_ON()
From: Dan Carpenter @ 2014-10-29 8:44 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Trond Myklebust, David S. Miller,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA
The m->pool_to[] array has "maxpools" number of elements. It's
allocated in svc_pool_map_alloc_arrays() which we called earlier in the
function. This test should be >= instead of >.
Signed-off-by: Dan Carpenter <dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
---
This is very old code, but hopefully the off by one doesn't affect
runtime.
diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
index ca8a795..349c98f 100644
--- a/net/sunrpc/svc.c
+++ b/net/sunrpc/svc.c
@@ -189,7 +189,7 @@ svc_pool_map_init_percpu(struct svc_pool_map *m)
return err;
for_each_online_cpu(cpu) {
- BUG_ON(pidx > maxpools);
+ BUG_ON(pidx >= maxpools);
m->to_pool[cpu] = pidx;
m->pool_to[pidx] = cpu;
pidx++;
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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 related
* [PATCH 1/1 net-next] ipx: remove all unnecessary castings on ntohl
From: Fabian Frederick @ 2014-10-29 8:31 UTC (permalink / raw)
To: linux-kernel
Cc: Fabian Frederick, Arnaldo Carvalho de Melo, David S. Miller,
netdev
Apply commit e0f36310f793
("ipx: remove unnecessary casting on ntohl")
to all seq_printf/08lX
Inspired-by: "David S. Miller" <davem@davemloft.net>
Inspired-by: Joe Perches <joe@perches.com>
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
net/ipx/ipx_proc.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/net/ipx/ipx_proc.c b/net/ipx/ipx_proc.c
index 8391191..c1d247e 100644
--- a/net/ipx/ipx_proc.c
+++ b/net/ipx/ipx_proc.c
@@ -45,7 +45,7 @@ static int ipx_seq_interface_show(struct seq_file *seq, void *v)
}
i = list_entry(v, struct ipx_interface, node);
- seq_printf(seq, "%08lX ", (unsigned long int)ntohl(i->if_netnum));
+ seq_printf(seq, "%08X ", ntohl(i->if_netnum));
seq_printf(seq, "%02X%02X%02X%02X%02X%02X ",
i->if_node[0], i->if_node[1], i->if_node[2],
i->if_node[3], i->if_node[4], i->if_node[5]);
@@ -87,7 +87,7 @@ static int ipx_seq_route_show(struct seq_file *seq, void *v)
rt = list_entry(v, struct ipx_route, node);
- seq_printf(seq, "%08lX ", (unsigned long int)ntohl(rt->ir_net));
+ seq_printf(seq, "%08X ", ntohl(rt->ir_net));
if (rt->ir_routed)
seq_printf(seq, "%08X %02X%02X%02X%02X%02X%02X\n",
ntohl(rt->ir_intrfc->if_netnum),
@@ -194,19 +194,19 @@ static int ipx_seq_socket_show(struct seq_file *seq, void *v)
s = v;
ipxs = ipx_sk(s);
#ifdef CONFIG_IPX_INTERN
- seq_printf(seq, "%08lX:%02X%02X%02X%02X%02X%02X:%04X ",
- (unsigned long)ntohl(ipxs->intrfc->if_netnum),
+ seq_printf(seq, "%08X:%02X%02X%02X%02X%02X%02X:%04X ",
+ ntohl(ipxs->intrfc->if_netnum),
ipxs->node[0], ipxs->node[1], ipxs->node[2], ipxs->node[3],
ipxs->node[4], ipxs->node[5], ntohs(ipxs->port));
#else
- seq_printf(seq, "%08lX:%04X ", (unsigned long) ntohl(ipxs->intrfc->if_netnum),
+ seq_printf(seq, "%08X:%04X ", ntohl(ipxs->intrfc->if_netnum),
ntohs(ipxs->port));
#endif /* CONFIG_IPX_INTERN */
if (s->sk_state != TCP_ESTABLISHED)
seq_printf(seq, "%-28s", "Not_Connected");
else {
- seq_printf(seq, "%08lX:%02X%02X%02X%02X%02X%02X:%04X ",
- (unsigned long)ntohl(ipxs->dest_addr.net),
+ seq_printf(seq, "%08X:%02X%02X%02X%02X%02X%02X:%04X ",
+ ntohl(ipxs->dest_addr.net),
ipxs->dest_addr.node[0], ipxs->dest_addr.node[1],
ipxs->dest_addr.node[2], ipxs->dest_addr.node[3],
ipxs->dest_addr.node[4], ipxs->dest_addr.node[5],
--
1.9.3
^ permalink raw reply related
* Re: ipv6 mld: packets are not looped back to/from kernel/querier
From: Pierre Pfister @ 2014-10-29 8:14 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev, liuhangbin
In-Reply-To: <544FDDA7.8020007@redhat.com>
Thanks for the quick answer,
See inline,
Le 28 oct. 2014 à 19:17, Daniel Borkmann <dborkman@redhat.com> a écrit :
> On 10/28/2014 05:32 PM, Pierre Pfister wrote:
>> Hello,
>>
>> I’m implementing a dual-stack multicast querier (IGMPv3 and MLDv2) along with the PIM protocol.
>> So I’ve got two multicast sockets, one for each protocol.
>>
>> I open the two sockets like this:
>>
>> ——————————————————
>> fd = socket(AF_INET, SOCK_RAW, IPPROTO_IGMP);
>> val = 1;
>> setsockopt(fd, IPPROTO_IP, MRT_INIT, &val, sizeof(val));
>> setsockopt(fd, IPPROTO_IP, IP_PKTINFO, &val, sizeof(val));
>> setsockopt(fd, IPPROTO_IP, IP_MULTICAST_TTL, &val, sizeof(val));
>> val = 0xc0;
>> setsockopt(fd, IPPROTO_IP, IP_TOS, &val, sizeof(val));
>> setsockopt(fd, IPPROTO_IP, IP_OPTIONS, &ipv4_rtr_alert, sizeof(ipv4_rtr_alert))
>>
>> fd = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6);
>> val = 1;
>> setsockopt(fd, IPPROTO_IPV6, MRT6_INIT, &val, sizeof(val));
>> setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPOPTS, &val, sizeof(val));
>> setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &val, sizeof(val));
>> setsockopt(fd, IPPROTO_IPV6, IPV6_MULTICAST_HOPS, &val, sizeof(val));
>> val = 2;
>> setsockopt(fd, IPPROTO_RAW, IPV6_CHECKSUM, &val, sizeof(val));
>> setsockopt(fd, IPPROTO_IPV6, IPV6_HOPOPTS, &ipv6_rtr_alert, sizeof(ipv6_rtr_alert));
>
> What kernel are you using? How do you setup ipv6_rtr_alert here?
>
> For inbound queries in IPv6, the kernel might be more picky after
> [correct] commit e940f5d6ba6a ("ipv6: Fix MLD Query message check"),
> so you need to make sure you have hop limit of 1 and a proper set
> up RA option …
I can reproduce the problem with both 3.10.28 and 3.14-0. I will try to try a later version.
I don’t think the packet itself can be a problem as other routers correctly receive it.
The problem comes with loopbacking to kernel and userspace (Depending whether the kernel or querier sent it).
Here is the router alert struct.
static struct {
struct ip6_hbh hdr;
struct ip6_opt_router rt;
uint8_t pad[2];
} ipv6_rtr_alert = {
.hdr = {0, 0},
.rt = {IP6OPT_ROUTER_ALERT, 2, {0, IP6_ALERT_MLD}},
.pad = {0, 0}
}
I also checked what that commit checks (wiresharked), and everything seems correct.
Thanks,
- Pierre
>
>> struct icmp6_filter flt;
>> ICMP6_FILTER_SETBLOCKALL(&flt);
>> ICMP6_FILTER_SETPASS(ICMPV6_MGM_QUERY, &flt);
>> ICMP6_FILTER_SETPASS(ICMPV6_MGM_REPORT, &flt);
>> ICMP6_FILTER_SETPASS(ICMPV6_MGM_REDUCTION, &flt);
>> ICMP6_FILTER_SETPASS(ICMPV6_MLD2_REPORT, &flt);
>> setsockopt(fd, IPPROTO_ICMPV6, ICMP6_FILTER, &flt, sizeof(flt));
>> ——————————————————————
>>
>> I’ve got two issues with the IPv6 socket.
>> When I send an MLD query, it is sent on the wire, but the kernel doesn’t interpret it (It doesn’t send MLD Reports as reply).
>> Similarly, when the kernel sends a Report, my MLD Querier socket doesn’t receive the message.
>>
>> The resulting problem is that everything works fine as long as the router doesn’t want to join a group. When it does, my Querier can’t know it, and the kernel doesn’t reply to Querier’s requests.
>>
>> It works well in IPv4.
>>
>> I tried removing the ICMPV6 filter as well as using IPV6_MULTICAST_LOOP.
>>
>> Am I doing something wrong or is it an actual bug ?
>> If you need more information, please ask.
>>
>> Thanks,
>>
>>
>> Pierre
>>
>>
>> --
>> 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
>>
> --
> 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
* [PATCH v2] ip6_tunnel: allow to change mode for the ip6tnl0
From: Alexey Andriyanov @ 2014-10-29 7:54 UTC (permalink / raw)
To: netdev; +Cc: Alexey Andriyanov, David S. Miller, Eric Dumazet
In-Reply-To: <1414563898-10347-1-git-send-email-alan@al-an.info>
The fallback device is in ipv6 mode by default.
The mode can not be changed in runtime, so there
is no way to decapsulate ip4in6 packets coming from
various sources without creating the specific tunnel
ifaces for each peer.
This allows to update the fallback tunnel device, but only
the mode could be changed. Usual command should work for the
fallback device: `ip -6 tun change ip6tnl0 mode any`
The fallback device can not be hidden from the packet receiver
as a regular tunnel, but there is no need for synchronization
as long as we do single assignment.
Cc: David S. Miller <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Alexey Andriyanov <alan@al-an.info>
---
net/ipv6/ip6_tunnel.c | 32 +++++++++++++++++++++++++-------
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 9409887..8c97cd1 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -477,6 +477,7 @@ ip6_tnl_err(struct sk_buff *skb, __u8 ipproto, struct inet6_skb_parm *opt,
int rel_msg = 0;
u8 rel_type = ICMPV6_DEST_UNREACH;
u8 rel_code = ICMPV6_ADDR_UNREACH;
+ u8 tproto;
__u32 rel_info = 0;
__u16 len;
int err = -ENOENT;
@@ -490,7 +491,8 @@ ip6_tnl_err(struct sk_buff *skb, __u8 ipproto, struct inet6_skb_parm *opt,
&ipv6h->saddr)) == NULL)
goto out;
- if (t->parms.proto != ipproto && t->parms.proto != 0)
+ tproto = ACCESS_ONCE(t->parms.proto);
+ if (tproto != ipproto && tproto != 0)
goto out;
err = 0;
@@ -791,6 +793,7 @@ static int ip6_tnl_rcv(struct sk_buff *skb, __u16 protocol,
{
struct ip6_tnl *t;
const struct ipv6hdr *ipv6h = ipv6_hdr(skb);
+ u8 tproto;
int err;
rcu_read_lock();
@@ -799,7 +802,8 @@ static int ip6_tnl_rcv(struct sk_buff *skb, __u16 protocol,
&ipv6h->daddr)) != NULL) {
struct pcpu_sw_netstats *tstats;
- if (t->parms.proto != ipproto && t->parms.proto != 0) {
+ tproto = ACCESS_ONCE(t->parms.proto);
+ if (tproto != ipproto && tproto != 0) {
rcu_read_unlock();
goto discard;
}
@@ -1078,9 +1082,11 @@ ip4ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev)
struct flowi6 fl6;
__u8 dsfield;
__u32 mtu;
+ u8 tproto;
int err;
- if ((t->parms.proto != IPPROTO_IPIP && t->parms.proto != 0) ||
+ tproto = ACCESS_ONCE(t->parms.proto);
+ if ((tproto != IPPROTO_IPIP && tproto != 0) ||
!ip6_tnl_xmit_ctl(t))
return -1;
@@ -1120,9 +1126,11 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev)
struct flowi6 fl6;
__u8 dsfield;
__u32 mtu;
+ u8 tproto;
int err;
- if ((t->parms.proto != IPPROTO_IPV6 && t->parms.proto != 0) ||
+ tproto = ACCESS_ONCE(t->parms.proto);
+ if ((tproto != IPPROTO_IPV6 && tproto != 0) ||
!ip6_tnl_xmit_ctl(t) || ip6_tnl_addr_conflict(t, ipv6h))
return -1;
@@ -1285,6 +1293,14 @@ static int ip6_tnl_update(struct ip6_tnl *t, struct __ip6_tnl_parm *p)
return err;
}
+static int ip6_tnl0_update(struct ip6_tnl *t, struct __ip6_tnl_parm *p)
+{
+ /* for default tnl0 device allow to change only the proto */
+ t->parms.proto = p->proto;
+ netdev_state_change(t->dev);
+ return 0;
+}
+
static void
ip6_tnl_parm_from_user(struct __ip6_tnl_parm *p, const struct ip6_tnl_parm *u)
{
@@ -1384,7 +1400,7 @@ ip6_tnl_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
break;
ip6_tnl_parm_from_user(&p1, &p);
t = ip6_tnl_locate(net, &p1, cmd == SIOCADDTUNNEL);
- if (dev != ip6n->fb_tnl_dev && cmd == SIOCCHGTUNNEL) {
+ if (cmd == SIOCCHGTUNNEL) {
if (t != NULL) {
if (t->dev != dev) {
err = -EEXIST;
@@ -1392,8 +1408,10 @@ ip6_tnl_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
}
} else
t = netdev_priv(dev);
-
- err = ip6_tnl_update(t, &p1);
+ if (dev == ip6n->fb_tnl_dev)
+ err = ip6_tnl0_update(t, &p1);
+ else
+ err = ip6_tnl_update(t, &p1);
}
if (t) {
err = 0;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] ip6_tunnel: allow to change mode for the ip6tnl0
From: Alexey Andriyanov @ 2014-10-29 7:46 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, David S. Miller, Eric Dumazet
In-Reply-To: <1414565213.631.77.camel@edumazet-glaptop2.roam.corp.google.com>
29.10.2014 09:46, Eric Dumazet wrote:
> ...
>> The fallback device can not be hidden from the packet receiver
>> as a regular tunnel, but there is no need for synchronization
>> as long as we do single assignment.
>
> This is not exact, I believe you need to add following changes :
Thank you, Eric, you're right, I missed that.
I'll repost the patch with your changes applied.
--
Best regards,
Alexey
^ permalink raw reply
* Re: [PATCH] ip6_tunnel: allow to change mode for the ip6tnl0
From: Eric Dumazet @ 2014-10-29 6:46 UTC (permalink / raw)
To: Alexey Andriyanov; +Cc: netdev, David S. Miller, Eric Dumazet
In-Reply-To: <1414563898-10347-1-git-send-email-alan@al-an.info>
On Wed, 2014-10-29 at 09:24 +0300, Alexey Andriyanov wrote:
...
> The fallback device can not be hidden from the packet receiver
> as a regular tunnel, but there is no need for synchronization
> as long as we do single assignment.
This is not exact, I believe you need to add following changes :
net/ipv6/ip6_tunnel.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 9409887fb664dd78d13937b89ea1b5044afdbc94..9d43b99073d656a5a8a38976ca593a41b3cbdca4 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -477,6 +477,7 @@ ip6_tnl_err(struct sk_buff *skb, __u8 ipproto, struct inet6_skb_parm *opt,
int rel_msg = 0;
u8 rel_type = ICMPV6_DEST_UNREACH;
u8 rel_code = ICMPV6_ADDR_UNREACH;
+ u8 tproto;
__u32 rel_info = 0;
__u16 len;
int err = -ENOENT;
@@ -490,7 +491,8 @@ ip6_tnl_err(struct sk_buff *skb, __u8 ipproto, struct inet6_skb_parm *opt,
&ipv6h->saddr)) == NULL)
goto out;
- if (t->parms.proto != ipproto && t->parms.proto != 0)
+ tproto = ACCESS_ONCE(t->parms.proto);
+ if (tproto != ipproto && tproto != 0)
goto out;
err = 0;
@@ -791,6 +793,7 @@ static int ip6_tnl_rcv(struct sk_buff *skb, __u16 protocol,
{
struct ip6_tnl *t;
const struct ipv6hdr *ipv6h = ipv6_hdr(skb);
+ u8 tproto;
int err;
rcu_read_lock();
@@ -799,7 +802,8 @@ static int ip6_tnl_rcv(struct sk_buff *skb, __u16 protocol,
&ipv6h->daddr)) != NULL) {
struct pcpu_sw_netstats *tstats;
- if (t->parms.proto != ipproto && t->parms.proto != 0) {
+ tproto = ACCESS_ONCE(t->parms.proto);
+ if (tproto != ipproto && tproto != 0) {
rcu_read_unlock();
goto discard;
}
@@ -1078,9 +1082,11 @@ ip4ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev)
struct flowi6 fl6;
__u8 dsfield;
__u32 mtu;
+ u8 tproto;
int err;
- if ((t->parms.proto != IPPROTO_IPIP && t->parms.proto != 0) ||
+ tproto = ACCESS_ONCE(t->parms.proto);
+ if ((tproto != IPPROTO_IPIP && tproto != 0) ||
!ip6_tnl_xmit_ctl(t))
return -1;
@@ -1120,9 +1126,11 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev)
struct flowi6 fl6;
__u8 dsfield;
__u32 mtu;
+ u8 tproto;
int err;
- if ((t->parms.proto != IPPROTO_IPV6 && t->parms.proto != 0) ||
+ tproto = ACCESS_ONCE(t->parms.proto);
+ if ((tproto != IPPROTO_IPV6 && tproto != 0) ||
!ip6_tnl_xmit_ctl(t) || ip6_tnl_addr_conflict(t, ipv6h))
return -1;
^ permalink raw reply related
* Re: [PATCH] mac80211_hwsim: release driver when ieee80211_register_hw fails
From: Martin Pitt @ 2014-10-29 6:45 UTC (permalink / raw)
To: Junjie Mao; +Cc: Fengguang Wu, linux-wireless, netdev, linux-kernel
In-Reply-To: <1414459907-7509-1-git-send-email-eternal.n08@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 540 bytes --]
Acked-By: Martin Pitt <martin.pitt@ubuntu.com>
Hello Junjie,
Junjie Mao [2014-10-28 9:31 +0800]:
> The driver is not released when ieee80211_register_hw fails in
> mac80211_hwsim_create_radio, leading to the access to the unregistered (and
> possibly freed) device in platform_driver_unregister:
Many thanks for fixing this! Sorry about that, I don't know these bits
very well.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Good day
From: nikkivcole @ 2014-10-29 6:14 UTC (permalink / raw)
To: netdev
Good day,This email is sequel to an ealier sent message of which you have not responded.I have a personal charity project which I will want you to execute on my behalf.Please kidnly get back to me with this code MHR/3910/2014 .You can reach me on mrsalimqadri@gmail.com .
Thank you
Salim Qadri
^ permalink raw reply
* [PATCH] ip6_tunnel: allow to change mode for the ip6tnl0
From: Alexey Andriyanov @ 2014-10-29 6:24 UTC (permalink / raw)
To: netdev; +Cc: Alexey Andriyanov, David S. Miller, Eric Dumazet
The fallback device is in ipv6 mode by default.
The mode can not be changed in runtime, so there
is no way to decapsulate ip4in6 packets coming from
various sources without creating the specific tunnel
ifaces for each peer.
This allows to update the fallback tunnel device, but only
the mode could be changed. Usual command should work for the
fallback device: `ip -6 tun change ip6tnl0 mode any`
The fallback device can not be hidden from the packet receiver
as a regular tunnel, but there is no need for synchronization
as long as we do single assignment.
Cc: David S. Miller <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Alexey Andriyanov <alan@al-an.info>
---
net/ipv6/ip6_tunnel.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 9409887..303c4dd 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1285,6 +1285,14 @@ static int ip6_tnl_update(struct ip6_tnl *t, struct __ip6_tnl_parm *p)
return err;
}
+static int ip6_tnl0_update(struct ip6_tnl *t, struct __ip6_tnl_parm *p)
+{
+ /* for default tnl0 device allow to change only the proto */
+ t->parms.proto = p->proto;
+ netdev_state_change(t->dev);
+ return 0;
+}
+
static void
ip6_tnl_parm_from_user(struct __ip6_tnl_parm *p, const struct ip6_tnl_parm *u)
{
@@ -1384,7 +1392,7 @@ ip6_tnl_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
break;
ip6_tnl_parm_from_user(&p1, &p);
t = ip6_tnl_locate(net, &p1, cmd == SIOCADDTUNNEL);
- if (dev != ip6n->fb_tnl_dev && cmd == SIOCCHGTUNNEL) {
+ if (cmd == SIOCCHGTUNNEL) {
if (t != NULL) {
if (t->dev != dev) {
err = -EEXIST;
@@ -1392,8 +1400,10 @@ ip6_tnl_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
}
} else
t = netdev_priv(dev);
-
- err = ip6_tnl_update(t, &p1);
+ if (dev == ip6n->fb_tnl_dev)
+ err = ip6_tnl0_update(t, &p1);
+ else
+ err = ip6_tnl_update(t, &p1);
}
if (t) {
err = 0;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net-next] net: introduce napi_schedule_irqoff()
From: Eric Dumazet @ 2014-10-29 6:20 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: David Miller, netdev
In-Reply-To: <CAADnVQJzk2_Kx=BGpYnNzpQb7OqSZ+KaeKFbUZxJ27WKC+DZww@mail.gmail.com>
On Tue, 2014-10-28 at 22:13 -0700, Alexei Starovoitov wrote:
> tried 50 parallel netperf -t TCP_RR over ixgbe
> and perf top were tcp stack bits, qdisc locks and netperf itself.
> What do you see?
You are kidding right ?
If you save 30 nsec ( 2 * 15 nsec) per transaction, and rtt is about 20
usec, its a 0.15 % gain. Not bad for a trivial patch.
Why are you using 50 parallel netperf, instead of trying a single
netperf, as I mentioned latency impact, not overall throughput ?
Do you believe typical servers in data centers are only sending &
receiving bulk packets, with no interrupt, and one cpu busy polling in
NAPI handler ?
Every atomic op we remove/avoid, every irq masking unmasking we remove,
every cache line miss or extra bus transaction we remove, TLB miss, is
the path for better latency.
You should take a look at recent commits I did, you'll get the general
picture if you missed it.
git log --oneline --author dumazet | head -100
^ permalink raw reply
* [PATCH] iproute2: ip6_tunnel mode bugfixes: any,vti6
From: Alexey Andriyanov @ 2014-10-29 6:19 UTC (permalink / raw)
To: netdev; +Cc: Alexey Andriyanov, Stephen Hemminger
- any ipv6 tunnel mode (proto == 0) could not be set
due to incomplete set of cases in do_add, do_del.
- vti6 logic was inverted: it was using "ip6_vti0" basedev
UNLESS mode is set to vti6.
We don't need a switch by p.proto in do_add()/do_del(): it
already exists in parse_args(). So if parse_args() call
was successful, no need to check tunnel mode again.
CC: Stephen Hemminger <shemming@brocade.com>
Signed-off-by: Alexey Andriyanov <alan@al-an.info>
---
ip/ip6tunnel.c | 40 ++++++++++++++--------------------------
1 file changed, 14 insertions(+), 26 deletions(-)
diff --git a/ip/ip6tunnel.c b/ip/ip6tunnel.c
index b83534e..62a8240 100644
--- a/ip/ip6tunnel.c
+++ b/ip/ip6tunnel.c
@@ -453,49 +453,37 @@ static int do_show(int argc, char **argv)
static int do_add(int cmd, int argc, char **argv)
{
struct ip6_tnl_parm2 p;
+ const char *basedev = "ip6tnl0";
ip6_tnl_parm_init(&p, 1);
if (parse_args(argc, argv, cmd, &p) < 0)
return -1;
- switch (p.proto) {
- case IPPROTO_IPIP:
- case IPPROTO_IPV6:
- if (p.i_flags != VTI_ISVTI)
- return tnl_add_ioctl(cmd, "ip6_vti0", p.name, &p);
- else
- return tnl_add_ioctl(cmd, "ip6tnl0", p.name, &p);
- case IPPROTO_GRE:
- return tnl_add_ioctl(cmd, "ip6gre0", p.name, &p);
- default:
- fprintf(stderr, "cannot determine tunnel mode (ip6ip6, ipip6, vti6 or gre)\n");
- }
- return -1;
+ if (p.proto == IPPROTO_GRE)
+ basedev = "ip6gre0";
+ else if (p.i_flags & VTI_ISVTI)
+ basedev = "ip6_vti0";
+
+ return tnl_add_ioctl(cmd, basedev, p.name, &p);
}
static int do_del(int argc, char **argv)
{
struct ip6_tnl_parm2 p;
+ const char *basedev = "ip6tnl0";
ip6_tnl_parm_init(&p, 1);
if (parse_args(argc, argv, SIOCDELTUNNEL, &p) < 0)
return -1;
- switch (p.proto) {
- case IPPROTO_IPIP:
- case IPPROTO_IPV6:
- if (p.i_flags != VTI_ISVTI)
- return tnl_del_ioctl("ip6_vti0", p.name, &p);
- else
- return tnl_del_ioctl("ip6tnl0", p.name, &p);
- case IPPROTO_GRE:
- return tnl_del_ioctl("ip6gre0", p.name, &p);
- default:
- return tnl_del_ioctl(p.name, p.name, &p);
- }
- return -1;
+ if (p.proto == IPPROTO_GRE)
+ basedev = "ip6gre0";
+ else if (p.i_flags & VTI_ISVTI)
+ basedev = "ip6_vti0";
+
+ return tnl_del_ioctl(basedev, p.name, &p);
}
int do_ip6tunnel(int argc, char **argv)
--
1.9.1
^ permalink raw reply related
* Re: some failures with vxlan offloads..
From: Or Gerlitz @ 2014-10-29 5:50 UTC (permalink / raw)
To: Tom Herbert; +Cc: netdev@vger.kernel.org
In-Reply-To: <CA+mtBx_ncYrp_fbp8ucXfBaCoPpv_X+TEsmofCnpzTyPPfLXnw@mail.gmail.com>
On 10/28/2014 5:36 PM, Tom Herbert wrote:
>> I wonder if we have another bug somewhere... when both sides were offloaded,
>> >it works even with the mlx4 bug, canyou explain that?is it possible that the
>> >GRO stack somehow covers on the bug when both sides are offloaded and
>> >GRO/VXLAN comes into play?
>>
> Look at the receive side. As I mentioned, if the device is returning
> checksum-unnecessary and setting csum_level to 1 (inner checksum was
> validated) then stack won't try to verify the outer checksum. So in
> this case if outer checksum is incorrect nobody complains about it.
OK, I'll look there. Anything that should worries us at that stack trace
I sent in my initial email of this thread, or you think this is related
to the mlx4 driver checksum bug?
Or.
>
^ permalink raw reply
* RE: suspend/resume broken on 3.18-rc2
From: fugang.duan @ 2014-10-29 5:46 UTC (permalink / raw)
To: Fabio Estevam, Frank.Li@freescale.com
Cc: Russell King, Shawn Guo, netdev@vger.kernel.org
In-Reply-To: <CAOMZO5C5znc2ZD5GoPKC7qQPoFGaJf47BoTMY0HQtEbW46d4dw@mail.gmail.com>
From: Fabio Estevam <festevam@gmail.com> Sent: Wednesday, October 29, 2014 1:19 AM
>To: Duan Fugang-B38611; Li Frank-B20596
>Cc: Russell King; Shawn Guo; netdev@vger.kernel.org
>Subject: fec: suspend/resume broken on 3.18-rc2
>
>Hi,
>
>I am running 3.18-rc2 on a mx6sx sdb board and noticed that fec
>suspend/resume is broken (works fine on 3.17 though):
>
>root@freescale /$ echo enabled > /sys/class/tty/ttymxc0/power/wakeup
>root@freescale /$ echo mem > /sys/power/state
>[ 12.383292] PM: Syncing filesystems ... done.
>[ 12.423555] Freezing user space processes ... (elapsed 0.003 seconds)
>done.
>[ 12.434382] Freezing remaining freezable tasks ... (elapsed 0.003
>seconds) done.
>[ 12.510232] PM: suspend of devices complete after 58.151 msecs
>[ 12.516258] PM: suspend devices took 0.080 seconds
>[ 12.530579] PM: late suspend of devices complete after 9.454 msecs
>[ 12.546818] PM: noirq suspend of devices complete after 9.806 msecs
>[ 12.553328] Disabling non-boot CPUs ...
>[ 12.568077] PM: noirq resume of devices complete after 9.212 msecs
>[ 12.582440] PM: early resume of devices complete after 6.426 msecs
>[ 12.593831] fec 2188000.ethernet eth0: rcv is not +last
>[ 12.599237] Unable to handle kernel NULL pointer dereference at
>virtual address 00000000
>[ 12.607438] pgd = 80004000
>[ 12.610187] [00000000] *pgd=00000000
>[ 12.613834] Internal error: Oops: 17 [#1] SMP ARM
>[ 12.618583] Modules linked in:
>[ 12.621706] CPU: 0 PID: 2 Comm: kthreadd Not tainted
>3.18.0-rc2-00043-gf7e87a4-dirty #178
>[ 12.629943] task: be0789c0 ti: be088000 task.ti: be088000
>[ 12.635398] PC is at memcpy+0x80/0x330
>[ 12.639197] LR is at gro_pull_from_frag0+0x34/0xa8
>[ 12.644034] pc : [<802a6b60>] lr : [<80539b8c>] psr: 00000153
>[ 12.644034] sp : be089b34 ip : 00000010 fp : be089b6c
>[ 12.655577] r10: 00000000 r9 : 0000000e r8 : 8094d9c0
>[ 12.660842] r7 : 8094d9c0 r6 : 00000012 r5 : bd9e5040 r4 : bd89d9c0
>[ 12.667412] r3 : 00000804 r2 : fffffff2 r1 : 00000000 r0 : bd9e483c
>[ 12.673987] Flags: nzcv IRQs on FIQs off Mode SVC_32 ISA ARM
>Segment kernel
>[ 12.681432] Control: 10c5387d Table: bd99804a DAC: 00000015
>[ 12.687228] Process kthreadd (pid: 2, stack limit = 0xbe088240)
>[ 12.693197] Stack: (0xbe089b34 to 0xbe08a000)
>[ 12.697601] 9b20:
>bd9e5040 00000012 8094d9c0
>[ 12.705850] 9b40: 8094d9c0 bd9e483c bd89d9c0 80539b8c 00000000
>bd89d9c0 be338710 00000003
>[ 12.714097] 9b60: be089bc4 be089b70 8053b0f4 80539b64 00000000
>00000000 8053b1b4 811a0f80
>[ 12.722344] 9b80: 000007c1 befa4c80 be338000 00000002 be089bcc
>8094d9c0 00000000 bd89d9c0
>[ 12.730588] 9ba0: be338710 00000000 bf084000 bd89d9c0 be338000
>00000001 be089bdc be089bc8
>[ 12.738833] 9bc0: 8053b8e0 8053b08c bf084000 00000080 be089c5c
>be089be0 80414f14 8053b8c4
>[ 12.747077] 9be0: 00000000 00000000 be338710 be338600 00000040
>be338694 00000000 00000000
>[ 12.755320] 9c00: 80984c74 bd0c0900 00000000 00000000 00000000
>be33a000 be33807c be338074
>[ 12.763565] 9c20: 00000040 00000001 80060d50 80060c18 0000012c
>0000012c be7c41c0 80946100
>[ 12.771810] 9c40: be7c41c8 00000040 00000003 be338710 be089c94
>be089c60 8053b628 80414ad8
>[ 12.780053] 9c60: 80060d50 ffff8fbc 00000008 00000000 8094608c
>be088000 00000003 00000100
>[ 12.788297] 9c80: 00000003 80946080 be089cdc be089c98 8002d008
>8053b568 be089cbc be089ca8
>[ 12.796542] 9ca0: 00000001 00208040 ffff8fbb 0000000a be089cdc
>be088000 8094cd78 80940e6c
>[ 12.804786] 9cc0: be088000 00000000 be00a400 00000001 be089cf4
>be089ce0 8002d448 8002cef4
>[ 12.813032] 9ce0: 00000180 00000000 be089d24 be089cf8 80069e40
>8002d3a4 be089d50 c080e10c
>[ 12.821277] 9d00: 00000086 be089d50 8094cef0 c080e100 bd02e180
>00000000 be089d4c be089d28
>[ 12.829521] 9d20: 8000875c 80069dd8 be0789c0 800b3f20 80000153
>ffffffff be089d84 809aa580
>[ 12.837766] 9d40: be089e54 be089d50 80012b64 80008740 00000000
>00000001 809a8940 00000000
>[ 12.846009] 9d60: 002000d0 809a8940 00000000 00000000 809aa580
>bd02e180 00000000 be089e54
>[ 12.854254] 9d80: 00200010 be089d98 00080008 800b3f20 80000153
>ffffffff 00000000 81157f4c
>[ 12.862498] 9da0: be0789c0 8096a990 80ad76a0 0000000c be088000
>be7c3b50 be089e5c be089dc8
>[ 12.870744] 9dc0: 8005e760 8005dd08 be0789c0 00000000 00000458
>802c749c 00000000 be7c3ba8
>[ 12.878988] 9de0: 00000002 00000000 00000458 00000000 be089e0c
>be089e00 80ad8360 be078e18
>[ 12.887232] 9e00: 0000000c 00000000 806a02e8 00000001 00002edb
>00000000 be001880 00000010
>[ 12.895476] 9e20: be089e64 be089e30 800e78ac 00800711 be088000
>be0789c0 00000000 809aa580
>[ 12.903722] 9e40: bd02e180 ffffffff be089e64 be089e58 800b48a8
>800b3ee8 be089ef4 be089e68
>[ 12.911967] 9e60: 80027a50 800b4894 80ad76a0 0000005c be088000
>8095c8c0 be089f1c be089e88
>[ 12.920210] 9e80: 8005e760 8005dd08 be089ecc be089e98 80047bdc
>806a02f8 00000000 00000000
>[ 12.928453] 9ea0: 80047b98 00000000 00000000 be3fef80 800433d8
>00000000 80add860 be078e18
>[ 12.936696] 9ec0: 0000005c 00000000 8069aec0 00800711 be3fef80
>00000000 00000000 00000000
>[ 12.944942] 9ee0: 00000001 be088000 be089f64 be089ef8 80028f1c
>8002798c 00000000 00000000
>[ 12.953186] 9f00: 00000001 00000000 00000001 be088000 be089f54
>be089f20 8006049c 8005e3b8
>[ 12.961429] 9f20: 00000001 00000000 be0789c0 8095c8b0 bd1a5c40
>8095c8b0 8095c8d0 be3fef94
>[ 12.969677] 9f40: be3fef80 8095c8b0 8095c8d0 00000000 00000001
>be088000 be089f7c be089f68
>[ 12.977921] 9f60: 8002925c 80028e80 00000000 be3fef94 be089fac
>be089f80 80043d24 80029238
>[ 12.986165] 9f80: ffffffff 00000000 80043c48 00000000 00000000
>00000000 00000000 00000000
>[ 12.994411] 9fa0: 00000000 be089fb0 8000ece8 80043c54 00000000
>00000000 00000000 00000000
>[ 13.002653] 9fc0: 00000000 00000000 00000000 00000000 00000000
>00000000 00000000 00000000
>[ 13.010897] 9fe0: 00000000 00000000 00000000 00000000 00000013
>00000000 beff3ab1 beff3c11
>[ 13.019129] Backtrace:
>[ 13.021659] [<80539b58>] (gro_pull_from_frag0) from [<8053b0f4>]
>(dev_gro_receive+0x74/0x3e8)
>[ 13.030245] r6:00000003 r5:be338710 r4:bd89d9c0 r3:00000000
>[ 13.036069] [<8053b080>] (dev_gro_receive) from [<8053b8e0>]
>(napi_gro_receive+0x28/0xa8)
>[ 13.044303] r10:00000001 r9:be338000 r8:bd89d9c0 r7:bf084000
>r6:00000000 r5:be338710
>[ 13.052314] r4:bd89d9c0
>[ 13.054927] [<8053b8b8>] (napi_gro_receive) from [<80414f14>]
>(fec_enet_rx_napi+0x448/0xadc)
>[ 13.063423] r5:00000080 r4:bf084000
>[ 13.067099] [<80414acc>] (fec_enet_rx_napi) from [<8053b628>]
>(net_rx_action+0xcc/0x1b4)
>[ 13.075246] r10:be338710 r9:00000003 r8:00000040 r7:be7c41c8
>r6:80946100 r5:be7c41c0
>[ 13.083257] r4:0000012c
>[ 13.085865] [<8053b55c>] (net_rx_action) from [<8002d008>]
>(__do_softirq+0x120/0x268)
>[ 13.093754] r10:80946080 r9:00000003 r8:00000100 r7:00000003
>r6:be088000 r5:8094608c
>[ 13.101766] r4:00000000
>[ 13.104368] [<8002cee8>] (__do_softirq) from [<8002d448>]
>(irq_exit+0xb0/0x104)
>[ 13.111731] r10:00000001 r9:be00a400 r8:00000000 r7:be088000
>r6:80940e6c r5:8094cd78
>[ 13.119738] r4:be088000
>[ 13.122345] [<8002d398>] (irq_exit) from [<80069e40>]
>(__handle_domain_irq+0x74/0xc8)
>[ 13.130233] r4:00000000 r3:00000180
>[ 13.133907] [<80069dcc>] (__handle_domain_irq) from [<8000875c>]
>(gic_handle_irq+0x28/0x68)
>[ 13.142317] r10:00000000 r9:bd02e180 r8:c080e100 r7:8094cef0
>r6:be089d50 r5:00000086
>[ 13.150328] r4:c080e10c r3:be089d50
>[ 13.153997] [<80008734>] (gic_handle_irq) from [<80012b64>]
>(__irq_svc+0x44/0x5c)
>[ 13.161539] Exception stack(0xbe089d50 to 0xbe089d98)
>[ 13.166638] 9d40: 00000000
>00000001 809a8940 00000000
>[ 13.174884] 9d60: 002000d0 809a8940 00000000 00000000 809aa580
>bd02e180 00000000 be089e54
>[ 13.183126] 9d80: 00200010 be089d98 00080008 800b3f20 80000153 ffffffff
>[ 13.189785] r8:809aa580 r7:be089d84 r6:ffffffff r5:80000153
>r4:800b3f20 r3:be0789c0
>[ 13.197725] [<800b3edc>] (__alloc_pages_nodemask) from [<800b48a8>]
>(alloc_kmem_pages_node+0x20/0x28)
>[ 13.207008] r10:ffffffff r9:bd02e180 r8:809aa580 r7:00000000
>r6:be0789c0 r5:be088000
>[ 13.215018] r4:00800711
>[ 13.217635] [<800b4888>] (alloc_kmem_pages_node) from [<80027a50>]
>(copy_process.part.52+0xd0/0x1440)
>[ 13.226938] [<80027980>] (copy_process.part.52) from [<80028f1c>]
>(do_fork+0xa8/0x3b8)
>[ 13.234913] r10:be088000 r9:00000001 r8:00000000 r7:00000000
>r6:00000000 r5:be3fef80
>[ 13.242922] r4:00800711
>[ 13.245528] [<80028e74>] (do_fork) from [<8002925c>]
>(kernel_thread+0x30/0x38)
>[ 13.252803] r10:be088000 r9:00000001 r8:00000000 r7:8095c8d0
>r6:8095c8b0 r5:be3fef80
>[ 13.260813] r4:be3fef94
>[ 13.263419] [<8002922c>] (kernel_thread) from [<80043d24>]
>(kthreadd+0xdc/0x14c)
>[ 13.270889] [<80043c48>] (kthreadd) from [<8000ece8>]
>(ret_from_fork+0x14/0x2c)
>[ 13.278254] r10:00000000 r9:00000000 r8:00000000 r7:00000000
>r6:00000000 r5:80043c48
>[ 13.286263] r4:00000000 r3:ffffffff
>[ 13.289930] Code: e320f000 e4913004 e4914004 e4915004 (e4916004)
>[ 13.296165] ---[ end trace bc69878b7a8d6f78 ]---
>[ 13.300839] Kernel panic - not syncing: Fatal exception in interrupt
>[ 13.307258] ---[ end Kernel panic - not syncing: Fatal exception in
>interrupt
>
>Haven't started debugging this yet, but just wanted to report in case this
>sounds familiar to someone.
>
Hi, Fabio,
I test 3.18.0-rc2, and has some problems:
- most of time, imx6sx-sdb cannot resume back regardless of nfs or SD rootfs, and power key also cannnot resume back.
- when do "echo core > /sys/power/pm_test", and then do suspend/resume test, console key can wake up system, but no broken issue found in nfs.
Regards,
Andy
^ permalink raw reply
* Re: [PATCH net-next] net: introduce napi_schedule_irqoff()
From: Alexei Starovoitov @ 2014-10-29 5:13 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1414557621.631.52.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, Oct 28, 2014 at 9:40 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2014-10-28 at 21:17 -0700, Alexei Starovoitov wrote:
>> On Tue, Oct 28, 2014 at 8:30 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> > On Tue, 2014-10-28 at 18:17 -0700, Alexei Starovoitov wrote:
>> >
>> >> Interesting! Are you trying to optimize some of such NIC drivers? ;)
>> >
>> > ??
>> >
>> >> but all of 10G+ and virtio won't apply, right?
>> >
>> >
>> > Which 10G+ driver could not use this ?
>> >
>> > mlx4 patch would be :
>>
>> right.
>> but it's not a critical path for napi drivers. Why bother?
>
> You probably are missing something.
>
> This is a critical path, of course.
>
> Try netperf -t TCP_RR for example.
tried 50 parallel netperf -t TCP_RR over ixgbe
and perf top were tcp stack bits, qdisc locks and netperf itself.
What do you see?
^ permalink raw reply
* Re: [PATCH net-next] net: introduce napi_schedule_irqoff()
From: Eric Dumazet @ 2014-10-29 4:40 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: David Miller, netdev
In-Reply-To: <CAADnVQJVizFA_Tpf0FpyH0uoKZa4TMiBaNPmD_-5Z5+Vg+hV8Q@mail.gmail.com>
On Tue, 2014-10-28 at 21:17 -0700, Alexei Starovoitov wrote:
> On Tue, Oct 28, 2014 at 8:30 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > On Tue, 2014-10-28 at 18:17 -0700, Alexei Starovoitov wrote:
> >
> >> Interesting! Are you trying to optimize some of such NIC drivers? ;)
> >
> > ??
> >
> >> but all of 10G+ and virtio won't apply, right?
> >
> >
> > Which 10G+ driver could not use this ?
> >
> > mlx4 patch would be :
>
> right.
> but it's not a critical path for napi drivers. Why bother?
You probably are missing something.
This is a critical path, of course.
Try netperf -t TCP_RR for example.
^ permalink raw reply
* Re: [PATCH net-next] net: introduce napi_schedule_irqoff()
From: Alexei Starovoitov @ 2014-10-29 4:17 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1414553435.631.41.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, Oct 28, 2014 at 8:30 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2014-10-28 at 18:17 -0700, Alexei Starovoitov wrote:
>
>> Interesting! Are you trying to optimize some of such NIC drivers? ;)
>
> ??
>
>> but all of 10G+ and virtio won't apply, right?
>
>
> Which 10G+ driver could not use this ?
>
> mlx4 patch would be :
right.
but it's not a critical path for napi drivers. Why bother?
^ permalink raw reply
* Re: [PATCH net-next] net: introduce napi_schedule_irqoff()
From: Eric Dumazet @ 2014-10-29 3:30 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: David Miller, netdev
In-Reply-To: <CAADnVQJ0XD6YmUi_MBpoEgkScxp2ictQepY2YqtvfbXzF=voZQ@mail.gmail.com>
On Tue, 2014-10-28 at 18:17 -0700, Alexei Starovoitov wrote:
> Interesting! Are you trying to optimize some of such NIC drivers? ;)
??
> but all of 10G+ and virtio won't apply, right?
Which 10G+ driver could not use this ?
mlx4 patch would be :
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index c8e75dab80553c876b195361456fb49587231055..c562c1468944f9ad4319e5faaf19bf9e66d15eaf 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -878,8 +878,8 @@ void mlx4_en_rx_irq(struct mlx4_cq *mcq)
struct mlx4_en_cq *cq = container_of(mcq, struct mlx4_en_cq, mcq);
struct mlx4_en_priv *priv = netdev_priv(cq->dev);
- if (priv->port_up)
- napi_schedule(&cq->napi);
+ if (likely(priv->port_up))
+ napi_schedule_irqoff(&cq->napi);
else
mlx4_en_arm_cq(priv, cq);
}
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
index 34c137878545fc672dad1a3d86e11c034c0ac368..5c4062921cdf46f1a7021a39705275c33ca4de77 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
@@ -479,8 +479,8 @@ void mlx4_en_tx_irq(struct mlx4_cq *mcq)
struct mlx4_en_cq *cq = container_of(mcq, struct mlx4_en_cq, mcq);
struct mlx4_en_priv *priv = netdev_priv(cq->dev);
- if (priv->port_up)
- napi_schedule(&cq->napi);
+ if (likely(priv->port_up))
+ napi_schedule_irqoff(&cq->napi);
else
mlx4_en_arm_cq(priv, cq);
}
^ permalink raw reply related
* [PATCH net 3/3] r8152: check WORK_ENABLE in suspend function
From: Hayes Wang @ 2014-10-29 3:12 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
In-Reply-To: <1394712342-15778-69-Taiwan-albertk@realtek.com>
Avoid unnecessary behavior when autosuspend occurs during open().
The relative processes should only be run after finishing open().
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f224231..ca3c5d5 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3207,7 +3207,7 @@ static int rtl8152_suspend(struct usb_interface *intf, pm_message_t message)
netif_device_detach(netdev);
}
- if (netif_running(netdev)) {
+ if (netif_running(netdev) && test_bit(WORK_ENABLE, &tp->flags)) {
clear_bit(WORK_ENABLE, &tp->flags);
usb_kill_urb(tp->intr_urb);
tasklet_disable(&tp->tl);
--
1.9.3
^ permalink raw reply related
* [PATCH net 2/3] r8152: reset tp->speed before autoresuming in open function
From: Hayes Wang @ 2014-10-29 3:12 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: nic_swsd-Rasf1IRRPZFBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Hayes Wang
In-Reply-To: <1394712342-15778-69-Taiwan-albertk-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>
If (tp->speed & LINK_STATUS) is not zero, the rtl8152_resume()
would call rtl_start_rx() before enabling the tx/rx. Avoid this
by resetting it to zero.
Signed-off-by: Hayes Wang <hayeswang-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>
---
drivers/net/usb/r8152.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index a17ca58..f224231 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2891,6 +2891,9 @@ static int rtl8152_open(struct net_device *netdev)
if (res)
goto out;
+ /* set speed to 0 to avoid autoresume try to submit rx */
+ tp->speed = 0;
+
res = usb_autopm_get_interface(tp->intf);
if (res < 0) {
free_all_mem(tp);
@@ -2904,6 +2907,8 @@ static int rtl8152_open(struct net_device *netdev)
clear_bit(WORK_ENABLE, &tp->flags);
usb_kill_urb(tp->intr_urb);
cancel_delayed_work_sync(&tp->schedule);
+
+ /* disable the tx/rx, if the workqueue has enabled them. */
if (tp->speed & LINK_STATUS)
tp->rtl_ops.disable(tp);
}
--
1.9.3
--
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 related
* [PATCH net 1/3] r8152: clear SELECTIVE_SUSPEND when autoresuming
From: Hayes Wang @ 2014-10-29 3:12 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
In-Reply-To: <1394712342-15778-69-Taiwan-albertk@realtek.com>
The flag of SELECTIVE_SUSPEND should be cleared when autoresuming.
Otherwise, when the system suspend and resume occur, it may have
the wrong flow.
Besides, because the flag of SELECTIVE_SUSPEND couldn't be used
to check if the hw enables the relative feature, it should alwayes
be disabled in close().
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index e3d84c3..a17ca58 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2955,10 +2955,7 @@ static int rtl8152_close(struct net_device *netdev)
* be disable when autoresume occurs, because the
* netif_running() would be false.
*/
- if (test_bit(SELECTIVE_SUSPEND, &tp->flags)) {
- rtl_runtime_suspend_enable(tp, false);
- clear_bit(SELECTIVE_SUSPEND, &tp->flags);
- }
+ rtl_runtime_suspend_enable(tp, false);
tasklet_disable(&tp->tl);
tp->rtl_ops.down(tp);
@@ -3253,6 +3250,8 @@ static int rtl8152_resume(struct usb_interface *intf)
set_bit(WORK_ENABLE, &tp->flags);
}
usb_submit_urb(tp->intr_urb, GFP_KERNEL);
+ } else if (test_bit(SELECTIVE_SUSPEND, &tp->flags)) {
+ clear_bit(SELECTIVE_SUSPEND, &tp->flags);
}
mutex_unlock(&tp->control);
--
1.9.3
^ permalink raw reply related
* [PATCH net 0/3] r8152: patches for autosuspend
From: Hayes Wang @ 2014-10-29 3:12 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
There are unexpected processes when enabling autosuspend.
These patches are used to fix them.
Hayes Wang (3):
r8152: clear SELECTIVE_SUSPEND when autoresuming
r8152: reset tp->speed before autoresuming in open function
r8152: check WORK_ENABLE in suspend function
drivers/net/usb/r8152.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
--
1.9.3
^ 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