* Adding path to the photos
From: Leo Young @ 2018-09-06 10:41 UTC (permalink / raw)
To: netdev
We provide image editing such as: image cutting out, retouching, masking
etc.
Here are the details what we can provide to your photos.
Jewelry retouching for your photos
Fashion retouching for your photos
Cutting out for your photos
Clipping path for your photos
Deep etch process for your photos
Image masking for your photos
Portrait retouching for your photos
We provide test editing for your photos.
let us know if interested.
Thanks,
Leo Young
^ permalink raw reply
* Re: KASAN: use-after-free Read in bpf_tcp_close (2)
From: John Fastabend @ 2018-09-06 19:53 UTC (permalink / raw)
To: syzbot, ast, daniel, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <000000000000f746f705752f95a6@google.com>
On 09/06/2018 01:22 AM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 11f026b4e306 libbpf: Remove the duplicate checking of func..
> git tree: bpf-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=153c55ca400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=4c7e83258d6e0156
> dashboard link: https://syzkaller.appspot.com/bug?extid=579adfa56843da894bc5
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+579adfa56843da894bc5@syzkaller.appspotmail.com
>
> ==================================================================
> BUG: KASAN: use-after-free in atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
> BUG: KASAN: use-after-free in virt_spin_lock arch/x86/include/asm/qspinlock.h:65 [inline]
> BUG: KASAN: use-after-free in native_queued_spin_lock_slowpath+0x189/0x1220 kernel/locking/qspinlock.c:305
> Read of size 4 at addr ffff8801bfd651a0 by task syz-executor1/9753
>
> CPU: 1 PID: 9753 Comm: syz-executor1 Not tainted 4.19.0-rc2+ #89
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
> print_address_description+0x6c/0x20b mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.7+0x242/0x30d mm/kasan/report.c:412
> check_memory_region_inline mm/kasan/kasan.c:260 [inline]
> check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
> kasan_check_read+0x11/0x20 mm/kasan/kasan.c:272
> atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
> virt_spin_lock arch/x86/include/asm/qspinlock.h:65 [inline]
> native_queued_spin_lock_slowpath+0x189/0x1220 kernel/locking/qspinlock.c:305
> pv_queued_spin_lock_slowpath arch/x86/include/asm/paravirt.h:679 [inline]
> queued_spin_lock_slowpath arch/x86/include/asm/qspinlock.h:32 [inline]
> queued_spin_lock include/asm-generic/qspinlock.h:88 [inline]
> do_raw_spin_lock+0x1a7/0x200 kernel/locking/spinlock_debug.c:113
> __raw_spin_lock_bh include/linux/spinlock_api_smp.h:136 [inline]
> _raw_spin_lock_bh+0x39/0x40 kernel/locking/spinlock.c:168
> bpf_tcp_close+0x68e/0x10d0 kernel/bpf/sockmap.c:349
> inet_release+0x104/0x1f0 net/ipv4/af_inet.c:428
> inet6_release+0x50/0x70 net/ipv6/af_inet6.c:457
> __sock_release+0xd7/0x250 net/socket.c:579
> sock_close+0x19/0x20 net/socket.c:1139
> __fput+0x38a/0xa40 fs/file_table.c:278
> ____fput+0x15/0x20 fs/file_table.c:309
> task_work_run+0x1e8/0x2a0 kernel/task_work.c:113
> tracehook_notify_resume include/linux/tracehook.h:193 [inline]
> exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166
> prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
> syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
> do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x410c51
> Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 34 19 00 00 c3 48 83 ec 08 e8 0a fc ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 53 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01
> RSP: 002b:00007ffeacb37d60 EFLAGS: 00000293 ORIG_RAX: 0000000000000003
> RAX: 0000000000000000 RBX: 0000000000000008 RCX: 0000000000410c51
> RDX: 0000000000000000 RSI: 0000000000731f70 RDI: 0000000000000007
> RBP: 0000000000000000 R08: ffffffffffffffff R09: ffffffffffffffff
> R10: 00007ffeacb37c90 R11: 0000000000000293 R12: 0000000000000010
> R13: 0000000000022aa9 R14: 000000000000004d R15: badc0ffeebadface
>
> Allocated by task 9754:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
> kmem_cache_alloc_trace+0x152/0x730 mm/slab.c:3620
> kmalloc include/linux/slab.h:513 [inline]
> kzalloc include/linux/slab.h:707 [inline]
> sock_map_alloc+0x209/0x430 kernel/bpf/sockmap.c:1653
> find_and_alloc_map kernel/bpf/syscall.c:129 [inline]
> map_create+0x3bd/0x1100 kernel/bpf/syscall.c:509
> __do_sys_bpf kernel/bpf/syscall.c:2356 [inline]
> __se_sys_bpf kernel/bpf/syscall.c:2333 [inline]
> __x64_sys_bpf+0x303/0x510 kernel/bpf/syscall.c:2333
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Freed by task 13:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
> kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
> __cache_free mm/slab.c:3498 [inline]
> kfree+0xd9/0x210 mm/slab.c:3813
> sock_map_remove_complete kernel/bpf/sockmap.c:1561 [inline]
> sock_map_free+0x428/0x570 kernel/bpf/sockmap.c:1756
> bpf_map_free_deferred+0xba/0xf0 kernel/bpf/syscall.c:290
> process_one_work+0xc73/0x1aa0 kernel/workqueue.c:2153
> worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
> kthread+0x35a/0x420 kernel/kthread.c:246
> ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:413
>
> The buggy address belongs to the object at ffff8801bfd65080
> which belongs to the cache kmalloc-512 of size 512
> The buggy address is located 288 bytes inside of
> 512-byte region [ffff8801bfd65080, ffff8801bfd65280)
> The buggy address belongs to the page:
> page:ffffea0006ff5940 count:1 mapcount:0 mapping:ffff8801dac00940 index:0xffff8801bfd65300
> flags: 0x2fffc0000000100(slab)
> raw: 02fffc0000000100 ffffea000702a488 ffffea00075c4148 ffff8801dac00940
> raw: ffff8801bfd65300 ffff8801bfd65080 0000000100000001 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8801bfd65080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8801bfd65100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ffff8801bfd65180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff8801bfd65200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8801bfd65280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ==================================================================
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot.
Introduced here (by a new reference to the map from the
tcp close context where a parallel free'ing of the map which
does not have a RCU grace period before free),
commit 585f5a6252ee43ec8feeee07387e3fcc7e8bb292
Author: Daniel Borkmann <daniel@iogearbox.net>
Date: Thu Aug 16 21:49:10 2018 +0200
bpf, sockmap: fix sock_map_ctx_update_elem race with exist/noexist
I'll have a fix shortly.
Thanks,
John
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: b53: Fix build with B53_SRAB enabled and not B53_SERDES
From: Andrew Lunn @ 2018-09-06 19:55 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, Vivien Didelot, David S. Miller, open list
In-Reply-To: <20180906184245.31442-1-f.fainelli@gmail.com>
On Thu, Sep 06, 2018 at 11:42:45AM -0700, Florian Fainelli wrote:
> In case B53_SRAB is enabled, but not B53_SERDES, we can get the
> following linking error:
>
> ERROR: "b53_serdes_init" [drivers/net/dsa/b53/b53_srab.ko] undefined!
>
> We also need to ifdef the body of b53_srab_serdes_map_lane() since it
> would not be used when B53_SERDES is disabled and that would produce a
> warning.
>
> Fixes: 0e01491de646 ("net: dsa: b53: Add SerDes support")
> Reported-by: kbuild test robot <lkp@intel.com>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH iproute2 1/3] bridge: minor change to mdb print
From: Stephen Hemminger @ 2018-09-06 15:30 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
Get port ifname once rather than on both sides of if(is_json_context).
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
bridge/mdb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/bridge/mdb.c b/bridge/mdb.c
index f38dc67c849a..9bdef0262c54 100644
--- a/bridge/mdb.c
+++ b/bridge/mdb.c
@@ -208,19 +208,19 @@ static void print_router_entries(FILE *fp, struct nlmsghdr *n,
} else {
struct rtattr *i = RTA_DATA(router);
uint32_t *port_ifindex = RTA_DATA(i);
+ const char *port_name = ll_index_to_name(*port_ifindex);
if (is_json_context()) {
open_json_array(PRINT_JSON, brifname);
open_json_object(NULL);
print_string(PRINT_JSON, "port", NULL,
- ll_index_to_name(*port_ifindex));
+ port_name);
close_json_object();
close_json_array(PRINT_JSON, NULL);
} else {
fprintf(fp, "router port dev %s master %s\n",
- ll_index_to_name(*port_ifindex),
- brifname);
+ port_name, brifname);
}
}
close_json_array(PRINT_JSON, NULL);
--
2.17.1
^ permalink raw reply related
* [PATCH iproute2 2/3] bridge: use print_json for some outputs
From: Stephen Hemminger @ 2018-09-06 15:30 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
In-Reply-To: <20180906153057.5379-1-stephen@networkplumber.org>
Rather than using is_json_context(), use the print_string functions
which handle both cases.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
bridge/mdb.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/bridge/mdb.c b/bridge/mdb.c
index 9bdef0262c54..cc1b4547865c 100644
--- a/bridge/mdb.c
+++ b/bridge/mdb.c
@@ -131,15 +131,8 @@ static void print_mdb_entry(FILE *f, int ifindex, const struct br_mdb_entry *e,
if (n->nlmsg_type == RTM_DELMDB)
print_bool(PRINT_ANY, "deleted", "Deleted ", true);
-
- if (is_json_context()) {
- print_int(PRINT_JSON, "index", NULL, ifindex);
- print_string(PRINT_JSON, "dev", NULL, dev);
- } else {
- fprintf(f, "%u: ", ifindex);
- color_fprintf(f, COLOR_IFNAME, "%s ", dev);
- }
-
+ print_int(PRINT_ANY, "index", "%u: ", ifindex);
+ print_color_string(PRINT_ANY, COLOR_IFNAME, "dev", "%s ", dev);
print_string(PRINT_ANY, "port", " %s ",
ll_index_to_name(e->ifindex));
--
2.17.1
^ permalink raw reply related
* [PATCH iproute2 3/3] bridge: fix vlan show formatting
From: Stephen Hemminger @ 2018-09-06 15:30 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
In-Reply-To: <20180906153057.5379-1-stephen@networkplumber.org>
The output of vlan show was broken previous change to use json_print.
Clean the code up and return to original format.
Note: the JSON syntax has changed to make the bridge vlan
show more like other outputs (e.g. ip -j li show).
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
bridge/br_common.h | 2 +-
bridge/link.c | 6 ++---
bridge/vlan.c | 61 +++++++++++++++++++++++++++-------------------
3 files changed, 40 insertions(+), 29 deletions(-)
diff --git a/bridge/br_common.h b/bridge/br_common.h
index 2f1cb8fd9f3d..69665fde32b6 100644
--- a/bridge/br_common.h
+++ b/bridge/br_common.h
@@ -6,7 +6,7 @@
#define MDB_RTR_RTA(r) \
((struct rtattr *)(((char *)(r)) + RTA_ALIGN(sizeof(__u32))))
-extern void print_vlan_info(FILE *fp, struct rtattr *tb);
+extern void print_vlan_info(struct rtattr *tb, int ifindex);
extern int print_linkinfo(const struct sockaddr_nl *who,
struct nlmsghdr *n,
void *arg);
diff --git a/bridge/link.c b/bridge/link.c
index 8d89aca2e638..a5ee9a5c58e6 100644
--- a/bridge/link.c
+++ b/bridge/link.c
@@ -161,7 +161,7 @@ static void print_protinfo(FILE *fp, struct rtattr *attr)
* This is reported by HW devices that have some bridging
* capabilities.
*/
-static void print_af_spec(FILE *fp, struct rtattr *attr)
+static void print_af_spec(struct rtattr *attr, int ifindex)
{
struct rtattr *aftb[IFLA_BRIDGE_MAX+1];
@@ -174,7 +174,7 @@ static void print_af_spec(FILE *fp, struct rtattr *attr)
return;
if (aftb[IFLA_BRIDGE_VLAN_INFO])
- print_vlan_info(fp, aftb[IFLA_BRIDGE_VLAN_INFO]);
+ print_vlan_info(aftb[IFLA_BRIDGE_VLAN_INFO], ifindex);
}
int print_linkinfo(const struct sockaddr_nl *who,
@@ -229,7 +229,7 @@ int print_linkinfo(const struct sockaddr_nl *who,
print_protinfo(fp, tb[IFLA_PROTINFO]);
if (tb[IFLA_AF_SPEC])
- print_af_spec(fp, tb[IFLA_AF_SPEC]);
+ print_af_spec(tb[IFLA_AF_SPEC], ifi->ifi_index);
print_string(PRINT_FP, NULL, "%s", "\n");
close_json_object();
diff --git a/bridge/vlan.c b/bridge/vlan.c
index 19a36b804069..bdce55ae4e14 100644
--- a/bridge/vlan.c
+++ b/bridge/vlan.c
@@ -252,10 +252,18 @@ static int filter_vlan_check(__u16 vid, __u16 flags)
return 1;
}
-static void print_vlan_port(FILE *fp, int ifi_index)
+static void open_vlan_port(int ifi_index)
{
- print_string(PRINT_ANY, NULL, "%s",
+ open_json_object(NULL);
+ print_string(PRINT_ANY, "ifname", "%s",
ll_index_to_name(ifi_index));
+ open_json_array(PRINT_JSON, "vlans");
+}
+
+static void close_vlan_port(void)
+{
+ close_json_array(PRINT_JSON, NULL);
+ close_json_object();
}
static void print_range(const char *name, __u16 start, __u16 id)
@@ -278,7 +286,7 @@ static void print_vlan_tunnel_info(FILE *fp, struct rtattr *tb, int ifindex)
__u32 last_tunid_start = 0;
if (!filter_vlan)
- print_vlan_port(fp, ifindex);
+ open_vlan_port(ifindex);
open_json_array(PRINT_JSON, "tunnel");
for (i = RTA_DATA(list); RTA_OK(i, rem); i = RTA_NEXT(i, rem)) {
@@ -323,18 +331,20 @@ static void print_vlan_tunnel_info(FILE *fp, struct rtattr *tb, int ifindex)
continue;
if (filter_vlan)
- print_vlan_port(fp, ifindex);
+ open_vlan_port(ifindex);
open_json_object(NULL);
print_range("vlan", last_vid_start, tunnel_vid);
print_range("tunid", last_tunid_start, tunnel_id);
close_json_object();
- if (!is_json_context())
- fprintf(fp, "\n");
-
+ print_string(PRINT_FP, NULL, "%s", _SL_);
+ if (filter_vlan)
+ close_vlan_port();
}
- close_json_array(PRINT_JSON, NULL);
+
+ if (!filter_vlan)
+ close_vlan_port();
}
static int print_vlan_tunnel(const struct sockaddr_nl *who,
@@ -421,8 +431,8 @@ static int print_vlan(const struct sockaddr_nl *who,
return 0;
}
- print_vlan_port(fp, ifm->ifi_index);
- print_vlan_info(fp, tb[IFLA_AF_SPEC]);
+ print_vlan_info(tb[IFLA_AF_SPEC], ifm->ifi_index);
+ print_string(PRINT_FP, NULL, "%s", _SL_);
fflush(fp);
return 0;
@@ -430,11 +440,16 @@ static int print_vlan(const struct sockaddr_nl *who,
static void print_vlan_flags(__u16 flags)
{
+ if (flags == 0)
+ return;
+
+ open_json_array(PRINT_JSON, "flags");
if (flags & BRIDGE_VLAN_INFO_PVID)
- print_null(PRINT_ANY, "pvid", " %s", "PVID");
+ print_string(PRINT_ANY, NULL, " %s", "PVID");
if (flags & BRIDGE_VLAN_INFO_UNTAGGED)
- print_null(PRINT_ANY, "untagged", " %s", "untagged");
+ print_string(PRINT_ANY, NULL, " %s", "Egress Untagged");
+ close_json_array(PRINT_JSON, NULL);
}
static void print_one_vlan_stats(const struct bridge_vlan_xstats *vstats)
@@ -461,6 +476,7 @@ static void print_vlan_stats_attr(struct rtattr *attr, int ifindex)
{
struct rtattr *brtb[LINK_XSTATS_TYPE_MAX+1];
struct rtattr *i, *list;
+ const char *ifname;
int rem;
parse_rtattr(brtb, LINK_XSTATS_TYPE_MAX, RTA_DATA(attr),
@@ -471,13 +487,12 @@ static void print_vlan_stats_attr(struct rtattr *attr, int ifindex)
list = brtb[LINK_XSTATS_TYPE_BRIDGE];
rem = RTA_PAYLOAD(list);
- open_json_object(NULL);
+ ifname = ll_index_to_name(ifindex);
+ open_json_object(ifname);
- print_color_string(PRINT_ANY, COLOR_IFNAME,
- "dev", "%-16s",
- ll_index_to_name(ifindex));
+ print_color_string(PRINT_FP, COLOR_IFNAME,
+ NULL, "%-16s", ifname);
- open_json_array(PRINT_JSON, "xstats");
for (i = RTA_DATA(list); RTA_OK(i, rem); i = RTA_NEXT(i, rem)) {
const struct bridge_vlan_xstats *vstats = RTA_DATA(i);
@@ -494,7 +509,6 @@ static void print_vlan_stats_attr(struct rtattr *attr, int ifindex)
print_one_vlan_stats(vstats);
}
- close_json_array(PRINT_ANY, "\n");
close_json_object();
}
@@ -623,16 +637,13 @@ static int vlan_show(int argc, char **argv)
return 0;
}
-void print_vlan_info(FILE *fp, struct rtattr *tb)
+void print_vlan_info(struct rtattr *tb, int ifindex)
{
struct rtattr *i, *list = tb;
int rem = RTA_PAYLOAD(list);
__u16 last_vid_start = 0;
- if (!is_json_context())
- fprintf(fp, "%s", _SL_);
-
- open_json_array(PRINT_JSON, "vlan");
+ open_vlan_port(ifindex);
for (i = RTA_DATA(list); RTA_OK(i, rem); i = RTA_NEXT(i, rem)) {
struct bridge_vlan_info *vinfo;
@@ -656,9 +667,9 @@ void print_vlan_info(FILE *fp, struct rtattr *tb)
print_vlan_flags(vinfo->flags);
close_json_object();
+ print_string(PRINT_FP, NULL, "%s", _SL_);
}
-
- close_json_array(PRINT_ANY, "\n");
+ close_vlan_port();
}
int do_vlan(int argc, char **argv)
--
2.17.1
^ permalink raw reply related
* [PATCH net-next] net: sched: cls_flower: dump offload count value
From: Vlad Buslov @ 2018-09-06 15:37 UTC (permalink / raw)
To: netdev; +Cc: jhs, xiyou.wangcong, jiri, davem, Vlad Buslov
Change flower in_hw_count type to fixed-size u32 and dump it as
TCA_FLOWER_IN_HW_COUNT. This change is necessary to properly test shared
blocks and re-offload functionality.
Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
---
include/net/sch_generic.h | 2 +-
include/uapi/linux/pkt_cls.h | 2 ++
net/sched/cls_flower.c | 5 ++++-
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index a6d00093f35e..d68ac55539a5 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -362,7 +362,7 @@ static inline void tcf_block_offload_dec(struct tcf_block *block, u32 *flags)
}
static inline void
-tc_cls_offload_cnt_update(struct tcf_block *block, unsigned int *cnt,
+tc_cls_offload_cnt_update(struct tcf_block *block, u32 *cnt,
u32 *flags, bool add)
{
if (add) {
diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index be382fb0592d..2824fb7ed1c9 100644
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@ -483,6 +483,8 @@ enum {
TCA_FLOWER_KEY_ENC_OPTS,
TCA_FLOWER_KEY_ENC_OPTS_MASK,
+ TCA_FLOWER_IN_HW_COUNT, /* be32 */
+
__TCA_FLOWER_MAX,
};
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index 6fd9bdd93796..4b8dd37dd4f8 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -98,7 +98,7 @@ struct cls_fl_filter {
struct list_head list;
u32 handle;
u32 flags;
- unsigned int in_hw_count;
+ u32 in_hw_count;
struct rcu_work rwork;
struct net_device *hw_dev;
};
@@ -1880,6 +1880,9 @@ static int fl_dump(struct net *net, struct tcf_proto *tp, void *fh,
if (f->flags && nla_put_u32(skb, TCA_FLOWER_FLAGS, f->flags))
goto nla_put_failure;
+ if (nla_put_u32(skb, TCA_FLOWER_IN_HW_COUNT, f->in_hw_count))
+ goto nla_put_failure;
+
if (tcf_exts_dump(skb, &f->exts))
goto nla_put_failure;
--
2.7.5
^ permalink raw reply related
* [PATCH net-next, net v2] net/tls: Set count of SG entries if sk_alloc_sg returns -ENOSPC
From: Vakul Garg @ 2018-09-06 16:11 UTC (permalink / raw)
To: netdev; +Cc: borisp, aviadye, davejwatson, davem, doronrk, Vakul Garg
tls_sw_sendmsg() allocates plaintext and encrypted SG entries using
function sk_alloc_sg(). In case the number of SG entries hit
MAX_SKB_FRAGS, sk_alloc_sg() returns -ENOSPC and sets the variable for
current SG index to '0'. This leads to calling of function
tls_push_record() with 'sg_encrypted_num_elem = 0' and later causes
kernel crash. To fix this, set the number of SG elements to the number
of elements in plaintext/encrypted SG arrays in case sk_alloc_sg()
returns -ENOSPC.
Fixes: 3c4d7559159b ("tls: kernel TLS support")
Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
---
Changes since v1:
- Added 'Fixes:' tag.
- Marking that patch applies to both 'net-next' & 'net' branches
- Resending after correcting system time.
- No code changes as such
net/tls/tls_sw.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index be4f2e990f9f..2dad3dc7be60 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -263,6 +263,9 @@ static int alloc_encrypted_sg(struct sock *sk, int len)
&ctx->sg_encrypted_num_elem,
&ctx->sg_encrypted_size, 0);
+ if (rc == -ENOSPC)
+ ctx->sg_encrypted_num_elem = ARRAY_SIZE(ctx->sg_encrypted_data);
+
return rc;
}
@@ -276,6 +279,9 @@ static int alloc_plaintext_sg(struct sock *sk, int len)
&ctx->sg_plaintext_num_elem, &ctx->sg_plaintext_size,
tls_ctx->pending_open_record_frags);
+ if (rc == -ENOSPC)
+ ctx->sg_plaintext_num_elem = ARRAY_SIZE(ctx->sg_plaintext_data);
+
return rc;
}
--
2.13.6
^ permalink raw reply related
* Re: [PATCH mlx5-next v1 05/15] net/mlx5: Break encap/decap into two separated flow table creation flags
From: Or Gerlitz @ 2018-09-06 16:13 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Jason Gunthorpe, Doug Ledford, RDMA mailing list, Ariel Levkovich,
Mark Bloch, Or Gerlitz, Saeed Mahameed, linux-netdev
In-Reply-To: <20180906040950.GX2977@mtr-leonro.mtl.com>
On Thu, Sep 6, 2018 at 7:09 AM, Leon Romanovsky <leonro@mellanox.com> wrote:
> On Thu, Sep 06, 2018 at 12:37:17AM +0300, Or Gerlitz wrote:
>> On Wed, Sep 5, 2018 at 9:11 PM, Leon Romanovsky wrote:
>> > On Wed, Sep 05, 2018 at 10:38:00AM -0600, Jason Gunthorpe wrote:
>> >> On Wed, Sep 05, 2018 at 08:10:25AM +0300, Leon Romanovsky wrote:
>> >> > > > - int en_encap_decap = !!(flags & MLX5_FLOW_TABLE_TUNNEL_EN);
>> >> > > > + int en_encap = !!(flags & MLX5_FLOW_TABLE_TUNNEL_EN_ENCAP);
>> >> > > > + int en_decap = !!(flags & MLX5_FLOW_TABLE_TUNNEL_EN_DECAP);
>> >> > >
>> >> > > Yuk, please don't use !!.
>> >> > >
>> >> > > bool en_decap = flags & MLX5_FLOW_TABLE_TUNNEL_EN_DECAP;
>> >> >
>> >> > We need to provide en_encap and en_decap as an input to MLX5_SET(...)
>> >> > which is passed to FW as 0 or 1.
>> >> >
>> >> > Boolean type is declared in C as int and treated as zero for false
>> >> > and any other value for true,
>> >>
>> >> No, that isn't right, the kernel uses C99's _Bool intrinsic type, which
>> >> is guaranteed to only hold 0 or 1 by the compiler.
>> >>
>> >> See types.h:
>> >>
>> >> typedef _Bool bool;
>> >
>> > Exciting, it took me a while to find C99 standard and relevant 6.3.1.2.
>> > Anyway, this patch didn't change previous functionality, which used "!!"
>> > convention.
>>
>> so? if we didn't do things properly prior to the patch, why not fixing it along
>> with the patch? lets fix
>
> Or,
>
> What exactly "to fix"? Both code lines:
> 1. Have correct syntax
> 2. Implement proper C99
> 3. Give same compiler code
> 4. Have same readability
>
> There is nothing to fix.
>
> And this patch is already merged, so if you truly care about this,
> please go ahead and prepare patch for whole driver, or better for
> whole kernel.
slow down, I was just supporting Jason's suggestion and said there's
no reason not to follow it.
If you don't agree with Jason, argue with him.
> kernel git:(rdma-next) git grep "\!\!" |wc -l
> 8125
^ permalink raw reply
* Re: [RFC/PATCH] net: nixge: Add PHYLINK support
From: Moritz Fischer @ 2018-09-06 16:36 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, netdev, David S. Miller, Alex Williams,
Linux Kernel Mailing List
In-Reply-To: <20180905123101.GA26739@lunn.ch>
Andrew,
On Wed, Sep 5, 2018 at 5:31 AM, Andrew Lunn <andrew@lunn.ch> wrote:
>> Let me check, it seems there is a register that indicates whether the MAC can
>> do either 1G or 10G. I might be able to use that for some of the above, but
>> there is not really much in terms of writable registers there.
>
> Can the MAC do 10 or 100? At the moment, you don't have anything
> stopping the PHY anto-neg'ing 10Half. If the MAC does not fully
> implement standard Ethernet, you need to tell the PHY driver about
> this. That is what the validate call is about. phylink and phylib
> knows what the PHY supports. It passes that list to the validate
> call. You need to then remove all the modes the MAC does not support.
Makes sense, thanks for clarifying. I'll do some more research on this.
>
>> It's like a DMA engine with a bit of MDIO on the side. Let me see if
>> I can make it look less weird with that. If not I'll go with a
>> comment explaining that there isn't much to do for the MLO_AN_PHY
>> case and the MLO_FIXED cases?
>
> You again need to configure the MAC to the selected speed, duplex,
> etc. If the link is down, you want to disable the MAC. You need this
> for both MLO_AN_PHY and MLO_FIXED, because both specify speeds,
> duplex, etc.
I'll look into it.
Moritz
^ permalink raw reply
* Re: [PATCH] [RFC v2] Drop all 00-INDEX files from Documentation/
From: Daniel Vetter @ 2018-09-06 21:39 UTC (permalink / raw)
To: Steven Rostedt
Cc: Mark Rutland, Linux MIPS Mailing List,
Linux Fbdev development list, Jan Kandziora,
Radim Krčmář, kvm, Linux Doc Mailing List,
Peter Zijlstra, James Hogan, Mark Brown, Henrik Austad,
Will Deacon, dri-devel, Masahiro Yamada, devicetree,
Paul Mackerras, Henrik Austad, Pavel Machek, H. Peter Anvin,
Evgeniy Polyakov, Ian Kent, linux-s390, Paul Moore
In-Reply-To: <20180906120120.3dd1fc91@gandalf.local.home>
On Thu, Sep 6, 2018 at 6:01 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Thu, 6 Sep 2018 09:58:04 -0600
> Jonathan Corbet <corbet@lwn.net> wrote:
>
>> Thanks,
>>
>> jon (who is increasingly inclined to apply this patch)
>
> As Colin Kaepernick now says... "Just do it!"
>
> ;-)
+1
But I'm biased, I'm part of the party that is responsible for the new
shiny documentation system ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH net] ip: frags: fix crash in ip_do_fragment()
From: Taehee Yoo @ 2018-09-06 17:50 UTC (permalink / raw)
To: davem, posk, netdev; +Cc: ap420073, pablo, fw, edumazet
A kernel crash occurrs when defragmented packet is fragmented
in ip_do_fragment().
In defragment routine, skb_orphan() is called and
skb->ip_defrag_offset is set. but skb->sk and
skb->ip_defrag_offset are same union member. so that
frag->sk is not NULL.
Hence crash occurrs in skb->sk check routine in ip_do_fragment() when
defragmented packet is fragmented.
test commands:
%iptables -t nat -I POSTROUTING -j MASQUERADE
%hping3 192.168.4.2 -s 1000 -p 2000 -d 60000
splat looks like:
[ 261.069429] kernel BUG at net/ipv4/ip_output.c:636!
[ 261.075753] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
[ 261.083854] CPU: 1 PID: 1349 Comm: hping3 Not tainted 4.19.0-rc2+ #3
[ 261.100977] RIP: 0010:ip_do_fragment+0x1613/0x2600
[ 261.106945] Code: e8 e2 38 e3 fe 4c 8b 44 24 18 48 8b 74 24 08 e9 92 f6 ff ff 80 3c 02 00 0f 85 da 07 00 00 48 8b b5 d0 00 00 00 e9 25 f6 ff ff <0f> 0b 0f 0b 44 8b 54 24 58 4c 8b 4c 24 18 4c 8b 5c 24 60 4c 8b 6c
[ 261.127015] RSP: 0018:ffff8801031cf2c0 EFLAGS: 00010202
[ 261.134156] RAX: 1ffff1002297537b RBX: ffffed0020639e6e RCX: 0000000000000004
[ 261.142156] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880114ba9bd8
[ 261.150157] RBP: ffff880114ba8a40 R08: ffffed0022975395 R09: ffffed0022975395
[ 261.158157] R10: 0000000000000001 R11: ffffed0022975394 R12: ffff880114ba9ca4
[ 261.166159] R13: 0000000000000010 R14: ffff880114ba9bc0 R15: dffffc0000000000
[ 261.174169] FS: 00007fbae2199700(0000) GS:ffff88011b400000(0000) knlGS:0000000000000000
[ 261.183012] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 261.189013] CR2: 00005579244fe000 CR3: 0000000119bf4000 CR4: 00000000001006e0
[ 261.198158] Call Trace:
[ 261.199018] ? dst_output+0x180/0x180
[ 261.205011] ? save_trace+0x300/0x300
[ 261.209018] ? ip_copy_metadata+0xb00/0xb00
[ 261.213034] ? sched_clock_local+0xd4/0x140
[ 261.218158] ? kill_l4proto+0x120/0x120 [nf_conntrack]
[ 261.223014] ? rt_cpu_seq_stop+0x10/0x10
[ 261.227014] ? find_held_lock+0x39/0x1c0
[ 261.233008] ip_finish_output+0x51d/0xb50
[ 261.237006] ? ip_fragment.constprop.56+0x220/0x220
[ 261.243011] ? nf_ct_l4proto_register_one+0x5b0/0x5b0 [nf_conntrack]
[ 261.250152] ? rcu_is_watching+0x77/0x120
[ 261.255010] ? nf_nat_ipv4_out+0x1e/0x2b0 [nf_nat_ipv4]
[ 261.261033] ? nf_hook_slow+0xb1/0x160
[ 261.265007] ip_output+0x1c7/0x710
[ 261.269005] ? ip_mc_output+0x13f0/0x13f0
[ 261.273002] ? __local_bh_enable_ip+0xe9/0x1b0
[ 261.278152] ? ip_fragment.constprop.56+0x220/0x220
[ 261.282996] ? nf_hook_slow+0xb1/0x160
[ 261.287007] raw_sendmsg+0x21f9/0x4420
[ 261.291008] ? dst_output+0x180/0x180
[ 261.297003] ? sched_clock_cpu+0x126/0x170
[ 261.301003] ? find_held_lock+0x39/0x1c0
[ 261.306155] ? stop_critical_timings+0x420/0x420
[ 261.311004] ? check_flags.part.36+0x450/0x450
[ 261.315005] ? _raw_spin_unlock_irq+0x29/0x40
[ 261.320995] ? _raw_spin_unlock_irq+0x29/0x40
[ 261.326142] ? cyc2ns_read_end+0x10/0x10
[ 261.330139] ? raw_bind+0x280/0x280
[ 261.334138] ? sched_clock_cpu+0x126/0x170
[ 261.338995] ? check_flags.part.36+0x450/0x450
[ 261.342991] ? __lock_acquire+0x4500/0x4500
[ 261.348994] ? inet_sendmsg+0x11c/0x500
[ 261.352989] ? dst_output+0x180/0x180
[ 261.357012] inet_sendmsg+0x11c/0x500
[ ... ]
Fixes: fa0f527358bd ("ip: use rb trees for IP frag queue.")
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
---
include/linux/skbuff.h | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 17a13e4785fc..2eb115be5bf6 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -676,16 +676,13 @@ struct sk_buff {
* UDP receive path is one user.
*/
unsigned long dev_scratch;
+ int ip_defrag_offset;
};
};
struct rb_node rbnode; /* used in netem, ip4 defrag, and tcp stack */
struct list_head list;
};
-
- union {
- struct sock *sk;
- int ip_defrag_offset;
- };
+ struct sock *sk;
union {
ktime_t tstamp;
--
2.17.1
^ permalink raw reply related
* Re: [bpf-next V2 PATCH 0/3] XDP micro optimizations for redirect
From: Alexei Starovoitov @ 2018-09-06 17:55 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: netdev, Daniel Borkmann
In-Reply-To: <153596124879.4754.16274555878412007253.stgit@firesoul>
On Mon, Sep 03, 2018 at 09:54:52AM +0200, Jesper Dangaard Brouer wrote:
> This patchset contains XDP micro optimizations for the redirect core.
> These are not functional changes. The optimizations revolve around
> getting the compiler to layout the code in a way that reflect how XDP
> redirect is used.
>
> Today the compiler chooses to inline and uninline (static C functions)
> in a suboptimal way, compared to how XDP redirect can be used. Perf
> top clearly shows that almost everything gets inlined into the
> function call xdp_do_redirect.
>
> The way the compiler chooses to inlines, does not reflect how XDP
> redirect is used, as the compile cannot know this.
Applied, Thanks
^ permalink raw reply
* Re: [PATCH bpf] selftests/bpf: add missing executables to .gitignore
From: Alexei Starovoitov @ 2018-09-06 17:57 UTC (permalink / raw)
To: Mauricio Vasquez B
Cc: Alexei Starovoitov, Daniel Borkmann, Shuah Khan, netdev,
linux-kernel, linux-kselftest
In-Reply-To: <1535990727-2778-1-git-send-email-mauricio.vasquez@polito.it>
On Mon, Sep 03, 2018 at 06:05:27PM +0200, Mauricio Vasquez B wrote:
> Signed-off-by: Mauricio Vasquez B <mauricio.vasquez@polito.it>
> ---
> tools/testing/selftests/bpf/.gitignore | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/tools/testing/selftests/bpf/.gitignore b/tools/testing/selftests/bpf/.gitignore
> index 49938d72cf63..4d789c1e5167 100644
> --- a/tools/testing/selftests/bpf/.gitignore
> +++ b/tools/testing/selftests/bpf/.gitignore
> @@ -19,3 +19,7 @@ test_btf
> test_sockmap
> test_lirc_mode2_user
> get_cgroup_id_user
> +test_skb_cgroup_id_user
> +test_socket_cookie
> +test_cgroup_storage
> +test_select_reuseport
Applied, Thanks
^ permalink raw reply
* Re: [PATCH net] ip: frags: fix crash in ip_do_fragment()
From: Eric Dumazet @ 2018-09-06 18:06 UTC (permalink / raw)
To: ap420073
Cc: David Miller, Peter Oskolkov, netdev, Pablo Neira Ayuso,
Florian Westphal
In-Reply-To: <20180906175053.1906-1-ap420073@gmail.com>
On Thu, Sep 6, 2018 at 10:51 AM Taehee Yoo <ap420073@gmail.com> wrote:
>
> A kernel crash occurrs when defragmented packet is fragmented
> in ip_do_fragment().
> In defragment routine, skb_orphan() is called and
> skb->ip_defrag_offset is set. but skb->sk and
> skb->ip_defrag_offset are same union member. so that
> frag->sk is not NULL.
> Hence crash occurrs in skb->sk check routine in ip_do_fragment() when
> defragmented packet is fragmented.
Have you tested this patch ?
Moving back ip_defrag_offset is conflicting with the rbnode !
A more correct fix would be to properly clear skb->sk at reassembly.
^ permalink raw reply
* Re: [PATCH bpf-next 0/4] tools/bpf: add bpftool net support
From: Alexei Starovoitov @ 2018-09-06 18:11 UTC (permalink / raw)
To: Yonghong Song; +Cc: ast, daniel, netdev, kernel-team
In-Reply-To: <20180905235806.1536396-1-yhs@fb.com>
On Wed, Sep 05, 2018 at 04:58:02PM -0700, Yonghong Song wrote:
> As bpf usage becomes more pervasive, people starts to worry
> about their cpu and memory cost. On a particular host,
> people often wanted to know all running bpf programs
> and their attachment context. So they can relate
> a performance/memory anormly quickly to a particular bpf
> program or an application.
>
> bpftool already provides a pretty good coverage for perf
> and cgroup related attachments. This patch set enabled
> to dump attachment info for xdp and tc bpf programs.
>
> Currently, users can already use "ip link show <dev>" and
> "tc filter show dev <dev> ..." to dump bpf program attachment
> information for xdp and tc bpf programs. The main reason
> to implement such functionality in bpftool as well is for
> better user experience. We want the bpftool to be the
> ultimate tool for bpf introspection. The bpftool net
> implementation will only present necessary bpf attachment
> information to the user, ignoring most other ip/tc
> specific information.
>
> For example, the below is a pretty json print for xdp
> and tc_filters.
>
> $ ./bpftool -jp net
> [{
> "xdp": [{
> "ifindex": 2,
> "devname": "eth0",
> "prog_id": 198
> }
> ],
> "tc_filters": [{
> "ifindex": 2,
> "kind": "qdisc_htb",
> "name": "prefix_matcher.o:[cls_prefix_matcher_htb]",
> "prog_id": 111727,
> "tag": "d08fe3b4319bc2fd",
> "act": []
> },{
> "ifindex": 2,
> "kind": "qdisc_clsact_ingress",
> "name": "fbflow_icmp",
> "prog_id": 130246,
> "tag": "3f265c7f26db62c9",
> "act": []
> },{
> "ifindex": 2,
> "kind": "qdisc_clsact_egress",
> "name": "prefix_matcher.o:[cls_prefix_matcher_clsact]",
> "prog_id": 111726,
> "tag": "99a197826974c876"
> },{
> "ifindex": 2,
> "kind": "qdisc_clsact_egress",
> "name": "cls_fg_dscp",
> "prog_id": 108619,
> "tag": "dc4630674fd72dcc",
> "act": []
> },{
> "ifindex": 2,
> "kind": "qdisc_clsact_egress",
> "name": "fbflow_egress",
> "prog_id": 130245,
> "tag": "72d2d830d6888d2c"
> }
> ]
> }
> ]
>
> Patch #1 synced kernel uapi header if_link.h to tools directory.
> Patch #2 moved tools/bpf/lib/bpf.c netlink related functions to
> a new file. Patch #3 implemented additional functions
> in libbpf which will be used in Patch #4.
> Patch #4 implemented bpftool net support to dump
> xdp and tc bpf program attachments.
Applied, Thanks
^ permalink raw reply
* Re: [PATCH net] ip: frags: fix crash in ip_do_fragment()
From: Eric Dumazet @ 2018-09-06 18:23 UTC (permalink / raw)
To: ap420073
Cc: David Miller, Peter Oskolkov, netdev, Pablo Neira Ayuso,
Florian Westphal
In-Reply-To: <CANn89iJENha1FiqA_pNpaXu-+vryHjw+6a-fR4Qc3-WmQsrXdQ@mail.gmail.com>
On Thu, Sep 6, 2018 at 11:06 AM Eric Dumazet <edumazet@google.com> wrote:
>
> On Thu, Sep 6, 2018 at 10:51 AM Taehee Yoo <ap420073@gmail.com> wrote:
> >
> > A kernel crash occurrs when defragmented packet is fragmented
> > in ip_do_fragment().
> > In defragment routine, skb_orphan() is called and
> > skb->ip_defrag_offset is set. but skb->sk and
> > skb->ip_defrag_offset are same union member. so that
> > frag->sk is not NULL.
> > Hence crash occurrs in skb->sk check routine in ip_do_fragment() when
> > defragmented packet is fragmented.
>
> Have you tested this patch ?
>
> Moving back ip_defrag_offset is conflicting with the rbnode !
>
> A more correct fix would be to properly clear skb->sk at reassembly.
Something like that :
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index 88281fbce88ce8f1062b99594665766c2a5f5b74..e7227128df2c8fd54727c234f76043133809bd1e
100644
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -599,6 +599,7 @@ static int ip_frag_reasm(struct ipq *qp, struct
sk_buff *skb,
nextp = &fp->next;
fp->prev = NULL;
memset(&fp->rbnode, 0, sizeof(fp->rbnode));
+ fp->sk = NULL;
head->data_len += fp->len;
head->len += fp->len;
if (head->ip_summed != fp->ip_summed)
^ permalink raw reply
* Re: [PATCH net] ip: frags: fix crash in ip_do_fragment()
From: Taehee Yoo @ 2018-09-06 18:48 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Peter Oskolkov, netdev, Pablo Neira Ayuso,
Florian Westphal
In-Reply-To: <CANn89iJfL_zafpBoFBoJKHRNxHogx_8V2BEEfkLW3DZFGCBe8w@mail.gmail.com>
2018-09-07 3:23 GMT+09:00 Eric Dumazet <edumazet@google.com>:
> On Thu, Sep 6, 2018 at 11:06 AM Eric Dumazet <edumazet@google.com> wrote:
>>
>> On Thu, Sep 6, 2018 at 10:51 AM Taehee Yoo <ap420073@gmail.com> wrote:
>> >
>> > A kernel crash occurrs when defragmented packet is fragmented
>> > in ip_do_fragment().
>> > In defragment routine, skb_orphan() is called and
>> > skb->ip_defrag_offset is set. but skb->sk and
>> > skb->ip_defrag_offset are same union member. so that
>> > frag->sk is not NULL.
>> > Hence crash occurrs in skb->sk check routine in ip_do_fragment() when
>> > defragmented packet is fragmented.
>>
>> Have you tested this patch ?
>>
>> Moving back ip_defrag_offset is conflicting with the rbnode !
>>
>> A more correct fix would be to properly clear skb->sk at reassembly.
>
> Something like that :
>
> diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
> index 88281fbce88ce8f1062b99594665766c2a5f5b74..e7227128df2c8fd54727c234f76043133809bd1e
> 100644
> --- a/net/ipv4/ip_fragment.c
> +++ b/net/ipv4/ip_fragment.c
> @@ -599,6 +599,7 @@ static int ip_frag_reasm(struct ipq *qp, struct
> sk_buff *skb,
> nextp = &fp->next;
> fp->prev = NULL;
> memset(&fp->rbnode, 0, sizeof(fp->rbnode));
> + fp->sk = NULL;
> head->data_len += fp->len;
> head->len += fp->len;
> if (head->ip_summed != fp->ip_summed)
Hi Eric!
Oh I'm sorry, I realized that ip_defrag_offset would be conflicting
with the rbnode just now
So, this patch should be dropped.
And I will make v2 patch regard you suggested!
Thank you for review and suggestion!
^ permalink raw reply
* linux-next: manual merge of the bpf-next tree with a previous revert
From: Stephen Rothwell @ 2018-09-07 0:12 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Björn Töpel, David Miller, Jacob Keller, Jeff Kirsher,
Andrew Bowers
[-- Attachment #1: Type: text/plain, Size: 2054 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
drivers/net/ethernet/intel/i40e/i40e_ethtool.c
between commit:
39b042e0b347 ("Merge remote-tracking branch 'net-next/master'")
(this is really my revert of
8fd75c58a09a ("i40e: move ethtool stats boiler plate code to i40e_ethtool_stats.h")
due to a build failure
)
and commit:
b5061a9e8785 ("i40e: disallow changing the number of descriptors when AF_XDP is on")
from the bpf-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index 235012b3bd42,3cd2c88c72f8..000000000000
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@@ -5,26 -5,9 +5,27 @@@
#include "i40e.h"
#include "i40e_diag.h"
+ #include "i40e_txrx_common.h"
-#include "i40e_ethtool_stats.h"
+struct i40e_stats {
+ /* The stat_string is expected to be a format string formatted using
+ * vsnprintf by i40e_add_stat_strings. Every member of a stats array
+ * should use the same format specifiers as they will be formatted
+ * using the same variadic arguments.
+ */
+ char stat_string[ETH_GSTRING_LEN];
+ int sizeof_stat;
+ int stat_offset;
+};
+
+#define I40E_STAT(_type, _name, _stat) { \
+ .stat_string = _name, \
+ .sizeof_stat = FIELD_SIZEOF(_type, _stat), \
+ .stat_offset = offsetof(_type, _stat) \
+}
+
+#define I40E_NETDEV_STAT(_net_stat) \
+ I40E_STAT(struct rtnl_link_stats64, #_net_stat, _net_stat)
#define I40E_PF_STAT(_name, _stat) \
I40E_STAT(struct i40e_pf, _name, _stat)
#define I40E_VSI_STAT(_name, _stat) \
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: build failure after merge of the bpf-next tree
From: Stephen Rothwell @ 2018-09-07 0:19 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Björn Töpel
[-- Attachment #1: Type: text/plain, Size: 618 bytes --]
Hi all,
After merging the bpf-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
ERROR: ".xsk_reuseq_swap" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined!
ERROR: ".xsk_reuseq_free" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined!
ERROR: ".xsk_reuseq_prepare" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined
Caused by commit
9654bd10da60 ("i40e: clean zero-copy XDP Rx ring on shutdown/reset")
CONFIG_XDP_SOCKETS is not set for this build.
I have used the version of the bfp-next tree from next-20180906 for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: Stephen Rothwell @ 2018-09-07 0:20 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Jacob Keller,
Jeff Kirsher, Andrew Bowers
In-Reply-To: <20180903094702.3e32d8f5@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1503 bytes --]
Hi all,
On Mon, 3 Sep 2018 09:47:02 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from drivers/net/ethernet/intel/i40e/i40e_ethtool.c:9:
> drivers/net/ethernet/intel/i40e/i40e_ethtool.c: In function '__i40e_add_stat_strings':
> drivers/net/ethernet/intel/i40e/i40e_ethtool_stats.h:193:20: error: function '__i40e_add_stat_strings' can never be inlined because it uses variable argument lists
> static inline void __i40e_add_stat_strings(u8 **p, const struct i40e_stats stats[],
> ^~~~~~~~~~~~~~~~~~~~~~~
>
> Caused by commit
>
> 8fd75c58a09a ("i40e: move ethtool stats boiler plate code to i40e_ethtool_stats.h")
>
> It is not clear this patch has any value anyway as the moved functions
> are only used in the file they were moved from.
>
> I reverted that commit for today.
>
> The same problem would exist in drivers/net/ethernet/intel/i40evf (where
> a lot of code is duplicated from drivers/net/ethernet/intel/i40e) except
> that this function is not declared inline there.
> Luckily, i40e_ethtool_stats.h is only included my one file
> drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c, otherwise there
> would be multiple copies of __i40e_add_stat_strings().
>
> Surely there is some scope for factoring out some common code between
> these two drivers?
Ping?
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] tcp: really ignore MSG_ZEROCOPY if no SO_ZEROCOPY
From: Willem de Bruijn @ 2018-09-06 19:44 UTC (permalink / raw)
To: vincent.whitchurch
Cc: David Miller, Network Development, Willem de Bruijn, rabinv
In-Reply-To: <20180906135459.15529-1-vincent.whitchurch@axis.com>
On Thu, Sep 6, 2018 at 9:58 AM Vincent Whitchurch
<vincent.whitchurch@axis.com> wrote:
>
> According to the documentation in msg_zerocopy.rst, the SO_ZEROCOPY
> flag was introduced because send(2) ignores unknown message flags and
> any legacy application which was accidentally passing the equivalent of
> MSG_ZEROCOPY earlier should not see any new behaviour.
>
> Before commit f214f915e7db ("tcp: enable MSG_ZEROCOPY"), a send(2) call
> which passed the equivalent of MSG_ZEROCOPY without setting SO_ZEROCOPY
> would succeed. However, after that commit, it fails with -ENOBUFS. So
> it appears that the SO_ZEROCOPY flag fails to fulfill its intended
> purpose. Fix it.
>
> Fixes: f214f915e7db ("tcp: enable MSG_ZEROCOPY")
>
> Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Good catch, thanks for fixing this.
Please remember to mark patches with PATCH net
^ permalink raw reply
* Re: linux-next: build failure after merge of the bpf-next tree
From: Alexei Starovoitov @ 2018-09-07 0:22 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Daniel Borkmann, Alexei Starovoitov, Networking,
Linux-Next Mailing List, Linux Kernel Mailing List,
Björn Töpel
In-Reply-To: <20180907101923.4d2a85c6@canb.auug.org.au>
On Fri, Sep 07, 2018 at 10:19:23AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the bpf-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> ERROR: ".xsk_reuseq_swap" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined!
> ERROR: ".xsk_reuseq_free" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined!
> ERROR: ".xsk_reuseq_prepare" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined
>
> Caused by commit
>
> 9654bd10da60 ("i40e: clean zero-copy XDP Rx ring on shutdown/reset")
>
> CONFIG_XDP_SOCKETS is not set for this build.
>
> I have used the version of the bfp-next tree from next-20180906 for today.
merge conflict and build error...
Bjorn, I'm thinking to toss the patches out of bpf-next and reapply
cleaned up version of the patches...
what do you think?
^ permalink raw reply
* Re: [PATCH net-next] net: sched: change tcf_del_walker() to use concurrent-safe delete
From: Cong Wang @ 2018-09-06 19:58 UTC (permalink / raw)
To: Vlad Buslov
Cc: Linux Kernel Network Developers, Jamal Hadi Salim, Jiri Pirko,
David Miller
In-Reply-To: <vbfworyx4hr.fsf@reg-r-vrt-018-180.mtr.labs.mlnx>
On Thu, Sep 6, 2018 at 4:14 AM Vlad Buslov <vladbu@mellanox.com> wrote:
> > Isn't a concurrent tcf_idr_check_alloc() able to livelock here with
> > your change?
> >
> > idr_for_each_entry_ul{
> > spin_lock(&idrinfo->lock);
> > idr_remove();
> > spin_unlock(&idrinfo->lock);
> > // tcf_idr_check_alloc() jumps in,
> > // allocates next ID which can be found
> > // by idr_get_next_ul()
> > } // the whole loop goes _literately_ infinite...
>
> idr_for_each_entry_ul traverses idr entries with ascending order of
> identifiers, so infinite livelock like this is not possible because it
> never goes back to newly added entries with id<current_id.
I said "literately infinite", it could go from 1 to UINT_MAX,
sufficient to prove my point of livelock.
> >
> > Also, idr_for_each_entry_ul() is supposed to be protected either
> > by RCU or idrinfo->lock, no? With your change or without any change,
> > it doesn't even have any lock after removing RTNL?
>
> After reading this comment I checked actual idr implementation and I
> think you are right. Even though idr_for_each_entry_ul() macro (and
> function idr_get_next_ul() that it uses to iterate over idr entries)
> doesn't specify any locking requirements in comment description (that is
> why this patch doesn't use any), its implementation seems to require
> external synchronization.
Yeah, it is also a reader, so either a reader lock like RCU or a writer lock
like idrinfo->lock.
>
> You suggest I should just hold idrinfo->lock for whole del_walker loop
> duration, or play nicely with potential concurrent users and
> take/release it per action?
My suggestion is pretty clear, you just missed it, let me copy-n-paste:
With what I suggest:
spin_lock(&idrinfo->lock);
idr_for_each_entry_ul{
idr_remove();
}
spin_unlock(&idrinfo->lock);
^ permalink raw reply
* [PATCH 0/2] ARM: dts: mvebu: marvell,prestera
From: Chris Packham @ 2018-09-07 0:59 UTC (permalink / raw)
To: robh+dt, gregory.clement
Cc: jason, davem, andrew, sebastian.hesselbarth, devicetree,
linux-arm-kernel, linux-kernel, netdev, Chris Packham
Define a generic compatible string so that drivers don't need to deal with the
specific variants.
Chris Packham (2):
dt-bindings: marvell,prestera: Add common compatible string
ARM: dts: mvebu: add "marvell,prestera" to PP nodes
Documentation/devicetree/bindings/net/marvell,prestera.txt | 4 ++--
arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 2 +-
arch/arm/boot/dts/armada-xp-98dx3336.dtsi | 2 +-
arch/arm/boot/dts/armada-xp-98dx4251.dtsi | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
--
2.18.0
^ 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