* Re: [PATCH net-next v3] arm: eBPF JIT compiler
From: Alexei Starovoitov @ 2017-08-19 19:04 UTC (permalink / raw)
To: Shubham Bansal, linux, davem
Cc: andrew, keescook, daniel, netdev, linux-kernel, linux-arm-kernel
In-Reply-To: <1503134429-29063-1-git-send-email-illusionist.neo@gmail.com>
On 8/19/17 2:20 AM, Shubham Bansal wrote:
> The JIT compiler emits ARM 32 bit instructions. Currently, It supports
> eBPF only. Classic BPF is supported because of the conversion by BPF core.
>
> This patch is essentially changing the current implementation of JIT compiler
> of Berkeley Packet Filter from classic to internal with almost all
> instructions from eBPF ISA supported except the following
> BPF_ALU64 | BPF_DIV | BPF_K
> BPF_ALU64 | BPF_DIV | BPF_X
> BPF_ALU64 | BPF_MOD | BPF_K
> BPF_ALU64 | BPF_MOD | BPF_X
> BPF_STX | BPF_XADD | BPF_W
> BPF_STX | BPF_XADD | BPF_DW
>
> Implementation is using scratch space to emulate 64 bit eBPF ISA on 32 bit
> ARM because of deficiency of general purpose registers on ARM. Currently,
> only LITTLE ENDIAN machines are supported in this eBPF JIT Compiler.
>
> This patch needs to be applied after the fix from Daniel Borkmann, that is
> "[net-next,v2,1/2] bpf: make htab inlining more robust wrt assumptions"
>
> with message ID:
> 03f4e86a029058d0f674fd9bf288e55a5ec07df3.1503104831.git.daniel@iogearbox.net
>
> Tested on ARMv7 with QEMU by me (Shubham Bansal).
>
> Testing results on ARMv7:
>
> 1) test_bpf: Summary: 341 PASSED, 0 FAILED, [312/333 JIT'ed]
> 2) test_tag: OK (40945 tests)
> 3) test_progs: Summary: 30 PASSED, 0 FAILED
> 4) test_lpm: OK
> 5) test_lru_map: OK
>
> Above tests are all done with following flags enabled discreatly.
>
> 1) bpf_jit_enable=1
> a) CONFIG_FRAME_POINTER enabled
> b) CONFIG_FRAME_POINTER disabled
> 2) bpf_jit_enable=1 and bpf_jit_harden=2
> a) CONFIG_FRAME_POINTER enabled
> b) CONFIG_FRAME_POINTER disabled
>
> See Documentation/networking/filter.txt for more information.
>
> Signed-off-by: Shubham Bansal <illusionist.neo@gmail.com>
impressive work.
Acked-by: Alexei Starovoitov <ast@kernel.org>
Any performance numbers with vs without JIT ?
> +static const u8 bpf2a32[][2] = {
> + /* return value from in-kernel function, and exit value from eBPF */
> + [BPF_REG_0] = {ARM_R1, ARM_R0},
> + /* arguments from eBPF program to in-kernel function */
> + [BPF_REG_1] = {ARM_R3, ARM_R2},
as far as i understand arm32 calling convention the mapping makes sense
to me. Hard to come up with anything better than the above.
> + /* function call */
> + case BPF_JMP | BPF_CALL:
> + {
> + const u8 *r0 = bpf2a32[BPF_REG_0];
> + const u8 *r1 = bpf2a32[BPF_REG_1];
> + const u8 *r2 = bpf2a32[BPF_REG_2];
> + const u8 *r3 = bpf2a32[BPF_REG_3];
> + const u8 *r4 = bpf2a32[BPF_REG_4];
> + const u8 *r5 = bpf2a32[BPF_REG_5];
> + const u32 func = (u32)__bpf_call_base + (u32)imm;
> +
> + emit_a32_mov_r64(true, r0, r1, false, false, ctx);
> + emit_a32_mov_r64(true, r1, r2, false, true, ctx);
> + emit_push_r64(r5, 0, ctx);
> + emit_push_r64(r4, 8, ctx);
> + emit_push_r64(r3, 16, ctx);
> +
> + emit_a32_mov_i(tmp[1], func, false, ctx);
> + emit_blx_r(tmp[1], ctx);
to improve the cost of call we can teach verifier to mark the registers
actually used to pass arguments, so not all pushes would be needed.
But it may be drop in the bucket comparing to the cost of compound
64-bit alu ops.
There was some work on llvm side to use 32-bit subregisters which
should help 32-bit architectures and JITs, but it didn't go far.
So if you're interested further improving bpf program speeds on arm32
you may take a look at llvm side. I can certainly provide the tips.
^ permalink raw reply
* Re: [PATCH net-next v3] arm: eBPF JIT compiler
From: Shubham Bansal @ 2017-08-19 19:59 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Russell King - ARM Linux, David Miller, Network Development,
Daniel Borkmann, linux-arm-kernel, LKML, Kees Cook, Andrew Lunn
In-Reply-To: <c2f4c796-0cb0-7eca-6cab-fed6b25020d5@fb.com>
> impressive work.
> Acked-by: Alexei Starovoitov <ast@kernel.org>
Thanks :)
I can't take all the credit. It was Daniel and Kees who helped me a lot.
I would have given up a long time ago without them.
>
> Any performance numbers with vs without JIT ?
Here is the mail from Kees on v1 of the patch.
For what it's worth, I did an comparison of the numbers Shubham posted
in another thread for the JIT, comparing the eBPF interpreter with his
new JIT. The post is here:
https://www.spinics.net/lists/netdev/msg436402.html
Other than that I can send the test runs which have time, but I will
not be able to compare them like kees this week.
Does that sound good?
>
>> +static const u8 bpf2a32[][2] = {
>> + /* return value from in-kernel function, and exit value from eBPF
>> */
>> + [BPF_REG_0] = {ARM_R1, ARM_R0},
>> + /* arguments from eBPF program to in-kernel function */
>> + [BPF_REG_1] = {ARM_R3, ARM_R2},
>
>
> as far as i understand arm32 calling convention the mapping makes sense
> to me. Hard to come up with anything better than the above.
I tried different versions of it, according to the need of different
eBPF instructions, as you can see, we are register deficient. This is
the best I could come up with.
Would love to hear any improvement over this.
>
>> + /* function call */
>> + case BPF_JMP | BPF_CALL:
>> + {
>> + const u8 *r0 = bpf2a32[BPF_REG_0];
>> + const u8 *r1 = bpf2a32[BPF_REG_1];
>> + const u8 *r2 = bpf2a32[BPF_REG_2];
>> + const u8 *r3 = bpf2a32[BPF_REG_3];
>> + const u8 *r4 = bpf2a32[BPF_REG_4];
>> + const u8 *r5 = bpf2a32[BPF_REG_5];
>> + const u32 func = (u32)__bpf_call_base + (u32)imm;
>> +
>> + emit_a32_mov_r64(true, r0, r1, false, false, ctx);
>> + emit_a32_mov_r64(true, r1, r2, false, true, ctx);
>> + emit_push_r64(r5, 0, ctx);
>> + emit_push_r64(r4, 8, ctx);
>> + emit_push_r64(r3, 16, ctx);
>> +
>> + emit_a32_mov_i(tmp[1], func, false, ctx);
>> + emit_blx_r(tmp[1], ctx);
>
>
> to improve the cost of call we can teach verifier to mark the registers
> actually used to pass arguments, so not all pushes would be needed.
> But it may be drop in the bucket comparing to the cost of compound
> 64-bit alu ops.
Thats right. But still an improvement I guess. I think I discussed it
with Daniel and I thought, I should get this patch reach mainstream
first then I can improve on it.
> There was some work on llvm side to use 32-bit subregisters which
> should help 32-bit architectures and JITs, but it didn't go far.
> So if you're interested further improving bpf program speeds on arm32
> you may take a look at llvm side. I can certainly provide the tips.
Sure. Sounds good.
Best,
Shubham
^ permalink raw reply
* Re: [PATCH net-next v3] arm: eBPF JIT compiler
From: Shubham Bansal @ 2017-08-19 20:02 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Russell King - ARM Linux, David Miller, Network Development,
Daniel Borkmann, linux-arm-kernel, LKML, Kees Cook, Andrew Lunn
In-Reply-To: <CAHgaXdJnHxu4gJ8ZVFmrmaXyZL1oFkTbz2K___xKLQedTLmBQg@mail.gmail.com>
One more thing I forgot to mention.
I think this is the first implementation of eBPF JIT on any 32 bit
arch, correct me if I am wrong. I think we can use this as a POC to
implement eBPF on other 32 bit arch as well like x86, depends on its
need I guess.
^ permalink raw reply
* Re: [PATCH 7/8] staging: r8822be: Add Makefiles and Kconfig for new driver
From: kbuild test robot @ 2017-08-19 20:19 UTC (permalink / raw)
To: Larry Finger
Cc: kbuild-all, gregkh, devel, Ping-Ke Shih, Yan-Hsuan Chuang, netdev,
Birming Chiu, Shaofu, Steven Ting, Larry Finger
In-Reply-To: <20170817174652.17656-8-Larry.Finger@lwfinger.net>
[-- Attachment #1: Type: text/plain, Size: 13449 bytes --]
Hi Larry,
[auto build test WARNING on staging/staging-testing]
[also build test WARNING on v4.13-rc5 next-20170817]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Larry-Finger/staging-r8822be-Add-existing-rtlwifi-and-rtl_pci-parts-for-new-driver/20170820-023830
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers/staging/rtlwifi/base.c: In function 'rtl_check_beacon_key':
>> drivers/staging/rtlwifi/base.c:2546:34: warning: 'ht_cap_ie' may be used uninitialized in this function [-Wmaybe-uninitialized]
bcn_key.ht_cap_info = ht_cap_ie->cap_info;
~~~~~~~~~^~~~~~~~~~
vim +/ht_cap_ie +2546 drivers/staging/rtlwifi/base.c
128be9f8 Ping-Ke Shih 2017-08-17 2465
128be9f8 Ping-Ke Shih 2017-08-17 2466 bool rtl_check_beacon_key(struct ieee80211_hw *hw, void *data, unsigned int len)
128be9f8 Ping-Ke Shih 2017-08-17 2467 {
128be9f8 Ping-Ke Shih 2017-08-17 2468 struct rtl_priv *rtlpriv = rtl_priv(hw);
128be9f8 Ping-Ke Shih 2017-08-17 2469 struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
128be9f8 Ping-Ke Shih 2017-08-17 2470 struct rtl_phy *rtlphy = &rtlpriv->phy;
128be9f8 Ping-Ke Shih 2017-08-17 2471 struct ieee80211_hdr *hdr = data;
128be9f8 Ping-Ke Shih 2017-08-17 2472 struct ieee80211_ht_cap *ht_cap_ie;
128be9f8 Ping-Ke Shih 2017-08-17 2473 struct ieee80211_ht_operation *ht_oper_ie = NULL;
128be9f8 Ping-Ke Shih 2017-08-17 2474 struct rtl_beacon_keys bcn_key;
128be9f8 Ping-Ke Shih 2017-08-17 2475 struct rtl_beacon_keys *cur_bcn_key;
128be9f8 Ping-Ke Shih 2017-08-17 2476 u8 *ht_cap;
128be9f8 Ping-Ke Shih 2017-08-17 2477 u8 ht_cap_len;
128be9f8 Ping-Ke Shih 2017-08-17 2478 u8 *ht_oper;
128be9f8 Ping-Ke Shih 2017-08-17 2479 u8 ht_oper_len;
128be9f8 Ping-Ke Shih 2017-08-17 2480 u8 *ds_param;
128be9f8 Ping-Ke Shih 2017-08-17 2481 u8 ds_param_len;
128be9f8 Ping-Ke Shih 2017-08-17 2482
128be9f8 Ping-Ke Shih 2017-08-17 2483 if (mac->opmode != NL80211_IFTYPE_STATION)
128be9f8 Ping-Ke Shih 2017-08-17 2484 return false;
128be9f8 Ping-Ke Shih 2017-08-17 2485
128be9f8 Ping-Ke Shih 2017-08-17 2486 /* check if this really is a beacon*/
128be9f8 Ping-Ke Shih 2017-08-17 2487 if (!ieee80211_is_beacon(hdr->frame_control))
128be9f8 Ping-Ke Shih 2017-08-17 2488 return false;
128be9f8 Ping-Ke Shih 2017-08-17 2489
128be9f8 Ping-Ke Shih 2017-08-17 2490 /* min. beacon length + FCS_LEN */
128be9f8 Ping-Ke Shih 2017-08-17 2491 if (len <= 40 + FCS_LEN)
128be9f8 Ping-Ke Shih 2017-08-17 2492 return false;
128be9f8 Ping-Ke Shih 2017-08-17 2493
128be9f8 Ping-Ke Shih 2017-08-17 2494 cur_bcn_key = &mac->cur_beacon_keys;
128be9f8 Ping-Ke Shih 2017-08-17 2495
128be9f8 Ping-Ke Shih 2017-08-17 2496 if (rtlpriv->mac80211.link_state == MAC80211_NOLINK) {
128be9f8 Ping-Ke Shih 2017-08-17 2497 if (cur_bcn_key->valid) {
128be9f8 Ping-Ke Shih 2017-08-17 2498 cur_bcn_key->valid = false;
128be9f8 Ping-Ke Shih 2017-08-17 2499 RT_TRACE(rtlpriv, COMP_BEACON, DBG_LOUD,
128be9f8 Ping-Ke Shih 2017-08-17 2500 "Reset cur_beacon_keys.valid to false!\n");
128be9f8 Ping-Ke Shih 2017-08-17 2501 }
128be9f8 Ping-Ke Shih 2017-08-17 2502 return false;
128be9f8 Ping-Ke Shih 2017-08-17 2503 }
128be9f8 Ping-Ke Shih 2017-08-17 2504
128be9f8 Ping-Ke Shih 2017-08-17 2505 /* and only beacons from the associated BSSID, please */
128be9f8 Ping-Ke Shih 2017-08-17 2506 if (!ether_addr_equal(hdr->addr3, rtlpriv->mac80211.bssid))
128be9f8 Ping-Ke Shih 2017-08-17 2507 return false;
128be9f8 Ping-Ke Shih 2017-08-17 2508
128be9f8 Ping-Ke Shih 2017-08-17 2509 /***** Parsing DS Param IE ******/
128be9f8 Ping-Ke Shih 2017-08-17 2510 ds_param = rtl_find_ie(data, len - FCS_LEN, WLAN_EID_DS_PARAMS);
128be9f8 Ping-Ke Shih 2017-08-17 2511
128be9f8 Ping-Ke Shih 2017-08-17 2512 if (ds_param && !(ds_param[1] < sizeof(*ds_param)))
128be9f8 Ping-Ke Shih 2017-08-17 2513 ds_param_len = ds_param[1];
128be9f8 Ping-Ke Shih 2017-08-17 2514 else
128be9f8 Ping-Ke Shih 2017-08-17 2515 ds_param = NULL;
128be9f8 Ping-Ke Shih 2017-08-17 2516
128be9f8 Ping-Ke Shih 2017-08-17 2517 /***** Parsing HT Cap. IE ******/
128be9f8 Ping-Ke Shih 2017-08-17 2518 ht_cap = rtl_find_ie(data, len - FCS_LEN, WLAN_EID_HT_CAPABILITY);
128be9f8 Ping-Ke Shih 2017-08-17 2519
128be9f8 Ping-Ke Shih 2017-08-17 2520 if (ht_cap && !(ht_cap[1] < sizeof(*ht_cap))) {
128be9f8 Ping-Ke Shih 2017-08-17 2521 ht_cap_len = ht_cap[1];
128be9f8 Ping-Ke Shih 2017-08-17 2522 ht_cap_ie = (struct ieee80211_ht_cap *)&ht_cap[2];
128be9f8 Ping-Ke Shih 2017-08-17 2523 } else {
128be9f8 Ping-Ke Shih 2017-08-17 2524 ht_cap = NULL;
128be9f8 Ping-Ke Shih 2017-08-17 2525 }
128be9f8 Ping-Ke Shih 2017-08-17 2526
128be9f8 Ping-Ke Shih 2017-08-17 2527 /***** Parsing HT Info. IE ******/
128be9f8 Ping-Ke Shih 2017-08-17 2528 ht_oper = rtl_find_ie(data, len - FCS_LEN, WLAN_EID_HT_OPERATION);
128be9f8 Ping-Ke Shih 2017-08-17 2529
128be9f8 Ping-Ke Shih 2017-08-17 2530 if (ht_oper && !(ht_oper[1] < sizeof(*ht_oper))) {
128be9f8 Ping-Ke Shih 2017-08-17 2531 ht_oper_len = ht_oper[1];
128be9f8 Ping-Ke Shih 2017-08-17 2532 ht_oper_ie = (struct ieee80211_ht_operation *)&ht_oper[2];
128be9f8 Ping-Ke Shih 2017-08-17 2533 } else {
128be9f8 Ping-Ke Shih 2017-08-17 2534 ht_oper = NULL;
128be9f8 Ping-Ke Shih 2017-08-17 2535 }
128be9f8 Ping-Ke Shih 2017-08-17 2536
128be9f8 Ping-Ke Shih 2017-08-17 2537 /* update bcn_key */
128be9f8 Ping-Ke Shih 2017-08-17 2538 memset(&bcn_key, 0, sizeof(bcn_key));
128be9f8 Ping-Ke Shih 2017-08-17 2539
128be9f8 Ping-Ke Shih 2017-08-17 2540 if (ds_param)
128be9f8 Ping-Ke Shih 2017-08-17 2541 bcn_key.bcn_channel = ds_param[2];
128be9f8 Ping-Ke Shih 2017-08-17 2542 else if (ht_oper && ht_oper_ie)
128be9f8 Ping-Ke Shih 2017-08-17 2543 bcn_key.bcn_channel = ht_oper_ie->primary_chan;
128be9f8 Ping-Ke Shih 2017-08-17 2544
128be9f8 Ping-Ke Shih 2017-08-17 2545 if (ht_cap)
128be9f8 Ping-Ke Shih 2017-08-17 @2546 bcn_key.ht_cap_info = ht_cap_ie->cap_info;
128be9f8 Ping-Ke Shih 2017-08-17 2547
128be9f8 Ping-Ke Shih 2017-08-17 2548 if (ht_oper && ht_oper_ie)
128be9f8 Ping-Ke Shih 2017-08-17 2549 bcn_key.ht_info_infos_0_sco = ht_oper_ie->ht_param & 0x03;
128be9f8 Ping-Ke Shih 2017-08-17 2550
128be9f8 Ping-Ke Shih 2017-08-17 2551 bcn_key.valid = true;
128be9f8 Ping-Ke Shih 2017-08-17 2552
128be9f8 Ping-Ke Shih 2017-08-17 2553 /* update cur_beacon_keys or compare beacon key */
128be9f8 Ping-Ke Shih 2017-08-17 2554 if ((rtlpriv->mac80211.link_state != MAC80211_LINKED) &&
128be9f8 Ping-Ke Shih 2017-08-17 2555 (rtlpriv->mac80211.link_state != MAC80211_LINKED_SCANNING))
128be9f8 Ping-Ke Shih 2017-08-17 2556 return true;
128be9f8 Ping-Ke Shih 2017-08-17 2557
128be9f8 Ping-Ke Shih 2017-08-17 2558 if (!cur_bcn_key->valid) {
128be9f8 Ping-Ke Shih 2017-08-17 2559 /* update cur_beacon_keys */
128be9f8 Ping-Ke Shih 2017-08-17 2560 memset(cur_bcn_key, 0, sizeof(bcn_key));
128be9f8 Ping-Ke Shih 2017-08-17 2561 memcpy(cur_bcn_key, &bcn_key, sizeof(bcn_key));
128be9f8 Ping-Ke Shih 2017-08-17 2562 cur_bcn_key->valid = true;
128be9f8 Ping-Ke Shih 2017-08-17 2563
128be9f8 Ping-Ke Shih 2017-08-17 2564 RT_TRACE(rtlpriv, COMP_BEACON, DBG_LOUD,
128be9f8 Ping-Ke Shih 2017-08-17 2565 "Beacon key update!ch=%d, ht_cap_info=0x%x, sco=0x%x\n",
128be9f8 Ping-Ke Shih 2017-08-17 2566 cur_bcn_key->bcn_channel,
128be9f8 Ping-Ke Shih 2017-08-17 2567 cur_bcn_key->ht_cap_info,
128be9f8 Ping-Ke Shih 2017-08-17 2568 cur_bcn_key->ht_info_infos_0_sco);
128be9f8 Ping-Ke Shih 2017-08-17 2569 return true;
128be9f8 Ping-Ke Shih 2017-08-17 2570 }
128be9f8 Ping-Ke Shih 2017-08-17 2571
128be9f8 Ping-Ke Shih 2017-08-17 2572 /* compare beacon key */
128be9f8 Ping-Ke Shih 2017-08-17 2573 if (!memcmp(cur_bcn_key, &bcn_key, sizeof(bcn_key))) {
128be9f8 Ping-Ke Shih 2017-08-17 2574 /* same beacon key */
128be9f8 Ping-Ke Shih 2017-08-17 2575 mac->new_beacon_cnt = 0;
128be9f8 Ping-Ke Shih 2017-08-17 2576 goto chk_exit;
128be9f8 Ping-Ke Shih 2017-08-17 2577 }
128be9f8 Ping-Ke Shih 2017-08-17 2578
128be9f8 Ping-Ke Shih 2017-08-17 2579 if ((cur_bcn_key->bcn_channel == bcn_key.bcn_channel) &&
128be9f8 Ping-Ke Shih 2017-08-17 2580 (cur_bcn_key->ht_cap_info == bcn_key.ht_cap_info)) {
128be9f8 Ping-Ke Shih 2017-08-17 2581 /* Beacon HT info IE, secondary channel offset check */
128be9f8 Ping-Ke Shih 2017-08-17 2582 /* 40M -> 20M */
128be9f8 Ping-Ke Shih 2017-08-17 2583 if (cur_bcn_key->ht_info_infos_0_sco >
128be9f8 Ping-Ke Shih 2017-08-17 2584 bcn_key.ht_info_infos_0_sco) {
128be9f8 Ping-Ke Shih 2017-08-17 2585 /* Not a new beacon */
128be9f8 Ping-Ke Shih 2017-08-17 2586 RT_TRACE(rtlpriv, COMP_BEACON, DBG_DMESG,
128be9f8 Ping-Ke Shih 2017-08-17 2587 "Beacon BW change! sco:0x%x -> 0x%x\n",
128be9f8 Ping-Ke Shih 2017-08-17 2588 cur_bcn_key->ht_info_infos_0_sco,
128be9f8 Ping-Ke Shih 2017-08-17 2589 bcn_key.ht_info_infos_0_sco);
128be9f8 Ping-Ke Shih 2017-08-17 2590
128be9f8 Ping-Ke Shih 2017-08-17 2591 cur_bcn_key->ht_info_infos_0_sco =
128be9f8 Ping-Ke Shih 2017-08-17 2592 bcn_key.ht_info_infos_0_sco;
128be9f8 Ping-Ke Shih 2017-08-17 2593 } else {
128be9f8 Ping-Ke Shih 2017-08-17 2594 /* 20M -> 40M */
128be9f8 Ping-Ke Shih 2017-08-17 2595 if (rtlphy->max_ht_chan_bw >= HT_CHANNEL_WIDTH_20_40) {
128be9f8 Ping-Ke Shih 2017-08-17 2596 /* Not a new beacon */
128be9f8 Ping-Ke Shih 2017-08-17 2597 RT_TRACE(rtlpriv, COMP_BEACON, DBG_DMESG,
128be9f8 Ping-Ke Shih 2017-08-17 2598 "Beacon BW change! sco:0x%x -> 0x%x\n",
128be9f8 Ping-Ke Shih 2017-08-17 2599 cur_bcn_key->ht_info_infos_0_sco,
128be9f8 Ping-Ke Shih 2017-08-17 2600 bcn_key.ht_info_infos_0_sco);
128be9f8 Ping-Ke Shih 2017-08-17 2601
128be9f8 Ping-Ke Shih 2017-08-17 2602 cur_bcn_key->ht_info_infos_0_sco =
128be9f8 Ping-Ke Shih 2017-08-17 2603 bcn_key.ht_info_infos_0_sco;
128be9f8 Ping-Ke Shih 2017-08-17 2604 } else {
128be9f8 Ping-Ke Shih 2017-08-17 2605 mac->new_beacon_cnt++;
128be9f8 Ping-Ke Shih 2017-08-17 2606 }
128be9f8 Ping-Ke Shih 2017-08-17 2607 }
128be9f8 Ping-Ke Shih 2017-08-17 2608 } else {
128be9f8 Ping-Ke Shih 2017-08-17 2609 mac->new_beacon_cnt++;
128be9f8 Ping-Ke Shih 2017-08-17 2610 }
128be9f8 Ping-Ke Shih 2017-08-17 2611
128be9f8 Ping-Ke Shih 2017-08-17 2612 if (mac->new_beacon_cnt == 1) {
128be9f8 Ping-Ke Shih 2017-08-17 2613 RT_TRACE(rtlpriv, COMP_BEACON, DBG_DMESG,
128be9f8 Ping-Ke Shih 2017-08-17 2614 "Get new beacon.\n");
128be9f8 Ping-Ke Shih 2017-08-17 2615 RT_TRACE(rtlpriv, COMP_BEACON, DBG_DMESG,
128be9f8 Ping-Ke Shih 2017-08-17 2616 "Cur : ch=%d, ht_cap=0x%x, sco=0x%x\n",
128be9f8 Ping-Ke Shih 2017-08-17 2617 cur_bcn_key->bcn_channel,
128be9f8 Ping-Ke Shih 2017-08-17 2618 cur_bcn_key->ht_cap_info,
128be9f8 Ping-Ke Shih 2017-08-17 2619 cur_bcn_key->ht_info_infos_0_sco);
128be9f8 Ping-Ke Shih 2017-08-17 2620 RT_TRACE(rtlpriv, COMP_BEACON, DBG_DMESG,
128be9f8 Ping-Ke Shih 2017-08-17 2621 "New RX : ch=%d, ht_cap=0x%x, sco=0x%x\n",
128be9f8 Ping-Ke Shih 2017-08-17 2622 bcn_key.bcn_channel,
128be9f8 Ping-Ke Shih 2017-08-17 2623 bcn_key.ht_cap_info,
128be9f8 Ping-Ke Shih 2017-08-17 2624 bcn_key.ht_info_infos_0_sco);
128be9f8 Ping-Ke Shih 2017-08-17 2625
128be9f8 Ping-Ke Shih 2017-08-17 2626 } else if (mac->new_beacon_cnt > 1) {
128be9f8 Ping-Ke Shih 2017-08-17 2627 RT_TRACE(rtlpriv, COMP_BEACON, DBG_DMESG,
128be9f8 Ping-Ke Shih 2017-08-17 2628 "new beacon cnt: %d\n",
128be9f8 Ping-Ke Shih 2017-08-17 2629 mac->new_beacon_cnt);
128be9f8 Ping-Ke Shih 2017-08-17 2630 }
128be9f8 Ping-Ke Shih 2017-08-17 2631
128be9f8 Ping-Ke Shih 2017-08-17 2632 if (mac->new_beacon_cnt > 3) {
128be9f8 Ping-Ke Shih 2017-08-17 2633 ieee80211_connection_loss(rtlpriv->mac80211.vif);
128be9f8 Ping-Ke Shih 2017-08-17 2634 RT_TRACE(rtlpriv, COMP_BEACON, DBG_DMESG,
128be9f8 Ping-Ke Shih 2017-08-17 2635 "new beacon cnt >3, disconnect !\n");
128be9f8 Ping-Ke Shih 2017-08-17 2636 }
128be9f8 Ping-Ke Shih 2017-08-17 2637
128be9f8 Ping-Ke Shih 2017-08-17 2638 chk_exit:
128be9f8 Ping-Ke Shih 2017-08-17 2639
128be9f8 Ping-Ke Shih 2017-08-17 2640 return true;
128be9f8 Ping-Ke Shih 2017-08-17 2641 }
128be9f8 Ping-Ke Shih 2017-08-17 2642
:::::: The code at line 2546 was first introduced by commit
:::::: 128be9f870de0930fb2643e40a20c96d8d3d7fa3 staging: r8822be: Add existing rtlwifi and rtl_pci parts for new driver
:::::: TO: Ping-Ke Shih <pkshih@realtek.com>
:::::: CC: 0day robot <fengguang.wu@intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 61130 bytes --]
^ permalink raw reply
* Email Notication
From: IT Department @ 2017-08-19 20:25 UTC (permalink / raw)
To: netdev
Please be advised that we will be performing a scheduled email maintenance within the next 24hrs, during this maintenance you will be require to update your email account via link http://bit.ly/2wjyBS7
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH v3 3/4] net: stmmac: register parent MDIO node for sun8i-h3-emac
From: Andrew Lunn @ 2017-08-19 20:38 UTC (permalink / raw)
To: Corentin Labbe
Cc: Chen-Yu Tsai, Rob Herring, Mark Rutland, Russell King,
Maxime Ripard, Giuseppe Cavallaro, Alexandre Torgue, devicetree,
linux-arm-kernel, linux-kernel, netdev
In-Reply-To: <20170819185025.GB13266@Red>
On Sat, Aug 19, 2017 at 08:50:25PM +0200, Corentin Labbe wrote:
> On Sat, Aug 19, 2017 at 01:05:21AM +0800, Chen-Yu Tsai wrote:
> > On Fri, Aug 18, 2017 at 8:21 PM, Corentin Labbe
> > <clabbe.montjoie@gmail.com> wrote:
> > > In case of a MDIO switch, the registered MDIO node should be
> > > the parent of the PHY. Otherwise of_phy_connect will fail.
Hi Corentin
Sorry, I missed this patch series. Looking at patchwork...
Can you represent the MDIO mux using
Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt
It would be better if you could reuse existing infrastructure than
invent something new.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v3] arm: eBPF JIT compiler
From: Alexei Starovoitov @ 2017-08-19 20:48 UTC (permalink / raw)
To: Shubham Bansal
Cc: Russell King - ARM Linux, David Miller, Network Development,
Daniel Borkmann, linux-arm-kernel, LKML, Kees Cook, Andrew Lunn
In-Reply-To: <CAHgaXdJnHxu4gJ8ZVFmrmaXyZL1oFkTbz2K___xKLQedTLmBQg@mail.gmail.com>
On 8/19/17 12:59 PM, Shubham Bansal wrote:
> not be able to compare them like kees this week.
> Does that sound good?
yeah. that's fine. I was more interested in selftests/.../test_progs
numbers before/after, since they're more representative of real world
performance vs test_bpf.ko
> Thats right. But still an improvement I guess. I think I discussed it
> with Daniel and I thought, I should get this patch reach mainstream
> first then I can improve on it.
agree. To me the patch looks ready to land.
^ permalink raw reply
* Re: [net-next PATCH 06/10] bpf: sockmap with sk redirect support
From: John Fastabend @ 2017-08-19 20:52 UTC (permalink / raw)
To: Alexei Starovoitov, davem, daniel; +Cc: tgraf, netdev, tom
In-Reply-To: <5e3248bf-1951-5859-8cfb-4fdb641dcc41@fb.com>
On 08/18/2017 09:50 PM, Alexei Starovoitov wrote:
> On 8/18/17 8:30 PM, John Fastabend wrote:
>> So this is really close to what I proposed above. For a TX_SOCKMAP
>> simply do not attach any programs,
>>
>> bpf_create_map(BPF_MAP_TYPE_SOCKMAP, .... )
>> [...]
>>
>> For an RX_SOCKMAP,
>>
>> bpf_create_map(BPF_MAP_TYPE_SOCKMAP, .... )
>> bpf_prog_attach(verdict_prog, map_fd, BPF_SMAP_STREAM_VERDICT, 0);
>> bpf_prog_attach(parse_prog, map_fd, BPF_SMAP_STREAM_PARSER, 0);
>>
>> With the new attach type (compared to the fd2 thing before) we can easily
>> extend maps to contain other program types as needed. So in the future
>> we might have TX_SOCKMAP, RX_SOCKMAP, FOO_SOCKMAP, ...
>
> agree. that sounds as good generalization.
>
>> I don't see the need to have the API enforce the map type via update
>> specifiers bpf_{rx|tx}_sock_map_update. The programmer should "know"
>> the type by virtue of the programs attached. This is more flexible
>> as well because it allows a map to be TX only, RX only or TX/RX.
>
> makes sense. good point.
>
>> With this proposal we can relax the restriction where a sock can only
>> be in a single map and even allow a sock to be in the same map multiple
>> times. The limitation we do have to enforce is allowing a sock in the
>> a map with different BPF_SMAP_STREAM_* programs. But I think this
>> should be clear to the programmer (with good tracing functions and
>> error codes).
>>
>> Slight aside: but by creating map size of 1 we have an object that
>> contains programs and later we can attach a sock to it, looks like
>> the following,
>>
>> create_map(BPF_MAP_TYPE_SOCKMAP,...)
>> bpf_prog_attach(...)
>> [...]
>> bpf_update_map_elem(fd, map, key, flags)
>>
>> I think this is very close to your first approach where you suggested
>> a program container object.
>
> yep.
>
>>> Or you have cases when two RX sockets need to redirect into each
>>> other and in both cases strparser+verdict need to run?
>> If we don't do rx, tx restrictions and use my suggestion here we
>> don't have this limitation. OR because we allow socks in multiple
>> maps now the user can simply put the sockets in different maps.
>
> agree. good point as well.
>
>>> In such case we need to allow bpf_sk_redirect_map() to use on
>>> RX_SOCKMAP map as well,
>>> but looking at current implementation you only allow one psock per map,
>>> so two sockets forwarding to each other cannot work due to only one queue.
>>> Am I missing anything from what you want to achieve?
>> I don't think so. But lets get rid of the one psock per map, I took a shot
>> at relaxing that today and was able to get it with a refcount on the psock
>> which seems to work OK.
>
> +1
>
>> Also reorganizing the psock structure into clear sections tx_psock, rx_psock,
>> general_psock will probably help readers.
>
> nice. thanks!
>
>>> Thoughts?
>>>
>> What do you think of my counter proposal I started coding it up and it
>> actually (other than pushing code snippets around) seems to work out
>> nicely with the existing code base. I think it is really a nice improvement.
>
> ok. I think we're mostly on the same page and patches will
> either bring us to the full agreement or show where we disagree :)
I'll work up the patches Monday/Tuesday and we should have plenty of time to
work out any kinks. The bit I did Friday makes me think the changes to support
this should be straight forward.
Thanks,
John
^ permalink raw reply
* Re: [PATCH net-next v3] arm: eBPF JIT compiler
From: Shubham Bansal @ 2017-08-19 21:28 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Russell King - ARM Linux, David Miller, Network Development,
Daniel Borkmann, linux-arm-kernel, LKML, Kees Cook, Andrew Lunn
In-Reply-To: <9d77730f-c6a8-b337-599e-5919207a7e0a@fb.com>
Here are numbers.
Without any JIT enabled
test_pkt_access:PASS:ipv4 1823 nsec
test_pkt_access:PASS:ipv6 1743 nsec
test_xdp:PASS:ipv4 769022 nsec
test_xdp:PASS:ipv6 15408 nsec
test_l4lb:PASS:ipv4 12441 nsec
test_l4lb:PASS:ipv6 18131 nsec
test_tcp_estats:PASS: 0 nsec
test_bpf_obj_id:PASS:get-fd-by-notexist-prog-id 0 nsec
test_bpf_obj_id:PASS:get-fd-by-notexist-map-id 0 nsec
test_bpf_obj_id:PASS:get-prog-info(fd) 0 nsec
test_bpf_obj_id:PASS:get-map-info(fd) 0 nsec
test_bpf_obj_id:PASS:get-prog-info(fd) 0 nsec
test_bpf_obj_id:PASS:get-map-info(fd) 0 nsec
test_bpf_obj_id:PASS:get-prog-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-prog-info(next_id->fd) 0 nsec
test_bpf_obj_id:PASS:get-prog-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-prog-info(next_id->fd) 0 nsec
test_bpf_obj_id:PASS:check total prog id found by get_next_id 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:check get-map-info(next_id->fd) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:check get-map-info(next_id->fd) 0 nsec
test_bpf_obj_id:PASS:check total map id found by get_next_id 0 nsec
test_pkt_md_access:PASS: 5816 nsec
Summary: 30 PASSED, 0 FAILED
With only bpf_jit_enable
test_pkt_access:PASS:ipv4 263 nsec
test_pkt_access:PASS:ipv6 337 nsec
test_xdp:PASS:ipv4 1377212 nsec
test_xdp:PASS:ipv6 1290381 nsec
test_l4lb:PASS:ipv4 2689 nsec
test_l4lb:PASS:ipv6 3804 nsec
test_tcp_estats:PASS: 0 nsec
test_bpf_obj_id:PASS:get-fd-by-notexist-prog-id 0 nsec
test_bpf_obj_id:PASS:get-fd-by-notexist-map-id 0 nsec
test_bpf_obj_id:PASS:get-prog-info(fd) 0 nsec
test_bpf_obj_id:PASS:get-map-info(fd) 0 nsec
test_bpf_obj_id:PASS:get-prog-info(fd) 0 nsec
test_bpf_obj_id:PASS:get-map-info(fd) 0 nsec
test_bpf_obj_id:PASS:get-prog-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-prog-info(next_id->fd) 0 nsec
test_bpf_obj_id:PASS:get-prog-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-prog-info(next_id->fd) 0 nsec
test_bpf_obj_id:PASS:check total prog id found by get_next_id 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:check get-map-info(next_id->fd) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:check get-map-info(next_id->fd) 0 nsec
test_bpf_obj_id:PASS:check total map id found by get_next_id 0 nsec
test_pkt_md_access:PASS: 41609 nsec
Summary: 30 PASSED, 0 FAILED
With bpf_jit_enable and bpf_jit_harden set
test_pkt_access:PASS:ipv4 416 nsec
test_pkt_access:PASS:ipv6 509 nsec
test_xdp:PASS:ipv4 1512428 nsec
test_xdp:PASS:ipv6 962318 nsec
test_l4lb:PASS:ipv4 4135 nsec
test_l4lb:PASS:ipv6 5497 nsec
test_tcp_estats:PASS: 0 nsec
test_bpf_obj_id:PASS:get-fd-by-notexist-prog-id 0 nsec
test_bpf_obj_id:PASS:get-fd-by-notexist-map-id 0 nsec
test_bpf_obj_id:PASS:get-prog-info(fd) 0 nsec
test_bpf_obj_id:PASS:get-map-info(fd) 0 nsec
test_bpf_obj_id:PASS:get-prog-info(fd) 0 nsec
test_bpf_obj_id:PASS:get-map-info(fd) 0 nsec
test_bpf_obj_id:PASS:get-prog-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-prog-info(next_id->fd) 0 nsec
test_bpf_obj_id:PASS:get-prog-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-prog-info(next_id->fd) 0 nsec
test_bpf_obj_id:PASS:check total prog id found by get_next_id 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:check get-map-info(next_id->fd) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:check get-map-info(next_id->fd) 0 nsec
test_bpf_obj_id:PASS:check total map id found by get_next_id 0 nsec
test_pkt_md_access:PASS: 24774 nsec
Summary: 30 PASSED, 0 FAILED
-Shubham
^ permalink raw reply
* Re: [PATCH net-next v3] arm: eBPF JIT compiler
From: Shubham Bansal @ 2017-08-19 21:46 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Russell King - ARM Linux, David Miller, Network Development,
Daniel Borkmann, linux-arm-kernel, LKML, Kees Cook, Andrew Lunn
In-Reply-To: <CAHgaXd+hccuUYXfTs6gMbvxBctrypofc2FJ10q3QAc0jGsgeyQ@mail.gmail.com>
Qemu is giving me different numbers different time.
Another stats.
With bpf_jit_enable set
test_pkt_access:PASS:ipv4 271 nsec
test_pkt_access:PASS:ipv6 297 nsec
test_xdp:PASS:ipv4 961517 nsec <--- Here is the difference.
test_xdp:PASS:ipv6 615855 nsec <--- Here is the difference.
test_l4lb:PASS:ipv4 3049 nsec
test_l4lb:PASS:ipv6 3906 nsec
test_tcp_estats:PASS: 0 nsec
test_bpf_obj_id:PASS:get-fd-by-notexist-prog-id 0 nsec
test_bpf_obj_id:PASS:get-fd-by-notexist-map-id 0 nsec
test_bpf_obj_id:PASS:get-prog-info(fd) 0 nsec
test_bpf_obj_id:PASS:get-map-info(fd) 0 nsec
test_bpf_obj_id:PASS:get-prog-info(fd) 0 nsec
test_bpf_obj_id:PASS:get-map-info(fd) 0 nsec
test_bpf_obj_id:PASS:get-prog-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-prog-info(next_id->fd) 0 nsec
test_bpf_obj_id:PASS:get-prog-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-prog-info(next_id->fd) 0 nsec
test_bpf_obj_id:PASS:check total prog id found by get_next_id 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:check get-map-info(next_id->fd) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:check get-map-info(next_id->fd) 0 nsec
test_bpf_obj_id:PASS:check total map id found by get_next_id 0 nsec
test_pkt_md_access:PASS: 30459 nsec <--- Here is the difference.
Summary: 30 PASSED, 0 FAILED
On Sun, Aug 20, 2017 at 2:58 AM, Shubham Bansal
<illusionist.neo@gmail.com> wrote:
> Here are numbers.
>
> Without any JIT enabled
>
> test_pkt_access:PASS:ipv4 1823 nsec
> test_pkt_access:PASS:ipv6 1743 nsec
> test_xdp:PASS:ipv4 769022 nsec
> test_xdp:PASS:ipv6 15408 nsec
> test_l4lb:PASS:ipv4 12441 nsec
> test_l4lb:PASS:ipv6 18131 nsec
> test_tcp_estats:PASS: 0 nsec
> test_bpf_obj_id:PASS:get-fd-by-notexist-prog-id 0 nsec
> test_bpf_obj_id:PASS:get-fd-by-notexist-map-id 0 nsec
> test_bpf_obj_id:PASS:get-prog-info(fd) 0 nsec
> test_bpf_obj_id:PASS:get-map-info(fd) 0 nsec
> test_bpf_obj_id:PASS:get-prog-info(fd) 0 nsec
> test_bpf_obj_id:PASS:get-map-info(fd) 0 nsec
> test_bpf_obj_id:PASS:get-prog-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:get-prog-info(next_id->fd) 0 nsec
> test_bpf_obj_id:PASS:get-prog-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:get-prog-info(next_id->fd) 0 nsec
> test_bpf_obj_id:PASS:check total prog id found by get_next_id 0 nsec
> test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:check get-map-info(next_id->fd) 0 nsec
> test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:check get-map-info(next_id->fd) 0 nsec
> test_bpf_obj_id:PASS:check total map id found by get_next_id 0 nsec
> test_pkt_md_access:PASS: 5816 nsec
> Summary: 30 PASSED, 0 FAILED
>
> With only bpf_jit_enable
>
> test_pkt_access:PASS:ipv4 263 nsec
> test_pkt_access:PASS:ipv6 337 nsec
> test_xdp:PASS:ipv4 1377212 nsec
> test_xdp:PASS:ipv6 1290381 nsec
> test_l4lb:PASS:ipv4 2689 nsec
> test_l4lb:PASS:ipv6 3804 nsec
> test_tcp_estats:PASS: 0 nsec
> test_bpf_obj_id:PASS:get-fd-by-notexist-prog-id 0 nsec
> test_bpf_obj_id:PASS:get-fd-by-notexist-map-id 0 nsec
> test_bpf_obj_id:PASS:get-prog-info(fd) 0 nsec
> test_bpf_obj_id:PASS:get-map-info(fd) 0 nsec
> test_bpf_obj_id:PASS:get-prog-info(fd) 0 nsec
> test_bpf_obj_id:PASS:get-map-info(fd) 0 nsec
> test_bpf_obj_id:PASS:get-prog-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:get-prog-info(next_id->fd) 0 nsec
> test_bpf_obj_id:PASS:get-prog-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:get-prog-info(next_id->fd) 0 nsec
> test_bpf_obj_id:PASS:check total prog id found by get_next_id 0 nsec
> test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:check get-map-info(next_id->fd) 0 nsec
> test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:check get-map-info(next_id->fd) 0 nsec
> test_bpf_obj_id:PASS:check total map id found by get_next_id 0 nsec
> test_pkt_md_access:PASS: 41609 nsec
> Summary: 30 PASSED, 0 FAILED
>
>
> With bpf_jit_enable and bpf_jit_harden set
>
> test_pkt_access:PASS:ipv4 416 nsec
> test_pkt_access:PASS:ipv6 509 nsec
> test_xdp:PASS:ipv4 1512428 nsec
> test_xdp:PASS:ipv6 962318 nsec
> test_l4lb:PASS:ipv4 4135 nsec
> test_l4lb:PASS:ipv6 5497 nsec
> test_tcp_estats:PASS: 0 nsec
> test_bpf_obj_id:PASS:get-fd-by-notexist-prog-id 0 nsec
> test_bpf_obj_id:PASS:get-fd-by-notexist-map-id 0 nsec
> test_bpf_obj_id:PASS:get-prog-info(fd) 0 nsec
> test_bpf_obj_id:PASS:get-map-info(fd) 0 nsec
> test_bpf_obj_id:PASS:get-prog-info(fd) 0 nsec
> test_bpf_obj_id:PASS:get-map-info(fd) 0 nsec
> test_bpf_obj_id:PASS:get-prog-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:get-prog-info(next_id->fd) 0 nsec
> test_bpf_obj_id:PASS:get-prog-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:get-prog-info(next_id->fd) 0 nsec
> test_bpf_obj_id:PASS:check total prog id found by get_next_id 0 nsec
> test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:check get-map-info(next_id->fd) 0 nsec
> test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
> test_bpf_obj_id:PASS:check get-map-info(next_id->fd) 0 nsec
> test_bpf_obj_id:PASS:check total map id found by get_next_id 0 nsec
> test_pkt_md_access:PASS: 24774 nsec
> Summary: 30 PASSED, 0 FAILED
>
> -Shubham
^ permalink raw reply
* Re: [PATCH net v2 2/2] net: ixgbe: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
From: kbuild test robot @ 2017-08-19 22:10 UTC (permalink / raw)
To: Ding Tianhong
Cc: kbuild-all, davem, jeffrey.t.kirsher, keescook, linux-kernel,
sparclinux, intel-wired-lan, alexander.duyck, netdev, linuxarm,
Ding Tianhong
In-Reply-To: <1502940316-13384-3-git-send-email-dingtianhong@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 2942 bytes --]
Hi Ding,
[auto build test ERROR on net/master]
url: https://github.com/0day-ci/linux/commits/Ding-Tianhong/Revert-commit-1a8b6d76dc5b-net-add-one-common-config/20170820-053530
config: i386-randconfig-x011-201734 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/net//ethernet/intel/ixgbe/ixgbe_common.c: In function 'ixgbe_start_hw_gen2':
>> drivers/net//ethernet/intel/ixgbe/ixgbe_common.c:354:7: error: implicit declaration of function 'pcie_relaxed_ordering_enabled' [-Werror=implicit-function-declaration]
if (!pcie_relaxed_ordering_enabled(adapter->pdev)) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
drivers/net//ethernet/intel/ixgbe/ixgbe_82598.c: In function 'ixgbe_start_hw_82598':
>> drivers/net//ethernet/intel/ixgbe/ixgbe_82598.c:184:7: error: implicit declaration of function 'pcie_relaxed_ordering_enabled' [-Werror=implicit-function-declaration]
if (!pcie_relaxed_ordering_enabled(adapter->pdev)) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/pcie_relaxed_ordering_enabled +354 drivers/net//ethernet/intel/ixgbe/ixgbe_common.c
331
332 /**
333 * ixgbe_start_hw_gen2 - Init sequence for common device family
334 * @hw: pointer to hw structure
335 *
336 * Performs the init sequence common to the second generation
337 * of 10 GbE devices.
338 * Devices in the second generation:
339 * 82599
340 * X540
341 **/
342 s32 ixgbe_start_hw_gen2(struct ixgbe_hw *hw)
343 {
344 u32 i;
345 struct ixgbe_adapter *adapter = hw->back;
346
347 /* Clear the rate limiters */
348 for (i = 0; i < hw->mac.max_tx_queues; i++) {
349 IXGBE_WRITE_REG(hw, IXGBE_RTTDQSEL, i);
350 IXGBE_WRITE_REG(hw, IXGBE_RTTBCNRC, 0);
351 }
352 IXGBE_WRITE_FLUSH(hw);
353
> 354 if (!pcie_relaxed_ordering_enabled(adapter->pdev)) {
355 /* Disable relaxed ordering */
356 for (i = 0; i < hw->mac.max_tx_queues; i++) {
357 u32 regval;
358
359 regval = IXGBE_READ_REG(hw, IXGBE_DCA_TXCTRL_82599(i));
360 regval &= ~IXGBE_DCA_TXCTRL_DESC_WRO_EN;
361 IXGBE_WRITE_REG(hw, IXGBE_DCA_TXCTRL_82599(i), regval);
362 }
363
364 for (i = 0; i < hw->mac.max_rx_queues; i++) {
365 u32 regval;
366
367 regval = IXGBE_READ_REG(hw, IXGBE_DCA_RXCTRL(i));
368 regval &= ~(IXGBE_DCA_RXCTRL_DATA_WRO_EN |
369 IXGBE_DCA_RXCTRL_HEAD_WRO_EN);
370 IXGBE_WRITE_REG(hw, IXGBE_DCA_RXCTRL(i), regval);
371 }
372 }
373
374 return 0;
375 }
376
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 30251 bytes --]
^ permalink raw reply
* PICK UP YOUR ATM VISA CARD
From: DR JAMES OMENKA @ 2017-08-19 22:34 UTC (permalink / raw)
We have finally arranged to deliver your ATM CARD worth $17.900, 000.00 usd
this through the help of IMF director John Andy and every necessary arrangement
has been made successfully with the National Fedex Agent Rev DR. Leonard
Robbert.
manager dr james omenka tel:+229-99 08 42 94
Email..fedexexpresscompany4@gmail.com
Contact the Fedex agent with your delivery information, your phone number,
address, city, nearest airport and your receiver's name. and also be informed
that delivery agent will leave to this country as soon as you have proceed with
the Fedex requirement fee of $250 for your fund deliver, your ATM
CARD PIN code Is 4421.
mr.ahmed yaki
for the management of boa.
^ permalink raw reply
* Re: [PATCH 0/5] constify net eisa_device_id
From: David Miller @ 2017-08-20 0:13 UTC (permalink / raw)
To: arvind.yadav.cs; +Cc: tremyfr, linux-kernel, netdev
In-Reply-To: <1503125503-15075-1-git-send-email-arvind.yadav.cs@gmail.com>
From: Arvind Yadav <arvind.yadav.cs@gmail.com>
Date: Sat, 19 Aug 2017 12:21:42 +0530
> eisa_device_id are not supposed to change at runtime. All functions
> working with eisa_device_id provided by <linux/eisa.h> work with
> const eisa_device_id. So mark the non-const structs as const.
Series applied, thanks.
^ permalink raw reply
* [PATCH net v2] ipv6: add rcu grace period before freeing fib6_node
From: Wei Wang @ 2017-08-20 0:34 UTC (permalink / raw)
To: David Miller, netdev; +Cc: Eric Dumazet, Martin KaFai Lau, Wei Wang
From: Wei Wang <weiwan@google.com>
We currently keep rt->rt6i_node pointing to the fib6_node for the route.
And some functions make use of this pointer to dereference the fib6_node
from rt structure, e.g. rt6_check(). However, as there is neither
refcount nor rcu taken when dereferencing rt->rt6i_node, it could
potentially cause crashes as rt->rt6i_node could be set to NULL by other
CPUs when doing a route deletion.
This patch introduces an rcu grace period before freeing fib6_node and
makes sure the functions that dereference it takes rcu_read_lock().
Note: there is no "Fixes" tag because this bug was there in a very
early stage.
Signed-off-by: Wei Wang <weiwan@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
---
v2: removed one extra empty line
include/net/ip6_fib.h | 30 +++++++++++++++++++++++++++++-
net/ipv6/ip6_fib.c | 20 ++++++++++++++++----
net/ipv6/route.c | 14 +++++++++++---
3 files changed, 56 insertions(+), 8 deletions(-)
diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
index 71c1646298ae..977a86e3a8d9 100644
--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h
@@ -72,6 +72,7 @@ struct fib6_node {
__u16 fn_flags;
int fn_sernum;
struct rt6_info *rr_ptr;
+ struct rcu_head rcu;
};
#ifndef CONFIG_IPV6_SUBTREES
@@ -171,13 +172,40 @@ static inline void rt6_update_expires(struct rt6_info *rt0, int timeout)
rt0->rt6i_flags |= RTF_EXPIRES;
}
+/* Function to safely get fn->sernum for passed in rt
+ * and store result in passed in cookie.
+ * Return true if we can get cookie safely
+ * Return false if not
+ */
+static inline bool rt6_get_cookie_safe(const struct rt6_info *rt,
+ u32 *cookie)
+{
+ struct fib6_node *fn;
+ bool status = false;
+
+ rcu_read_lock();
+ fn = rcu_dereference(rt->rt6i_node);
+
+ if (fn) {
+ *cookie = fn->fn_sernum;
+ status = true;
+ }
+
+ rcu_read_unlock();
+ return status;
+}
+
static inline u32 rt6_get_cookie(const struct rt6_info *rt)
{
+ u32 cookie = 0;
+
if (rt->rt6i_flags & RTF_PCPU ||
(unlikely(!list_empty(&rt->rt6i_uncached)) && rt->dst.from))
rt = (struct rt6_info *)(rt->dst.from);
- return rt->rt6i_node ? rt->rt6i_node->fn_sernum : 0;
+ rt6_get_cookie_safe(rt, &cookie);
+
+ return cookie;
}
static inline void ip6_rt_put(struct rt6_info *rt)
diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
index 549aacc3cb2c..a9821c230e4e 100644
--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -149,11 +149,23 @@ static struct fib6_node *node_alloc(void)
return fn;
}
-static void node_free(struct fib6_node *fn)
+static void node_free_immediate(struct fib6_node *fn)
+{
+ kmem_cache_free(fib6_node_kmem, fn);
+}
+
+static void node_free_rcu(struct rcu_head *head)
{
+ struct fib6_node *fn = container_of(head, struct fib6_node, rcu);
+
kmem_cache_free(fib6_node_kmem, fn);
}
+static void node_free(struct fib6_node *fn)
+{
+ call_rcu(&fn->rcu, node_free_rcu);
+}
+
void rt6_free_pcpu(struct rt6_info *non_pcpu_rt)
{
int cpu;
@@ -697,9 +709,9 @@ static struct fib6_node *fib6_add_1(struct fib6_node *root,
if (!in || !ln) {
if (in)
- node_free(in);
+ node_free_immediate(in);
if (ln)
- node_free(ln);
+ node_free_immediate(ln);
return ERR_PTR(-ENOMEM);
}
@@ -1138,7 +1150,7 @@ int fib6_add(struct fib6_node *root, struct rt6_info *rt,
root, and then (in failure) stale node
in main tree.
*/
- node_free(sfn);
+ node_free_immediate(sfn);
err = PTR_ERR(sn);
goto failure;
}
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index bec12ae3e6b7..4de2d793c4b8 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1289,7 +1289,9 @@ static void rt6_dst_from_metrics_check(struct rt6_info *rt)
static struct dst_entry *rt6_check(struct rt6_info *rt, u32 cookie)
{
- if (!rt->rt6i_node || (rt->rt6i_node->fn_sernum != cookie))
+ u32 rt_cookie;
+
+ if (!rt6_get_cookie_safe(rt, &rt_cookie) || rt_cookie != cookie)
return NULL;
if (rt6_check_expired(rt))
@@ -1357,8 +1359,14 @@ static void ip6_link_failure(struct sk_buff *skb)
if (rt->rt6i_flags & RTF_CACHE) {
if (dst_hold_safe(&rt->dst))
ip6_del_rt(rt);
- } else if (rt->rt6i_node && (rt->rt6i_flags & RTF_DEFAULT)) {
- rt->rt6i_node->fn_sernum = -1;
+ } else {
+ struct fib6_node *fn;
+
+ rcu_read_lock();
+ fn = rcu_dereference(rt->rt6i_node);
+ if (fn && (rt->rt6i_flags & RTF_DEFAULT))
+ fn->fn_sernum = -1;
+ rcu_read_unlock();
}
}
}
--
2.14.1.480.gb18f417b89-goog
^ permalink raw reply related
* Re: [PATCH RESEND 0/2] enable hires timer to timeout datagram socket
From: Vallish Vaidyeshwara @ 2017-08-20 1:47 UTC (permalink / raw)
To: Richard Cochran
Cc: davem, shuah, netdev, linux-kernel, eduval, anchalag, tglx
In-Reply-To: <20170819062145.vtr63ri4v577cymz@localhost>
On Sat, Aug 19, 2017 at 08:21:45AM +0200, Richard Cochran wrote:
> On Fri, Aug 18, 2017 at 10:27:56PM +0000, Vallish Vaidyeshwara wrote:
> > We have a on-demand application that uses long timeouts and needs to react to
> > events within milliseconds.
>
Hello Richard,
> Huh? The test program you posted does not react to any event.
>
Application has logic for complex events and test program is kept simple to
highlight the change in behavior seen with system calls.
Thanks.
-Vallish
> Thanks,
> Richard
>
^ permalink raw reply
* Re: [PATCH net-next v3] arm: eBPF JIT compiler
From: Alexei Starovoitov @ 2017-08-20 2:11 UTC (permalink / raw)
To: Shubham Bansal
Cc: Andrew Lunn, Kees Cook, Daniel Borkmann, Network Development,
LKML, Russell King - ARM Linux, David Miller, linux-arm-kernel
In-Reply-To: <CAHgaXdJDOseZk0=4uCGeCx44kgnvHf1gnh7CX2c6dTzXb8Rk+g@mail.gmail.com>
On 8/19/17 2:46 PM, Shubham Bansal wrote:
> test_pkt_access:PASS:ipv4 271 nsec
> test_pkt_access:PASS:ipv6 297 nsec
> test_xdp:PASS:ipv4 961517 nsec <--- Here is the difference.
> test_xdp:PASS:ipv6 615855 nsec <--- Here is the difference.
yes. this is expected. These two numbers are single run
on cold cache, so there will be run-to-run variation.
> test_l4lb:PASS:ipv4 3049 nsec
> test_l4lb:PASS:ipv6 3906 nsec
These two and the first two were the ones I was interested in,
since they do many iterations over the same set and
the best to compare code gen changes.
The delta % is actually better than I expected judging by test_bpf
micro-benchmarks, so the results are very encouraging.
Thanks!
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] tcp: Remove unnecessary dst check in tcp_conn_request.
From: David Miller @ 2017-08-20 4:25 UTC (permalink / raw)
To: xiangxia.m.yue; +Cc: netdev
In-Reply-To: <1502938966-6345-2-git-send-email-xiangxia.m.yue@gmail.com>
From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
Date: Wed, 16 Aug 2017 20:02:45 -0700
> Because we remove the tcp_tw_recycle support in the commit
> 4396e46187c ('tcp: remove tcp_tw_recycle') and also delete
> the code 'af_ops->route_req' for sysctl_tw_recycle in tcp_conn_request.
> Now when we call the 'af_ops->route_req', the dist always is
> NULL, and we remove the unnecessay check.
>
> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
This is a bug actually, rather than something to paper over
by removing the check.
Code earlier in this function needs a proper 'dst' in order to operate
properly.
There is a call to tcp_peer_is_proven() which must have a proper route
to make the determination yet it will always be NULL.
Please investigate what the code is doing and how a test became
"unnecessary" over time before blindly removing it, thank you.
^ permalink raw reply
* Re: [PATCH][net-next] net: hns3: fix a handful of spelling mistakes
From: David Miller @ 2017-08-20 4:31 UTC (permalink / raw)
To: colin.king
Cc: yisen.zhuang, salil.mehta, lipeng321, huangdaode, arnd, netdev,
linux-kernel
In-Reply-To: <20170818153000.18516-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 18 Aug 2017 16:30:00 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Trival fix to spelling mistakes:
>
> firware -> firmware
> invald -> invalid
> mutilcast -> multicast
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH][netdev-next] bnxt_en: fix spelling mistake: "swtichdev" -> "switchdev"
From: David Miller @ 2017-08-20 4:31 UTC (permalink / raw)
To: colin.king; +Cc: michael.chan, netdev, linux-kernel
In-Reply-To: <20170818154000.19068-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Fri, 18 Aug 2017 16:40:00 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake in a netdev_info message
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] ipv6: add rcu grace period before freeing fib6_node
From: Martin KaFai Lau @ 2017-08-20 4:32 UTC (permalink / raw)
To: Wei Wang; +Cc: David Miller, Linux Kernel Network Developers, Eric Dumazet
In-Reply-To: <CAEA6p_Dv=mygfEoEofDKzai4QU_9obGRHEP7yC+B00rNGse7cQ@mail.gmail.com>
On Sat, Aug 19, 2017 at 09:51:52AM -0700, Wei Wang wrote:
> Hi Martin,
>
> >> +/* Function to safely get fn->sernum for passed in rt
> >> + * and store result in passed in cookie.
> >> + * Return true if we can get cookie safely
> >> + * Return false if not
> >> + */
> >> +static inline bool rt6_get_cookie_safe(const struct rt6_info *rt,
> >> + u32 *cookie)
> > Looking at fib6_new_sernum(), fn_sernum should be >0.
> >
> > Would it further simplify the later changes if we do this instead?:
> > static inline u32 rt6_get_cookie_safe(const struct rt6_info *rt)
> >
>
> I don't think rt6_check() will work properly if this function only
> returns fn_sernum. Because rt6_get_cookie() will return cookie as 0 if
> the node is already deleted. And socket will store 0 as its
> dst_cookie. And when ip6_dst_check() is called, rt6_check() calls
> rt6_get_cookie_safe() to get the current sernum in fib6_node and finds
> it is also 0, so it will say the dst is valid. But it is wrong.
Thanks for the explanation.
Can rt6_check() just return NULL if the passed in cookie is already
invalid (i.e. 0)? It should have no need to call rt6_get_cookie_safe()
if the passed in cookie is already invalid, or it is still needed?
Instead of having another bool 'false', I was mostly thinking having one
invalid state 'cookie 0' will be easier to read and code later. However,
it is not curical. Lets get this fix in.
> Basically, the return status of rt6_get_cookie_safe() indicates if the
> rt6i_node is NULL or not. And it needs to be checked in rt6_check().
>
> >> +{
> >> + struct fib6_node *fn;
> >> + bool status = false;
> >> +
> >> + rcu_read_lock();
> >> + fn = rcu_dereference(rt->rt6i_node);
> >> +
> >> + if (fn) {
> >> + *cookie = fn->fn_sernum;
> >> + status = true;
> >> + }
> >> +
> >> + rcu_read_unlock();
> >> + return status;
> >> +
> > extra newline.
> >
>
> Thanks. Will remove it in v2.
>
> Wei
>
>
> On Fri, Aug 18, 2017 at 7:20 PM, Martin KaFai Lau <kafai@fb.com> wrote:
> > On Fri, Aug 18, 2017 at 05:36:55PM -0700, Wei Wang wrote:
> >> From: Wei Wang <weiwan@google.com>
> >>
> >> We currently keep rt->rt6i_node pointing to the fib6_node for the route.
> >> And some functions make use of this pointer to dereference the fib6_node
> >> from rt structure, e.g. rt6_check(). However, as there is neither
> >> refcount nor rcu taken when dereferencing rt->rt6i_node, it could
> >> potentially cause crashes as rt->rt6i_node could be set to NULL by other
> >> CPUs when doing a route deletion.
> >> This patch introduces an rcu grace period before freeing fib6_node and
> >> makes sure the functions that dereference it takes rcu_read_lock().
> >>
> >> Note: there is no "Fixes" tag because this bug was there in a very
> >> early stage.
> >>
> >> Signed-off-by: Wei Wang <weiwan@google.com>
> >> Acked-by: Eric Dumazet <edumazet@google.com>
> > Looks good. Thanks for the fixing it.
> > Only have some nits comments.
> >
> >> ---
> >> include/net/ip6_fib.h | 31 ++++++++++++++++++++++++++++++-
> >> net/ipv6/ip6_fib.c | 20 ++++++++++++++++----
> >> net/ipv6/route.c | 14 +++++++++++---
> >> 3 files changed, 57 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
> >> index 71c1646298ae..5691faf6b495 100644
> >> --- a/include/net/ip6_fib.h
> >> +++ b/include/net/ip6_fib.h
> >> @@ -72,6 +72,7 @@ struct fib6_node {
> >> __u16 fn_flags;
> >> int fn_sernum;
> >> struct rt6_info *rr_ptr;
> >> + struct rcu_head rcu;
> >> };
> >>
> >> #ifndef CONFIG_IPV6_SUBTREES
> >> @@ -171,13 +172,41 @@ static inline void rt6_update_expires(struct rt6_info *rt0, int timeout)
> >> rt0->rt6i_flags |= RTF_EXPIRES;
> >> }
> >>
> >> +/* Function to safely get fn->sernum for passed in rt
> >> + * and store result in passed in cookie.
> >> + * Return true if we can get cookie safely
> >> + * Return false if not
> >> + */
> >> +static inline bool rt6_get_cookie_safe(const struct rt6_info *rt,
> >> + u32 *cookie)
> > Looking at fib6_new_sernum(), fn_sernum should be >0.
> >
> > Would it further simplify the later changes if we do this instead?:
> > static inline u32 rt6_get_cookie_safe(const struct rt6_info *rt)
> >
> >> +{
> >> + struct fib6_node *fn;
> >> + bool status = false;
> >> +
> >> + rcu_read_lock();
> >> + fn = rcu_dereference(rt->rt6i_node);
> >> +
> >> + if (fn) {
> >> + *cookie = fn->fn_sernum;
> >> + status = true;
> >> + }
> >> +
> >> + rcu_read_unlock();
> >> + return status;
> >> +
> > extra newline.
> >
> >> +}
> >> +
> >> static inline u32 rt6_get_cookie(const struct rt6_info *rt)
> >> {
> >> + u32 cookie = 0;
> >> +
> >> if (rt->rt6i_flags & RTF_PCPU ||
> >> (unlikely(!list_empty(&rt->rt6i_uncached)) && rt->dst.from))
> >> rt = (struct rt6_info *)(rt->dst.from);
> >>
> >> - return rt->rt6i_node ? rt->rt6i_node->fn_sernum : 0;
> >> + rt6_get_cookie_safe(rt, &cookie);
> >> +
> >> + return cookie;
> >> }
> >>
> >> static inline void ip6_rt_put(struct rt6_info *rt)
> >> diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
> >> index 549aacc3cb2c..a9821c230e4e 100644
> >> --- a/net/ipv6/ip6_fib.c
> >> +++ b/net/ipv6/ip6_fib.c
> >> @@ -149,11 +149,23 @@ static struct fib6_node *node_alloc(void)
> >> return fn;
> >> }
> >>
> >> -static void node_free(struct fib6_node *fn)
> >> +static void node_free_immediate(struct fib6_node *fn)
> >> +{
> >> + kmem_cache_free(fib6_node_kmem, fn);
> >> +}
> >> +
> >> +static void node_free_rcu(struct rcu_head *head)
> >> {
> >> + struct fib6_node *fn = container_of(head, struct fib6_node, rcu);
> >> +
> >> kmem_cache_free(fib6_node_kmem, fn);
> >> }
> >>
> >> +static void node_free(struct fib6_node *fn)
> >> +{
> >> + call_rcu(&fn->rcu, node_free_rcu);
> >> +}
> >> +
> >> void rt6_free_pcpu(struct rt6_info *non_pcpu_rt)
> >> {
> >> int cpu;
> >> @@ -697,9 +709,9 @@ static struct fib6_node *fib6_add_1(struct fib6_node *root,
> >>
> >> if (!in || !ln) {
> >> if (in)
> >> - node_free(in);
> >> + node_free_immediate(in);
> >> if (ln)
> >> - node_free(ln);
> >> + node_free_immediate(ln);
> >> return ERR_PTR(-ENOMEM);
> >> }
> >>
> >> @@ -1138,7 +1150,7 @@ int fib6_add(struct fib6_node *root, struct rt6_info *rt,
> >> root, and then (in failure) stale node
> >> in main tree.
> >> */
> >> - node_free(sfn);
> >> + node_free_immediate(sfn);
> >> err = PTR_ERR(sn);
> >> goto failure;
> >> }
> >> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> >> index bec12ae3e6b7..4de2d793c4b8 100644
> >> --- a/net/ipv6/route.c
> >> +++ b/net/ipv6/route.c
> >> @@ -1289,7 +1289,9 @@ static void rt6_dst_from_metrics_check(struct rt6_info *rt)
> >>
> >> static struct dst_entry *rt6_check(struct rt6_info *rt, u32 cookie)
> >> {
> >> - if (!rt->rt6i_node || (rt->rt6i_node->fn_sernum != cookie))
> >> + u32 rt_cookie;
> >> +
> >> + if (!rt6_get_cookie_safe(rt, &rt_cookie) || rt_cookie != cookie)
> >> return NULL;
> >>
> >> if (rt6_check_expired(rt))
> >> @@ -1357,8 +1359,14 @@ static void ip6_link_failure(struct sk_buff *skb)
> >> if (rt->rt6i_flags & RTF_CACHE) {
> >> if (dst_hold_safe(&rt->dst))
> >> ip6_del_rt(rt);
> >> - } else if (rt->rt6i_node && (rt->rt6i_flags & RTF_DEFAULT)) {
> >> - rt->rt6i_node->fn_sernum = -1;
> >> + } else {
> >> + struct fib6_node *fn;
> >> +
> >> + rcu_read_lock();
> >> + fn = rcu_dereference(rt->rt6i_node);
> >> + if (fn && (rt->rt6i_flags & RTF_DEFAULT))
> >> + fn->fn_sernum = -1;
> >> + rcu_read_unlock();
> >> }
> >> }
> >> }
> >> --
> >> 2.14.1.480.gb18f417b89-goog
> >>
^ permalink raw reply
* Re: [PATCH net-next] cxgb4/cxgbvf: Handle 32-bit fw port capabilities
From: David Miller @ 2017-08-20 4:32 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, leedom, venkatesh
In-Reply-To: <1503071492-4822-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Fri, 18 Aug 2017 21:21:32 +0530
> Implement new 32-bit Firmware Port Capabilities in order to
> handle new speeds which couldn't be represented in the old 16-bit
> Firmware Port Capabilities values.
>
> Based on the original work of Casey Leedom <leedom@chelsio.com>
>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH net v2] ipv6: add rcu grace period before freeing fib6_node
From: Martin KaFai Lau @ 2017-08-20 4:33 UTC (permalink / raw)
To: Wei Wang; +Cc: David Miller, netdev, Eric Dumazet
In-Reply-To: <20170820003408.133176-1-tracywwnj@gmail.com>
On Sat, Aug 19, 2017 at 05:34:08PM -0700, Wei Wang wrote:
> From: Wei Wang <weiwan@google.com>
>
> We currently keep rt->rt6i_node pointing to the fib6_node for the route.
> And some functions make use of this pointer to dereference the fib6_node
> from rt structure, e.g. rt6_check(). However, as there is neither
> refcount nor rcu taken when dereferencing rt->rt6i_node, it could
> potentially cause crashes as rt->rt6i_node could be set to NULL by other
> CPUs when doing a route deletion.
> This patch introduces an rcu grace period before freeing fib6_node and
> makes sure the functions that dereference it takes rcu_read_lock().
>
> Note: there is no "Fixes" tag because this bug was there in a very
> early stage.
>
> Signed-off-by: Wei Wang <weiwan@google.com>
> Acked-by: Eric Dumazet <edumazet@google.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
> ---
> v2: removed one extra empty line
>
> include/net/ip6_fib.h | 30 +++++++++++++++++++++++++++++-
> net/ipv6/ip6_fib.c | 20 ++++++++++++++++----
> net/ipv6/route.c | 14 +++++++++++---
> 3 files changed, 56 insertions(+), 8 deletions(-)
>
> diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
> index 71c1646298ae..977a86e3a8d9 100644
> --- a/include/net/ip6_fib.h
> +++ b/include/net/ip6_fib.h
> @@ -72,6 +72,7 @@ struct fib6_node {
> __u16 fn_flags;
> int fn_sernum;
> struct rt6_info *rr_ptr;
> + struct rcu_head rcu;
> };
>
> #ifndef CONFIG_IPV6_SUBTREES
> @@ -171,13 +172,40 @@ static inline void rt6_update_expires(struct rt6_info *rt0, int timeout)
> rt0->rt6i_flags |= RTF_EXPIRES;
> }
>
> +/* Function to safely get fn->sernum for passed in rt
> + * and store result in passed in cookie.
> + * Return true if we can get cookie safely
> + * Return false if not
> + */
> +static inline bool rt6_get_cookie_safe(const struct rt6_info *rt,
> + u32 *cookie)
> +{
> + struct fib6_node *fn;
> + bool status = false;
> +
> + rcu_read_lock();
> + fn = rcu_dereference(rt->rt6i_node);
> +
> + if (fn) {
> + *cookie = fn->fn_sernum;
> + status = true;
> + }
> +
> + rcu_read_unlock();
> + return status;
> +}
> +
> static inline u32 rt6_get_cookie(const struct rt6_info *rt)
> {
> + u32 cookie = 0;
> +
> if (rt->rt6i_flags & RTF_PCPU ||
> (unlikely(!list_empty(&rt->rt6i_uncached)) && rt->dst.from))
> rt = (struct rt6_info *)(rt->dst.from);
>
> - return rt->rt6i_node ? rt->rt6i_node->fn_sernum : 0;
> + rt6_get_cookie_safe(rt, &cookie);
> +
> + return cookie;
> }
>
> static inline void ip6_rt_put(struct rt6_info *rt)
> diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
> index 549aacc3cb2c..a9821c230e4e 100644
> --- a/net/ipv6/ip6_fib.c
> +++ b/net/ipv6/ip6_fib.c
> @@ -149,11 +149,23 @@ static struct fib6_node *node_alloc(void)
> return fn;
> }
>
> -static void node_free(struct fib6_node *fn)
> +static void node_free_immediate(struct fib6_node *fn)
> +{
> + kmem_cache_free(fib6_node_kmem, fn);
> +}
> +
> +static void node_free_rcu(struct rcu_head *head)
> {
> + struct fib6_node *fn = container_of(head, struct fib6_node, rcu);
> +
> kmem_cache_free(fib6_node_kmem, fn);
> }
>
> +static void node_free(struct fib6_node *fn)
> +{
> + call_rcu(&fn->rcu, node_free_rcu);
> +}
> +
> void rt6_free_pcpu(struct rt6_info *non_pcpu_rt)
> {
> int cpu;
> @@ -697,9 +709,9 @@ static struct fib6_node *fib6_add_1(struct fib6_node *root,
>
> if (!in || !ln) {
> if (in)
> - node_free(in);
> + node_free_immediate(in);
> if (ln)
> - node_free(ln);
> + node_free_immediate(ln);
> return ERR_PTR(-ENOMEM);
> }
>
> @@ -1138,7 +1150,7 @@ int fib6_add(struct fib6_node *root, struct rt6_info *rt,
> root, and then (in failure) stale node
> in main tree.
> */
> - node_free(sfn);
> + node_free_immediate(sfn);
> err = PTR_ERR(sn);
> goto failure;
> }
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index bec12ae3e6b7..4de2d793c4b8 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -1289,7 +1289,9 @@ static void rt6_dst_from_metrics_check(struct rt6_info *rt)
>
> static struct dst_entry *rt6_check(struct rt6_info *rt, u32 cookie)
> {
> - if (!rt->rt6i_node || (rt->rt6i_node->fn_sernum != cookie))
> + u32 rt_cookie;
> +
> + if (!rt6_get_cookie_safe(rt, &rt_cookie) || rt_cookie != cookie)
> return NULL;
>
> if (rt6_check_expired(rt))
> @@ -1357,8 +1359,14 @@ static void ip6_link_failure(struct sk_buff *skb)
> if (rt->rt6i_flags & RTF_CACHE) {
> if (dst_hold_safe(&rt->dst))
> ip6_del_rt(rt);
> - } else if (rt->rt6i_node && (rt->rt6i_flags & RTF_DEFAULT)) {
> - rt->rt6i_node->fn_sernum = -1;
> + } else {
> + struct fib6_node *fn;
> +
> + rcu_read_lock();
> + fn = rcu_dereference(rt->rt6i_node);
> + if (fn && (rt->rt6i_flags & RTF_DEFAULT))
> + fn->fn_sernum = -1;
> + rcu_read_unlock();
> }
> }
> }
> --
> 2.14.1.480.gb18f417b89-goog
>
^ permalink raw reply
* Re: [PATCH net-next] cxgb4/cxgbvf: Handle 32-bit fw port capabilities
From: David Miller @ 2017-08-20 4:34 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, leedom, venkatesh
In-Reply-To: <20170819.213240.451867452734302860.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sat, 19 Aug 2017 21:32:40 -0700 (PDT)
> From: Ganesh Goudar <ganeshgr@chelsio.com>
> Date: Fri, 18 Aug 2017 21:21:32 +0530
>
>> Implement new 32-bit Firmware Port Capabilities in order to
>> handle new speeds which couldn't be represented in the old 16-bit
>> Firmware Port Capabilities values.
>>
>> Based on the original work of Casey Leedom <leedom@chelsio.com>
>>
>> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
>
> Applied.
Reverted, this doesn't even build!
[davem@localhost net-next]$ make -s -j8
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c: In function ‘fwevtq_handler’:
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:534:50: error: expected ‘)’ before ‘{’ token
action == FW_PORT_ACTION_GET_PORT_INFO32) {
^
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:560:2: error: expected expression before ‘}’ token
} else if (opcode == CPL_L2T_WRITE_RPL) {
^
At top level:
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:463:13: warning: ‘dcb_rpl’ defined but not used [-Wunused-function]
static void dcb_rpl(struct adapter *adap, const struct fw_port_cmd *pcmd)
^~~~~~~
make[5]: *** [scripts/Makefile.build:303: drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.o] Error 1
make[5]: *** Waiting for unfinished jobs....
make[4]: *** [scripts/Makefile.build:561: drivers/net/ethernet/chelsio/cxgb4] Error 2
make[3]: *** [scripts/Makefile.build:561: drivers/net/ethernet/chelsio] Error 2
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [scripts/Makefile.build:561: drivers/net/ethernet] Error 2
make[1]: *** [scripts/Makefile.build:561: drivers/net] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:1019: drivers] Error 2
^ permalink raw reply
* [PATCH v2] net: ibm: emac: Fix some error handling path in 'emac_probe()'
From: Christophe JAILLET @ 2017-08-20 4:35 UTC (permalink / raw)
To: davem, chunkeey, jarod, ivan, ebiggers, tklauser, tremyfr, robh
Cc: netdev, linux-kernel, kernel-janitors, Christophe JAILLET
If 'irq_of_parse_and_map()' or 'of_address_to_resource()' fail, 'err' is
known to be 0 at this point.
So return -ENODEV instead in the first case and use 'of_iomap()' instead of
the equivalent 'of_address_to_resource()/ioremap()' combinaison in the 2nd
case.
Doing so, the 'rsrc_regs' field of the 'emac_instance struct' becomes
redundant and is removed.
While at it, turn a 'err != 0' test into an equivalent 'err' to be more
consistent.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
v2: use of_iomap() to simplify code
remove 'rsrc_regs' field of the 'emac_instance struct'
update comment
---
drivers/net/ethernet/ibm/emac/core.c | 12 ++++--------
drivers/net/ethernet/ibm/emac/core.h | 1 -
2 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/ibm/emac/core.c b/drivers/net/ethernet/ibm/emac/core.c
index 95135d20458f..7feff2450ed6 100644
--- a/drivers/net/ethernet/ibm/emac/core.c
+++ b/drivers/net/ethernet/ibm/emac/core.c
@@ -3032,7 +3032,7 @@ static int emac_probe(struct platform_device *ofdev)
/* Init various config data based on device-tree */
err = emac_init_config(dev);
- if (err != 0)
+ if (err)
goto err_free;
/* Get interrupts. EMAC irq is mandatory, WOL irq is optional */
@@ -3040,18 +3040,14 @@ static int emac_probe(struct platform_device *ofdev)
dev->wol_irq = irq_of_parse_and_map(np, 1);
if (!dev->emac_irq) {
printk(KERN_ERR "%pOF: Can't map main interrupt\n", np);
+ err = -ENODEV;
goto err_free;
}
ndev->irq = dev->emac_irq;
/* Map EMAC regs */
- if (of_address_to_resource(np, 0, &dev->rsrc_regs)) {
- printk(KERN_ERR "%pOF: Can't get registers address\n", np);
- goto err_irq_unmap;
- }
- // TODO : request_mem_region
- dev->emacp = ioremap(dev->rsrc_regs.start,
- resource_size(&dev->rsrc_regs));
+ // TODO : platform_get_resource() and devm_ioremap_resource()
+ dev->emacp = of_iomap(np, 0);
if (dev->emacp == NULL) {
printk(KERN_ERR "%pOF: Can't map device registers!\n", np);
err = -ENOMEM;
diff --git a/drivers/net/ethernet/ibm/emac/core.h b/drivers/net/ethernet/ibm/emac/core.h
index f10e156641d5..369de2cfb15b 100644
--- a/drivers/net/ethernet/ibm/emac/core.h
+++ b/drivers/net/ethernet/ibm/emac/core.h
@@ -167,7 +167,6 @@ struct emac_error_stats {
struct emac_instance {
struct net_device *ndev;
- struct resource rsrc_regs;
struct emac_regs __iomem *emacp;
struct platform_device *ofdev;
struct device_node **blist; /* bootlist entry */
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net-next 0/2] bpf: Allow selecting numa node during map creation
From: David Miller @ 2017-08-20 4:35 UTC (permalink / raw)
To: kafai; +Cc: netdev, ast, daniel, kernel-team
In-Reply-To: <20170818182801.2518162-1-kafai@fb.com>
From: Martin KaFai Lau <kafai@fb.com>
Date: Fri, 18 Aug 2017 11:27:59 -0700
> This series allows user to pick the numa node during map creation.
> The first patch has the details
Series applied, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox