* Re: [PATCH v2 03/14] sh_eth: simplify link auto-negotiation by ethtool
From: Sergei Shtylyov @ 2018-07-06 18:48 UTC (permalink / raw)
To: Vladimir Zapolskiy, David S . Miller
Cc: Andrew Lunn, Geert Uytterhoeven, netdev, linux-renesas-soc
In-Reply-To: <20180704081245.7395-4-vladimir_zapolskiy@mentor.com>
On 07/04/2018 11:12 AM, Vladimir Zapolskiy wrote:
> There is no need to call a heavyweight phy_start_aneg() for phy
> auto-negotiation by ethtool, the phy is already initialized and
> link auto-negotiation is started by calling phy_start() from
> sh_eth_phy_start() when a network device is opened.
>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
[...]
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* [PATCH net 0/2] net/sched: fix NULL dereference in 'goto chain' control action
From: Davide Caratti @ 2018-07-06 19:01 UTC (permalink / raw)
To: Jiri Pirko, Amir Vadai, David S. Miller; +Cc: netdev
in a couple of TC actions (i.e. csum and tunnel_key), the control action
is stored together with the action-specific configuration data.
This avoids a race condition (see [1]), but it causes a crash when 'goto
chain' is used with the above actions. Since this race condition is
tolerated on the other TC actions (it's present even on actions where the
spinlock is still used), storing the control action in the common area
should be acceptable for tunnel_key and csum as well.
[1] https://www.spinics.net/lists/netdev/msg472047.html
Davide Caratti (2):
net/sched: act_csum: fix NULL dereference when 'goto chain' is used
net/sched: act_tunnel_key: fix NULL dereference when 'goto chain' is
used
include/net/tc_act/tc_csum.h | 1 -
include/net/tc_act/tc_tunnel_key.h | 1 -
net/sched/act_csum.c | 6 +++---
net/sched/act_tunnel_key.c | 6 +++---
4 files changed, 6 insertions(+), 8 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH net 1/2] net/sched: act_csum: fix NULL dereference when 'goto chain' is used
From: Davide Caratti @ 2018-07-06 19:01 UTC (permalink / raw)
To: Jiri Pirko, Amir Vadai, David S. Miller; +Cc: netdev
In-Reply-To: <cover.1530903047.git.dcaratti@redhat.com>
the control action in the common member of struct tcf_csum must be a valid
value, as it can contain the chain index when 'goto chain' is used. Ensure
that the control action can be read as x->tcfa_action, when x is a pointer
to struct tc_action and x->ops->type is TCA_ACT_CSUM, to prevent the
following command:
# tc filter add dev $h2 ingress protocol ip pref 1 handle 101 flower \
> $tcflags dst_mac $h2mac action csum ip or tcp or udp or sctp goto chain 1
from triggering a NULL pointer dereference when a matching packet is
received.
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
PGD 800000010416b067 P4D 800000010416b067 PUD 1041be067 PMD 0
Oops: 0000 [#1] SMP PTI
CPU: 0 PID: 3072 Comm: mausezahn Tainted: G E 4.18.0-rc2.auguri+ #421
Hardware name: Hewlett-Packard HP Z220 CMT Workstation/1790, BIOS K51 v01.58 02/07/2013
RIP: 0010:tcf_action_exec+0xb8/0x100
Code: 00 00 00 20 74 1d 83 f8 03 75 09 49 83 c4 08 4d 39 ec 75 bc 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 49 8b 97 a8 00 00 00 <48> 8b 12 48 89 55 00 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3
RSP: 0018:ffffa020dea03c40 EFLAGS: 00010246
RAX: 0000000020000001 RBX: ffffa020d7ccef00 RCX: 0000000000000054
RDX: 0000000000000000 RSI: ffffa020ca5ae000 RDI: ffffa020d7ccef00
RBP: ffffa020dea03e60 R08: 0000000000000000 R09: ffffa020dea03c9c
R10: ffffa020dea03c78 R11: 0000000000000008 R12: ffffa020d3fe4f00
R13: ffffa020d3fe4f08 R14: 0000000000000001 R15: ffffa020d53ca300
FS: 00007f5a46942740(0000) GS:ffffa020dea00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000000104218002 CR4: 00000000001606f0
Call Trace:
<IRQ>
fl_classify+0x1ad/0x1c0 [cls_flower]
? arp_rcv+0x121/0x1b0
? __x2apic_send_IPI_dest+0x40/0x40
? smp_reschedule_interrupt+0x1c/0xd0
? reschedule_interrupt+0xf/0x20
? reschedule_interrupt+0xa/0x20
? device_is_rmrr_locked+0xe/0x50
? iommu_should_identity_map+0x49/0xd0
? __intel_map_single+0x30/0x140
? e1000e_update_rdt_wa.isra.52+0x22/0xb0 [e1000e]
? e1000_alloc_rx_buffers+0x233/0x250 [e1000e]
? kmem_cache_alloc+0x38/0x1c0
tcf_classify+0x89/0x140
__netif_receive_skb_core+0x5ea/0xb70
? enqueue_task_fair+0xb6/0x7d0
? process_backlog+0x97/0x150
process_backlog+0x97/0x150
net_rx_action+0x14b/0x3e0
__do_softirq+0xde/0x2b4
do_softirq_own_stack+0x2a/0x40
</IRQ>
do_softirq.part.18+0x49/0x50
__local_bh_enable_ip+0x49/0x50
__dev_queue_xmit+0x4ab/0x8a0
? wait_woken+0x80/0x80
? packet_sendmsg+0x38f/0x810
? __dev_queue_xmit+0x8a0/0x8a0
packet_sendmsg+0x38f/0x810
sock_sendmsg+0x36/0x40
__sys_sendto+0x10e/0x140
? do_vfs_ioctl+0xa4/0x630
? syscall_trace_enter+0x1df/0x2e0
? __audit_syscall_exit+0x22a/0x290
__x64_sys_sendto+0x24/0x30
do_syscall_64+0x5b/0x180
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f5a45cbec93
Code: 48 8b 0d 18 83 20 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 59 c7 20 00 00 75 13 49 89 ca b8 2c 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 34 c3 48 83 ec 08 e8 2b f7 ff ff 48 89 04 24
RSP: 002b:00007ffd0ee6d748 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000000001161010 RCX: 00007f5a45cbec93
RDX: 0000000000000062 RSI: 0000000001161322 RDI: 0000000000000003
RBP: 00007ffd0ee6d780 R08: 00007ffd0ee6d760 R09: 0000000000000014
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000062
R13: 0000000001161322 R14: 00007ffd0ee6d760 R15: 0000000000000003
Modules linked in: act_csum act_gact cls_flower sch_ingress vrf veth act_tunnel_key(E) xt_CHECKSUM iptable_mangle ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel snd_hda_codec_hdmi snd_hda_codec_realtek kvm snd_hda_codec_generic hp_wmi iTCO_wdt sparse_keymap rfkill mei_wdt iTCO_vendor_support wmi_bmof gpio_ich irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel snd_hda_intel crypto_simd cryptd snd_hda_codec glue_helper snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm pcspkr i2c_i801 snd_timer snd sg lpc_ich soundcore wmi mei_me
mei ie31200_edac nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sr_mod cdrom sd_mod ahci libahci crc32c_intel i915 ixgbe serio_raw libata video dca i2c_algo_bit sfc drm_kms_helper syscopyarea mtd sysfillrect mdio sysimgblt fb_sys_fops drm e1000e i2c_core
CR2: 0000000000000000
---[ end trace 3c9e9d1a77df4026 ]---
RIP: 0010:tcf_action_exec+0xb8/0x100
Code: 00 00 00 20 74 1d 83 f8 03 75 09 49 83 c4 08 4d 39 ec 75 bc 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 49 8b 97 a8 00 00 00 <48> 8b 12 48 89 55 00 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3
RSP: 0018:ffffa020dea03c40 EFLAGS: 00010246
RAX: 0000000020000001 RBX: ffffa020d7ccef00 RCX: 0000000000000054
RDX: 0000000000000000 RSI: ffffa020ca5ae000 RDI: ffffa020d7ccef00
RBP: ffffa020dea03e60 R08: 0000000000000000 R09: ffffa020dea03c9c
R10: ffffa020dea03c78 R11: 0000000000000008 R12: ffffa020d3fe4f00
R13: ffffa020d3fe4f08 R14: 0000000000000001 R15: ffffa020d53ca300
FS: 00007f5a46942740(0000) GS:ffffa020dea00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000000104218002 CR4: 00000000001606f0
Kernel panic - not syncing: Fatal exception in interrupt
Kernel Offset: 0x26400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
Fixes: 9c5f69bbd75a ("net/sched: act_csum: don't use spinlock in the fast path")
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
include/net/tc_act/tc_csum.h | 1 -
net/sched/act_csum.c | 6 +++---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/include/net/tc_act/tc_csum.h b/include/net/tc_act/tc_csum.h
index 9470fd7e4350..32d2454c0479 100644
--- a/include/net/tc_act/tc_csum.h
+++ b/include/net/tc_act/tc_csum.h
@@ -7,7 +7,6 @@
#include <linux/tc_act/tc_csum.h>
struct tcf_csum_params {
- int action;
u32 update_flags;
struct rcu_head rcu;
};
diff --git a/net/sched/act_csum.c b/net/sched/act_csum.c
index 526a8e491626..6e7124e57918 100644
--- a/net/sched/act_csum.c
+++ b/net/sched/act_csum.c
@@ -91,7 +91,7 @@ static int tcf_csum_init(struct net *net, struct nlattr *nla,
}
params_old = rtnl_dereference(p->params);
- params_new->action = parm->action;
+ p->tcf_action = parm->action;
params_new->update_flags = parm->update_flags;
rcu_assign_pointer(p->params, params_new);
if (params_old)
@@ -561,7 +561,7 @@ static int tcf_csum(struct sk_buff *skb, const struct tc_action *a,
tcf_lastuse_update(&p->tcf_tm);
bstats_cpu_update(this_cpu_ptr(p->common.cpu_bstats), skb);
- action = params->action;
+ action = READ_ONCE(p->tcf_action);
if (unlikely(action == TC_ACT_SHOT))
goto drop_stats;
@@ -599,11 +599,11 @@ static int tcf_csum_dump(struct sk_buff *skb, struct tc_action *a, int bind,
.index = p->tcf_index,
.refcnt = p->tcf_refcnt - ref,
.bindcnt = p->tcf_bindcnt - bind,
+ .action = p->tcf_action,
};
struct tcf_t t;
params = rtnl_dereference(p->params);
- opt.action = params->action;
opt.update_flags = params->update_flags;
if (nla_put(skb, TCA_CSUM_PARMS, sizeof(opt), &opt))
--
2.17.1
^ permalink raw reply related
* [PATCH net 2/2] net/sched: act_tunnel_key: fix NULL dereference when 'goto chain' is used
From: Davide Caratti @ 2018-07-06 19:01 UTC (permalink / raw)
To: Jiri Pirko, Amir Vadai, David S. Miller; +Cc: netdev
In-Reply-To: <cover.1530903047.git.dcaratti@redhat.com>
the control action in the common member of struct tcf_tunnel_key must be a
valid value, as it can contain the chain index when 'goto chain' is used.
Ensure that the control action can be read as x->tcfa_action, when x is a
pointer to struct tc_action and x->ops->type is TCA_ACT_TUNNEL_KEY, to
prevent the following command:
# tc filter add dev $h2 ingress protocol ip pref 1 handle 101 flower \
> $tcflags dst_mac $h2mac action tunnel_key unset goto chain 1
from causing a NULL dereference when a matching packet is received:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
PGD 80000001097ac067 P4D 80000001097ac067 PUD 103b0a067 PMD 0
Oops: 0000 [#1] SMP PTI
CPU: 0 PID: 3491 Comm: mausezahn Tainted: G E 4.18.0-rc2.auguri+ #421
Hardware name: Hewlett-Packard HP Z220 CMT Workstation/1790, BIOS K51 v01.58 02/07/2013
RIP: 0010:tcf_action_exec+0xb8/0x100
Code: 00 00 00 20 74 1d 83 f8 03 75 09 49 83 c4 08 4d 39 ec 75 bc 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 49 8b 97 a8 00 00 00 <48> 8b 12 48 89 55 00 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3
RSP: 0018:ffff95145ea03c40 EFLAGS: 00010246
RAX: 0000000020000001 RBX: ffff9514499e5800 RCX: 0000000000000001
RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000000
RBP: ffff95145ea03e60 R08: 0000000000000000 R09: ffff95145ea03c9c
R10: ffff95145ea03c78 R11: 0000000000000008 R12: ffff951456a69800
R13: ffff951456a69808 R14: 0000000000000001 R15: ffff95144965ee40
FS: 00007fd67ee11740(0000) GS:ffff95145ea00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000001038a2006 CR4: 00000000001606f0
Call Trace:
<IRQ>
fl_classify+0x1ad/0x1c0 [cls_flower]
? __update_load_avg_se.isra.47+0x1ca/0x1d0
? __update_load_avg_se.isra.47+0x1ca/0x1d0
? update_load_avg+0x665/0x690
? update_load_avg+0x665/0x690
? kmem_cache_alloc+0x38/0x1c0
tcf_classify+0x89/0x140
__netif_receive_skb_core+0x5ea/0xb70
? enqueue_entity+0xd0/0x270
? process_backlog+0x97/0x150
process_backlog+0x97/0x150
net_rx_action+0x14b/0x3e0
__do_softirq+0xde/0x2b4
do_softirq_own_stack+0x2a/0x40
</IRQ>
do_softirq.part.18+0x49/0x50
__local_bh_enable_ip+0x49/0x50
__dev_queue_xmit+0x4ab/0x8a0
? wait_woken+0x80/0x80
? packet_sendmsg+0x38f/0x810
? __dev_queue_xmit+0x8a0/0x8a0
packet_sendmsg+0x38f/0x810
sock_sendmsg+0x36/0x40
__sys_sendto+0x10e/0x140
? do_vfs_ioctl+0xa4/0x630
? syscall_trace_enter+0x1df/0x2e0
? __audit_syscall_exit+0x22a/0x290
__x64_sys_sendto+0x24/0x30
do_syscall_64+0x5b/0x180
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7fd67e18dc93
Code: 48 8b 0d 18 83 20 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 59 c7 20 00 00 75 13 49 89 ca b8 2c 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 34 c3 48 83 ec 08 e8 2b f7 ff ff 48 89 04 24
RSP: 002b:00007ffe0189b748 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00000000020ca010 RCX: 00007fd67e18dc93
RDX: 0000000000000062 RSI: 00000000020ca322 RDI: 0000000000000003
RBP: 00007ffe0189b780 R08: 00007ffe0189b760 R09: 0000000000000014
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000062
R13: 00000000020ca322 R14: 00007ffe0189b760 R15: 0000000000000003
Modules linked in: act_tunnel_key act_gact cls_flower sch_ingress vrf veth act_csum(E) xt_CHECKSUM iptable_mangle ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter intel_rapl snd_hda_codec_hdmi x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_realtek coretemp snd_hda_codec_generic kvm_intel kvm irqbypass snd_hda_intel crct10dif_pclmul crc32_pclmul hp_wmi ghash_clmulni_intel pcbc snd_hda_codec aesni_intel sparse_keymap rfkill snd_hda_core snd_hwdep snd_seq crypto_simd iTCO_wdt gpio_ich iTCO_vendor_support wmi_bmof cryptd mei_wdt glue_helper snd_seq_device snd_pcm pcspkr snd_timer snd i2c_i801 lpc_ich sg soundcore wmi mei_me
mei ie31200_edac nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sd_mod sr_mod cdrom i915 video i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ahci crc32c_intel libahci serio_raw sfc libata mtd drm ixgbe mdio i2c_core e1000e dca
CR2: 0000000000000000
---[ end trace 1ab8b5b5d4639dfc ]---
RIP: 0010:tcf_action_exec+0xb8/0x100
Code: 00 00 00 20 74 1d 83 f8 03 75 09 49 83 c4 08 4d 39 ec 75 bc 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 49 8b 97 a8 00 00 00 <48> 8b 12 48 89 55 00 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3
RSP: 0018:ffff95145ea03c40 EFLAGS: 00010246
RAX: 0000000020000001 RBX: ffff9514499e5800 RCX: 0000000000000001
RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000000
RBP: ffff95145ea03e60 R08: 0000000000000000 R09: ffff95145ea03c9c
R10: ffff95145ea03c78 R11: 0000000000000008 R12: ffff951456a69800
R13: ffff951456a69808 R14: 0000000000000001 R15: ffff95144965ee40
FS: 00007fd67ee11740(0000) GS:ffff95145ea00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000001038a2006 CR4: 00000000001606f0
Kernel panic - not syncing: Fatal exception in interrupt
Kernel Offset: 0x11400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
Fixes: d0f6dd8a914f ("net/sched: Introduce act_tunnel_key")
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
include/net/tc_act/tc_tunnel_key.h | 1 -
net/sched/act_tunnel_key.c | 6 +++---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/include/net/tc_act/tc_tunnel_key.h b/include/net/tc_act/tc_tunnel_key.h
index efef0b4b1b2b..46b8c7f1c8d5 100644
--- a/include/net/tc_act/tc_tunnel_key.h
+++ b/include/net/tc_act/tc_tunnel_key.h
@@ -18,7 +18,6 @@
struct tcf_tunnel_key_params {
struct rcu_head rcu;
int tcft_action;
- int action;
struct metadata_dst *tcft_enc_metadata;
};
diff --git a/net/sched/act_tunnel_key.c b/net/sched/act_tunnel_key.c
index 626dac81a48a..9bc6c2ae98a5 100644
--- a/net/sched/act_tunnel_key.c
+++ b/net/sched/act_tunnel_key.c
@@ -36,7 +36,7 @@ static int tunnel_key_act(struct sk_buff *skb, const struct tc_action *a,
tcf_lastuse_update(&t->tcf_tm);
bstats_cpu_update(this_cpu_ptr(t->common.cpu_bstats), skb);
- action = params->action;
+ action = READ_ONCE(t->tcf_action);
switch (params->tcft_action) {
case TCA_TUNNEL_KEY_ACT_RELEASE:
@@ -182,7 +182,7 @@ static int tunnel_key_init(struct net *net, struct nlattr *nla,
params_old = rtnl_dereference(t->params);
- params_new->action = parm->action;
+ t->tcf_action = parm->action;
params_new->tcft_action = parm->t_action;
params_new->tcft_enc_metadata = metadata;
@@ -254,13 +254,13 @@ static int tunnel_key_dump(struct sk_buff *skb, struct tc_action *a,
.index = t->tcf_index,
.refcnt = t->tcf_refcnt - ref,
.bindcnt = t->tcf_bindcnt - bind,
+ .action = t->tcf_action,
};
struct tcf_t tm;
params = rtnl_dereference(t->params);
opt.t_action = params->tcft_action;
- opt.action = params->action;
if (nla_put(skb, TCA_TUNNEL_KEY_PARMS, sizeof(opt), &opt))
goto nla_put_failure;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2 04/14] sh_eth: remove custom .nway_reset from ethtool ops
From: Sergei Shtylyov @ 2018-07-06 19:04 UTC (permalink / raw)
To: Vladimir Zapolskiy, David S . Miller
Cc: Andrew Lunn, Geert Uytterhoeven, netdev, linux-renesas-soc
In-Reply-To: <20180704081245.7395-5-vladimir_zapolskiy@mentor.com>
On 07/04/2018 11:12 AM, Vladimir Zapolskiy wrote:
> The generic phy_ethtool_nway_reset() function from phylib can be used
> instead of in-house sh_eth_nway_reset().
>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
[...]
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v2 05/14] sh_eth: remove useless serialization in sh_eth_get_link_ksettings()
From: Sergei Shtylyov @ 2018-07-06 19:06 UTC (permalink / raw)
To: Vladimir Zapolskiy, David S . Miller
Cc: Andrew Lunn, Geert Uytterhoeven, netdev, linux-renesas-soc
In-Reply-To: <20180704081451.7482-1-vladimir_zapolskiy@mentor.com>
On 07/04/2018 11:14 AM, Vladimir Zapolskiy wrote:
> phy_ethtool_ksettings_get() call does not modify device state or device
> driver state, hence there is no need to utilize a driver specific
> spinlock.
>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
[...]
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v2 06/14] sh_eth: remove custom .get_link_ksettings from ethtool ops
From: Sergei Shtylyov @ 2018-07-06 19:08 UTC (permalink / raw)
To: Vladimir Zapolskiy, David S . Miller
Cc: Andrew Lunn, Geert Uytterhoeven, netdev, linux-renesas-soc
In-Reply-To: <20180704081451.7482-2-vladimir_zapolskiy@mentor.com>
On 07/04/2018 11:14 AM, Vladimir Zapolskiy wrote:
> The generic phy_ethtool_get_link_ksettings() function from phylib can be
> used instead of in-house sh_eth_get_link_ksettings().
>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
[...]
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v2 07/14] sh_eth: remove custom .set_link_ksettings from ethtool ops
From: Sergei Shtylyov @ 2018-07-06 19:15 UTC (permalink / raw)
To: Vladimir Zapolskiy, David S . Miller
Cc: Andrew Lunn, Geert Uytterhoeven, netdev, linux-renesas-soc
In-Reply-To: <20180704081451.7482-3-vladimir_zapolskiy@mentor.com>
On 07/04/2018 11:14 AM, Vladimir Zapolskiy wrote:
> The generic phy_ethtool_set_link_ksettings() function from phylib can
> be used instead of in-house sh_eth_set_link_ksettings().
>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
[...]
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v2 08/14] ravb: fix invalid context bug while calling auto-negotiation by ethtool
From: Sergei Shtylyov @ 2018-07-06 19:47 UTC (permalink / raw)
To: Vladimir Zapolskiy, David S . Miller
Cc: Andrew Lunn, Geert Uytterhoeven, netdev, linux-renesas-soc
In-Reply-To: <20180704081451.7482-4-vladimir_zapolskiy@mentor.com>
On 07/04/2018 11:14 AM, Vladimir Zapolskiy wrote:
> Since commit 35b5f6b1a82b ("PHYLIB: Locking fixes for PHY I/O
> potentially sleeping") phy_start_aneg() function utilizes a mutex
> to serialize changes to phy state, however the helper function is
> called in atomic context.
>
> The bug can be reproduced by running "ethtool -r" command, the bug
> is reported if CONFIG_DEBUG_ATOMIC_SLEEP build option is enabled.
>
> Fixes: a0d2f20650e8 ("Renesas Ethernet AVB PTP clock driver")
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
[...]
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Again, the patch order question...
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v2 09/14] ravb: fix invalid context bug while changing link options by ethtool
From: Sergei Shtylyov @ 2018-07-06 19:58 UTC (permalink / raw)
To: Vladimir Zapolskiy, David S . Miller
Cc: Andrew Lunn, Geert Uytterhoeven, netdev, linux-renesas-soc
In-Reply-To: <20180704081451.7482-5-vladimir_zapolskiy@mentor.com>
On 07/04/2018 11:14 AM, Vladimir Zapolskiy wrote:
> The change fixes sleep in atomic context bug, which is encountered
> every time when link settings are changed by ethtool.
>
> Since commit 35b5f6b1a82b ("PHYLIB: Locking fixes for PHY I/O
> potentially sleeping") phy_start_aneg() function utilizes a mutex
> to serialize changes to phy state, however that helper function is
> called in atomic context under a grabbed spinlock, because
> phy_start_aneg() is called by phy_ethtool_ksettings_set() and by
> replaced phy_ethtool_sset() helpers from phylib.
>
> Now duplex mode setting is enforced in ravb_adjust_link() only, also
> now RX/TX is disabled when link is put down or modifications to E-MAC
> registers ECMR and GECMR are expected for both cases of checked and
> ignored link status pin state from E-MAC interrupt handler.
>
> Fixes: a0d2f20650e8 ("Renesas Ethernet AVB PTP clock driver")
Wrong commit, as already noted...
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
[...]
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* [PATCH net v2] net/mlx5: fix uaccess beyond "count" in debugfs read/write handlers
From: Jann Horn @ 2018-07-06 20:18 UTC (permalink / raw)
To: Saeed Mahameed, Leon Romanovsky, David S. Miller, jannh
Cc: netdev, linux-rdma, linux-kernel
In general, accessing userspace memory beyond the length of the supplied
buffer in VFS read/write handlers can lead to both kernel memory corruption
(via kernel_read()/kernel_write(), which can e.g. be triggered via
sys_splice()) and privilege escalation inside userspace.
In this case, the affected files are in debugfs (and should therefore only
be accessible to root) and check that *pos is zero (which prevents the
sys_splice() trick). Therefore, this is not a security fix, but rather a
small cleanup.
For the read handlers, fix it by using simple_read_from_buffer() instead of
custom logic.
For the write handler, add a check.
changed in v2:
- also fix dbg_write()
Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters")
Signed-off-by: Jann Horn <jannh@google.com>
---
drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 28 +++++--------------
.../net/ethernet/mellanox/mlx5/core/debugfs.c | 22 ++-------------
2 files changed, 9 insertions(+), 41 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
index 384c1fa49081..92578074145d 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
@@ -1022,7 +1022,10 @@ static ssize_t dbg_write(struct file *filp, const char __user *buf,
if (!dbg->in_msg || !dbg->out_msg)
return -ENOMEM;
- if (copy_from_user(lbuf, buf, sizeof(lbuf)))
+ if (count < sizeof(lbuf) - 1)
+ return -EINVAL;
+
+ if (copy_from_user(lbuf, buf, sizeof(lbuf) - 1))
return -EFAULT;
lbuf[sizeof(lbuf) - 1] = 0;
@@ -1226,21 +1229,12 @@ static ssize_t data_read(struct file *filp, char __user *buf, size_t count,
{
struct mlx5_core_dev *dev = filp->private_data;
struct mlx5_cmd_debug *dbg = &dev->cmd.dbg;
- int copy;
-
- if (*pos)
- return 0;
if (!dbg->out_msg)
return -ENOMEM;
- copy = min_t(int, count, dbg->outlen);
- if (copy_to_user(buf, dbg->out_msg, copy))
- return -EFAULT;
-
- *pos += copy;
-
- return copy;
+ return simple_read_from_buffer(buf, count, pos, dbg->out_msg,
+ dbg->outlen);
}
static const struct file_operations dfops = {
@@ -1258,19 +1252,11 @@ static ssize_t outlen_read(struct file *filp, char __user *buf, size_t count,
char outlen[8];
int err;
- if (*pos)
- return 0;
-
err = snprintf(outlen, sizeof(outlen), "%d", dbg->outlen);
if (err < 0)
return err;
- if (copy_to_user(buf, &outlen, err))
- return -EFAULT;
-
- *pos += err;
-
- return err;
+ return simple_read_from_buffer(buf, count, pos, outlen, err);
}
static ssize_t outlen_write(struct file *filp, const char __user *buf,
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/debugfs.c b/drivers/net/ethernet/mellanox/mlx5/core/debugfs.c
index 413080a312a7..90fabd612b6c 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/debugfs.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/debugfs.c
@@ -150,22 +150,13 @@ static ssize_t average_read(struct file *filp, char __user *buf, size_t count,
int ret;
char tbuf[22];
- if (*pos)
- return 0;
-
stats = filp->private_data;
spin_lock_irq(&stats->lock);
if (stats->n)
field = div64_u64(stats->sum, stats->n);
spin_unlock_irq(&stats->lock);
ret = snprintf(tbuf, sizeof(tbuf), "%llu\n", field);
- if (ret > 0) {
- if (copy_to_user(buf, tbuf, ret))
- return -EFAULT;
- }
-
- *pos += ret;
- return ret;
+ return simple_read_from_buffer(buf, count, pos, tbuf, ret);
}
static ssize_t average_write(struct file *filp, const char __user *buf,
@@ -442,9 +433,6 @@ static ssize_t dbg_read(struct file *filp, char __user *buf, size_t count,
u64 field;
int ret;
- if (*pos)
- return 0;
-
desc = filp->private_data;
d = (void *)(desc - desc->i) - sizeof(*d);
switch (d->type) {
@@ -470,13 +458,7 @@ static ssize_t dbg_read(struct file *filp, char __user *buf, size_t count,
else
ret = snprintf(tbuf, sizeof(tbuf), "0x%llx\n", field);
- if (ret > 0) {
- if (copy_to_user(buf, tbuf, ret))
- return -EFAULT;
- }
-
- *pos += ret;
- return ret;
+ return simple_read_from_buffer(buf, count, pos, tbuf, ret);
}
static const struct file_operations fops = {
--
2.18.0.203.gfac676dfb9-goog
^ permalink raw reply related
* Re: [PATCH v2 10/14] ravb: simplify link auto-negotiation by ethtool
From: Sergei Shtylyov @ 2018-07-06 20:30 UTC (permalink / raw)
To: Vladimir Zapolskiy, David S . Miller
Cc: Andrew Lunn, Geert Uytterhoeven, netdev, linux-renesas-soc
In-Reply-To: <20180704081612.7628-1-vladimir_zapolskiy@mentor.com>
On 07/04/2018 11:16 AM, Vladimir Zapolskiy wrote:
> There is no need to call a heavyweight phy_start_aneg() for phy
> auto-negotiation by ethtool, the phy is already initialized and
> link auto-negotiation is started by calling phy_start() from
> ravb_phy_start() when a network device is opened.
>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
[...]
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v2 11/14] ravb: remove custom .nway_reset from ethtool ops
From: Sergei Shtylyov @ 2018-07-06 20:30 UTC (permalink / raw)
To: Vladimir Zapolskiy, David S . Miller
Cc: Andrew Lunn, Geert Uytterhoeven, netdev, linux-renesas-soc
In-Reply-To: <20180704081612.7628-2-vladimir_zapolskiy@mentor.com>
On 07/04/2018 11:16 AM, Vladimir Zapolskiy wrote:
> The generic phy_ethtool_nway_reset() function from phylib can be used
> instead of in-house ravb_nway_reset().
>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
[...]
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v2 12/14] ravb: remove useless serialization in ravb_get_link_ksettings()
From: Sergei Shtylyov @ 2018-07-06 20:31 UTC (permalink / raw)
To: Vladimir Zapolskiy, David S . Miller
Cc: Andrew Lunn, Geert Uytterhoeven, netdev, linux-renesas-soc
In-Reply-To: <20180704081612.7628-3-vladimir_zapolskiy@mentor.com>
On 07/04/2018 11:16 AM, Vladimir Zapolskiy wrote:
> phy_ethtool_ksettings_get() call does not modify device state or device
> driver state, hence there is no need to utilize a driver specific
> spinlock.
>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
[...]
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v2 13/14] ravb: remove custom .get_link_ksettings from ethtool ops
From: Sergei Shtylyov @ 2018-07-06 20:39 UTC (permalink / raw)
To: Vladimir Zapolskiy, David S . Miller
Cc: Andrew Lunn, Geert Uytterhoeven, netdev, linux-renesas-soc
In-Reply-To: <20180704081612.7628-4-vladimir_zapolskiy@mentor.com>
On 07/04/2018 11:16 AM, Vladimir Zapolskiy wrote:
> The generic phy_ethtool_get_link_ksettings() function from phylib can be
> used instead of in-house ravb_get_link_ksettings().
>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
[...]
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v2 14/14] ravb: remove custom .set_link_ksettings from ethtool ops
From: Sergei Shtylyov @ 2018-07-06 20:41 UTC (permalink / raw)
To: Vladimir Zapolskiy, David S . Miller
Cc: Andrew Lunn, Geert Uytterhoeven, netdev, linux-renesas-soc
In-Reply-To: <20180704081612.7628-5-vladimir_zapolskiy@mentor.com>
On 07/04/2018 11:16 AM, Vladimir Zapolskiy wrote:
> The generic phy_ethtool_set_link_ksettings() function from phylib can
> be used instead of in-house ravb_set_link_ksettings().
>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
[...]
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* Re: [RFC bpf-next 2/6] net: xdp: RX meta data infrastructure
From: Waskiewicz Jr, Peter @ 2018-07-06 20:44 UTC (permalink / raw)
To: alexei.starovoitov@gmail.com, jakub.kicinski@netronome.com
Cc: Duyck, Alexander H, daniel@iogearbox.net, saeedm@mellanox.com,
brouer@redhat.com, borkmann@iogearbox.net, tariqt@mellanox.com,
john.fastabend@gmail.com, netdev@vger.kernel.org,
saeedm@dev.mellanox.co.il
In-Reply-To: <20180706163041.xstyfednmgho23m3@ast-mbp.dhcp.thefacebook.com>
On Fri, 2018-07-06 at 09:30 -0700, Alexei Starovoitov wrote:
> On Thu, Jul 05, 2018 at 10:18:23AM -0700, Jakub Kicinski wrote:
> >
> > I'm also not 100% on board with the argument that "future" FW can
> > reshuffle things whatever way it wants to. Is the assumption that
> > future ASICs/FW will be designed to always use the "blessed" BTF
> > format? Or will it be reconfigurable at runtime?
>
> let's table configuration of metadata aside for a second.
I agree that this should/could be NIC-specific and shouldn't weigh on
the metadata interface between the drivers and XDP layer.
> Describing metedata layout in BTF allows NICs to disclose everything
> NIC has to users in a standard and generic way.
> Whether firmware is reconfigurable on the fly or has to reflashed
> and hw powercycled to have new md layout (and corresponding BTF
> description)
> is a separate discussion.
> Saeed's proposal introduces the concept of 'offset' inside 'struct
> xdp_md_info'
> to reach 'hash' value in metadata.
> Essentially it's a run-time way to access 'hash' instead of build-
> time.
> So bpf program would need two loads to read csum or hash field
> instead of one.
> With BTF the layout of metadata is known to the program at build-
> time.
>
> To reiterate the proposal:
> - driver+firmware keep layout of the metadata in BTF format (either
> in the driver
> or driver can read it from firmware)
> - 'bpftool read-metadata-desc eth0 > md_desc.h' command will query
> the driver and
> generate normal C header file based on BTF in the given NIC
> - user does #include "md_desc.h" and bpf program can access md->csum
> or md->hash
> with direct single load out of metadata area in front of the packet
This piece is where I'd like to discuss more. When we discussed this
in Seoul, the initial proposal was a static struct that we'd try to
hammer out a common layout between the interested parties. That
obviously wasn't going to scale, and we wanted to pursue something more
dynamic. But I thought the goal was the XDP/eBPF program wouldn't want
to care what the underlying device is, and could just ask for metadata
that it's interested in. With this approach, your eBPF program is now
bound/tied to the NIC/driver, and if you switched to a differen
NIC/driver combo, then you'd have to rewrite part of your eBPF program
to comprehend that. I thought we were trying to avoid that.
Our proposed approach (still working on something ready to RFC) is to
provide a method for the eBPF program to send a struct of requested
hints down to the driver on load. If the driver can provide the hints,
then that'd be how they'd be laid out in the metadata. If it can't
provide them, we'd probably reject the program loading, or discuss
providing a software fallback (I know this is an area of contention).
I suppose we could get there with the rewriting mechanism described
below, but that'd be a tough sell to set a bit of ABI for metadata,
then change it to be potentially dynamic at runtime in the future.
-PJ
^ permalink raw reply
* Re: [PATCH v1 iproute2 1/2] uapi pkt_sched: Add etf info - DO NOT COMMIT
From: Stephen Hemminger @ 2018-07-06 20:54 UTC (permalink / raw)
To: Jesus Sanchez-Palencia
Cc: netdev, jhs, kurt.kanzenbach, xiyou.wangcong, jiri,
vinicius.gomes
In-Reply-To: <20180627220912.7148-1-jesus.sanchez-palencia@intel.com>
On Wed, 27 Jun 2018 15:09:11 -0700
Jesus Sanchez-Palencia <jesus.sanchez-palencia@intel.com> wrote:
> This should come from the next uapi headers update.
> Sending it now just as a convenience so anyone can build tc with etf
> and taprio support.
>
> Signed-off-by: Jesus Sanchez-Palencia <jesus.sanchez-palencia@intel.com>
This should be targeted at iproute2-next
^ permalink raw reply
* Re: [PATCH v2 bpf-next 3/3] bpftool: add bash completion for cgroup tree command
From: Jakub Kicinski @ 2018-07-06 20:58 UTC (permalink / raw)
To: Roman Gushchin
Cc: netdev, linux-kernel, kernel-team, Quentin Monnet,
Daniel Borkmann, Alexei Starovoitov
In-Reply-To: <20180706183012.6475-3-guro@fb.com>
On Fri, 6 Jul 2018 11:30:12 -0700, Roman Gushchin wrote:
> This commit adds a bash completion to the bpftool cgroup tree
> command.
>
> Signed-off-by: Roman Gushchin <guro@fb.com>
> Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
> Cc: Quentin Monnet <quentin.monnet@netronome.com>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Alexei Starovoitov <ast@kernel.org>
> ---
> tools/bpf/bpftool/bash-completion/bpftool | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/tools/bpf/bpftool/bash-completion/bpftool b/tools/bpf/bpftool/bash-completion/bpftool
> index fffd76f4998b..82681eb9c02a 100644
> --- a/tools/bpf/bpftool/bash-completion/bpftool
> +++ b/tools/bpf/bpftool/bash-completion/bpftool
> @@ -414,6 +414,9 @@ _bpftool()
> _filedir
> return 0
> ;;
> + tree)
> + _filedir
> + return 0
Oh you have not tested this at all, have you?
You're missing ;; at the end of the case, this is not correct bash
syntax and completely breaks the script.
When you respin please use spaces instead of tabs (I know, *very*
annoying but that's apparently how things should be for bash
completions :/).
And please add "tree" to the *) case which completes the actions.
> attach|detach)
> local ATTACH_TYPES='ingress egress sock_create sock_ops \
> device bind4 bind6 post_bind4 post_bind6 connect4 \
^ permalink raw reply
* Re: [PATCH v2 bpf-next 1/3] bpftool: introduce cgroup tree command
From: Jakub Kicinski @ 2018-07-06 21:01 UTC (permalink / raw)
To: Roman Gushchin
Cc: netdev, linux-kernel, kernel-team, Quentin Monnet,
Daniel Borkmann, Alexei Starovoitov
In-Reply-To: <20180706183012.6475-1-guro@fb.com>
On Fri, 6 Jul 2018 11:30:10 -0700, Roman Gushchin wrote:
> This commit introduces a new bpftool command: cgroup tree.
> The idea is to iterate over the whole cgroup tree and print
> all attached programs.
>
> I was debugging a bpf/systemd issue, and found, that there is
> no simple way to listen all bpf programs attached to cgroups.
> I did master something in bash, but after some time got tired of it,
> and decided, that adding a dedicated bpftool command could be
> a better idea.
>
> So, here it is:
> $ sudo ./bpftool cgroup tree
> CgroupPath
> ID AttachType AttachFlags Name
> /sys/fs/cgroup/system.slice/systemd-machined.service
> 18 ingress
> 17 egress
> /sys/fs/cgroup/system.slice/systemd-logind.service
> 20 ingress
> 19 egress
> /sys/fs/cgroup/system.slice/systemd-udevd.service
> 16 ingress
> 15 egress
> /sys/fs/cgroup/system.slice/systemd-journald.service
> 14 ingress
> 13 egress
>
> Signed-off-by: Roman Gushchin <guro@fb.com>
> Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
> Cc: Quentin Monnet <quentin.monnet@netronome.com>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Alexei Starovoitov <ast@kernel.org>
Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
^ permalink raw reply
* Re: [PATCH bpf-next 1/2] bpftool: introduce cgroup tree command
From: Jakub Kicinski @ 2018-07-06 21:03 UTC (permalink / raw)
To: Roman Gushchin
Cc: netdev, linux-kernel, kernel-team, Quentin Monnet,
Daniel Borkmann, Alexei Starovoitov, David Ahern
In-Reply-To: <20180706182542.GA27167@castle.DHCP.thefacebook.com>
On Fri, 6 Jul 2018 11:25:45 -0700, Roman Gushchin wrote:
> > Looks very useful! Minor nits/questions below. I think the reverse
> > mapping could also be interesting - similar to how -f flag shows where
> > program is pinned, we could add a flag which in
> >
> > # bpftool prog show/list
> >
> > adds info about cgroups where the program is attached? Obviously as a
> > future extension.
>
> Well, it would be convenient, but it's not always possible.
> A program can be attached to a dying cgroup (a cgroup which was deleted
> by a user, but still has some associated resources, e.g. pagecache).
Ack, the bpffs and cgroupfs searches are best effort by definition.
Thanks for addressing the other comments!
^ permalink raw reply
* Re: [PATCH v1 net-next 9/9] lan743x: Add PTP support
From: kbuild test robot @ 2018-07-06 21:07 UTC (permalink / raw)
To: Bryan Whitehead; +Cc: kbuild-all, davem, netdev, UNGLinuxDriver
In-Reply-To: <1530808766-13973-10-git-send-email-Bryan.Whitehead@microchip.com>
[-- Attachment #1: Type: text/plain, Size: 907 bytes --]
Hi Bryan,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Bryan-Whitehead/lan743x-Add-features-to-lan743x-driver/20180706-051812
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
>> ERROR: "__moddi3" [drivers/net/ethernet/microchip/lan743x.ko] undefined!
>> ERROR: "__udivdi3" [drivers/net/ethernet/microchip/lan743x.ko] undefined!
>> ERROR: "__umoddi3" [drivers/net/ethernet/microchip/lan743x.ko] undefined!
>> ERROR: "__divdi3" [drivers/net/ethernet/microchip/lan743x.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 64129 bytes --]
^ permalink raw reply
* Fw: [Bug 200187] New: UBSAN: Undefined behaviour in net/sunrpc/xprt.c:568
From: Stephen Hemminger @ 2018-07-06 21:21 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Fri, 22 Jun 2018 15:09:48 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 200187] New: UBSAN: Undefined behaviour in net/sunrpc/xprt.c:568
https://bugzilla.kernel.org/show_bug.cgi?id=200187
Bug ID: 200187
Summary: UBSAN: Undefined behaviour in net/sunrpc/xprt.c:568
Product: Networking
Version: 2.5
Kernel Version: v4.18-rc2
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
Assignee: stephen@networkplumber.org
Reporter: icytxw@gmail.com
Regression: No
It seems like that to->to_retries to large while shift exponent.
if (to->to_exponential)
req->rq_majortimeo <<= to->to_retries;
else
================================================================================
UBSAN: Undefined behaviour in net/sunrpc/xprt.c:568:22
shift exponent 536870976 is too large for 64-bit type 'long unsigned int'
CPU: 0 PID: 21219 Comm: syz-executor1 Not tainted 4.18.0-rc1 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x122/0x1c8 lib/dump_stack.c:113
ubsan_epilogue+0x12/0x86 lib/ubsan.c:159
__ubsan_handle_shift_out_of_bounds+0x29a/0x2ff lib/ubsan.c:425
xprt_reset_majortimeo+0x323/0x440 net/sunrpc/xprt.c:568
xprt_request_init+0x4d2/0x730 net/sunrpc/xprt.c:1330
call_reserveresult+0x9d/0x240 net/sunrpc/clnt.c:1549
__rpc_execute+0x23a/0xc20 net/sunrpc/sched.c:784
rpc_execute+0xf5/0x250 net/sunrpc/sched.c:852
rpc_run_task+0x4a1/0x9f0 net/sunrpc/clnt.c:1053
rpc_call_sync+0xcf/0x1a0 net/sunrpc/clnt.c:1082
rpc_ping+0xde/0x140 net/sunrpc/clnt.c:2514
rpc_create_xprt+0x1e8/0x590 net/sunrpc/clnt.c:479
rpc_create+0x3a9/0x600 net/sunrpc/clnt.c:587
nfs_create_rpc_client+0x3a1/0x4d0 fs/nfs/client.c:523
nfs_init_client+0x7b/0x100 fs/nfs/client.c:634
nfs_get_client+0xa74/0x1440 fs/nfs/client.c:425
nfs_init_server+0x236/0xdf0 fs/nfs/client.c:670
nfs_create_server+0x9a/0x750 fs/nfs/client.c:953
nfs_try_mount+0x270/0xaf0 fs/nfs/super.c:1884
nfs_fs_mount+0x151f/0x30e0 fs/nfs/super.c:2695
mount_fs+0xaf/0x330 fs/super.c:1277
vfs_kern_mount+0xfc/0x4d0 fs/namespace.c:1037
do_new_mount fs/namespace.c:2518 [inline]
do_mount+0x46f/0x2fa0 fs/namespace.c:2848
ksys_mount+0xb0/0x120 fs/namespace.c:3064
__do_sys_mount fs/namespace.c:3078 [inline]
__se_sys_mount fs/namespace.c:3075 [inline]
__x64_sys_mount+0xcc/0x170 fs/namespace.c:3075
do_syscall_64+0xb8/0x3a0 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x455a09
Code: 1d ba fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83
eb b9 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f11c724ac68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007f11c724b6d4 RCX: 0000000000455a09
RDX: 00000000200001c0 RSI: 0000000020000100 RDI: 0000000020000200
RBP: 000000000072bea0 R08: 0000000020000180 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000000004d1 R14: 00000000006fc438 R15: 0000000000000000
================================================================================
rpcbind: RPC call returned error 22
rpcbind: RPC call returned error 22
rpcbind: RPC call returned error 22
rpcbind: RPC call returned error 22
rpcbind: RPC call returned error 22
FAT-fs (loop1): bogus number of reserved sectors
FAT-fs (loop1): Can't find a valid FAT filesystem
FAT-fs (loop1): bogus number of reserved sectors
FAT-fs (loop1): Can't find a valid FAT filesystem
FAT-fs (loop1): bogus number of reserved sectors
FAT-fs (loop1): Can't find a valid FAT filesystem
FAT-fs (loop1): bogus number of reserved sectors
FAT-fs (loop1): Can't find a valid FAT filesystem
FAT-fs (loop1): bogus number of reserved sectors
FAT-fs (loop1): Can't find a valid FAT filesystem
EXT4-fs (sda): re-mounted. Opts:
EXT4-fs (sda): re-mounted. Opts:
EXT4-fs (sda): re-mounted. Opts:
EXT4-fs (sda): re-mounted. Opts:
EXT4-fs (sda): re-mounted. Opts:
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Fw: [Bug 200195] New: [Regression] Network does not come back after suspend
From: Stephen Hemminger @ 2018-07-06 21:23 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Fri, 22 Jun 2018 18:04:00 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 200195] New: [Regression] Network does not come back after suspend
https://bugzilla.kernel.org/show_bug.cgi?id=200195
Bug ID: 200195
Summary: [Regression] Network does not come back after suspend
Product: Networking
Version: 2.5
Kernel Version: 4.17.2
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
Assignee: stephen@networkplumber.org
Reporter: aacid@kde.org
Regression: No
Created attachment 276753
--> https://bugzilla.kernel.org/attachment.cgi?id=276753&action=edit
lspci -vvv output
Setup:
* Using Archlinux
* Using wired network
Only difference is using kernel 4.17.2 vs kernel 4.16.13
When using 4.17.2, the network does not work after resuming from suspend. With
4.16.13 it works as expected.
My guess is that this is driver/hardware dependent since i have another machine
with the same setup and it does not seem to have that regression.
I'm attaching the lspci output of 4.16.13.
Anything else I can provide or test to pinpoint where the regression happened
please do not hesitate to ask.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Fw: [Bug 200215] New: UBSAN: Undefined behaviour in net/core/sock.c:LINE
From: Stephen Hemminger @ 2018-07-06 21:24 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Sat, 23 Jun 2018 00:00:25 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 200215] New: UBSAN: Undefined behaviour in net/core/sock.c:LINE
https://bugzilla.kernel.org/show_bug.cgi?id=200215
Bug ID: 200215
Summary: UBSAN: Undefined behaviour in net/core/sock.c:LINE
Product: Networking
Version: 2.5
Kernel Version: v4.18-rc2
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
Assignee: stephen@networkplumber.org
Reporter: icytxw@gmail.com
Regression: No
Hi,
This bug was found in Linux Kernel v4.18-rc2
$ cat report4
================================================================================
UBSAN: Undefined behaviour in net/core/sock.c:793:19
signed integer overflow:
-1704733899 * 2 cannot be represented in type 'int'
CPU: 0 PID: 5695 Comm: syz-executor1 Not tainted 4.18.0-rc1 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x122/0x1c8 lib/dump_stack.c:113
ubsan_epilogue+0x12/0x86 lib/ubsan.c:159
handle_overflow+0x1c2/0x21f lib/ubsan.c:190
__ubsan_handle_mul_overflow+0x2a/0x38 lib/ubsan.c:214
sock_setsockopt+0x17f1/0x1c80 net/core/sock.c:793
__sys_setsockopt+0x23f/0x2a0 net/socket.c:1943
__do_sys_setsockopt net/socket.c:1958 [inline]
__se_sys_setsockopt net/socket.c:1955 [inline]
__x64_sys_setsockopt+0xcc/0x170 net/socket.c:1955
do_syscall_64+0xb8/0x3a0 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x455a09
Code: 1d ba fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83
eb b9 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fb211862c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00007fb2118636d4 RCX: 0000000000455a09
RDX: 0000000000000021 RSI: 0000000000000001 RDI: 0000000000000013
RBP: 000000000072bea0 R08: 0000000000000004 R09: 0000000000000000
R10: 0000000020000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000000006dc R14: 00000000006ff540 R15: 0000000000000000
================================================================================
sr 1:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sr 1:0:0:0: [sr0] tag#0 Sense Key : Not Ready [current]
sr 1:0:0:0: [sr0] tag#0 Add. Sense: Medium not present
sr 1:0:0:0: [sr0] tag#0 CDB: Read(10) 28 00 00 00 00 00 00 00 40 00
print_req_error: I/O error, dev sr0, sector 0
sr 1:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sr 1:0:0:0: [sr0] tag#0 Sense Key : Not Ready [current]
sr 1:0:0:0: [sr0] tag#0 Add. Sense: Medium not present
sr 1:0:0:0: [sr0] tag#0 CDB: Read(10) 28 00 00 00 00 40 00 00 40 00
print_req_error: I/O error, dev sr0, sector 256
sr 1:0:0:0: [sr0] unaligned transfer
sr 1:0:0:0: [sr0] unaligned transfer
sr 1:0:0:0: [sr0] unaligned transfer
sr 1:0:0:0: [sr0] unaligned transfer
sr 1:0:0:0: [sr0] unaligned transfer
sr 1:0:0:0: [sr0] unaligned transfer
sr 1:0:0:0: [sr0] unaligned transfer
sr 1:0:0:0: [sr0] unaligned transfer
sr 1:0:0:0: [sr0] unaligned transfer
sr 1:0:0:0: [sr0] unaligned transfer
sr 1:0:0:0: [sr0] unaligned transfer
sr 1:0:0:0: [sr0] unaligned transfer
sr 1:0:0:0: [sr0] unaligned transfer
sr 1:0:0:0: [sr0] unaligned transfer
sr 1:0:0:0: [sr0] unaligned transfer
sr 1:0:0:0: [sr0] unaligned transfer
sr 1:0:0:0: [sr0] unaligned transfer
sr 1:0:0:0: [sr0] unaligned transfer
sr 1:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sr 1:0:0:0: [sr0] tag#0 Sense Key : Illegal Request [current]
sr 1:0:0:0: [sr0] tag#0 Add. Sense: Invalid command operation code
sr 1:0:0:0: [sr0] tag#0 CDB: Write(10) 2a 00 00 00 00 00 00 00 02 00
print_req_error: critical target error, dev sr0, sector 0
Buffer I/O error on dev sr0, logical block 0, lost async page write
Buffer I/O error on dev sr0, logical block 1, lost async page write
Buffer I/O error on dev sr0, logical block 2, lost async page write
Buffer I/O error on dev sr0, logical block 3, lost async page write
Buffer I/O error on dev sr0, logical block 4, lost async page write
Buffer I/O error on dev sr0, logical block 5, lost async page write
Buffer I/O error on dev sr0, logical block 6, lost async page write
Buffer I/O error on dev sr0, logical block 7, lost async page write
This bug can be repro, if you need it, please tell me.
Thanks,
Icytxw
--
You are receiving this mail because:
You are the assignee for the bug.
^ 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