Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

-Wimplicit-function-declaration of current_thread_info #1048

Closed
nickdesaulniers opened this issue Jun 9, 2020 · 3 comments
Closed

-Wimplicit-function-declaration of current_thread_info #1048

nickdesaulniers opened this issue Jun 9, 2020 · 3 comments
Labels
[ARCH] risc-v This bug impacts ARCH=riscv [BUG] linux-next This is an issue only seen in linux-next [FIXED][LINUX] development cycle This bug was only present and fixed in a -next or -rc cycle

Comments

@nickdesaulniers
Copy link
Member

via last night's linux-next: https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/346493536

In file included from arch/riscv/kernel/asm-offsets.c:10:
In file included from ./include/linux/sched.h:14:
In file included from ./include/linux/pid.h:6:
In file included from ./include/linux/wait.h:9:
In file included from ./include/linux/spinlock.h:60:
In file included from ./arch/riscv/include/asm/mmiowb.h:13:
./include/asm-generic/mmiowb.h:37:28: error: implicit declaration of function 'current_thread_info' [-Werror,-Wimplicit-function-declaration]
        struct mmiowb_state *ms = __mmiowb_state();
                                  ^
./include/asm-generic/mmiowb.h:30:26: note: expanded from macro '__mmiowb_state'
#define __mmiowb_state()        this_cpu_ptr(&__mmiowb_state)
                                ^
./include/linux/percpu-defs.h:252:27: note: expanded from macro 'this_cpu_ptr'
#define this_cpu_ptr(ptr) raw_cpu_ptr(ptr)
                          ^
./include/linux/percpu-defs.h:242:2: note: expanded from macro 'raw_cpu_ptr'
        arch_raw_cpu_ptr(ptr);                                          \
        ^
./include/asm-generic/percpu.h:44:53: note: expanded from macro 'arch_raw_cpu_ptr'
#define arch_raw_cpu_ptr(ptr) SHIFT_PERCPU_PTR(ptr, __my_cpu_offset)
                                                    ^
./include/asm-generic/percpu.h:31:40: note: expanded from macro '__my_cpu_offset'
#define __my_cpu_offset per_cpu_offset(raw_smp_processor_id())
                                       ^
./arch/riscv/include/asm/smp.h:47:33: note: expanded from macro 'raw_smp_processor_id'
#define raw_smp_processor_id() (current_thread_info()->cpu)
                                ^
@nickdesaulniers nickdesaulniers added [ARCH] risc-v This bug impacts ARCH=riscv [BUG] linux-next This is an issue only seen in linux-next labels Jun 9, 2020
@nickdesaulniers
Copy link
Member Author

@palmer-dabbelt mentions this may already be fixed.

@palmer-dabbelt
Copy link

This was the one I actually saw first in my make, so it's definitely fixed. The other two smell like they'd come from the same issue. It took a bit to track down because we had a breakage in Linus', as of 084623e ("Merge tag 'modules-for-v5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux") it should build (my for-next is now on top of that).

@nathanchance
Copy link
Member

Long been fixed.

@nathanchance nathanchance added the [FIXED][LINUX] development cycle This bug was only present and fixed in a -next or -rc cycle label Aug 26, 2020
nathanchance pushed a commit that referenced this issue Jan 22, 2021
Wolfram reports that his R-Car H2-based Lager board can no longer be
rebooted in v5.11-rc1, as it crashes with an imprecise external abort.
The issue can be reproduced on other boards (e.g. Koelsch with R-Car
M2-W) too, if CONFIG_IP_PNP is disabled, and the Ethernet interface is
down at reboot time:

    Unhandled fault: imprecise external abort (0x1406) at 0x00000000
    pgd = (ptrval)
    [00000000] *pgd=422b6835, *pte=00000000, *ppte=00000000
    Internal error: : 1406 [#1] ARM
    Modules linked in:
    CPU: 0 PID: 1105 Comm: init Tainted: G        W         5.10.0-rc1-00402-ge2f016cf7751 #1048
    Hardware name: Generic R-Car Gen2 (Flattened Device Tree)
    PC is at sh_mdio_ctrl+0x44/0x60
    LR is at sh_mmd_ctrl+0x20/0x24
    ...
    Backtrace:
    [<c0451f30>] (sh_mdio_ctrl) from [<c0451fd4>] (sh_mmd_ctrl+0x20/0x24)
     r7:0000001f r6:00000020 r5:00000002 r4:c22a1dc4
    [<c0451fb4>] (sh_mmd_ctrl) from [<c044fc18>] (mdiobb_cmd+0x38/0xa8)
    [<c044fbe0>] (mdiobb_cmd) from [<c044feb8>] (mdiobb_read+0x58/0xdc)
     r9:c229f844 r8:c0c329dc r7:c221e000 r6:00000001 r5:c22a1dc4 r4:00000001
    [<c044fe60>] (mdiobb_read) from [<c044c854>] (__mdiobus_read+0x74/0xe0)
     r7:0000001f r6:00000001 r5:c221e000 r4:c221e000
    [<c044c7e0>] (__mdiobus_read) from [<c044c9d8>] (mdiobus_read+0x40/0x54)
     r7:0000001f r6:00000001 r5:c221e000 r4:c221e458
    [<c044c998>] (mdiobus_read) from [<c044d678>] (phy_read+0x1c/0x20)
     r7:ffffe000 r6:c221e470 r5:00000200 r4:c229f800
    [<c044d65c>] (phy_read) from [<c044d94c>] (kszphy_config_intr+0x44/0x80)
    [<c044d908>] (kszphy_config_intr) from [<c044694c>] (phy_disable_interrupts+0x44/0x50)
     r5:c229f800 r4:c229f800
    [<c0446908>] (phy_disable_interrupts) from [<c0449370>] (phy_shutdown+0x18/0x1c)
     r5:c229f800 r4:c229f804
    [<c0449358>] (phy_shutdown) from [<c040066c>] (device_shutdown+0x168/0x1f8)
    [<c0400504>] (device_shutdown) from [<c013de44>] (kernel_restart_prepare+0x3c/0x48)
     r9:c22d2000 r8:c0100264 r7:c0b0d034 r6:00000000 r5:4321fedc r4:00000000
    [<c013de08>] (kernel_restart_prepare) from [<c013dee0>] (kernel_restart+0x1c/0x60)
    [<c013dec4>] (kernel_restart) from [<c013e1d8>] (__do_sys_reboot+0x168/0x208)
     r5:4321fedc r4:01234567
    [<c013e070>] (__do_sys_reboot) from [<c013e2e8>] (sys_reboot+0x18/0x1c)
     r7:00000058 r6:00000000 r5:00000000 r4:00000000
    [<c013e2d0>] (sys_reboot) from [<c0100060>] (ret_fast_syscall+0x0/0x54)

As of commit e2f016c ("net: phy: add a shutdown procedure"),
system reboot calls phy_disable_interrupts() during shutdown.  As this
happens unconditionally, the PHY registers may be accessed while the
device is suspended, causing undefined behavior, which may crash the
system.

Fix this by wrapping the PHY bitbang accessors in the sh_eth driver by
wrappers that take care of Runtime PM, to resume the device when needed.

Reported-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[ARCH] risc-v This bug impacts ARCH=riscv [BUG] linux-next This is an issue only seen in linux-next [FIXED][LINUX] development cycle This bug was only present and fixed in a -next or -rc cycle
Projects
None yet
Development

No branches or pull requests

3 participants