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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ