* 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
* Re: [PATCH net-next] datapath: Rename last_action() as nla_is_last() and move to netlink.h
From: Simon Horman @ 2014-10-29 2:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev, pshelar, dev, tgraf, azhou
In-Reply-To: <20141028.170808.1107344256534933398.davem@davemloft.net>
On Tue, Oct 28, 2014 at 05:08:08PM -0400, David Miller wrote:
> From: Simon Horman <simon.horman@netronome.com>
> Date: Mon, 27 Oct 2014 16:12:16 +0900
>
> > The original motivation for this change was to allow the helper to be used
> > in files other than actions.c as part of work on an odp select group
> > action.
> >
> > It was as pointed out by Thomas Graf that this helper would be best off
> > living in netlink.h. Furthermore, I think that the generic nature of this
> > helper means it is best off in netlink.h regardless of if it is used more
> > than one .c file or not. Thus, I would like it considered independent of
> > the work on an odp select group action.
> >
> > Cc: Thomas Graf <tgraf@suug.ch>
> > Cc: Pravin Shelar <pshelar@nicira.com>
> > Cc: Andy Zhou <azhou@nicira.com>
> > Signed-off-by: Simon Horman <simon.horman@netronome.com>
>
> Applied, thanks Simon.
Thanks
^ permalink raw reply
* RE: suspend/resume broken on 3.18-rc2
From: fugang.duan @ 2014-10-29 2:04 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.
>
>Regards,
>
>Fabio Estevam
I will double check it. Thanks for your report.
Regards,
Andy
^ permalink raw reply
* Re: [PATCH V3.18] rtlwifi: Add check for get_btc_status callback
From: Murilo Opsfelder Araujo @ 2014-10-29 1:43 UTC (permalink / raw)
To: Larry Finger, linville
Cc: linux-wireless, troy_tan, netdev, Mike Galbraith, Thadeu Cascardo
In-Reply-To: <1414081629-23002-1-git-send-email-Larry.Finger@lwfinger.net>
On 10/23/2014 02:27 PM, Larry Finger wrote:
> Drivers that do not use the get_btc_status() callback may not define a
> dummy routine. The caller needs to check before making the call.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Murilo Opsfelder Araujo <mopsfelder@gmail.com>
> Cc: Mike Galbraith <umgwanakikbuti@gmail.com>
> Cc: Thadeu Cascardo <cascardo@cascardo.eti.br>
> ---
>
> John,
>
> This missing statement is causing kernel crashes for several of the drivers.
> This patch should be applied ASAP.
>
> Larry
> ---
>
> drivers/net/wireless/rtlwifi/pci.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/rtlwifi/pci.c b/drivers/net/wireless/rtlwifi/pci.c
> index 667aba8..25daa87 100644
> --- a/drivers/net/wireless/rtlwifi/pci.c
> +++ b/drivers/net/wireless/rtlwifi/pci.c
> @@ -1796,7 +1796,8 @@ static int rtl_pci_start(struct ieee80211_hw *hw)
> rtl_pci_reset_trx_ring(hw);
>
> rtlpci->driver_is_goingto_unload = false;
> - if (rtlpriv->cfg->ops->get_btc_status()) {
> + if (rtlpriv->cfg->ops->get_btc_status &&
> + rtlpriv->cfg->ops->get_btc_status()) {
> rtlpriv->btcoexist.btc_ops->btc_init_variables(rtlpriv);
> rtlpriv->btcoexist.btc_ops->btc_init_hal_vars(rtlpriv);
> }
>
Hi, Larry & everyone.
This patch didn't solve and next-20141028 is still crashing on my laptop
with rtl8192se device:
http://opsfelder.com/~murilo/lkml/next-20141028_crashing.jpg
--
Murilo
^ permalink raw reply
* Re: [PATCH net-next 2/2] udp: Reset flow table for flows over unconnected sockets
From: Tom Herbert @ 2014-10-29 1:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Linux Netdev List
In-Reply-To: <1414517910.631.14.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, Oct 28, 2014 at 10:38 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2014-10-28 at 08:18 -0700, Tom Herbert wrote:
>
>> UDP tunnels are becoming increasingly common. VXLAN, FOU, GUE, geneve,
>> l2tp, esp/UDP, GRE/UDP, nvgre, etc. all rely on steering based on the
>> outer header without deep inspection. When the source port is set to
>> inner hash RFS works as is and steering is effectively done based
>> inner TCP connections. If aRFS supports UDP, then this should just
>> work also for UDP tunnels (another instance where we don't need
>> protocol specific support in devices for tunneling).
>
>
> If you really wanted to solve this, you would need to change RFS to be
> aware of the tunnel and find L4 information, instead of current
> implementation stopping at first UDP layer.
>
> But as get_rps_cpu() / __skb_flow_dissect() have no way to find this,
> you instead chose to invalidate RFS and maybe rely on RPS, because it
> might help your workload.
>
> Just to be clear : I tested the patch and saw a regression in my tests,
> sending as little as one million UDP packets per second on the target.
>
Can you describe this test so that I can try to reproduce and maybe
debug the issue you're seeing with the patch?
Thanks,
Tom
> Not only UDP rx processing was slower, but TCP flows were impacted.
>
> With a table of 65536 slots, each slot was written 16 times per second
> in average.
>
> Google kernels have RFS_Hit/FRS_Miss snmp counters to catch this kind of
> problems. Maybe I should upstream this part.
>
>
>
^ permalink raw reply
* Re: [PATCH net-next] net: introduce napi_schedule_irqoff()
From: Alexei Starovoitov @ 2014-10-29 1:17 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1414544713.631.30.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, Oct 28, 2014 at 6:05 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> napi_schedule() can be called from any context and has to mask hard
> irqs.
>
> Add a variant that can only be called from hard interrupts handlers
> or when irqs are already masked.
>
> Many NIC drivers can use it from their hard IRQ handler instead of
> generic variant.
Interesting! Are you trying to optimize some of such NIC drivers? ;)
but all of 10G+ and virtio won't apply, right?
^ permalink raw reply
* [PATCH net-next] net: introduce napi_schedule_irqoff()
From: Eric Dumazet @ 2014-10-29 1:05 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
napi_schedule() can be called from any context and has to mask hard
irqs.
Add a variant that can only be called from hard interrupts handlers
or when irqs are already masked.
Many NIC drivers can use it from their hard IRQ handler instead of
generic variant.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/linux/netdevice.h | 13 +++++++++++++
net/core/dev.c | 15 ++++++++++++++-
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 74fd5d37f15a472239c1c63cebe7ce9e59fc4c90..c85e065122460e9f077bcb6788018be38e1d7ddf 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -386,6 +386,7 @@ typedef enum rx_handler_result rx_handler_result_t;
typedef rx_handler_result_t rx_handler_func_t(struct sk_buff **pskb);
void __napi_schedule(struct napi_struct *n);
+void __napi_schedule_irqoff(struct napi_struct *n);
static inline bool napi_disable_pending(struct napi_struct *n)
{
@@ -420,6 +421,18 @@ static inline void napi_schedule(struct napi_struct *n)
__napi_schedule(n);
}
+/**
+ * napi_schedule_irqoff - schedule NAPI poll
+ * @n: napi context
+ *
+ * Variant of napi_schedule(), assuming hard irqs are masked.
+ */
+static inline void napi_schedule_irqoff(struct napi_struct *n)
+{
+ if (napi_schedule_prep(n))
+ __napi_schedule_irqoff(n);
+}
+
/* Try to reschedule poll. Called by dev->poll() after napi_complete(). */
static inline bool napi_reschedule(struct napi_struct *napi)
{
diff --git a/net/core/dev.c b/net/core/dev.c
index b793e3521a3631319bf4d0e7c17c0c9a933331da..759940cdf89635d58778502276d9914e47f837f9 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4372,7 +4372,8 @@ static int process_backlog(struct napi_struct *napi, int quota)
* __napi_schedule - schedule for receive
* @n: entry to schedule
*
- * The entry's receive function will be scheduled to run
+ * The entry's receive function will be scheduled to run.
+ * Consider using __napi_schedule_irqoff() if hard irqs are masked.
*/
void __napi_schedule(struct napi_struct *n)
{
@@ -4384,6 +4385,18 @@ void __napi_schedule(struct napi_struct *n)
}
EXPORT_SYMBOL(__napi_schedule);
+/**
+ * __napi_schedule_irqoff - schedule for receive
+ * @n: entry to schedule
+ *
+ * Variant of __napi_schedule() assuming hard irqs are masked
+ */
+void __napi_schedule_irqoff(struct napi_struct *n)
+{
+ ____napi_schedule(this_cpu_ptr(&softnet_data), n);
+}
+EXPORT_SYMBOL(__napi_schedule_irqoff);
+
void __napi_complete(struct napi_struct *n)
{
BUG_ON(!test_bit(NAPI_STATE_SCHED, &n->state));
^ permalink raw reply related
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2014-10-29 0:14 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Vince Bridgers, Viet Nga Dao
[-- Attachment #1: Type: text/plain, Size: 604 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/phy/marvell.c between commit 99d881f993f0 ("net: phy: Add
SGMII Configuration for Marvell 88E1145 Initialization") from the net
tree and commit b02241755d0e ("net: phy: Adding SGMII support for
Marvell 88ee1145 driver") from the net-next tree.
I fixed it up (they are basically the same patch :-( so I just fixed up
the differences and basically used the net tree version) and can carry
the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH net-next 1/3] bpf: reduce verifier memory consumption
From: Alexei Starovoitov @ 2014-10-28 22:11 UTC (permalink / raw)
To: David S. Miller
Cc: Hannes Frederic Sowa, Eric Dumazet, Daniel Borkmann,
Andy Lutomirski, netdev, linux-kernel
In-Reply-To: <1414534303-9906-1-git-send-email-ast@plumgrid.com>
verifier keeps track of register state spilled to stack.
registers are 8-byte wide and always aligned, so instead of tracking them
in every byte-sized stack slot, use MAX_BPF_STACK / 8 array to track
spilled register state.
Though verifier runs in user context and its state freed immediately
after verification, it makes sense to reduce its memory usage.
This optimization reduces sizeof(struct verifier_state)
from 12464 to 1712 on 64-bit and from 6232 to 1112 on 32-bit.
Note, this patch doesn't change existing limits, which are there to bound
time and memory during verification: 4k total number of insns in a program,
1k number of jumps (states to visit) and 32k number of processed insn
(since an insn may be visited multiple times). Theoretical worst case memory
during verification is 1712 * 1k = 17Mbyte. Out-of-memory situation triggers
cleanup and rejects the program.
Suggested-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
---
kernel/bpf/verifier.c | 101 ++++++++++++++++++++++++++++---------------------
1 file changed, 57 insertions(+), 44 deletions(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 9f81818f2941..b6a1f7c14a67 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -153,22 +153,19 @@ struct reg_state {
enum bpf_stack_slot_type {
STACK_INVALID, /* nothing was stored in this stack slot */
- STACK_SPILL, /* 1st byte of register spilled into stack */
- STACK_SPILL_PART, /* other 7 bytes of register spill */
+ STACK_SPILL, /* register spilled into stack */
STACK_MISC /* BPF program wrote some data into this slot */
};
-struct bpf_stack_slot {
- enum bpf_stack_slot_type stype;
- struct reg_state reg_st;
-};
+#define BPF_REG_SIZE 8 /* size of eBPF register in bytes */
/* state of the program:
* type of all registers and stack info
*/
struct verifier_state {
struct reg_state regs[MAX_BPF_REG];
- struct bpf_stack_slot stack[MAX_BPF_STACK];
+ u8 stack_slot_type[MAX_BPF_STACK];
+ struct reg_state spilled_regs[MAX_BPF_STACK / BPF_REG_SIZE];
};
/* linked list of verifier states used to prune search */
@@ -259,10 +256,10 @@ static void print_verifier_state(struct verifier_env *env)
env->cur_state.regs[i].map_ptr->key_size,
env->cur_state.regs[i].map_ptr->value_size);
}
- for (i = 0; i < MAX_BPF_STACK; i++) {
- if (env->cur_state.stack[i].stype == STACK_SPILL)
+ for (i = 0; i < MAX_BPF_STACK; i += BPF_REG_SIZE) {
+ if (env->cur_state.stack_slot_type[i] == STACK_SPILL)
verbose(" fp%d=%s", -MAX_BPF_STACK + i,
- reg_type_str[env->cur_state.stack[i].reg_st.type]);
+ reg_type_str[env->cur_state.spilled_regs[i / BPF_REG_SIZE].type]);
}
verbose("\n");
}
@@ -539,8 +536,10 @@ static int bpf_size_to_bytes(int bpf_size)
static int check_stack_write(struct verifier_state *state, int off, int size,
int value_regno)
{
- struct bpf_stack_slot *slot;
int i;
+ /* caller checked that off % size == 0 and -MAX_BPF_STACK <= off < 0,
+ * so it's aligned access and [off, off + size) are within stack limits
+ */
if (value_regno >= 0 &&
(state->regs[value_regno].type == PTR_TO_MAP_VALUE ||
@@ -548,30 +547,24 @@ static int check_stack_write(struct verifier_state *state, int off, int size,
state->regs[value_regno].type == PTR_TO_CTX)) {
/* register containing pointer is being spilled into stack */
- if (size != 8) {
+ if (size != BPF_REG_SIZE) {
verbose("invalid size of register spill\n");
return -EACCES;
}
- slot = &state->stack[MAX_BPF_STACK + off];
- slot->stype = STACK_SPILL;
/* save register state */
- slot->reg_st = state->regs[value_regno];
- for (i = 1; i < 8; i++) {
- slot = &state->stack[MAX_BPF_STACK + off + i];
- slot->stype = STACK_SPILL_PART;
- slot->reg_st.type = UNKNOWN_VALUE;
- slot->reg_st.map_ptr = NULL;
- }
- } else {
+ state->spilled_regs[(MAX_BPF_STACK + off) / BPF_REG_SIZE] =
+ state->regs[value_regno];
+ for (i = 0; i < BPF_REG_SIZE; i++)
+ state->stack_slot_type[MAX_BPF_STACK + off + i] = STACK_SPILL;
+ } else {
/* regular write of data into stack */
- for (i = 0; i < size; i++) {
- slot = &state->stack[MAX_BPF_STACK + off + i];
- slot->stype = STACK_MISC;
- slot->reg_st.type = UNKNOWN_VALUE;
- slot->reg_st.map_ptr = NULL;
- }
+ state->spilled_regs[(MAX_BPF_STACK + off) / BPF_REG_SIZE] =
+ (struct reg_state) {};
+
+ for (i = 0; i < size; i++)
+ state->stack_slot_type[MAX_BPF_STACK + off + i] = STACK_MISC;
}
return 0;
}
@@ -579,19 +572,18 @@ static int check_stack_write(struct verifier_state *state, int off, int size,
static int check_stack_read(struct verifier_state *state, int off, int size,
int value_regno)
{
+ u8 *slot_type;
int i;
- struct bpf_stack_slot *slot;
- slot = &state->stack[MAX_BPF_STACK + off];
+ slot_type = &state->stack_slot_type[MAX_BPF_STACK + off];
- if (slot->stype == STACK_SPILL) {
- if (size != 8) {
+ if (slot_type[0] == STACK_SPILL) {
+ if (size != BPF_REG_SIZE) {
verbose("invalid size of register spill\n");
return -EACCES;
}
- for (i = 1; i < 8; i++) {
- if (state->stack[MAX_BPF_STACK + off + i].stype !=
- STACK_SPILL_PART) {
+ for (i = 1; i < BPF_REG_SIZE; i++) {
+ if (slot_type[i] != STACK_SPILL) {
verbose("corrupted spill memory\n");
return -EACCES;
}
@@ -599,12 +591,12 @@ static int check_stack_read(struct verifier_state *state, int off, int size,
if (value_regno >= 0)
/* restore register state from stack */
- state->regs[value_regno] = slot->reg_st;
+ state->regs[value_regno] =
+ state->spilled_regs[(MAX_BPF_STACK + off) / BPF_REG_SIZE];
return 0;
} else {
for (i = 0; i < size; i++) {
- if (state->stack[MAX_BPF_STACK + off + i].stype !=
- STACK_MISC) {
+ if (slot_type[i] != STACK_MISC) {
verbose("invalid read from stack off %d+%d size %d\n",
off, i, size);
return -EACCES;
@@ -747,7 +739,7 @@ static int check_stack_boundary(struct verifier_env *env,
}
for (i = 0; i < access_size; i++) {
- if (state->stack[MAX_BPF_STACK + off + i].stype != STACK_MISC) {
+ if (state->stack_slot_type[MAX_BPF_STACK + off + i] != STACK_MISC) {
verbose("invalid indirect read from stack off %d+%d size %d\n",
off, i, access_size);
return -EACCES;
@@ -1417,12 +1409,33 @@ static bool states_equal(struct verifier_state *old, struct verifier_state *cur)
}
for (i = 0; i < MAX_BPF_STACK; i++) {
- if (memcmp(&old->stack[i], &cur->stack[i],
- sizeof(old->stack[0])) != 0) {
- if (old->stack[i].stype == STACK_INVALID)
- continue;
+ if (old->stack_slot_type[i] == STACK_INVALID)
+ continue;
+ if (old->stack_slot_type[i] != cur->stack_slot_type[i])
+ /* Ex: old explored (safe) state has STACK_SPILL in
+ * this stack slot, but current has has STACK_MISC ->
+ * this verifier states are not equivalent,
+ * return false to continue verification of this path
+ */
return false;
- }
+ if (i % BPF_REG_SIZE)
+ continue;
+ if (memcmp(&old->spilled_regs[i / BPF_REG_SIZE],
+ &cur->spilled_regs[i / BPF_REG_SIZE],
+ sizeof(old->spilled_regs[0])))
+ /* when explored and current stack slot types are
+ * the same, check that stored pointers types
+ * are the same as well.
+ * Ex: explored safe path could have stored
+ * (struct reg_state) {.type = PTR_TO_STACK, .imm = -8}
+ * but current path has stored:
+ * (struct reg_state) {.type = PTR_TO_STACK, .imm = -16}
+ * such verifier states are not equivalent.
+ * return false to continue verification of this path
+ */
+ return false;
+ else
+ continue;
}
return true;
}
--
1.7.9.5
^ permalink raw reply related
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