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.

Sign up for GitHub

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

Jump to bottom

-Wunneeded-internal-declaration in drivers/mfd/cros_ec_dev.c #179

Closed
nathanchance opened this issue Sep 27, 2018 · 3 comments
Closed

-Wunneeded-internal-declaration in drivers/mfd/cros_ec_dev.c #179

nathanchance opened this issue Sep 27, 2018 · 3 comments
Assignees
@nathanchance
Labels
-Wunneeded-internal-declaration [BUG] linux A bug that should be fixed in the mainline kernel. [FIXED][LINUX] 4.20 This bug was fixed in Linux 4.20

Comments

@nathanchance
Copy link
Member 

drivers/mfd/cros_ec_dev.c:509:40: warning: variable 'cros_ec_id' is not needed and will not be emitted [-Wunneeded-internal-declaration]
static const struct platform_device_id cros_ec_id[] = {
                                       ^
1 warning generated.

I think that cros_ec_id should be added to cros_ec_dev_driver with the id_table member. Patch sent under that assumption: https://lore.kernel.org/lkml/20180927033316.9784-1-natechancellor@gmail.com/
@nathanchance nathanchance added [BUG] linux A bug that should be fixed in the mainline kernel. [PATCH] Submitted A patch has been submitted for review -Wunneeded-internal-declaration labels Sep 27, 2018
@nathanchance nathanchance self-assigned this Sep 27, 2018
nathanchance pushed a commit that referenced this issue Oct 5, 2018
@mwbringmann @mpe
powerpc/pseries: Fix unitialized timer reset on migration
8604895 
After migration of a powerpc LPAR, the kernel executes code to
update the system state to reflect new platform characteristics.

Such changes include modifications to device tree properties provided
to the system by PHYP. Property notifications received by the
post_mobility_fixup() code are passed along to the kernel in general
through a call to of_update_property() which in turn passes such
events back to all modules through entries like the '.notifier_call'
function within the NUMA module.

When the NUMA module updates its state, it resets its event timer. If
this occurs after a previous call to stop_topology_update() or on a
system without VPHN enabled, the code runs into an unitialized timer
structure and crashes. This patch adds a safety check along this path
toward the problem code.

An example crash log is as follows.

  ibmvscsi 30000081: Re-enabling adapter!
  ------------[ cut here ]------------
  kernel BUG at kernel/time/timer.c:958!
  Oops: Exception in kernel mode, sig: 5 [#1]
  LE SMP NR_CPUS=2048 NUMA pSeries
  Modules linked in: nfsv3 nfs_acl nfs tcp_diag udp_diag inet_diag lockd unix_diag af_packet_diag netlink_diag grace fscache sunrpc xts vmx_crypto pseries_rng sg binfmt_misc ip_tables xfs libcrc32c sd_mod ibmvscsi ibmveth scsi_transport_srp dm_mirror dm_region_hash dm_log dm_mod
  CPU: 11 PID: 3067 Comm: drmgr Not tainted 4.17.0+ #179
  ...
  NIP mod_timer+0x4c/0x400
  LR  reset_topology_timer+0x40/0x60
  Call Trace:
    0xc0000003f9407830 (unreliable)
    reset_topology_timer+0x40/0x60
    dt_update_callback+0x100/0x120
    notifier_call_chain+0x90/0x100
    __blocking_notifier_call_chain+0x60/0x90
    of_property_notify+0x90/0xd0
    of_update_property+0x104/0x150
    update_dt_property+0xdc/0x1f0
    pseries_devicetree_update+0x2d0/0x510
    post_mobility_fixup+0x7c/0xf0
    migration_store+0xa4/0xc0
    kobj_attr_store+0x30/0x60
    sysfs_kf_write+0x64/0xa0
    kernfs_fop_write+0x16c/0x240
    __vfs_write+0x40/0x200
    vfs_write+0xc8/0x240
    ksys_write+0x5c/0x100
    system_call+0x58/0x6c

Fixes: 5d88aa8 ("powerpc/pseries: Update CPU maps when device tree is updated")
Cc: stable@vger.kernel.org # v3.10+
Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
@nathanchance
Copy link
Member Author

Patch accepted: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git/commit/?id=de6f25ddc4289596c9fbaec91be82d14fff4eeee

@nathanchance nathanchance added [PATCH] Accepted A submitted patch has been accepted upstream and removed [PATCH] Submitted A patch has been submitted for review labels Oct 9, 2018
@nathanchance
Copy link
Member Author

Merged into mainline: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6eb357844373f833f085e63e6c8c026a61568c57

@nathanchance nathanchance added [FIXED][LINUX] 4.20 This bug was fixed in Linux 4.20 and removed [PATCH] Accepted A submitted patch has been accepted upstream labels Oct 25, 2018
@nickdesaulniers
Copy link
Member

possibly also fixed on the llvm side by #232

nathanchance pushed a commit that referenced this issue Aug 14, 2020
@stffrdhrn
init: Align init_task to avoid conflict with MUTEX_FLAGS
d0b7213 
When booting on 32-bit machines (seen on OpenRISC) I saw this warning
with CONFIG_DEBUG_MUTEXES turned on.

    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 0 at kernel/locking/mutex.c:1242 __mutex_unlock_slowpath+0x328/0x3ec
    DEBUG_LOCKS_WARN_ON(__owner_task(owner) != current)
    Modules linked in:
    CPU: 0 PID: 0 Comm: swapper Not tainted 5.8.0-rc1-simple-smp-00005-g2864e2171db4-dirty #179
    Call trace:
    [<(ptrval)>] dump_stack+0x34/0x48
    [<(ptrval)>] __warn+0x104/0x158
    [<(ptrval)>] ? __mutex_unlock_slowpath+0x328/0x3ec
    [<(ptrval)>] warn_slowpath_fmt+0x7c/0x94
    [<(ptrval)>] __mutex_unlock_slowpath+0x328/0x3ec
    [<(ptrval)>] mutex_unlock+0x18/0x28
    [<(ptrval)>] __cpuhp_setup_state_cpuslocked.part.0+0x29c/0x2f4
    [<(ptrval)>] ? page_alloc_cpu_dead+0x0/0x30
    [<(ptrval)>] ? start_kernel+0x0/0x684
    [<(ptrval)>] __cpuhp_setup_state+0x4c/0x5c
    [<(ptrval)>] page_alloc_init+0x34/0x68
    [<(ptrval)>] ? start_kernel+0x1a0/0x684
    [<(ptrval)>] ? early_init_dt_scan_nodes+0x60/0x70
    irq event stamp: 0

I traced this to kernel/locking/mutex.c storing 3 bits of MUTEX_FLAGS in
the task_struct pointer (mutex.owner).  There is a comment saying that
task_structs are always aligned to L1_CACHE_BYTES.  This is not true for
the init_task.

On 64-bit machines this is not a problem because symbol addresses are
naturally aligned to 64-bits providing 3 bits for MUTEX_FLAGS.  Howerver,
for 32-bit machines the symbol address only has 2 bits available.

Fix this by setting init_task alignment to at least L1_CACHE_BYTES.

Signed-off-by: Stafford Horne <shorne@gmail.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@nathanchance nathanchance

Labels
-Wunneeded-internal-declaration [BUG] linux A bug that should be fixed in the mainline kernel. [FIXED][LINUX] 4.20 This bug was fixed in Linux 4.20
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@nickdesaulniers @nathanchance