* Re: Blogpost evaluation this [PATCH v4 net-next RFC] net: Generic XDP
From: David Miller @ 2017-04-24 22:26 UTC (permalink / raw)
To: brouer; +Cc: xdp-newbies, netdev, andy
In-Reply-To: <20170424162405.1183f2e7@redhat.com>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Date: Mon, 24 Apr 2017 16:24:05 +0200
> I've done a very detailed evaluation of this patch, and I've created a
> blogpost like report here:
>
> https://prototype-kernel.readthedocs.io/en/latest/blogposts/xdp25_eval_generic_xdp_tx.html
Thanks for doing this Jesper.
> I didn't evaluate the adjust_head part, so I hope Andy is still
> planning to validate that part?
I was hoping he would post some results today as well.
Andy, how goes it? :)
Once the basic patch is ready and integrated in we can try to do
xmit_more in generic XDP and see what that does for XDP_TX
performance.
^ permalink raw reply
* Re: [PATCH net 0/3] net: dsa: b53: BCM58xx devices fixes
From: David Miller @ 2017-04-24 22:29 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot, eric, jon.mason
In-Reply-To: <20170424212723.15407-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 24 Apr 2017 14:27:20 -0700
> This patch series contains fixes for the 58xx devices (Broadcom Northstar
> Plus), which were identified thanks to the help of Eric Anholt.
Series applied, thanks Florian.
^ permalink raw reply
* Re: [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: Scott Branden @ 2017-04-24 22:50 UTC (permalink / raw)
To: Eric Anholt, Florian Fainelli, Vivien Didelot, Andrew Lunn,
netdev-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Ray Jui,
Scott Branden, Jon Mason
In-Reply-To: <20170424215022.30382-2-eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
Minor comment in line
On 17-04-24 02:50 PM, Eric Anholt wrote:
> Cygnus is a small family of SoCs, of which we currently have
> devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the
> same as 58xx, just requiring a tiny bit of setup that was previously
> missing.
>
> Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
> ---
> Documentation/devicetree/bindings/net/dsa/b53.txt | 3 +++
> drivers/net/dsa/b53/b53_srab.c | 2 ++
> 2 files changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/dsa/b53.txt b/Documentation/devicetree/bindings/net/dsa/b53.txt
> index d6c6e41648d4..49c93d3c0839 100644
> --- a/Documentation/devicetree/bindings/net/dsa/b53.txt
> +++ b/Documentation/devicetree/bindings/net/dsa/b53.txt
> @@ -29,6 +29,9 @@ Required properties:
> "brcm,bcm58625-srab"
> "brcm,bcm88312-srab" and the mandatory "brcm,nsp-srab string
>
> + For the BCM11360 SoC, must be:
> + "brcm,bcm11360-srab" and the mandatory "brcm,cygnus-srab string
> +
place in alphabetical order in the doc?
> For the BCM63xx/33xx SoCs with an integrated switch, must be one of:
> "brcm,bcm3384-switch"
> "brcm,bcm6328-switch"
> diff --git a/drivers/net/dsa/b53/b53_srab.c b/drivers/net/dsa/b53/b53_srab.c
> index 8a62b6a69703..c37ffd1b6833 100644
> --- a/drivers/net/dsa/b53/b53_srab.c
> +++ b/drivers/net/dsa/b53/b53_srab.c
> @@ -364,6 +364,7 @@ static const struct of_device_id b53_srab_of_match[] = {
> { .compatible = "brcm,bcm53018-srab" },
> { .compatible = "brcm,bcm53019-srab" },
> { .compatible = "brcm,bcm5301x-srab" },
> + { .compatible = "brcm,bcm11360-srab", .data = (void *)BCM58XX_DEVICE_ID },
> { .compatible = "brcm,bcm58522-srab", .data = (void *)BCM58XX_DEVICE_ID },
> { .compatible = "brcm,bcm58525-srab", .data = (void *)BCM58XX_DEVICE_ID },
> { .compatible = "brcm,bcm58535-srab", .data = (void *)BCM58XX_DEVICE_ID },
> @@ -371,6 +372,7 @@ static const struct of_device_id b53_srab_of_match[] = {
> { .compatible = "brcm,bcm58623-srab", .data = (void *)BCM58XX_DEVICE_ID },
> { .compatible = "brcm,bcm58625-srab", .data = (void *)BCM58XX_DEVICE_ID },
> { .compatible = "brcm,bcm88312-srab", .data = (void *)BCM58XX_DEVICE_ID },
> + { .compatible = "brcm,cygnus-srab", .data = (void *)BCM58XX_DEVICE_ID },
> { .compatible = "brcm,nsp-srab", .data = (void *)BCM58XX_DEVICE_ID },
> { /* sentinel */ },
> };
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v5 1/2] net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch
From: Jamal Hadi Salim @ 2017-04-24 22:58 UTC (permalink / raw)
To: David Miller
Cc: simon.horman, jiri, xiyou.wangcong, eric.dumazet, netdev, tom,
pablo
In-Reply-To: <20170424.182453.1488000441860994588.davem@davemloft.net>
On 17-04-24 06:24 PM, David Miller wrote:
>
> I think we should eat the pain now and use the strict checks
> for all new features like this.
>
> I'm sorry if this makes more work for you, but this is really
> how we have to proceed moving forward.
>
There is no work for me to do in tc if i push this in without
the liberal flag i was suggesting.
This is more about the next flag change that will fail with
older kernels unless the large tc change happens
i.e future ones after this kernel patch.
cheers,
jamal
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH] ixgbe: initialize u64_stats_sync structures early at ixgbe_probe
From: Singh, Krishneil K @ 2017-04-24 23:00 UTC (permalink / raw)
To: Song, Liwei (Wind River), Kirsher, Jeffrey T
Cc: netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
linux-kernel@vger.kernel.org, Song, Liwei (Wind River)
In-Reply-To: <1480909244-16460-1-git-send-email-liwei.song@windriver.com>
-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-bounces@lists.osuosl.org] On Behalf Of Liwei Song
Sent: Sunday, December 4, 2016 7:41 PM
To: Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>
Cc: netdev@vger.kernel.org; intel-wired-lan@lists.osuosl.org; linux-kernel@vger.kernel.org; Song, Liwei (Wind River) <liwei.song@windriver.com>
Subject: [Intel-wired-lan] [PATCH] ixgbe: initialize u64_stats_sync structures early at ixgbe_probe
Fix the following CallTrace:
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 71 PID: 1 Comm: swapper/0 Not tainted 4.8.8-WR9.0.0.1_standard #11 Hardware name: Intel Corporation S2600WTT/S2600WTT, BIOS GRNDSDP1.86B.0036.R05.1407140519 07/14/2014
00200086 00200086 eb5e1ab8 c144dd70 00000000 00000000 eb5e1af8 c10af89a
c1d23de4 eb5e1af8 00000009 eb5d8600 eb5d8638 eb5e1af8 c10b14d8 00000009 0000000a c1d32911 00000000 00000000 e44c826c eb5d8000 eb5e1b74 c10b214e Call Trace:
[<c144dd70>] dump_stack+0x5f/0x8f
[<c10af89a>] register_lock_class+0x25a/0x4c0 [<c10b14d8>] ? check_irq_usage+0x88/0xc0 [<c10b214e>] __lock_acquire+0x5e/0x17a0 [<c1abdb9b>] ? _raw_spin_unlock_irqrestore+0x3b/0x70
[<c10cf14a>] ? rcu_read_lock_sched_held+0x8a/0x90
[<c10b3c5f>] lock_acquire+0x9f/0x1f0
[<c1922dcf>] ? dev_get_stats+0x5f/0x110 [<c176e6b3>] ixgbe_get_stats64+0x113/0x320 [<c1922dcf>] ? dev_get_stats+0x5f/0x110 [<c1922dcf>] dev_get_stats+0x5f/0x110 [<c1ab5415>] rtnl_fill_stats+0x40/0x105 [<c193dd45>] rtnl_fill_ifinfo+0x4c5/0xd20 [<c11c5115>] ? __kmalloc_node_track_caller+0x1a5/0x410
[<c1917487>] ? __kmalloc_reserve.isra.42+0x27/0x80
[<c191754f>] ? __alloc_skb+0x6f/0x270
[<c1942291>] rtmsg_ifinfo_build_skb+0x71/0xd0 [<c194230a>] rtmsg_ifinfo.part.23+0x1a/0x50 [<c1923dad>] ? call_netdevice_notifiers_info+0x2d/0x60
[<c194236b>] rtmsg_ifinfo+0x2b/0x40
[<c192f997>] register_netdevice+0x3d7/0x4d0 [<c192faa7>] register_netdev+0x17/0x30 [<c177b83d>] ixgbe_probe+0x118d/0x1610 [<c1498202>] local_pci_probe+0x32/0x80 [<c1498172>] ? pci_match_device+0xd2/0x100 [<c14991e0>] pci_device_probe+0xc0/0x110 [<c1652cc5>] driver_probe_device+0x1c5/0x280 [<c1498172>] ? pci_match_device+0xd2/0x100 [<c1652e09>] __driver_attach+0x89/0x90 [<c1652d80>] ? driver_probe_device+0x280/0x280 [<c165114f>] bus_for_each_dev+0x4f/0x80 [<c165269e>] driver_attach+0x1e/0x20 [<c1652d80>] ? driver_probe_device+0x280/0x280 [<c1652317>] bus_add_driver+0x1a7/0x220 [<c1653a79>] driver_register+0x59/0xe0 [<c1f897b8>] ? igb_init_module+0x49/0x49 [<c1497b2a>] __pci_register_driver+0x4a/0x50 [<c1f8985d>] ixgbe_init_module+0xa5/0xc4 [<c1000485>] do_one_initcall+0x3
5/0x150 [<c107e818>] ? parameq+0x18/0x70 [<c1f395d8>] ? repair_env_string+0x12/0x51 [<c107ead0>] ? parse_args+0x260/0x3b0 [<c1074f73>] ? __usermodehelper_set_disable_depth+0x43/0x50
[<c1f39e90>] kernel_init_freeable+0x19b/0x267 [<c1f395c6>] ? set_debug_rodata+0xf/0xf [<c10b1e7b>] ? trace_hardirqs_on+0xb/0x10 [<c1abdc02>] ? _raw_spin_unlock_irq+0x32/0x50 [<c1085f0b>] ? finish_task_switch+0xab/0x1f0 [<c1085ec9>] ? finish_task_switch+0x69/0x1f0 [<c1ab6a30>] kernel_init+0x10/0x110 [<c108bd65>] ? schedule_tail+0x25/0x80 [<c1abe422>] ret_from_kernel_thread+0xe/0x24 [<c1ab6a20>] ? rest_init+0x130/0x130
This CallTrace occurred on 32-bit kernel with CONFIG_PROVE_LOCKING enabled.
This happens at ixgbe driver probe hardware stage, when comes to ixgbe_get_stats64, the seqcount/seqlock still not initialize, although this was initialize in TX/RX resources setup routin, but it was too late, then lockdep give this Warning.
To fix this, move the u64_stats_init function to driver probe stage, which before we get the status of seqcount and after the RX/TX ring was finished init.
Signed-off-by: Liwei Song <liwei.song@windriver.com>
---
Tested-by: Krishneil Singh <krishneil.k.singh@intel.com>
^ permalink raw reply
* [PATCH] sparc64: Support cbcond instructions in eBPF JIT.
From: David Miller @ 2017-04-24 23:02 UTC (permalink / raw)
To: netdev; +Cc: ast, daniel
cbcond combines a compare with a branch into a single instruction.
The limitations are:
1) Only newer chips support it
2) For immediate compares we are limited to 5-bit signed immediate
values
3) The branch displacement is limited to 10-bit signed
4) We cannot use it for JSET
Also, cbcond (unlike all other sparc control transfers) lacks a delay
slot.
Currently we don't have a useful instruction we can push into the
delay slot of normal branches. So using cbcond pretty much always
increases code density, and is therefore a win.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
Example output from "ALU_ADD_K: 0 + 0x80008000 = 0xffffffff80008000":
0000000000000000 <foo>:
0: 9d e3 bf 50 save %sp, -176, %sp
4: 01 00 00 00 nop
8: 90 10 00 18 mov %i0, %o0
c: 03 00 00 00 sethi %hi(0), %g1
10: 82 10 60 00 mov %g1, %g1 ! 0 <foo>
14: 13 00 00 00 sethi %hi(0), %o1
18: 92 12 60 00 mov %o1, %o1 ! 0 <foo>
1c: 83 28 70 20 sllx %g1, 0x20, %g1
20: 92 12 40 01 or %o1, %g1, %o1
24: 03 3f ff ff sethi %hi(0xfffffc00), %g1
28: 82 10 63 ff or %g1, 0x3ff, %g1 ! ffffffff <foo+0xffffffff>
2c: 15 20 00 20 sethi %hi(0x80008000), %o2
30: 94 12 a0 00 mov %o2, %o2 ! 80008000 <foo+0x80008000>
34: 83 28 70 20 sllx %g1, 0x20, %g1
38: 94 12 80 01 or %o2, %g1, %o2
3c: 03 1f ff df sethi %hi(0x7fff7c00), %g1
40: 82 18 7c 00 xor %g1, -1024, %g1
44: 92 02 40 01 add %o1, %g1, %o1
48: 12 e2 40 8a cxbe %o1, %o2, 58 <foo+0x58>
4c: 9a 10 20 02 mov 2, %o5
50: 10 60 00 03 b,pn %xcc, 5c <foo+0x5c>
54: 01 00 00 00 nop
58: 9a 10 20 01 mov 1, %o5 ! 1 <foo+0x1>
5c: 81 c7 e0 08 ret
60: 91 eb 40 00 restore %o5, %g0, %o0
arch/sparc/net/bpf_jit_comp_64.c | 238 ++++++++++++++++++++++++++++++---------
1 file changed, 184 insertions(+), 54 deletions(-)
diff --git a/arch/sparc/net/bpf_jit_comp_64.c b/arch/sparc/net/bpf_jit_comp_64.c
index 43bef1c..2b2f3c3 100644
--- a/arch/sparc/net/bpf_jit_comp_64.c
+++ b/arch/sparc/net/bpf_jit_comp_64.c
@@ -18,6 +18,16 @@ static inline bool is_simm13(unsigned int value)
return value + 0x1000 < 0x2000;
}
+static inline bool is_simm10(unsigned int value)
+{
+ return value + 0x200 < 0x400;
+}
+
+static inline bool is_simm5(unsigned int value)
+{
+ return value + 0x10 < 0x20;
+}
+
static void bpf_flush_icache(void *start_, void *end_)
{
/* Cheetah's I-cache is fully coherent. */
@@ -39,6 +49,7 @@ static void bpf_flush_icache(void *start_, void *end_)
#define SEEN_MEM 4 /* use mem[] for temporary storage */
#define S13(X) ((X) & 0x1fff)
+#define S5(X) ((X) & 0x1f)
#define IMMED 0x00002000
#define RD(X) ((X) << 25)
#define RS1(X) ((X) << 14)
@@ -46,7 +57,8 @@ static void bpf_flush_icache(void *start_, void *end_)
#define OP(X) ((X) << 30)
#define OP2(X) ((X) << 22)
#define OP3(X) ((X) << 19)
-#define COND(X) ((X) << 25)
+#define COND(X) (((X) & 0xf) << 25)
+#define CBCOND(X) (((X) & 0x1f) << 25)
#define F1(X) OP(X)
#define F2(X, Y) (OP(X) | OP2(Y))
#define F3(X, Y) (OP(X) | OP3(Y))
@@ -75,10 +87,39 @@ static void bpf_flush_icache(void *start_, void *end_)
#define WDISP22(X) (((X) >> 2) & 0x3fffff)
#define WDISP19(X) (((X) >> 2) & 0x7ffff)
+/* The 10-bit branch displacement for CBCOND is split into two fields */
+static u32 WDISP10(u32 off)
+{
+ u32 ret = ((off >> 2) & 0xff) << 5;
+
+ ret |= ((off >> (2 + 8)) & 0x03) << 19;
+
+ return ret;
+}
+
+#define CBCONDE CBCOND(0x09)
+#define CBCONDLE CBCOND(0x0a)
+#define CBCONDL CBCOND(0x0b)
+#define CBCONDLEU CBCOND(0x0c)
+#define CBCONDCS CBCOND(0x0d)
+#define CBCONDN CBCOND(0x0e)
+#define CBCONDVS CBCOND(0x0f)
+#define CBCONDNE CBCOND(0x19)
+#define CBCONDG CBCOND(0x1a)
+#define CBCONDGE CBCOND(0x1b)
+#define CBCONDGU CBCOND(0x1c)
+#define CBCONDCC CBCOND(0x1d)
+#define CBCONDPOS CBCOND(0x1e)
+#define CBCONDVC CBCOND(0x1f)
+
+#define CBCONDGEU CBCONDCC
+#define CBCONDLU CBCONDCS
+
#define ANNUL (1 << 29)
#define XCC (1 << 21)
#define BRANCH (F2(0, 1) | XCC)
+#define CBCOND_OP (F2(0, 3) | XCC)
#define BA (BRANCH | CONDA)
#define BG (BRANCH | CONDG)
@@ -351,6 +392,22 @@ static void emit_branch(unsigned int br_opc, unsigned int from_idx, unsigned int
emit(br_opc | WDISP22(off << 2), ctx);
}
+static void emit_cbcond(unsigned int cb_opc, unsigned int from_idx, unsigned int to_idx,
+ const u8 dst, const u8 src, struct jit_ctx *ctx)
+{
+ unsigned int off = to_idx - from_idx;
+
+ emit(cb_opc | WDISP10(off << 2) | RS1(dst) | RS2(src), ctx);
+}
+
+static void emit_cbcondi(unsigned int cb_opc, unsigned int from_idx, unsigned int to_idx,
+ const u8 dst, s32 imm, struct jit_ctx *ctx)
+{
+ unsigned int off = to_idx - from_idx;
+
+ emit(cb_opc | IMMED | WDISP10(off << 2) | RS1(dst) | S5(imm), ctx);
+}
+
#define emit_read_y(REG, CTX) emit(RD_Y | RD(REG), CTX)
#define emit_write_y(REG, CTX) emit(WR_Y | IMMED | RS1(REG) | S13(0), CTX)
@@ -358,7 +415,7 @@ static void emit_branch(unsigned int br_opc, unsigned int from_idx, unsigned int
emit(SUBCC | RS1(R1) | RS2(R2) | RD(G0), CTX)
#define emit_cmpi(R1, IMM, CTX) \
- emit(SUBCC | IMMED | RS1(R1) | S13(IMM) | RD(G0), CTX);
+ emit(SUBCC | IMMED | RS1(R1) | S13(IMM) | RD(G0), CTX)
#define emit_btst(R1, R2, CTX) \
emit(ANDCC | RS1(R1) | RS2(R2) | RD(G0), CTX)
@@ -366,6 +423,117 @@ static void emit_branch(unsigned int br_opc, unsigned int from_idx, unsigned int
#define emit_btsti(R1, IMM, CTX) \
emit(ANDCC | IMMED | RS1(R1) | S13(IMM) | RD(G0), CTX)
+static int emit_compare_and_branch(const u8 code, const u8 dst, u8 src,
+ const s32 imm, bool is_imm, int branch_dst,
+ struct jit_ctx *ctx)
+{
+ bool use_cbcond = (sparc64_elf_hwcap & AV_SPARC_CBCOND) != 0;
+ const u8 tmp = bpf2sparc[TMP_REG_1];
+
+ branch_dst = ctx->offset[branch_dst];
+
+ if (!is_simm10(branch_dst - ctx->idx) ||
+ BPF_OP(code) == BPF_JSET)
+ use_cbcond = false;
+
+ if (is_imm) {
+ bool fits = true;
+
+ if (use_cbcond) {
+ if (!is_simm5(imm))
+ fits = false;
+ } else if (!is_simm13(imm)) {
+ fits = false;
+ }
+ if (!fits) {
+ ctx->tmp_1_used = true;
+ emit_loadimm_sext(imm, tmp, ctx);
+ src = tmp;
+ is_imm = false;
+ }
+ }
+
+ if (!use_cbcond) {
+ u32 br_opcode;
+
+ if (BPF_OP(code) == BPF_JSET) {
+ if (is_imm)
+ emit_btsti(dst, imm, ctx);
+ else
+ emit_btst(dst, src, ctx);
+ } else {
+ if (is_imm)
+ emit_cmpi(dst, imm, ctx);
+ else
+ emit_cmp(dst, src, ctx);
+ }
+ switch (BPF_OP(code)) {
+ case BPF_JEQ:
+ br_opcode = BE;
+ break;
+ case BPF_JGT:
+ br_opcode = BGU;
+ break;
+ case BPF_JGE:
+ br_opcode = BGEU;
+ break;
+ case BPF_JSET:
+ case BPF_JNE:
+ br_opcode = BNE;
+ break;
+ case BPF_JSGT:
+ br_opcode = BG;
+ break;
+ case BPF_JSGE:
+ br_opcode = BGE;
+ break;
+ default:
+ /* Make sure we dont leak kernel information to the
+ * user.
+ */
+ return -EFAULT;
+ }
+ emit_branch(br_opcode, ctx->idx, branch_dst, ctx);
+ emit_nop(ctx);
+ } else {
+ u32 cbcond_opcode;
+
+ switch (BPF_OP(code)) {
+ case BPF_JEQ:
+ cbcond_opcode = CBCONDE;
+ break;
+ case BPF_JGT:
+ cbcond_opcode = CBCONDGU;
+ break;
+ case BPF_JGE:
+ cbcond_opcode = CBCONDGEU;
+ break;
+ case BPF_JNE:
+ cbcond_opcode = CBCONDNE;
+ break;
+ case BPF_JSGT:
+ cbcond_opcode = CBCONDG;
+ break;
+ case BPF_JSGE:
+ cbcond_opcode = CBCONDGE;
+ break;
+ default:
+ /* Make sure we dont leak kernel information to the
+ * user.
+ */
+ return -EFAULT;
+ }
+ cbcond_opcode |= CBCOND_OP;
+ if (is_imm)
+ emit_cbcondi(cbcond_opcode, ctx->idx, branch_dst,
+ dst, imm, ctx);
+ else
+ emit_cbcond(cbcond_opcode, ctx->idx, branch_dst,
+ dst, src, ctx);
+ }
+ return 0;
+}
+
static void load_skb_regs(struct jit_ctx *ctx, u8 r_skb)
{
const u8 r_headlen = bpf2sparc[SKB_HLEN_REG];
@@ -765,44 +933,15 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx)
case BPF_JMP | BPF_JGE | BPF_X:
case BPF_JMP | BPF_JNE | BPF_X:
case BPF_JMP | BPF_JSGT | BPF_X:
- case BPF_JMP | BPF_JSGE | BPF_X: {
- u32 br_opcode;
+ case BPF_JMP | BPF_JSGE | BPF_X:
+ case BPF_JMP | BPF_JSET | BPF_X: {
+ int err;
- emit_cmp(dst, src, ctx);
-emit_cond_jmp:
- switch (BPF_OP(code)) {
- case BPF_JEQ:
- br_opcode = BE;
- break;
- case BPF_JGT:
- br_opcode = BGU;
- break;
- case BPF_JGE:
- br_opcode = BGEU;
- break;
- case BPF_JSET:
- case BPF_JNE:
- br_opcode = BNE;
- break;
- case BPF_JSGT:
- br_opcode = BG;
- break;
- case BPF_JSGE:
- br_opcode = BGE;
- break;
- default:
- /* Make sure we dont leak kernel information to the
- * user.
- */
- return -EFAULT;
- }
- emit_branch(br_opcode, ctx->idx, ctx->offset[i + off], ctx);
- emit_nop(ctx);
+ err = emit_compare_and_branch(code, dst, src, 0, false, i + off, ctx);
+ if (err)
+ return err;
break;
}
- case BPF_JMP | BPF_JSET | BPF_X:
- emit_btst(dst, src, ctx);
- goto emit_cond_jmp;
/* IF (dst COND imm) JUMP off */
case BPF_JMP | BPF_JEQ | BPF_K:
case BPF_JMP | BPF_JGT | BPF_K:
@@ -810,23 +949,14 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx)
case BPF_JMP | BPF_JNE | BPF_K:
case BPF_JMP | BPF_JSGT | BPF_K:
case BPF_JMP | BPF_JSGE | BPF_K:
- if (is_simm13(imm)) {
- emit_cmpi(dst, imm, ctx);
- } else {
- ctx->tmp_1_used = true;
- emit_loadimm_sext(imm, bpf2sparc[TMP_REG_1], ctx);
- emit_cmp(dst, bpf2sparc[TMP_REG_1], ctx);
- }
- goto emit_cond_jmp;
- case BPF_JMP | BPF_JSET | BPF_K:
- if (is_simm13(imm)) {
- emit_btsti(dst, imm, ctx);
- } else {
- ctx->tmp_1_used = true;
- emit_loadimm_sext(imm, bpf2sparc[TMP_REG_1], ctx);
- emit_btst(dst, bpf2sparc[TMP_REG_1], ctx);
- }
- goto emit_cond_jmp;
+ case BPF_JMP | BPF_JSET | BPF_K: {
+ int err;
+
+ err = emit_compare_and_branch(code, dst, 0, imm, true, i + off, ctx);
+ if (err)
+ return err;
+ break;
+ }
/* function call */
case BPF_JMP | BPF_CALL:
--
2.1.2.532.g19b5d50
^ permalink raw reply related
* Re: [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: Arun Parameswaran @ 2017-04-24 23:03 UTC (permalink / raw)
To: Eric Anholt, Florian Fainelli, Vivien Didelot, Andrew Lunn,
netdev-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Ray Jui,
Scott Branden, Jon Mason
In-Reply-To: <20170424215022.30382-2-eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
Hi Eric
A comment on the Device ID.
On 17-04-24 02:50 PM, Eric Anholt wrote:
> Cygnus is a small family of SoCs, of which we currently have
> devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the
> same as 58xx, just requiring a tiny bit of setup that was previously
> missing.
>
> Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
> ---
> Documentation/devicetree/bindings/net/dsa/b53.txt | 3 +++
> drivers/net/dsa/b53/b53_srab.c | 2 ++
> 2 files changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/dsa/b53.txt b/Documentation/devicetree/bindings/net/dsa/b53.txt
> index d6c6e41648d4..49c93d3c0839 100644
> --- a/Documentation/devicetree/bindings/net/dsa/b53.txt
> +++ b/Documentation/devicetree/bindings/net/dsa/b53.txt
> @@ -29,6 +29,9 @@ Required properties:
> "brcm,bcm58625-srab"
> "brcm,bcm88312-srab" and the mandatory "brcm,nsp-srab string
>
> + For the BCM11360 SoC, must be:
> + "brcm,bcm11360-srab" and the mandatory "brcm,cygnus-srab string
> +
> For the BCM63xx/33xx SoCs with an integrated switch, must be one of:
> "brcm,bcm3384-switch"
> "brcm,bcm6328-switch"
> diff --git a/drivers/net/dsa/b53/b53_srab.c b/drivers/net/dsa/b53/b53_srab.c
> index 8a62b6a69703..c37ffd1b6833 100644
> --- a/drivers/net/dsa/b53/b53_srab.c
> +++ b/drivers/net/dsa/b53/b53_srab.c
> @@ -364,6 +364,7 @@ static const struct of_device_id b53_srab_of_match[] = {
> { .compatible = "brcm,bcm53018-srab" },
> { .compatible = "brcm,bcm53019-srab" },
> { .compatible = "brcm,bcm5301x-srab" },
> + { .compatible = "brcm,bcm11360-srab", .data = (void *)BCM58XX_DEVICE_ID },
> { .compatible = "brcm,bcm58522-srab", .data = (void *)BCM58XX_DEVICE_ID },
> { .compatible = "brcm,bcm58525-srab", .data = (void *)BCM58XX_DEVICE_ID },
> { .compatible = "brcm,bcm58535-srab", .data = (void *)BCM58XX_DEVICE_ID },
> @@ -371,6 +372,7 @@ static const struct of_device_id b53_srab_of_match[] = {
> { .compatible = "brcm,bcm58623-srab", .data = (void *)BCM58XX_DEVICE_ID },
> { .compatible = "brcm,bcm58625-srab", .data = (void *)BCM58XX_DEVICE_ID },
> { .compatible = "brcm,bcm88312-srab", .data = (void *)BCM58XX_DEVICE_ID },
> + { .compatible = "brcm,cygnus-srab", .data = (void *)BCM58XX_DEVICE_ID },
The device ID should be 0xd300. This is the actual value read from the switch regs.
This also requires an entry in the 'b53_switch_chips' structure in b53_common.c.
> { .compatible = "brcm,nsp-srab", .data = (void *)BCM58XX_DEVICE_ID },
> { /* sentinel */ },
> };
Other wise this patch set looks good.
I was testing a similar change (except for the above, which doesn't
affect the functionality) to get the switch working and it works.
Thanks
Arun
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* test_progs packed...
From: David Miller @ 2017-04-24 23:06 UTC (permalink / raw)
To: ast; +Cc: daniel, kafai, netdev
Alexei, why the packed attribute usage in test_progs.c?
There should be no reason for this and it results in the object(s)
having odd addresses (and thus be unaligned) on sparc.
^ permalink raw reply
* Re: [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: Florian Fainelli @ 2017-04-24 23:07 UTC (permalink / raw)
To: Arun Parameswaran, Eric Anholt, Vivien Didelot, Andrew Lunn,
netdev, Rob Herring, Mark Rutland, devicetree
Cc: linux-arm-kernel, linux-kernel, bcm-kernel-feedback-list, Ray Jui,
Scott Branden, Jon Mason
In-Reply-To: <ee265657-8175-b6c7-a0dc-cec216cd9ede@broadcom.com>
On 04/24/2017 04:03 PM, Arun Parameswaran wrote:
> Hi Eric
>
> A comment on the Device ID.
>
>
> On 17-04-24 02:50 PM, Eric Anholt wrote:
>> Cygnus is a small family of SoCs, of which we currently have
>> devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the
>> same as 58xx, just requiring a tiny bit of setup that was previously
>> missing.
>>
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> ---
>> Documentation/devicetree/bindings/net/dsa/b53.txt | 3 +++
>> drivers/net/dsa/b53/b53_srab.c | 2 ++
>> 2 files changed, 5 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/dsa/b53.txt b/Documentation/devicetree/bindings/net/dsa/b53.txt
>> index d6c6e41648d4..49c93d3c0839 100644
>> --- a/Documentation/devicetree/bindings/net/dsa/b53.txt
>> +++ b/Documentation/devicetree/bindings/net/dsa/b53.txt
>> @@ -29,6 +29,9 @@ Required properties:
>> "brcm,bcm58625-srab"
>> "brcm,bcm88312-srab" and the mandatory "brcm,nsp-srab string
>>
>> + For the BCM11360 SoC, must be:
>> + "brcm,bcm11360-srab" and the mandatory "brcm,cygnus-srab string
>> +
>> For the BCM63xx/33xx SoCs with an integrated switch, must be one of:
>> "brcm,bcm3384-switch"
>> "brcm,bcm6328-switch"
>> diff --git a/drivers/net/dsa/b53/b53_srab.c b/drivers/net/dsa/b53/b53_srab.c
>> index 8a62b6a69703..c37ffd1b6833 100644
>> --- a/drivers/net/dsa/b53/b53_srab.c
>> +++ b/drivers/net/dsa/b53/b53_srab.c
>> @@ -364,6 +364,7 @@ static const struct of_device_id b53_srab_of_match[] = {
>> { .compatible = "brcm,bcm53018-srab" },
>> { .compatible = "brcm,bcm53019-srab" },
>> { .compatible = "brcm,bcm5301x-srab" },
>> + { .compatible = "brcm,bcm11360-srab", .data = (void *)BCM58XX_DEVICE_ID },
>> { .compatible = "brcm,bcm58522-srab", .data = (void *)BCM58XX_DEVICE_ID },
>> { .compatible = "brcm,bcm58525-srab", .data = (void *)BCM58XX_DEVICE_ID },
>> { .compatible = "brcm,bcm58535-srab", .data = (void *)BCM58XX_DEVICE_ID },
>> @@ -371,6 +372,7 @@ static const struct of_device_id b53_srab_of_match[] = {
>> { .compatible = "brcm,bcm58623-srab", .data = (void *)BCM58XX_DEVICE_ID },
>> { .compatible = "brcm,bcm58625-srab", .data = (void *)BCM58XX_DEVICE_ID },
>> { .compatible = "brcm,bcm88312-srab", .data = (void *)BCM58XX_DEVICE_ID },
>> + { .compatible = "brcm,cygnus-srab", .data = (void *)BCM58XX_DEVICE_ID },
> The device ID should be 0xd300. This is the actual value read from the switch regs.
> This also requires an entry in the 'b53_switch_chips' structure in b53_common.c.
These are not real ID numbers, these are values that indicate the
generation of the switch being embedded into the SoC. Within
b53_common.c we don't have to differentiate a Starfighter 2 embedded in
BCM11360, NSP, or 7445 or 7278, which is why using 58XX_DEVICE_ID should
be good enough.
>> { .compatible = "brcm,nsp-srab", .data = (void *)BCM58XX_DEVICE_ID },
>> { /* sentinel */ },
>> };
> Other wise this patch set looks good.
>
> I was testing a similar change (except for the above, which doesn't
> affect the functionality) to get the switch working and it works.
>
> Thanks
> Arun
>
--
Florian
^ permalink raw reply
* Re: [PATCH] sparc64: Support cbcond instructions in eBPF JIT.
From: Alexei Starovoitov @ 2017-04-24 23:09 UTC (permalink / raw)
To: David Miller, netdev; +Cc: daniel
In-Reply-To: <20170424.190228.571734658408906331.davem@davemloft.net>
On 4/24/17 4:02 PM, David Miller wrote:
>
> cbcond combines a compare with a branch into a single instruction.
>
> The limitations are:
>
> 1) Only newer chips support it
>
> 2) For immediate compares we are limited to 5-bit signed immediate
> values
>
> 3) The branch displacement is limited to 10-bit signed
>
> 4) We cannot use it for JSET
llvm doesn't know how to generate it yet. So it's only seen after
classic->extended conversion.
Hence not a concern at all for this optimization.
> Also, cbcond (unlike all other sparc control transfers) lacks a delay
> slot.
>
> Currently we don't have a useful instruction we can push into the
> delay slot of normal branches. So using cbcond pretty much always
> increases code density, and is therefore a win.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
Nice!
Acked-by: Alexei Starovoitov <ast@kernel.org>
That puts up a pressure to optimize x64 JIT too :)
^ permalink raw reply
* Re: [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: Arun Parameswaran @ 2017-04-24 23:15 UTC (permalink / raw)
To: Florian Fainelli, Eric Anholt, Vivien Didelot, Andrew Lunn,
netdev-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Ray Jui,
Scott Branden, Jon Mason
In-Reply-To: <173c8ff2-6a31-5460-9a3f-8d8ac445a336-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 17-04-24 04:07 PM, Florian Fainelli wrote:
> On 04/24/2017 04:03 PM, Arun Parameswaran wrote:
>> Hi Eric
>>
>> A comment on the Device ID.
>>
>>
>> On 17-04-24 02:50 PM, Eric Anholt wrote:
>>> Cygnus is a small family of SoCs, of which we currently have
>>> devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the
>>> same as 58xx, just requiring a tiny bit of setup that was previously
>>> missing.
>>>
>>> Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
>>> ---
>>> Documentation/devicetree/bindings/net/dsa/b53.txt | 3 +++
>>> drivers/net/dsa/b53/b53_srab.c | 2 ++
>>> 2 files changed, 5 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/dsa/b53.txt b/Documentation/devicetree/bindings/net/dsa/b53.txt
>>> index d6c6e41648d4..49c93d3c0839 100644
>>> --- a/Documentation/devicetree/bindings/net/dsa/b53.txt
>>> +++ b/Documentation/devicetree/bindings/net/dsa/b53.txt
>>> @@ -29,6 +29,9 @@ Required properties:
>>> "brcm,bcm58625-srab"
>>> "brcm,bcm88312-srab" and the mandatory "brcm,nsp-srab string
>>>
>>> + For the BCM11360 SoC, must be:
>>> + "brcm,bcm11360-srab" and the mandatory "brcm,cygnus-srab string
>>> +
>>> For the BCM63xx/33xx SoCs with an integrated switch, must be one of:
>>> "brcm,bcm3384-switch"
>>> "brcm,bcm6328-switch"
>>> diff --git a/drivers/net/dsa/b53/b53_srab.c b/drivers/net/dsa/b53/b53_srab.c
>>> index 8a62b6a69703..c37ffd1b6833 100644
>>> --- a/drivers/net/dsa/b53/b53_srab.c
>>> +++ b/drivers/net/dsa/b53/b53_srab.c
>>> @@ -364,6 +364,7 @@ static const struct of_device_id b53_srab_of_match[] = {
>>> { .compatible = "brcm,bcm53018-srab" },
>>> { .compatible = "brcm,bcm53019-srab" },
>>> { .compatible = "brcm,bcm5301x-srab" },
>>> + { .compatible = "brcm,bcm11360-srab", .data = (void *)BCM58XX_DEVICE_ID },
>>> { .compatible = "brcm,bcm58522-srab", .data = (void *)BCM58XX_DEVICE_ID },
>>> { .compatible = "brcm,bcm58525-srab", .data = (void *)BCM58XX_DEVICE_ID },
>>> { .compatible = "brcm,bcm58535-srab", .data = (void *)BCM58XX_DEVICE_ID },
>>> @@ -371,6 +372,7 @@ static const struct of_device_id b53_srab_of_match[] = {
>>> { .compatible = "brcm,bcm58623-srab", .data = (void *)BCM58XX_DEVICE_ID },
>>> { .compatible = "brcm,bcm58625-srab", .data = (void *)BCM58XX_DEVICE_ID },
>>> { .compatible = "brcm,bcm88312-srab", .data = (void *)BCM58XX_DEVICE_ID },
>>> + { .compatible = "brcm,cygnus-srab", .data = (void *)BCM58XX_DEVICE_ID },
>> The device ID should be 0xd300. This is the actual value read from the switch regs.
>> This also requires an entry in the 'b53_switch_chips' structure in b53_common.c.
> These are not real ID numbers, these are values that indicate the
> generation of the switch being embedded into the SoC. Within
> b53_common.c we don't have to differentiate a Starfighter 2 embedded in
> BCM11360, NSP, or 7445 or 7278, which is why using 58XX_DEVICE_ID should
> be good enough.
Ok. Thanks.
I was under the impression, that these id's could be used in the b53_switch_detect()
API to auto detect the switch. In that API, the switch ID is read from the
Management page register.
>>> { .compatible = "brcm,nsp-srab", .data = (void *)BCM58XX_DEVICE_ID },
>>> { /* sentinel */ },
>>> };
>> Other wise this patch set looks good.
>>
>> I was testing a similar change (except for the above, which doesn't
>> affect the functionality) to get the switch working and it works.
>>
>> Thanks
>> Arun
>>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: test_progs packed...
From: Alexei Starovoitov @ 2017-04-24 23:16 UTC (permalink / raw)
To: David Miller; +Cc: daniel, kafai, netdev
In-Reply-To: <20170424.190601.2066346847263955701.davem@davemloft.net>
On 4/24/17 4:06 PM, David Miller wrote:
>
> Alexei, why the packed attribute usage in test_progs.c?
>
> There should be no reason for this and it results in the object(s)
> having odd addresses (and thus be unaligned) on sparc.
because in:
static struct {
struct ethhdr eth;
struct iphdr iph;
struct tcphdr tcp;
} __packed pkt_v4 = {
iph is 4 byte aligned and eth is 2-byte.
We can add 2 byte hole in front of eth, but it's ugly since clean:
bpf_prog_test_run(prog_fd, 100000, &pkt_v4, sizeof(pkt_v4),
would need to deal with this extra padding explicitly.
It's only a user space thing and not in critical path,
so inefficient loads shouldn't be a problem.
You're bringing a good point that bpf_prog_test_run_skb() on
the kernel side should probably do:
skb_reserve(skb, NET_SKB_PAD + NET_IP_ALIGN);
^ permalink raw reply
* Re: [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: Florian Fainelli @ 2017-04-24 23:17 UTC (permalink / raw)
To: Arun Parameswaran, Eric Anholt, Vivien Didelot, Andrew Lunn,
netdev-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Ray Jui,
Scott Branden, Jon Mason
In-Reply-To: <1361654c-e4eb-e0a0-3397-b43235b5ff60-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On 04/24/2017 04:15 PM, Arun Parameswaran wrote:
>
>
> On 17-04-24 04:07 PM, Florian Fainelli wrote:
>> On 04/24/2017 04:03 PM, Arun Parameswaran wrote:
>>> Hi Eric
>>>
>>> A comment on the Device ID.
>>>
>>>
>>> On 17-04-24 02:50 PM, Eric Anholt wrote:
>>>> Cygnus is a small family of SoCs, of which we currently have
>>>> devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the
>>>> same as 58xx, just requiring a tiny bit of setup that was previously
>>>> missing.
>>>>
>>>> Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
>>>> ---
>>>> Documentation/devicetree/bindings/net/dsa/b53.txt | 3 +++
>>>> drivers/net/dsa/b53/b53_srab.c | 2 ++
>>>> 2 files changed, 5 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/net/dsa/b53.txt b/Documentation/devicetree/bindings/net/dsa/b53.txt
>>>> index d6c6e41648d4..49c93d3c0839 100644
>>>> --- a/Documentation/devicetree/bindings/net/dsa/b53.txt
>>>> +++ b/Documentation/devicetree/bindings/net/dsa/b53.txt
>>>> @@ -29,6 +29,9 @@ Required properties:
>>>> "brcm,bcm58625-srab"
>>>> "brcm,bcm88312-srab" and the mandatory "brcm,nsp-srab string
>>>>
>>>> + For the BCM11360 SoC, must be:
>>>> + "brcm,bcm11360-srab" and the mandatory "brcm,cygnus-srab string
>>>> +
>>>> For the BCM63xx/33xx SoCs with an integrated switch, must be one of:
>>>> "brcm,bcm3384-switch"
>>>> "brcm,bcm6328-switch"
>>>> diff --git a/drivers/net/dsa/b53/b53_srab.c b/drivers/net/dsa/b53/b53_srab.c
>>>> index 8a62b6a69703..c37ffd1b6833 100644
>>>> --- a/drivers/net/dsa/b53/b53_srab.c
>>>> +++ b/drivers/net/dsa/b53/b53_srab.c
>>>> @@ -364,6 +364,7 @@ static const struct of_device_id b53_srab_of_match[] = {
>>>> { .compatible = "brcm,bcm53018-srab" },
>>>> { .compatible = "brcm,bcm53019-srab" },
>>>> { .compatible = "brcm,bcm5301x-srab" },
>>>> + { .compatible = "brcm,bcm11360-srab", .data = (void *)BCM58XX_DEVICE_ID },
>>>> { .compatible = "brcm,bcm58522-srab", .data = (void *)BCM58XX_DEVICE_ID },
>>>> { .compatible = "brcm,bcm58525-srab", .data = (void *)BCM58XX_DEVICE_ID },
>>>> { .compatible = "brcm,bcm58535-srab", .data = (void *)BCM58XX_DEVICE_ID },
>>>> @@ -371,6 +372,7 @@ static const struct of_device_id b53_srab_of_match[] = {
>>>> { .compatible = "brcm,bcm58623-srab", .data = (void *)BCM58XX_DEVICE_ID },
>>>> { .compatible = "brcm,bcm58625-srab", .data = (void *)BCM58XX_DEVICE_ID },
>>>> { .compatible = "brcm,bcm88312-srab", .data = (void *)BCM58XX_DEVICE_ID },
>>>> + { .compatible = "brcm,cygnus-srab", .data = (void *)BCM58XX_DEVICE_ID },
>>> The device ID should be 0xd300. This is the actual value read from the switch regs.
>>> This also requires an entry in the 'b53_switch_chips' structure in b53_common.c.
>> These are not real ID numbers, these are values that indicate the
>> generation of the switch being embedded into the SoC. Within
>> b53_common.c we don't have to differentiate a Starfighter 2 embedded in
>> BCM11360, NSP, or 7445 or 7278, which is why using 58XX_DEVICE_ID should
>> be good enough.
> Ok. Thanks.
>
> I was under the impression, that these id's could be used in the b53_switch_detect()
> API to auto detect the switch. In that API, the switch ID is read from the
> Management page register.
For external switches that is the case, but for internal/integrated
switches, the ID is not always representative of the switch. This is why
the choice of a chip-type ID was used here while adding support for NSP
to the b53 driver.
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v3 0/5] virtio-net tx napi
From: Michael S. Tsirkin @ 2017-04-24 23:35 UTC (permalink / raw)
To: Willem de Bruijn
Cc: netdev, jasowang, virtualization, davem, Willem de Bruijn
In-Reply-To: <20170424174930.82623-1-willemdebruijn.kernel@gmail.com>
On Mon, Apr 24, 2017 at 01:49:25PM -0400, Willem de Bruijn wrote:
> From: Willem de Bruijn <willemb@google.com>
>
> Add napi for virtio-net transmit completion processing.
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> Changes:
> v2 -> v3:
> - convert __netif_tx_trylock to __netif_tx_lock on tx napi poll
> ensure that the handler always cleans, to avoid deadlock
> - unconditionally clean in start_xmit
> avoid adding an unnecessary "if (use_napi)" branch
> - remove virtqueue_disable_cb in patch 5/5
> a noop in the common event_idx based loop
> - document affinity_hint_set constraint
>
> v1 -> v2:
> - disable by default
> - disable unless affinity_hint_set
> because cache misses add up to a third higher cycle cost,
> e.g., in TCP_RR tests. This is not limited to the patch
> that enables tx completion cleaning in rx napi.
> - use trylock to avoid contention between tx and rx napi
> - keep interrupts masked during xmit_more (new patch 5/5)
> this improves cycles especially for multi UDP_STREAM, which
> does not benefit from cleaning tx completions on rx napi.
> - move free_old_xmit_skbs (new patch 3/5)
> to avoid forward declaration
>
> not changed:
> - deduplicate virnet_poll_tx and virtnet_poll_txclean
> they look similar, but have differ too much to make it
> worthwhile.
> - delay netif_wake_subqueue for more than 2 + MAX_SKB_FRAGS
> evaluated, but made no difference
> - patch 1/5
>
> RFC -> v1:
> - dropped vhost interrupt moderation patch:
> not needed and likely expensive at light load
> - remove tx napi weight
> - always clean all tx completions
> - use boolean to toggle tx-napi, instead
> - only clean tx in rx if tx-napi is enabled
> - then clean tx before rx
> - fix: add missing braces in virtnet_freeze_down
> - testing: add 4KB TCP_RR + UDP test results
>
> Based on previous patchsets by Jason Wang:
>
> [RFC V7 PATCH 0/7] enable tx interrupts for virtio-net
> http://lkml.iu.edu/hypermail/linux/kernel/1505.3/00245.html
>
>
> Before commit b0c39dbdc204 ("virtio_net: don't free buffers in xmit
> ring") the virtio-net driver would free transmitted packets on
> transmission of new packets in ndo_start_xmit and, to catch the edge
> case when no new packet is sent, also in a timer at 10HZ.
>
> A timer can cause long stalls. VIRTIO_F_NOTIFY_ON_EMPTY avoids stalls
> due to low free descriptor count. It does not address a stalls due to
> low socket SO_SNDBUF. Increasing timer frequency decreases that stall
> time, but increases interrupt rate and, thus, cycle count.
>
> Currently, with no timer, packets are freed only at ndo_start_xmit.
> Latency of consume_skb is now unbounded. To avoid a deadlock if a sock
> reaches SO_SNDBUF, packets are orphaned on tx. This breaks TCP small
> queues.
>
> Reenable TCP small queues by removing the orphan. Instead of using a
> timer, convert the driver to regular tx napi. This does not have the
> unresolved stall issue and does not have any frequency to tune.
>
> By keeping interrupts enabled by default, napi increases tx
> interrupt rate. VIRTIO_F_EVENT_IDX avoids sending an interrupt if
> one is already unacknowledged, so makes this more feasible today.
> Combine that with an optimization that brings interrupt rate
> back in line with the existing version for most workloads:
>
> Tx completion cleaning on rx interrupts elides most explicit tx
> interrupts by relying on the fact that many rx interrupts fire.
>
> Tested by running {1, 10, 100} {TCP, UDP} STREAM, RR, 4K_RR benchmarks
> from a guest to a server on the host, on an x86_64 Haswell. The guest
> runs 4 vCPUs pinned to 4 cores. vhost and the test server are
> pinned to a core each.
>
> All results are the median of 5 runs, with variance well < 10%.
> Used neper (github.com/google/neper) as test process.
>
> Napi increases single stream throughput, but increases cycle cost.
> The optimizations bring this down. The previous patchset saw a
> regression with UDP_STREAM, which does not benefit from cleaning tx
> interrupts in rx napi. This regression is now gone for 10x, 100x.
> Remaining difference is higher 1x TCP_STREAM, lower 1x UDP_STREAM.
>
> The latest results are with process, rx napi and tx napi affine to
> the same core. All numbers are lower than the previous patchset.
>
>
> upstream napi
> TCP_STREAM:
> 1x:
> Mbps 27816 39805
> Gcycles 274 285
>
> 10x:
> Mbps 42947 42531
> Gcycles 300 296
>
> 100x:
> Mbps 31830 28042
> Gcycles 279 269
>
> TCP_RR Latency (us):
> 1x:
> p50 21 21
> p99 27 27
> Gcycles 180 167
>
> 10x:
> p50 40 39
> p99 52 52
> Gcycles 214 211
>
> 100x:
> p50 281 241
> p99 411 337
> Gcycles 218 226
>
> TCP_RR 4K:
> 1x:
> p50 28 29
> p99 34 36
> Gcycles 177 167
>
> 10x:
> p50 70 71
> p99 85 134
> Gcycles 213 214
>
> 100x:
> p50 442 611
> p99 802 785
> Gcycles 237 216
>
> UDP_STREAM:
> 1x:
> Mbps 29468 26800
> Gcycles 284 293
>
> 10x:
> Mbps 29891 29978
> Gcycles 285 312
>
> 100x:
> Mbps 30269 30304
> Gcycles 318 316
>
> UDP_RR:
> 1x:
> p50 19 19
> p99 23 23
> Gcycles 180 173
>
> 10x:
> p50 35 40
> p99 54 64
> Gcycles 245 237
>
> 100x:
> p50 234 286
> p99 484 473
> Gcycles 224 214
>
> Note that GSO is enabled, so 4K RR still translates to one packet
> per request.
>
> Lower throughput at 100x vs 10x can be (at least in part)
> explained by looking at bytes per packet sent (nstat). It likely
> also explains the lower throughput of 1x for some variants.
>
> upstream:
>
> N=1 bytes/pkt=16581
> N=10 bytes/pkt=61513
> N=100 bytes/pkt=51558
>
> at_rx:
>
> N=1 bytes/pkt=65204
> N=10 bytes/pkt=65148
> N=100 bytes/pkt=56840
>
> Willem de Bruijn (5):
> virtio-net: napi helper functions
> virtio-net: transmit napi
> virtio-net: move free_old_xmit_skbs
> virtio-net: clean tx descriptors from rx napi
> virtio-net: keep tx interrupts disabled unless kick
>
> drivers/net/virtio_net.c | 193 ++++++++++++++++++++++++++++++++---------------
> 1 file changed, 132 insertions(+), 61 deletions(-)
>
> --
> 2.12.2.816.g2cccc81164-goog
^ permalink raw reply
* Fw: New Defects reported by Coverity Scan for Linux
From: Stephen Hemminger @ 2017-04-24 23:41 UTC (permalink / raw)
To: Jamal Hadi Salim, Cong Wang, Jiri Pirko; +Cc: netdev
This looks like a false positive
Date: Mon, 24 Apr 2017 14:40:46 -0700
From: scan-admin@coverity.com
To: stephen@networkplumber.org
Subject: New Defects reported by Coverity Scan for Linux
1 new defect(s) introduced to Linux found with Coverity Scan.
2 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)
** CID 1405487: Resource leaks (RESOURCE_LEAK)
/net/sched/act_api.c: 635 in tcf_action_init_1()
________________________________________________________________________________________________________
*** CID 1405487: Resource leaks (RESOURCE_LEAK)
/net/sched/act_api.c: 635 in tcf_action_init_1()
629 * if it exists and is only bound to in a_o->init() then
630 * ACT_P_CREATED is not returned (a zero is).
631 */
632 if (err != ACT_P_CREATED)
633 module_put(a_o->owner);
634
>>> CID 1405487: Resource leaks (RESOURCE_LEAK)
>>> Variable "cookie" going out of scope leaks the storage it points to.
635 return a;
636
637 err_mod:
638 module_put(a_o->owner);
639 err_out:
640 if (cookie) {
^ permalink raw reply
* Re: [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: Eric Anholt @ 2017-04-24 23:54 UTC (permalink / raw)
To: Scott Branden, Florian Fainelli, Vivien Didelot, Andrew Lunn,
netdev-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Ray Jui,
Scott Branden, Jon Mason
In-Reply-To: <a2f4f0c9-feea-291b-dae5-f4ed10f9c547-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1263 bytes --]
Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> writes:
> Minor comment in line
>
> On 17-04-24 02:50 PM, Eric Anholt wrote:
>> Cygnus is a small family of SoCs, of which we currently have
>> devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the
>> same as 58xx, just requiring a tiny bit of setup that was previously
>> missing.
>>
>> Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/net/dsa/b53.txt | 3 +++
>> drivers/net/dsa/b53/b53_srab.c | 2 ++
>> 2 files changed, 5 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/dsa/b53.txt b/Documentation/devicetree/bindings/net/dsa/b53.txt
>> index d6c6e41648d4..49c93d3c0839 100644
>> --- a/Documentation/devicetree/bindings/net/dsa/b53.txt
>> +++ b/Documentation/devicetree/bindings/net/dsa/b53.txt
>> @@ -29,6 +29,9 @@ Required properties:
>> "brcm,bcm58625-srab"
>> "brcm,bcm88312-srab" and the mandatory "brcm,nsp-srab string
>>
>> + For the BCM11360 SoC, must be:
>> + "brcm,bcm11360-srab" and the mandatory "brcm,cygnus-srab string
>> +
> place in alphabetical order in the doc?
Moved it above BCM5310x now. I hope that's what you meant.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: Scott Branden @ 2017-04-24 23:57 UTC (permalink / raw)
To: Eric Anholt, Florian Fainelli, Vivien Didelot, Andrew Lunn,
netdev-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Ray Jui,
Scott Branden, Jon Mason
In-Reply-To: <8760hte4zw.fsf-omZaPlIz5HhaEpDpdNBo/KxOck334EZe@public.gmane.org>
On 17-04-24 04:54 PM, Eric Anholt wrote:
> Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> writes:
>
>> Minor comment in line
>>
>> On 17-04-24 02:50 PM, Eric Anholt wrote:
>>> Cygnus is a small family of SoCs, of which we currently have
>>> devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the
>>> same as 58xx, just requiring a tiny bit of setup that was previously
>>> missing.
>>>
>>> Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
>>> ---
>>> Documentation/devicetree/bindings/net/dsa/b53.txt | 3 +++
>>> drivers/net/dsa/b53/b53_srab.c | 2 ++
>>> 2 files changed, 5 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/dsa/b53.txt b/Documentation/devicetree/bindings/net/dsa/b53.txt
>>> index d6c6e41648d4..49c93d3c0839 100644
>>> --- a/Documentation/devicetree/bindings/net/dsa/b53.txt
>>> +++ b/Documentation/devicetree/bindings/net/dsa/b53.txt
>>> @@ -29,6 +29,9 @@ Required properties:
>>> "brcm,bcm58625-srab"
>>> "brcm,bcm88312-srab" and the mandatory "brcm,nsp-srab string
>>>
>>> + For the BCM11360 SoC, must be:
>>> + "brcm,bcm11360-srab" and the mandatory "brcm,cygnus-srab string
>>> +
>> place in alphabetical order in the doc?
>
> Moved it above BCM5310x now. I hope that's what you meant.
>
Yes, sorry for not being more clear.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
From: Eric Anholt @ 2017-04-25 0:00 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, Vivien Didelot, netdev, Rob Herring,
Mark Rutland, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, Ray Jui, Scott Branden, Jon Mason
In-Reply-To: <20170424220842.GA26241@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 568 bytes --]
Andrew Lunn <andrew@lunn.ch> writes:
>> + mdio: mdio@18002000 {
>> + compatible = "brcm,iproc-mdio";
>> + reg = <0x18002000 0x8>;
>> + #size-cells = <1>;
>> + #address-cells = <0>;
>> +
>> + gphy0: eth-gphy@0 {
>> + reg = <0>;
>> + max-speed = <1000>;
>> + };
>> +
>> + gphy1: eth-gphy@1 {
>> + reg = <1>;
>> + max-speed = <1000>;
>> + };
>> + };
>
> Hi Eric
>
> Do these max-speed properties do anything useful? Is the PHY capable
> of > 1Gbps?
Not sure where I had those copy-and-pasted from, but they don't seem
necessary. Dropped.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
From: Eric Anholt @ 2017-04-25 0:02 UTC (permalink / raw)
To: Florian Fainelli, Vivien Didelot, Andrew Lunn,
netdev-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Ray Jui,
Scott Branden, Jon Mason
In-Reply-To: <1759fb29-0678-0ec5-5398-16c4a3ba9660-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 613 bytes --]
Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> On 04/24/2017 02:50 PM, Eric Anholt wrote:
>> Cygnus has a single amac controller connected to the B53 switch with 2
>> PHYs. On the BCM911360_EP platform, those two PHYs are connected to
>> the external ethernet jacks.
>>
>> Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
>
> This looks fine, just a few nits on the label names:
Thanks. I've applied all of these (and Andrew's and Scott's
suggestions), and I'll send out a new version once the DT maintainers
have had a chance to look.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: Fw: New Defects reported by Coverity Scan for Linux
From: Cong Wang @ 2017-04-25 0:09 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Jamal Hadi Salim, Jiri Pirko, Linux Kernel Network Developers
In-Reply-To: <20170424164127.5a2145e8@xeon-e3>
On Mon, Apr 24, 2017 at 4:41 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> This looks like a false positive
> ________________________________________________________________________________________________________
> *** CID 1405487: Resource leaks (RESOURCE_LEAK)
> /net/sched/act_api.c: 635 in tcf_action_init_1()
> 629 * if it exists and is only bound to in a_o->init() then
> 630 * ACT_P_CREATED is not returned (a zero is).
> 631 */
> 632 if (err != ACT_P_CREATED)
> 633 module_put(a_o->owner);
> 634
>>>> CID 1405487: Resource leaks (RESOURCE_LEAK)
>>>> Variable "cookie" going out of scope leaks the storage it points to.
> 635 return a;
I don't see how we could leak it either.
^ permalink raw reply
* Re: Fw: New Defects reported by Coverity Scan for Linux
From: Jamal Hadi Salim @ 2017-04-25 0:23 UTC (permalink / raw)
To: Cong Wang; +Cc: Stephen Hemminger, Jiri Pirko, Linux Kernel Network Developers
In-Reply-To: <CAM_iQpUTxNdp-uC0pGkvW0uceOpouAQ1abrU-u4wvR9ftqXN7w@mail.gmail.com>
Yeah, not sure i see it either.
cheers,
jamal
On Mon, Apr 24, 2017 at 8:09 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Mon, Apr 24, 2017 at 4:41 PM, Stephen Hemminger
> <stephen@networkplumber.org> wrote:
>> This looks like a false positive
>> ________________________________________________________________________________________________________
>> *** CID 1405487: Resource leaks (RESOURCE_LEAK)
>> /net/sched/act_api.c: 635 in tcf_action_init_1()
>> 629 * if it exists and is only bound to in a_o->init() then
>> 630 * ACT_P_CREATED is not returned (a zero is).
>> 631 */
>> 632 if (err != ACT_P_CREATED)
>> 633 module_put(a_o->owner);
>> 634
>>>>> CID 1405487: Resource leaks (RESOURCE_LEAK)
>>>>> Variable "cookie" going out of scope leaks the storage it points to.
>> 635 return a;
>
> I don't see how we could leak it either.
^ permalink raw reply
* Re: [PATCH net-next 0/2] flower: add MPLS matching support
From: Jamal Hadi Salim @ 2017-04-25 0:58 UTC (permalink / raw)
To: David Miller, benjamin.lahaise; +Cc: netdev, bcrl, Jiri Pirko
In-Reply-To: <20170424.143257.1003081554810761464.davem@davemloft.net>
On 17-04-24 02:32 PM, David Miller wrote:
> From: Benjamin LaHaise <benjamin.lahaise@netronome.com>
>
> Series applied, but in the future:
>
> 1) Put the "v2", "v3", whatever in the inital [PATCH xxx] bracketed
> part of the subject line, otherwise it ends up in the GIT commit
> message header line and that's not desired.
>
> 2) Please cut it with these double signoffs, and add an appropriate
> entry to the email aliases file.
I know i should have spoken earlier, wanted to but got distracted - but
shouldnt the new rules have applied to this patch too? ;->
You have 3 TLVs, one of which is u8 that only allows use of 3 bits.
The other is a u32 which allows only 20 bits to be set.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH v2] net: core: Prevent from dereferencing null pointer when
From: Myungho Jung @ 2017-04-25 1:00 UTC (permalink / raw)
To: David Miller; +Cc: edumazet, netdev
In-Reply-To: <20170424.120235.438297438450788048.davem@davemloft.net>
On Mon, Apr 24, 2017 at 12:02:35PM -0400, David Miller wrote:
> From: Myungho Jung <mhjungk@gmail.com>
> Date: Thu, 20 Apr 2017 16:59:20 -0700
>
> > Added NULL check to make __dev_kfree_skb_irq consistent with kfree
> > family of functions.
> >
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=195289
> >
> > Signed-off-by: Myungho Jung <mhjungk@gmail.com>
> > ---
> > Changes in v2:
> > - Correct category in subject
>
> This subject line is an incomplete sentence.
>
> This patch prevents dereferenccing a null pointer when "what"?
As it was reported on bugzilla, it would happen when plugging p54 usb device
to RPi2. But, i'm not 100% sure that this patch will resolve the issue because
the reporter didn't try my patch yet and I don't have the device to test.
And there might be some other places calling the function without checking
null pointer. The thing is that only the function don't check null among
kfree functions. So, I just hope this patch will prevent potential oops
issues.
Thanks,
Myungho
^ permalink raw reply
* Re: [PATCH net-next 0/2] flower: add MPLS matching support
From: Benjamin LaHaise @ 2017-04-25 1:05 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: David Miller, netdev, bcrl, Jiri Pirko
In-Reply-To: <d54cca4b-6212-bf7d-93e2-8314177df42c@mojatatu.com>
On Mon, Apr 24, 2017 at 08:58:18PM -0400, Jamal Hadi Salim wrote:
> On 17-04-24 02:32 PM, David Miller wrote:
> > From: Benjamin LaHaise <benjamin.lahaise@netronome.com>
>
> >
> > Series applied, but in the future:
> >
> > 1) Put the "v2", "v3", whatever in the inital [PATCH xxx] bracketed
> > part of the subject line, otherwise it ends up in the GIT commit
> > message header line and that's not desired.
> >
> > 2) Please cut it with these double signoffs, and add an appropriate
> > entry to the email aliases file.
>
> I know i should have spoken earlier, wanted to but got distracted - but
> shouldnt the new rules have applied to this patch too? ;->
>
> You have 3 TLVs, one of which is u8 that only allows use of 3 bits.
> The other is a u32 which allows only 20 bits to be set.
What are the new rules for TLVs -- do you want a new type added for the
subset values that are limited to the number of bits actually used? A
pointed here would be helpful.
-ben
> cheers,
> jamal
^ permalink raw reply
* Re: [PATCH v2] net: core: Prevent from dereferencing null pointer when
From: Eric Dumazet @ 2017-04-25 1:10 UTC (permalink / raw)
To: Myungho Jung; +Cc: David Miller, netdev
In-Reply-To: <20170425010052.GA8717@fqdn.specialj.com>
On Mon, Apr 24, 2017 at 6:00 PM, Myungho Jung <mhjungk@gmail.com> wrote:
> On Mon, Apr 24, 2017 at 12:02:35PM -0400, David Miller wrote:
>> From: Myungho Jung <mhjungk@gmail.com>
>> Date: Thu, 20 Apr 2017 16:59:20 -0700
>>
>> > Added NULL check to make __dev_kfree_skb_irq consistent with kfree
>> > family of functions.
>> >
>> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=195289
>> >
>> > Signed-off-by: Myungho Jung <mhjungk@gmail.com>
>> > ---
>> > Changes in v2:
>> > - Correct category in subject
>>
>> This subject line is an incomplete sentence.
>>
>> This patch prevents dereferenccing a null pointer when "what"?
>
> As it was reported on bugzilla, it would happen when plugging p54 usb device
> to RPi2. But, i'm not 100% sure that this patch will resolve the issue because
> the reporter didn't try my patch yet and I don't have the device to test.
>
> And there might be some other places calling the function without checking
> null pointer. The thing is that only the function don't check null among
> kfree functions. So, I just hope this patch will prevent potential oops
> issues.
Okay, but your patch title was : "net: core: Prevent from
dereferencing null pointer when"
"when" is usually followed by other words.
^ 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