| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <OSAPR01MB3089DFDA4E10E40537968A7DD81E0@OSAPR01MB3089.jpnprd01.prod.outlook.com>
Date: Tue, 28 May 2019 02:33:58 +0000
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>
To: Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-renesas-soc@...r.kernel.org"
<linux-renesas-soc@...r.kernel.org>,
"davem@...emloft.net" <davem@...emloft.net>
Subject: RE: [PATCH] net: sh_eth: fix mdio access in sh_eth_close() for some
SoCs
Hi Sergei-san,
> From: Sergei Shtylyov, Sent: Sunday, May 26, 2019 3:06 AM
>
> Hello!
>
> On 05/20/2019 10:42 AM, Yoshihiro Shimoda wrote:
>
> > Thank you for the reply! And, I'm sorry for the delayed response because I had days off in last week.
>
> And sorry for my delayed reply as well!
>
> >> It's not "some SoCs", it's only R-Car gen2 and RZ/G1 SoCs.
> >
> > Do you prefer the subject "net: sh_eth: fix mdio access in sh_eth_close() for R-Car gen2 and RZ/G1 SoCs"
> > instead of "... some SoCs"?
>
> Yes, it's just about a single SoC family as the driver knows them, really: R-Car gen2;
> RZ/G1 uses the same SoC data.
I got it.
> >>> The sh_eth_close() resets the MAC and then calls phy_stop()
> >>> so that mdio read access result is incorrect without any error
> >>> according to kernel trace like below:
> >>>
> >>> ifconfig-216 [003] .n.. 109.133124: mdio_access: ee700000.ethernet-ffffffff read phy:0x01 reg:0x00 val:0xffff
> >>
> >> Not sure how RMII mode affects the MDIO transfers...
> >
> > I should have described what happen on the previous code.
> > According to the hardware manual, the RMII mode should be set to 1 before
> > operation the Ethernet MAC. The MDIO transferring is one of the Ethernet MAC operation.
> > So, I assumed this RMII mode affects the MDIO transfers.
> >
> > By the way, I also should have described what happen on the previous code.
> > If I input the following command on non-NFS rootfs environment (e.g. USB memory rootfs),
> > sometimes, a lot of FCD interruption happened and then the following "rcu "error happened.
> > ---
> > # ifconfig eth0 down# ifconfig eth0 up
> > [ 794.545823] Micrel KSZ8041RNLI ee700000.ethernet-ffffffff:01: attached PHY driver [Micrel KSZ8041RNLI]
> (mii_bus:phy_addr=ee700000.ethernet-ffffffff:01, irq=157)
> > # ifconfig eth0 up# ifconfig eth0 down
> > # ifconfig eth0 down# ifconfig eth0 up
> > [ 797.662138] Micrel KSZ8041RNLI ee700000.ethernet-ffffffff:01: attached PHY driver [Micrel KSZ8041RNLI]
> (mii_bus:phy_addr=ee700000.ethernet-ffffffff:01, irq=157)
> > [ 797.689158] sh-eth ee700000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
> > [ 797.702631] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> > # [ 818.759628] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
> > [ 818.770827] rcu: 0-....: (2 GPs behind) idle=d12/0/0x3 softirq=388/388 fqs=1051
> > [ 818.783635] rcu: (detected by 1, t=2104 jiffies, g=377, q=18)
> > [ 818.794848] Sending NMI from CPU 1 to CPUs 0:
> > [ 818.804733] NMI backtrace for cpu 0
> > [ 818.804736] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.1.0-00002-g192664e-dirty #27
> > [ 818.804738] Hardware name: Generic R-Car Gen2 (Flattened Device Tree)
> > [ 818.804740] PC is at __do_softirq+0x7c/0x344
> > [ 818.804742] LR is at irq_exit+0x6c/0xcc
> > [ 818.804744] pc : [<c01021e4>] lr : [<c0126aa0>] psr: 60030113
> > [ 818.804746] sp : c0d01eb8 ip : 00200102 fp : c0d03080
> > [ 818.804748] r10: 00000001 r9 : 0000000a r8 : c0ca2940
> > [ 818.804750] r7 : 00000004 r6 : c0ca2934 r5 : 00000000 r4 : ffffe000
> > [ 818.804752] r3 : c0ca2940 r2 : 2aaa8000 r1 : 00000000 r0 : 2aaa8000
> > [ 818.804754] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> > [ 818.804756] Control: 10c5387d Table: 6a5f006a DAC: 00000051
> > [ 818.804758] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.1.0-00002-g192664e-dirty #27
> > [ 818.804760] Hardware name: Generic R-Car Gen2 (Flattened Device Tree)
> > [ 818.804762] [<c011049c>] (unwind_backtrace) from [<c010bc0c>] (show_stack+0x18/0x1c)
> > [ 818.804764] [<c010bc0c>] (show_stack) from [<c07f7458>] (dump_stack+0x7c/0x9c)
> > [ 818.804766] [<c07f7458>] (dump_stack) from [<c07fd358>] (nmi_cpu_backtrace+0x98/0xb8)
> > [ 818.804768] [<c07fd358>] (nmi_cpu_backtrace) from [<c010e6bc>] (handle_IPI+0x2bc/0x33c)
> > [ 818.804770] [<c010e6bc>] (handle_IPI) from [<c03fa084>] (gic_handle_irq+0x8c/0x98)
> > [ 818.804773] [<c03fa084>] (gic_handle_irq) from [<c0101a8c>] (__irq_svc+0x6c/0x90)
> > [ 818.804774] Exception stack(0xc0d01e68 to 0xc0d01eb0)
> > [ 818.804777] 1e60: 2aaa8000 00000000 2aaa8000 c0ca2940 ffffe000 00000000
> > [ 818.804779] 1e80: c0ca2934 00000004 c0ca2940 0000000a 00000001 c0d03080 00200102 c0d01eb8
> > [ 818.804781] 1ea0: c0126aa0 c01021e4 60030113 ffffffff
> > [ 818.804783] [<c0101a8c>] (__irq_svc) from [<c01021e4>] (__do_softirq+0x7c/0x344)
> > [ 818.804785] [<c01021e4>] (__do_softirq) from [<c0126aa0>] (irq_exit+0x6c/0xcc)
> > [ 818.804787] [<c0126aa0>] (irq_exit) from [<c016c344>] (__handle_domain_irq+0x88/0xbc)
> > [ 818.804789] [<c016c344>] (__handle_domain_irq) from [<c03fa058>] (gic_handle_irq+0x60/0x98)
> > [ 818.804791] [<c03fa058>] (gic_handle_irq) from [<c0101a8c>] (__irq_svc+0x6c/0x90)
> > [ 818.804793] Exception stack(0xc0d01f38 to 0xc0d01f80)
> > [ 818.804795] 1f20: 00000000 0008bbb8
> > [ 818.804798] 1f40: eb74b520 c011aee0 00000001 ffffe000 c0d08c30 c0d8e5be c0d08c74 c0d980c0
> > [ 818.804800] 1f60: 00000001 c0c5ea40 00000000 c0d01f88 c01084ec c014c85c 60030013 ffffffff
> > [ 818.804802] [<c0101a8c>] (__irq_svc) from [<c014c85c>] (do_idle+0xf0/0x13c)
> > [ 818.804804] [<c014c85c>] (do_idle) from [<c014cb10>] (cpu_startup_entry+0x20/0x24)
> > [ 818.804806] [<c014cb10>] (cpu_startup_entry) from [<c0c00fac>] (start_kernel+0x3e0/0x488)
>
> This *usually* means a register is accessed while the clock is off...
I see..
> > Note:
> > - After I input the second ifconfig eth0 up, I cannot input any command.
> > - If I disconnect an ethernet cable, I can input command again.
>
> Hm...
>
> > ---
> >
> >>> To fix the issue, this patch adds a condition and set the RMII mode
> >>> regiseter in sh_eth_dev_exit() for some SoCs.
>
> Register.
Oops. I'll fix it.
<snip>
> >>> diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
> >>> index e33af37..106ae90 100644
> >>> --- a/drivers/net/ethernet/renesas/sh_eth.c
> >>> +++ b/drivers/net/ethernet/renesas/sh_eth.c
> >>> @@ -1596,6 +1596,10 @@ static void sh_eth_dev_exit(struct net_device *ndev)
> >>>
> >>> /* Set MAC address again */
> >>> update_mac_address(ndev);
> >>> +
> >>> + /* Set the mode again if required */
> >>
> >> Should be "RMII mode", n ot just "Mode". We prolly need more detailed explanation...
> >
> > I got it.
>
> Your fix seems legit now, just misplaced a bit...
Thank you for your comment! I'll move the RMIIMODE setting before calls update_mac_address().
> >>> + if (mdp->cd->rmiimode)
> >>> + sh_eth_write(ndev, 0x1, RMIIMODE);
>
> According to the gen2 manual, this register should be written right after the soft reset
> via EDMR.
I got it.
Best regards,
Yoshihiro Shimoda
> >>> }
> >>>
> >>> static void sh_eth_rx_csum(struct sk_buff *skb)
>
> MBR, Sergei
Powered by blists - more mailing lists