* sparc64 and ARM64 JIT bug (was Re: LLVM 4.0 code generation bug)
From: David Miller @ 2017-05-02 3:02 UTC (permalink / raw)
To: ast; +Cc: daniel, netdev, xi.wang, catalin.marinas
In-Reply-To: <e75404e5-c68d-6f08-afdc-e57174b88a32@fb.com>
From: Alexei Starovoitov <ast@fb.com>
Date: Mon, 1 May 2017 19:39:33 -0700
> On 5/1/17 7:31 PM, David Miller wrote:
>>
>> If the last BPF instruction before exit is a ldimm64, branches to the
>> exit point at the wrong location.
>>
>> Here is what I get from test_pkt_access.c on sparc:
>>
>> 0000000000000000 <process>:
>> 0: b7 00 00 00 00 00 00 02 mov r0, 2
>> 8: 61 21 00 50 00 00 00 00 ldw r2, [r1+80]
>> 10: 61 11 00 4c 00 00 00 00 ldw r1, [r1+76]
>> 18: bf 41 00 00 00 00 00 00 mov r4, r1
>> 20: 07 40 00 00 00 00 00 0e add r4, 14
>> 28: 2d 42 00 25 00 00 00 00 jgt r4, r2, 148 <LBB0_11>
>> ...
>> 0000000000000148 <LBB0_11>:
>> 148: 18 00 00 00 ff ff ff ff ldimm64 r0, 4294967295
>> 150: 00 00 00 00 00 00 00 00
>>
>> 0000000000000158 <LBB0_12>:
>> 158: 95 00 00 00 00 00 00 00 exit
...
> looks fine to me. it jumps to 0x158,
> since offset 0 is the next insn after jump which is 0x30
> That's how classic bpf defined jumps.
Ok, it seems that both arm64 and sparc64's JIT handle the above
situation improperly.
They both work by recording the instruction offsets in an array which
is indexed off by one. It it built like this:
for (i = 0; i < prog->len; i++) {
const struct bpf_insn *insn = &prog->insnsi[i];
int ret;
ret = build_insn(insn, ctx);
ctx->offset[i] = ctx->idx;
if (ret > 0) {
i++;
continue;
}
if (ret)
return ret;
}
That is, we record the JIT'd instruction offset for BPF instruction
'idx' in array entry 'idx - 1'.
Then when we emit a relative branch, we lookup the destination offset
using "ctx->offset[this_insn_idx + insn->off]"
And this works most of the time. It doesn't work for the scenerio
above, because 'idx - 1' is not necessarily the index of the previous
BPF instruction. Instead, that might point to the second half of an
lddimm64 instruction.
This bug was introduced by commit
8eee539ddea09bccae2426f09b0ba6a18b72b691 ("arm64: bpf: fix
out-of-bounds read in bpf2a64_offset()") and I copied the logic into
sparc64 :-)
^ permalink raw reply
* Re: [PATCH v3 binutils] Add BPF support to binutils...
From: Alexei Starovoitov @ 2017-05-02 2:49 UTC (permalink / raw)
To: David Miller; +Cc: daniel, aconole, netdev, xdp-newbies
In-Reply-To: <20170430.142104.1845572453793505873.davem@davemloft.net>
On 4/30/17 11:21 AM, David Miller wrote:
> built with:
>
> clang -O2 -target bpfel -g -c x.c -o x.o
>
> readelf can see it just fine:
>
> [davem@localhost binutils]$ ./readelf --debug-dump=loc ./xel.o
> Contents of the .debug_loc section:
>
> Offset Begin End Expression
> 00000000 0000000000000000 0000000000000010 (DW_OP_reg1 (r1))
> 00000013 <End of list>
> 00000023 0000000000000010 0000000000000020 (DW_OP_constu: 590618314553; DW_OP_stack_value)
> 0000003d 0000000000000020 0000000000000030 (DW_OP_reg1 (r1))
> 00000050 <End of list>
>
> But with big-endian:
>
> [davem@localhost binutils]$ ./readelf --debug-dump=loc ./xeb.o
> readelf: Warning: Invalid pointer size (0) in compunit header, using 4 instead
> readelf: Warning: Bogus end-of-siblings marker detected at offset 27 in .debug_info section
> readelf: Warning: Bogus end-of-siblings marker detected at offset 28 in .debug_info section
> readelf: Warning: DIE at offset 0x29 refers to abbreviation number 48 which does not exist
> readelf: Warning: Unable to load/parse the .debug_info section, so cannot interpret the .debug_loc section.
yeah. clang emitted dwarf for big-endian is broken.
This dwarf stuff is too complicated for normal human beings.
The tight packing making debugging it quite painful.
^ permalink raw reply
* [PATCH net v2] net: hns: fix ethtool_get_strings overflow in hns driver
From: Timmy Li @ 2017-05-02 2:46 UTC (permalink / raw)
To: davem, huangdaode, lipeng321, yisen.zhuang, salil.mehta,
yankejian
Cc: mbrugger, netdev, linux-kernel, linuxarm, Timmy Li
hns_get_sset_count() returns HNS_NET_STATS_CNT and the data space allocated
is not enough for ethtool_get_strings(), which will cause random memory
corruption.
When SLAB and DEBUG_SLAB are both enabled, memory corruptions like the
the following can be observed without this patch:
[ 43.115200] Slab corruption (Not tainted): Acpi-ParseExt start=ffff801fb0b69030, len=80
[ 43.115206] Redzone: 0x9f911029d006462/0x5f78745f31657070.
[ 43.115208] Last user: [<5f7272655f746b70>](0x5f7272655f746b70)
[ 43.115214] 010: 70 70 65 31 5f 74 78 5f 70 6b 74 00 6b 6b 6b 6b ppe1_tx_pkt.kkkk
[ 43.115217] 030: 70 70 65 31 5f 74 78 5f 70 6b 74 5f 6f 6b 00 6b ppe1_tx_pkt_ok.k
[ 43.115218] Next obj: start=ffff801fb0b69098, len=80
[ 43.115220] Redzone: 0x706d655f6f666966/0x9f911029d74e35b.
[ 43.115229] Last user: [<ffff0000084b11b0>](acpi_os_release_object+0x28/0x38)
[ 43.115231] 000: 74 79 00 6b 6b 6b 6b 6b 70 70 65 31 5f 74 78 5f ty.kkkkkppe1_tx_
[ 43.115232] 010: 70 6b 74 5f 65 72 72 5f 63 73 75 6d 5f 66 61 69 pkt_err_csum_fai
Signed-off-by: Timmy Li <lixiaoping3@huawei.com>
---
Changelog:
v1 -> v2:
* Remove unnecessary parenthesis
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
index 3382441..310cc92 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
@@ -672,7 +672,7 @@ static void hns_gmac_get_strings(u32 stringset, u8 *data)
static int hns_gmac_get_sset_count(int stringset)
{
- if (stringset == ETH_SS_STATS)
+ if (stringset == ETH_SS_STATS || stringset == ETH_SS_PRIV_FLAGS)
return ARRAY_SIZE(g_gmac_stats_string);
return 0;
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
index 6ea8722..4ecb809 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
@@ -422,7 +422,7 @@ void hns_ppe_update_stats(struct hns_ppe_cb *ppe_cb)
int hns_ppe_get_sset_count(int stringset)
{
- if (stringset == ETH_SS_STATS)
+ if (stringset == ETH_SS_STATS || stringset == ETH_SS_PRIV_FLAGS)
return ETH_PPE_STATIC_NUM;
return 0;
}
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
index f0ed80d6..c176db0 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
@@ -799,7 +799,7 @@ void hns_rcb_get_stats(struct hnae_queue *queue, u64 *data)
*/
int hns_rcb_get_ring_sset_count(int stringset)
{
- if (stringset == ETH_SS_STATS)
+ if (stringset == ETH_SS_STATS || stringset == ETH_SS_PRIV_FLAGS)
return HNS_RING_STATIC_REG_NUM;
return 0;
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
index aae830a..faacab8 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
@@ -793,7 +793,7 @@ static void hns_xgmac_get_strings(u32 stringset, u8 *data)
*/
static int hns_xgmac_get_sset_count(int stringset)
{
- if (stringset == ETH_SS_STATS)
+ if (stringset == ETH_SS_STATS || stringset == ETH_SS_PRIV_FLAGS)
return ARRAY_SIZE(g_xgmac_stats_string);
return 0;
--
1.9.1
^ permalink raw reply related
* those bpf binutils testsuite failures..
From: David Miller @ 2017-05-02 2:45 UTC (permalink / raw)
To: aconole; +Cc: netdev
I wonder if whatever tool you used to get rid of trailing whitespace
did so in the testsuite foo.d files too? That definitely is
undesirable :-)
^ permalink raw reply
* Re: net/ipv6: use-after-free in __call_rcu/in6_dev_finish_destroy_rcu
From: David Ahern @ 2017-05-02 2:44 UTC (permalink / raw)
To: Andrey Konovalov, Paul E. McKenney
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Josh Triplett,
Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, Eric Dumazet,
Cong Wang, Dmitry Vyukov, Kostya Serebryany, syzkaller
In-Reply-To: <CAAeHK+yzuh7mAmLR9DgHsLYBykqD8YhFcv=Nx6Az_f+PV_YMzw@mail.gmail.com>
On 4/26/17 9:15 AM, Andrey Konovalov wrote:
> +David
>
> I've enabled CONFIG_DEBUG_OBJECTS_RCU_HEAD and this is what I get.
>
> Apparently the rcu warning is related to the fib6_del_route bug I've
> been trying to reproduce:
> https://groups.google.com/forum/#!msg/syzkaller/3SS80JbVPKA/2tfIAcW7DwAJ
>
> Adding David, who provided the fix:
> https://patchwork.ozlabs.org/patch/754913/
>
> I've managed to extract a reproducer, attached together with the
> .config that I used.
>
> On commit 5a7ad1146caa895ad718a534399e38bd2ba721b7 (4.11-rc8) with
> David's patch applied.
>
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 5911 at lib/debugobjects.c:289
> debug_print_object+0x175/0x210
> ODEBUG: activate active (active state 1) object type: rcu_head hint:
> (null)
> Modules linked in:
> CPU: 1 PID: 5911 Comm: a.out Not tainted 4.11.0-rc8+ #271
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:16
> dump_stack+0x192/0x22d lib/dump_stack.c:52
> __warn+0x19f/0x1e0 kernel/panic.c:549
> warn_slowpath_fmt+0xe0/0x120 kernel/panic.c:564
> debug_print_object+0x175/0x210 lib/debugobjects.c:286
> debug_object_activate+0x574/0x7e0 lib/debugobjects.c:442
> debug_rcu_head_queue kernel/rcu/rcu.h:75
> __call_rcu.constprop.76+0xff/0x9c0 kernel/rcu/tree.c:3229
> call_rcu_sched+0x12/0x20 kernel/rcu/tree.c:3288
> rt6_rcu_free net/ipv6/ip6_fib.c:158
> rt6_release+0x1ea/0x290 net/ipv6/ip6_fib.c:188
> fib6_del_route net/ipv6/ip6_fib.c:1461
I think I got to the bottom of this one.
With your config, ip6_tunnel is compiled in.
The program runs in a very tight loop, calling 'unshare -n' and then
spawns 2 sets of 14 threads running random ioctl calls. The networking
sequence:
1. New network namespace created via unshare -n
- ip6tnl0 device is created in down state
2. address added to ip6tnl0 (equivalent to ip -6 addr add dev ip6tnl0
fd00::bb/1)
- the host route is created and inserted into FIB
3. ip6tnl0 is brought up - starts DAD on the address
4. exit namespace
- teardown / cleanup sequence starts
- lo teardown appears to happen BEFORE teardown of ip6tunl0
+ removes host route from FIB
+ host route added to rcu callback list: call_rcu(&rt->dst.rcu_head,
dst_rcu_free);
+ rcu callback has not run yet, so rt is NOT on the gc list so it has
NOT been marked obsolete
5. worker_thread runs addrconf_dad_completed
- calls ipv6_ifa_notify which inserts the host route
All of that happens very quickly. The result is that a route that has
been deleted and added to the RCU list is re-inserted into the FIB. What
happens next depends on order -- in this case the exit namespace
eventually gets to cleaning up ip6tnl0 which removes the host route from
the FIB, calls the rcu function for cleanup -- and triggers the double
rcu trace.
I have a hack that flags this sequence and prevents the re-insertion
following DAD. That allows the command to run until it consumes all 2G
of memory the VM has -- about 600+ iterations without triggering any
stack traces.
^ permalink raw reply
* Re: LLVM 4.0 code generation bug
From: David Miller @ 2017-05-02 2:41 UTC (permalink / raw)
To: ast; +Cc: daniel, netdev
In-Reply-To: <e75404e5-c68d-6f08-afdc-e57174b88a32@fb.com>
From: Alexei Starovoitov <ast@fb.com>
Date: Mon, 1 May 2017 19:39:33 -0700
> On 5/1/17 7:31 PM, David Miller wrote:
>>
>> If the last BPF instruction before exit is a ldimm64, branches to the
>> exit point at the wrong location.
>>
>> Here is what I get from test_pkt_access.c on sparc:
>>
>> 0000000000000000 <process>:
>> 0: b7 00 00 00 00 00 00 02 mov r0, 2
>> 8: 61 21 00 50 00 00 00 00 ldw r2, [r1+80]
>> 10: 61 11 00 4c 00 00 00 00 ldw r1, [r1+76]
>> 18: bf 41 00 00 00 00 00 00 mov r4, r1
>> 20: 07 40 00 00 00 00 00 0e add r4, 14
>> 28: 2d 42 00 25 00 00 00 00 jgt r4, r2, 148 <LBB0_11>
>> ...
>> 0000000000000148 <LBB0_11>:
>> 148: 18 00 00 00 ff ff ff ff ldimm64 r0, 4294967295
>> 150: 00 00 00 00 00 00 00 00
>>
>> 0000000000000158 <LBB0_12>:
>> 158: 95 00 00 00 00 00 00 00 exit
>>
>> The offset field in the "jgt" instruction is 0x25 which multiplied by
>> 8 is 0x128, add 0x128 to the instruction location which is 0x28, and
>> we get 0x150, which is the second 64-bit chunk of the ldimm64
>> instruction.
>
> looks fine to me. it jumps to 0x158,
> since offset 0 is the next insn after jump which is 0x30
> That's how classic bpf defined jumps.
Ok, let me first fix the binutils disassembler :-)
^ permalink raw reply
* Re: LLVM 4.0 code generation bug
From: Alexei Starovoitov @ 2017-05-02 2:39 UTC (permalink / raw)
To: David Miller; +Cc: daniel, netdev
In-Reply-To: <20170501.223136.1311890506697006266.davem@davemloft.net>
On 5/1/17 7:31 PM, David Miller wrote:
>
> If the last BPF instruction before exit is a ldimm64, branches to the
> exit point at the wrong location.
>
> Here is what I get from test_pkt_access.c on sparc:
>
> 0000000000000000 <process>:
> 0: b7 00 00 00 00 00 00 02 mov r0, 2
> 8: 61 21 00 50 00 00 00 00 ldw r2, [r1+80]
> 10: 61 11 00 4c 00 00 00 00 ldw r1, [r1+76]
> 18: bf 41 00 00 00 00 00 00 mov r4, r1
> 20: 07 40 00 00 00 00 00 0e add r4, 14
> 28: 2d 42 00 25 00 00 00 00 jgt r4, r2, 148 <LBB0_11>
> ...
> 0000000000000148 <LBB0_11>:
> 148: 18 00 00 00 ff ff ff ff ldimm64 r0, 4294967295
> 150: 00 00 00 00 00 00 00 00
>
> 0000000000000158 <LBB0_12>:
> 158: 95 00 00 00 00 00 00 00 exit
>
> The offset field in the "jgt" instruction is 0x25 which multiplied by
> 8 is 0x128, add 0x128 to the instruction location which is 0x28, and
> we get 0x150, which is the second 64-bit chunk of the ldimm64
> instruction.
looks fine to me. it jumps to 0x158,
since offset 0 is the next insn after jump which is 0x30
That's how classic bpf defined jumps.
^ permalink raw reply
* LLVM 4.0 code generation bug
From: David Miller @ 2017-05-02 2:31 UTC (permalink / raw)
To: ast; +Cc: daniel, netdev
If the last BPF instruction before exit is a ldimm64, branches to the
exit point at the wrong location.
Here is what I get from test_pkt_access.c on sparc:
0000000000000000 <process>:
0: b7 00 00 00 00 00 00 02 mov r0, 2
8: 61 21 00 50 00 00 00 00 ldw r2, [r1+80]
10: 61 11 00 4c 00 00 00 00 ldw r1, [r1+76]
18: bf 41 00 00 00 00 00 00 mov r4, r1
20: 07 40 00 00 00 00 00 0e add r4, 14
28: 2d 42 00 25 00 00 00 00 jgt r4, r2, 148 <LBB0_11>
...
0000000000000148 <LBB0_11>:
148: 18 00 00 00 ff ff ff ff ldimm64 r0, 4294967295
150: 00 00 00 00 00 00 00 00
0000000000000158 <LBB0_12>:
158: 95 00 00 00 00 00 00 00 exit
The offset field in the "jgt" instruction is 0x25 which multiplied by
8 is 0x128, add 0x128 to the instruction location which is 0x28, and
we get 0x150, which is the second 64-bit chunk of the ldimm64
instruction.
At least this is what my JIT is interpreting this situation as, am I
off by one or something?
^ permalink raw reply
* RE: [PATCH net v3] driver: dummy: Fix one possbile memleak when fail to register_netdevice
From: Gao Feng @ 2017-05-02 2:15 UTC (permalink / raw)
To: 'David Miller'; +Cc: sd, phil, stephen, zhangshengju, netdev
In-Reply-To: <20170430.225336.754367857537363635.davem@davemloft.net>
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Monday, May 1, 2017 10:54 AM
>
> Please, Gao, submit this as a proper, numbered, patch series with a proper
> header posting.
>
> That way you can explain why you took this strategy to fix this problem,
> compared to your original approach.
>
> Thanks.
OK, no problem.
Regards
Feng
^ permalink raw reply
* Re: [PATCH net] tcp: fix wraparound issue in tcp_lp
From: Eric Dumazet @ 2017-05-02 1:58 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <1493687087.31837.30.camel@edumazet-glaptop3.roam.corp.google.com>
On Mon, 2017-05-01 at 18:04 -0700, Eric Dumazet wrote:
>
> Simply to not perform (tcp_time_stamp - tp->rx_opt.rcv_tsecr) twice.
>
> jiffies being volatile, this can not be optimized by the compiler.
>
> I have a patch series (for linux-4.13) that will switch TCP stack to 1ms
> TS options, regardless of CONFIG_HZ value, and when cooking it I found
> this bug.
I forgot to say that after this upcoming patch series, tcp_time_stamp
will become a more expensive function, no longer a plain (u32)jiffies.
^ permalink raw reply
* Re: linux-next: build failure after merge of the block tree
From: Jens Axboe @ 2017-05-02 1:45 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, Networking, Linux-Next Mailing List,
Linux Kernel Mailing List, Josef Bacik, Johannes Berg, Linus
In-Reply-To: <20170502113720.0e5a6ab4@canb.auug.org.au>
On May 1, 2017, at 7:37 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Jens,
>
>> On Mon, 1 May 2017 19:09:34 -0600 Jens Axboe <axboe@kernel.dk> wrote:
>>
>> Indeed, I have warned Linus about it. Thanks Stephen.
>
> Thanks.
>
> BTW, (unusually) I did not see your pull request(s) ...
I CC'ed linux-block, so they showed up there at least.
^ permalink raw reply
* Re: linux-next: build failure after merge of the block tree
From: Stephen Rothwell @ 2017-05-02 1:37 UTC (permalink / raw)
To: Jens Axboe
Cc: David Miller, Networking, Linux-Next Mailing List,
Linux Kernel Mailing List, Josef Bacik, Johannes Berg, Linus
In-Reply-To: <5CC6C5A2-B648-45F4-ACD4-AB27CE9AF9BF@kernel.dk>
Hi Jens,
On Mon, 1 May 2017 19:09:34 -0600 Jens Axboe <axboe@kernel.dk> wrote:
>
> Indeed, I have warned Linus about it. Thanks Stephen.
Thanks.
BTW, (unusually) I did not see your pull request(s) ...
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: [PATCH] flower: check unused bits in MPLS fields
From: Jamal Hadi Salim @ 2017-05-02 1:37 UTC (permalink / raw)
To: Benjamin LaHaise, netdev
Cc: David Miller, Simon Horman, Jakub Kicinski, Jiri Pirko
In-Reply-To: <1493647120-17406-1-git-send-email-benjamin.lahaise@netronome.com>
On 17-05-01 09:58 AM, Benjamin LaHaise wrote:
> Since several of the the netlink attributes used to configure the flower
> classifier's MPLS TC, BOS and Label fields have additional bits which are
> unused, check those bits to ensure that they are actually 0 as suggested
> by Jamal.
>
> Signed-off-by: Benjamin LaHaise <benjamin.lahaise@netronome.com>
> Cc: David Miller <davem@davemloft.net>
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> Cc: Simon Horman <simon.horman@netronome.com>
> Cc: Jakub Kicinski <kubakici@wp.pl>
> Cc: Jiri Pirko <jiri@resnulli.us>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* Re: [PATCH/RFC net-next 0/4] net/sched: cls_flower: avoid false matching of truncated packets
From: Jamal Hadi Salim @ 2017-05-02 1:35 UTC (permalink / raw)
To: Simon Horman
Cc: Jiri Pirko, Cong Wang, Dinan Gunawardena, netdev, oss-drivers
In-Reply-To: <20170501103645.GC24399@vergenet.net>
On 17-05-01 06:36 AM, Simon Horman wrote:
> On Sun, Apr 30, 2017 at 09:51:30AM -0400, Jamal Hadi Salim wrote:
>> On 17-04-28 10:14 AM, Simon Horman wrote:
[..]
>> minimal some flag should qualify it as "truncated".
>
> Would changing TCA_FLOWER_HEADER_PARSE_ERR_ACT to
> TCA_FLOWER_META_TRUNCATED help?
>
I think so - as long as you are able to recognize the truncated
vs real 0 port/type etc.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net-next] xdp: fix parameter kdoc for extack
From: David Miller @ 2017-05-02 1:30 UTC (permalink / raw)
To: jakub.kicinski; +Cc: netdev, kbuild-all, fengguang.wu
In-Reply-To: <20170501225343.22157-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Mon, 1 May 2017 15:53:43 -0700
> Fix kdoc parameter spelling from extact to extack.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] bpf, samples: fix build warning in cookie_uid_helper_example
From: David Miller @ 2017-05-02 1:30 UTC (permalink / raw)
To: daniel; +Cc: alexei.starovoitov, netdev
In-Reply-To: <43325f50d66abec6b35439422b6c9b0211bd30e9.1493678555.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Tue, 2 May 2017 00:47:09 +0200
> Fix the following warnings triggered by 51570a5ab2b7 ("A Sample of
> using socket cookie and uid for traffic monitoring"):
...
> Fixes: 51570a5ab2b7 ("A Sample of using socket cookie and uid for traffic monitoring")
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Applied.
^ permalink raw reply
* Re: linux-next: build failure after merge of the block tree
From: Jens Axboe @ 2017-05-02 1:09 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, Networking, Linux-Next Mailing List,
Linux Kernel Mailing List, Josef Bacik, Johannes Berg, Linus
In-Reply-To: <20170502110704.79bb7760@canb.auug.org.au>
> On May 1, 2017, at 7:07 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
>> On Tue, 18 Apr 2017 13:02:29 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> After merging the block tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>>
>> drivers/block/nbd.c: In function 'nbd_genl_connect':
>> drivers/block/nbd.c:1662:10: error: too few arguments to function 'nla_parse_nested'
>> ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
>> ^
>> In file included from include/net/rtnetlink.h:5:0,
>> from include/net/sch_generic.h:12,
>> from include/linux/filter.h:20,
>> from include/net/sock.h:64,
>> from drivers/block/nbd.c:32:
>> include/net/netlink.h:754:19: note: declared here
>> static inline int nla_parse_nested(struct nlattr *tb[], int maxtype,
>> ^
>> drivers/block/nbd.c: In function 'nbd_genl_reconfigure':
>> drivers/block/nbd.c:1818:10: error: too few arguments to function 'nla_parse_nested'
>> ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
>> ^
>> In file included from include/net/rtnetlink.h:5:0,
>> from include/net/sch_generic.h:12,
>> from include/linux/filter.h:20,
>> from include/net/sock.h:64,
>> from drivers/block/nbd.c:32:
>> include/net/netlink.h:754:19: note: declared here
>> static inline int nla_parse_nested(struct nlattr *tb[], int maxtype,
>> ^
>>
>> Caused by commits
>>
>> e46c7287b1c2 ("nbd: add a basic netlink interface")
>> b7aa3d39385d ("nbd: add a reconfigure netlink command")
>>
>> interacting with commit
>>
>> fceb6435e852 ("netlink: pass extended ACK struct to parsing functions")
>>
>> from the net-next tree.
>>
>> I have applied the following merge fix patch:
>>
>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date: Tue, 18 Apr 2017 12:59:05 +1000
>> Subject: [PATCH] nbd: fix up for nla_parse_nested() API change
>>
>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>> ---
>> drivers/block/nbd.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
>> index b78f23ce2395..5049d19f3940 100644
>> --- a/drivers/block/nbd.c
>> +++ b/drivers/block/nbd.c
>> @@ -1660,7 +1660,7 @@ static int nbd_genl_connect(struct sk_buff *skb, struct genl_info *info)
>> goto out;
>> }
>> ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
>> - nbd_sock_policy);
>> + nbd_sock_policy, NULL);
>> if (ret != 0) {
>> printk(KERN_ERR "nbd: error processing sock list\n");
>> ret = -EINVAL;
>> @@ -1816,7 +1816,7 @@ static int nbd_genl_reconfigure(struct sk_buff *skb, struct genl_info *info)
>> goto out;
>> }
>> ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
>> - nbd_sock_policy);
>> + nbd_sock_policy, NULL);
>> if (ret != 0) {
>> printk(KERN_ERR "nbd: error processing sock list\n");
>> ret = -EINVAL;
>> --
>> 2.11.0
>
> So, this merge fix is now needed when the net-next tree is merged (as
> Linus has merged the block tree).
Indeed, I have warned Linus about it. Thanks Stephen.
^ permalink raw reply
* Re: linux-next: build failure after merge of the block tree
From: Stephen Rothwell @ 2017-05-02 1:07 UTC (permalink / raw)
To: Jens Axboe, David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Josef Bacik,
Johannes Berg, Linus
In-Reply-To: <20170418130229.04289bd6@canb.auug.org.au>
Hi all,
On Tue, 18 Apr 2017 13:02:29 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the block tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/block/nbd.c: In function 'nbd_genl_connect':
> drivers/block/nbd.c:1662:10: error: too few arguments to function 'nla_parse_nested'
> ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
> ^
> In file included from include/net/rtnetlink.h:5:0,
> from include/net/sch_generic.h:12,
> from include/linux/filter.h:20,
> from include/net/sock.h:64,
> from drivers/block/nbd.c:32:
> include/net/netlink.h:754:19: note: declared here
> static inline int nla_parse_nested(struct nlattr *tb[], int maxtype,
> ^
> drivers/block/nbd.c: In function 'nbd_genl_reconfigure':
> drivers/block/nbd.c:1818:10: error: too few arguments to function 'nla_parse_nested'
> ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
> ^
> In file included from include/net/rtnetlink.h:5:0,
> from include/net/sch_generic.h:12,
> from include/linux/filter.h:20,
> from include/net/sock.h:64,
> from drivers/block/nbd.c:32:
> include/net/netlink.h:754:19: note: declared here
> static inline int nla_parse_nested(struct nlattr *tb[], int maxtype,
> ^
>
> Caused by commits
>
> e46c7287b1c2 ("nbd: add a basic netlink interface")
> b7aa3d39385d ("nbd: add a reconfigure netlink command")
>
> interacting with commit
>
> fceb6435e852 ("netlink: pass extended ACK struct to parsing functions")
>
> from the net-next tree.
>
> I have applied the following merge fix patch:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 18 Apr 2017 12:59:05 +1000
> Subject: [PATCH] nbd: fix up for nla_parse_nested() API change
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/block/nbd.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
> index b78f23ce2395..5049d19f3940 100644
> --- a/drivers/block/nbd.c
> +++ b/drivers/block/nbd.c
> @@ -1660,7 +1660,7 @@ static int nbd_genl_connect(struct sk_buff *skb, struct genl_info *info)
> goto out;
> }
> ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
> - nbd_sock_policy);
> + nbd_sock_policy, NULL);
> if (ret != 0) {
> printk(KERN_ERR "nbd: error processing sock list\n");
> ret = -EINVAL;
> @@ -1816,7 +1816,7 @@ static int nbd_genl_reconfigure(struct sk_buff *skb, struct genl_info *info)
> goto out;
> }
> ret = nla_parse_nested(socks, NBD_SOCK_MAX, attr,
> - nbd_sock_policy);
> + nbd_sock_policy, NULL);
> if (ret != 0) {
> printk(KERN_ERR "nbd: error processing sock list\n");
> ret = -EINVAL;
> --
> 2.11.0
So, this merge fix is now needed when the net-next tree is merged (as
Linus has merged the block tree).
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: [PATCH net] tcp: fix wraparound issue in tcp_lp
From: Eric Dumazet @ 2017-05-02 1:04 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20170501165643.698aa0b5@xeon-e3>
On Mon, 2017-05-01 at 16:56 -0700, Stephen Hemminger wrote:
> On Mon, 01 May 2017 15:29:48 -0700
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > From: Eric Dumazet <edumazet@google.com>
> >
> > Be careful when comparing tcp_time_stamp to some u32 quantity,
> > otherwise result can be surprising.
> >
> > Fixes: 7c106d7e782b ("[TCP]: TCP Low Priority congestion control")
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > ---
> > net/ipv4/tcp_lp.c | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/ipv4/tcp_lp.c b/net/ipv4/tcp_lp.c
> > index 046fd3910873306d74207615d6997e1c847ea361..d6fb6c067af4641f232b94e7c590c212648e8173 100644
> > --- a/net/ipv4/tcp_lp.c
> > +++ b/net/ipv4/tcp_lp.c
> > @@ -264,13 +264,15 @@ static void tcp_lp_pkts_acked(struct sock *sk, const struct ack_sample *sample)
> > {
> > struct tcp_sock *tp = tcp_sk(sk);
> > struct lp *lp = inet_csk_ca(sk);
> > + u32 delta;
> >
> > if (sample->rtt_us > 0)
> > tcp_lp_rtt_sample(sk, sample->rtt_us);
> >
> > /* calc inference */
> > - if (tcp_time_stamp > tp->rx_opt.rcv_tsecr)
> > - lp->inference = 3 * (tcp_time_stamp - tp->rx_opt.rcv_tsecr);
> > + delta = tcp_time_stamp - tp->rx_opt.rcv_tsecr;
> > + if ((s32)delta > 0)
> > + lp->inference = 3 * delta;
>
> Agreed time wraparound would cause problems.
> But why not use existing time_after() macro here?
>
Simply to not perform (tcp_time_stamp - tp->rx_opt.rcv_tsecr) twice.
jiffies being volatile, this can not be optimized by the compiler.
I have a patch series (for linux-4.13) that will switch TCP stack to 1ms
TS options, regardless of CONFIG_HZ value, and when cooking it I found
this bug.
^ permalink raw reply
* Re: [PATCH 0/2] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
From: Ding Tianhong @ 2017-05-02 0:56 UTC (permalink / raw)
To: Casey Leedom, Bjorn Helgaas, leedom
Cc: Michael Werner, Ganesh Goudar, Arjun V, David Miller,
Asit K Mallick, Patrick J Cramer, Ashok Raj,
Suravee Suthikulpanit, Bob Shaw, h, Alexander Duyck, Mark Rutland,
Amir Ancel, Gabriele Paoloni, Catalin Marinas, Will Deacon,
LinuxArm, David Laight, jeffrey.t.kirsher, netdev
In-Reply-To: <cover.1493678834.git.leedom@chelsio.com>
Hi Casey:
This solution looks good to me, I will test this for ixgbe.:)
Thanks
Ding
On 2017/5/2 7:13, Casey Leedom wrote:
> Some devices have problems with Transaction Layer Packets with the Relaxed
> Ordering Attribute set. This patch set adds a new PCIe Device Flag,
> PCI_DEV_FLAGS_NO_RELAXED_ORDERING, a set of PCI Quirks to catch some known
> devices with Relaxed Ordering issues, and a use of this new flag by the
> cxgb4 driver to avoid using Relaxed Ordering with problematic Root Complex
> Ports.
>
> It's been years since I've submitted kernel.org patches, I appolgise for the
> almost certain submission errors.
>
> Casey Leedom (2):
> PCI: Add new PCIe Fabric End Node flag,
> PCI_DEV_FLAGS_NO_RELAXED_ORDERING
> net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
>
> drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 +
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 17 +++++++++++
> drivers/net/ethernet/chelsio/cxgb4/sge.c | 5 ++--
> drivers/pci/quirks.c | 38 +++++++++++++++++++++++++
> include/linux/pci.h | 2 ++
> 5 files changed, 61 insertions(+), 2 deletions(-)
>
^ permalink raw reply
* Re: [PATCH net] tcp: fix wraparound issue in tcp_lp
From: Neal Cardwell @ 2017-05-02 0:31 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Eric Dumazet, David Miller, netdev
In-Reply-To: <20170501165643.698aa0b5@xeon-e3>
On Mon, May 1, 2017 at 7:56 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> On Mon, 01 May 2017 15:29:48 -0700
> Agreed time wraparound would cause problems.
> But why not use existing time_after() macro here?
>
I suspect this is because time_after() asserts that it is being used
on unsigned long (64 bits), and tcp_time_stamp is 32 bits.
I suppose for tcp_time_stamp comparisons we could re-use the u32 TCP
sequence macros for before() and after()? Even the comment for
before()/after() is already generic enough to apply to tcp_time_stamp:
"The next routines deal with comparing 32 bit unsigned ints and worry
about wraparound (automatic with unsigned arithmetic)." That might be
nice.
neal
^ permalink raw reply
* NOTE!
From: Ramona Chuckaree @ 2017-05-01 23:20 UTC (permalink / raw)
To: Recipients
Dear Email Owner,
Your compensation refund is completed. Kindly find more details in attached file. We hope you find this improvement useful .
Kind Regards,
Mrs. Ramona Chuckaree .
For: The Management.(UNCC)
^ permalink raw reply
* Re: [PATCH net] tcp: fix wraparound issue in tcp_lp
From: Stephen Hemminger @ 2017-05-01 23:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1493677788.31837.25.camel@edumazet-glaptop3.roam.corp.google.com>
On Mon, 01 May 2017 15:29:48 -0700
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Be careful when comparing tcp_time_stamp to some u32 quantity,
> otherwise result can be surprising.
>
> Fixes: 7c106d7e782b ("[TCP]: TCP Low Priority congestion control")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> net/ipv4/tcp_lp.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv4/tcp_lp.c b/net/ipv4/tcp_lp.c
> index 046fd3910873306d74207615d6997e1c847ea361..d6fb6c067af4641f232b94e7c590c212648e8173 100644
> --- a/net/ipv4/tcp_lp.c
> +++ b/net/ipv4/tcp_lp.c
> @@ -264,13 +264,15 @@ static void tcp_lp_pkts_acked(struct sock *sk, const struct ack_sample *sample)
> {
> struct tcp_sock *tp = tcp_sk(sk);
> struct lp *lp = inet_csk_ca(sk);
> + u32 delta;
>
> if (sample->rtt_us > 0)
> tcp_lp_rtt_sample(sk, sample->rtt_us);
>
> /* calc inference */
> - if (tcp_time_stamp > tp->rx_opt.rcv_tsecr)
> - lp->inference = 3 * (tcp_time_stamp - tp->rx_opt.rcv_tsecr);
> + delta = tcp_time_stamp - tp->rx_opt.rcv_tsecr;
> + if ((s32)delta > 0)
> + lp->inference = 3 * delta;
Agreed time wraparound would cause problems.
But why not use existing time_after() macro here?
^ permalink raw reply
* [PATCH] i40evf: Use le32_to_cpu before evaluating HW desc fields.
From: Tushar Dave @ 2017-05-01 23:15 UTC (permalink / raw)
To: jeffrey.t.kirsher, intel-wired-lan, netdev
i40e hardware descriptor fields are in little-endian format. Driver
must use le32_to_cpu while evaluating these fields otherwise on
big-endian arch we end up evaluating incorrect values, cause errors
like:
i40evf 0001:04:02.0: Expected response 0 from PF, received 285212672
i40evf 0001:04:02.1: Expected response 0 from PF, received 285212672
Signed-off-by: Tushar Dave <tushar.n.dave@oracle.com>
---
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index f35dcaa..2c1dfaf 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -1923,8 +1923,10 @@ static void i40evf_adminq_task(struct work_struct *work)
if (ret || !v_msg->v_opcode)
break; /* No event to process or error cleaning ARQ */
- i40evf_virtchnl_completion(adapter, v_msg->v_opcode,
- v_msg->v_retval, event.msg_buf,
+ i40evf_virtchnl_completion(adapter,
+ le32_to_cpu(v_msg->v_opcode),
+ le32_to_cpu(v_msg->v_retval),
+ event.msg_buf,
event.msg_len);
if (pending != 0)
memset(event.msg_buf, 0, I40EVF_MAX_AQ_BUF_SIZE);
--
1.9.1
^ permalink raw reply related
* [PATCH 0/2] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
From: Casey Leedom @ 2017-05-01 23:13 UTC (permalink / raw)
To: Bjorn Helgaas, leedom
Cc: Casey Leedom, Michael Werner, Ganesh Goudar, Arjun V,
David Miller, Asit K Mallick, Patrick J Cramer, Ashok Raj,
Suravee Suthikulpanit, Bob Shaw, h, Alexander Duyck,
Ding Tianhong, Mark Rutland, Amir Ancel, Gabriele Paoloni,
Catalin Marinas, Will Deacon, LinuxArm, David Laight
Some devices have problems with Transaction Layer Packets with the Relaxed
Ordering Attribute set. This patch set adds a new PCIe Device Flag,
PCI_DEV_FLAGS_NO_RELAXED_ORDERING, a set of PCI Quirks to catch some known
devices with Relaxed Ordering issues, and a use of this new flag by the
cxgb4 driver to avoid using Relaxed Ordering with problematic Root Complex
Ports.
It's been years since I've submitted kernel.org patches, I appolgise for the
almost certain submission errors.
Casey Leedom (2):
PCI: Add new PCIe Fabric End Node flag,
PCI_DEV_FLAGS_NO_RELAXED_ORDERING
net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 17 +++++++++++
drivers/net/ethernet/chelsio/cxgb4/sge.c | 5 ++--
drivers/pci/quirks.c | 38 +++++++++++++++++++++++++
include/linux/pci.h | 2 ++
5 files changed, 61 insertions(+), 2 deletions(-)
--
1.9.1
^ 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