04 Apr, 2020

1 commit

  • Similar to commit 0266d81e9bf5 ("acpi/processor: Prevent cpu hotplug
    deadlock") except this is for acpi_processor_ffh_cstate_probe():

    "The problem is that the work is scheduled on the current CPU from the
    hotplug thread associated with that CPU.

    It's not required to invoke these functions via the workqueue because
    the hotplug thread runs on the target CPU already.

    Check whether current is a per cpu thread pinned on the target CPU and
    invoke the function directly to avoid the workqueue."

    WARNING: possible circular locking dependency detected
    ------------------------------------------------------
    cpuhp/1/15 is trying to acquire lock:
    ffffc90003447a28 ((work_completion)(&wfc.work)){+.+.}-{0:0}, at: __flush_work+0x4c6/0x630

    but task is already holding lock:
    ffffffffafa1c0e8 (cpuidle_lock){+.+.}-{3:3}, at: cpuidle_pause_and_lock+0x17/0x20

    which lock already depends on the new lock.

    the existing dependency chain (in reverse order) is:

    -> #1 (cpu_hotplug_lock){++++}-{0:0}:
    cpus_read_lock+0x3e/0xc0
    irq_calc_affinity_vectors+0x5f/0x91
    __pci_enable_msix_range+0x10f/0x9a0
    pci_alloc_irq_vectors_affinity+0x13e/0x1f0
    pci_alloc_irq_vectors_affinity at drivers/pci/msi.c:1208
    pqi_ctrl_init+0x72f/0x1618 [smartpqi]
    pqi_pci_probe.cold.63+0x882/0x892 [smartpqi]
    local_pci_probe+0x7a/0xc0
    work_for_cpu_fn+0x2e/0x50
    process_one_work+0x57e/0xb90
    worker_thread+0x363/0x5b0
    kthread+0x1f4/0x220
    ret_from_fork+0x27/0x50

    -> #0 ((work_completion)(&wfc.work)){+.+.}-{0:0}:
    __lock_acquire+0x2244/0x32a0
    lock_acquire+0x1a2/0x680
    __flush_work+0x4e6/0x630
    work_on_cpu+0x114/0x160
    acpi_processor_ffh_cstate_probe+0x129/0x250
    acpi_processor_evaluate_cst+0x4c8/0x580
    acpi_processor_get_power_info+0x86/0x740
    acpi_processor_hotplug+0xc3/0x140
    acpi_soft_cpu_online+0x102/0x1d0
    cpuhp_invoke_callback+0x197/0x1120
    cpuhp_thread_fun+0x252/0x2f0
    smpboot_thread_fn+0x255/0x440
    kthread+0x1f4/0x220
    ret_from_fork+0x27/0x50

    other info that might help us debug this:

    Chain exists of:
    (work_completion)(&wfc.work) --> cpuhp_state-up --> cpuidle_lock

    Possible unsafe locking scenario:

    CPU0 CPU1
    ---- ----
    lock(cpuidle_lock);
    lock(cpuhp_state-up);
    lock(cpuidle_lock);
    lock((work_completion)(&wfc.work));

    *** DEADLOCK ***

    3 locks held by cpuhp/1/15:
    #0: ffffffffaf51ab10 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x69/0x2f0
    #1: ffffffffaf51ad40 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x69/0x2f0
    #2: ffffffffafa1c0e8 (cpuidle_lock){+.+.}-{3:3}, at: cpuidle_pause_and_lock+0x17/0x20

    Call Trace:
    dump_stack+0xa0/0xea
    print_circular_bug.cold.52+0x147/0x14c
    check_noncircular+0x295/0x2d0
    __lock_acquire+0x2244/0x32a0
    lock_acquire+0x1a2/0x680
    __flush_work+0x4e6/0x630
    work_on_cpu+0x114/0x160
    acpi_processor_ffh_cstate_probe+0x129/0x250
    acpi_processor_evaluate_cst+0x4c8/0x580
    acpi_processor_get_power_info+0x86/0x740
    acpi_processor_hotplug+0xc3/0x140
    acpi_soft_cpu_online+0x102/0x1d0
    cpuhp_invoke_callback+0x197/0x1120
    cpuhp_thread_fun+0x252/0x2f0
    smpboot_thread_fn+0x255/0x440
    kthread+0x1f4/0x220
    ret_from_fork+0x27/0x50

    Signed-off-by: Qian Cai
    Tested-by: Borislav Petkov
    [ rjw: Subject ]
    Signed-off-by: Rafael J. Wysocki

    Qian Cai
     

31 May, 2019

1 commit

  • Based on 3 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version this program is distributed in the
    hope that it will be useful but without any warranty without even
    the implied warranty of merchantability or fitness for a particular
    purpose see the gnu general public license for more details

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version [author] [kishon] [vijay] [abraham]
    [i] [kishon]@[ti] [com] this program is distributed in the hope that
    it will be useful but without any warranty without even the implied
    warranty of merchantability or fitness for a particular purpose see
    the gnu general public license for more details

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version [author] [graeme] [gregory]
    [gg]@[slimlogic] [co] [uk] [author] [kishon] [vijay] [abraham] [i]
    [kishon]@[ti] [com] [based] [on] [twl6030]_[usb] [c] [author] [hema]
    [hk] [hemahk]@[ti] [com] this program is distributed in the hope
    that it will be useful but without any warranty without even the
    implied warranty of merchantability or fitness for a particular
    purpose see the gnu general public license for more details

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 1105 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Reviewed-by: Richard Fontana
    Reviewed-by: Kate Stewart
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190527070033.202006027@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

13 Jun, 2018

1 commit

  • The kmalloc() function has a 2-factor argument form, kmalloc_array(). This
    patch replaces cases of:

    kmalloc(a * b, gfp)

    with:
    kmalloc_array(a * b, gfp)

    as well as handling cases of:

    kmalloc(a * b * c, gfp)

    with:

    kmalloc(array3_size(a, b, c), gfp)

    as it's slightly less ugly than:

    kmalloc_array(array_size(a, b), c, gfp)

    This does, however, attempt to ignore constant size factors like:

    kmalloc(4 * 1024, gfp)

    though any constants defined via macros get caught up in the conversion.

    Any factors with a sizeof() of "unsigned char", "char", and "u8" were
    dropped, since they're redundant.

    The tools/ directory was manually excluded, since it has its own
    implementation of kmalloc().

    The Coccinelle script used for this was:

    // Fix redundant parens around sizeof().
    @@
    type TYPE;
    expression THING, E;
    @@

    (
    kmalloc(
    - (sizeof(TYPE)) * E
    + sizeof(TYPE) * E
    , ...)
    |
    kmalloc(
    - (sizeof(THING)) * E
    + sizeof(THING) * E
    , ...)
    )

    // Drop single-byte sizes and redundant parens.
    @@
    expression COUNT;
    typedef u8;
    typedef __u8;
    @@

    (
    kmalloc(
    - sizeof(u8) * (COUNT)
    + COUNT
    , ...)
    |
    kmalloc(
    - sizeof(__u8) * (COUNT)
    + COUNT
    , ...)
    |
    kmalloc(
    - sizeof(char) * (COUNT)
    + COUNT
    , ...)
    |
    kmalloc(
    - sizeof(unsigned char) * (COUNT)
    + COUNT
    , ...)
    |
    kmalloc(
    - sizeof(u8) * COUNT
    + COUNT
    , ...)
    |
    kmalloc(
    - sizeof(__u8) * COUNT
    + COUNT
    , ...)
    |
    kmalloc(
    - sizeof(char) * COUNT
    + COUNT
    , ...)
    |
    kmalloc(
    - sizeof(unsigned char) * COUNT
    + COUNT
    , ...)
    )

    // 2-factor product with sizeof(type/expression) and identifier or constant.
    @@
    type TYPE;
    expression THING;
    identifier COUNT_ID;
    constant COUNT_CONST;
    @@

    (
    - kmalloc
    + kmalloc_array
    (
    - sizeof(TYPE) * (COUNT_ID)
    + COUNT_ID, sizeof(TYPE)
    , ...)
    |
    - kmalloc
    + kmalloc_array
    (
    - sizeof(TYPE) * COUNT_ID
    + COUNT_ID, sizeof(TYPE)
    , ...)
    |
    - kmalloc
    + kmalloc_array
    (
    - sizeof(TYPE) * (COUNT_CONST)
    + COUNT_CONST, sizeof(TYPE)
    , ...)
    |
    - kmalloc
    + kmalloc_array
    (
    - sizeof(TYPE) * COUNT_CONST
    + COUNT_CONST, sizeof(TYPE)
    , ...)
    |
    - kmalloc
    + kmalloc_array
    (
    - sizeof(THING) * (COUNT_ID)
    + COUNT_ID, sizeof(THING)
    , ...)
    |
    - kmalloc
    + kmalloc_array
    (
    - sizeof(THING) * COUNT_ID
    + COUNT_ID, sizeof(THING)
    , ...)
    |
    - kmalloc
    + kmalloc_array
    (
    - sizeof(THING) * (COUNT_CONST)
    + COUNT_CONST, sizeof(THING)
    , ...)
    |
    - kmalloc
    + kmalloc_array
    (
    - sizeof(THING) * COUNT_CONST
    + COUNT_CONST, sizeof(THING)
    , ...)
    )

    // 2-factor product, only identifiers.
    @@
    identifier SIZE, COUNT;
    @@

    - kmalloc
    + kmalloc_array
    (
    - SIZE * COUNT
    + COUNT, SIZE
    , ...)

    // 3-factor product with 1 sizeof(type) or sizeof(expression), with
    // redundant parens removed.
    @@
    expression THING;
    identifier STRIDE, COUNT;
    type TYPE;
    @@

    (
    kmalloc(
    - sizeof(TYPE) * (COUNT) * (STRIDE)
    + array3_size(COUNT, STRIDE, sizeof(TYPE))
    , ...)
    |
    kmalloc(
    - sizeof(TYPE) * (COUNT) * STRIDE
    + array3_size(COUNT, STRIDE, sizeof(TYPE))
    , ...)
    |
    kmalloc(
    - sizeof(TYPE) * COUNT * (STRIDE)
    + array3_size(COUNT, STRIDE, sizeof(TYPE))
    , ...)
    |
    kmalloc(
    - sizeof(TYPE) * COUNT * STRIDE
    + array3_size(COUNT, STRIDE, sizeof(TYPE))
    , ...)
    |
    kmalloc(
    - sizeof(THING) * (COUNT) * (STRIDE)
    + array3_size(COUNT, STRIDE, sizeof(THING))
    , ...)
    |
    kmalloc(
    - sizeof(THING) * (COUNT) * STRIDE
    + array3_size(COUNT, STRIDE, sizeof(THING))
    , ...)
    |
    kmalloc(
    - sizeof(THING) * COUNT * (STRIDE)
    + array3_size(COUNT, STRIDE, sizeof(THING))
    , ...)
    |
    kmalloc(
    - sizeof(THING) * COUNT * STRIDE
    + array3_size(COUNT, STRIDE, sizeof(THING))
    , ...)
    )

    // 3-factor product with 2 sizeof(variable), with redundant parens removed.
    @@
    expression THING1, THING2;
    identifier COUNT;
    type TYPE1, TYPE2;
    @@

    (
    kmalloc(
    - sizeof(TYPE1) * sizeof(TYPE2) * COUNT
    + array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
    , ...)
    |
    kmalloc(
    - sizeof(TYPE1) * sizeof(THING2) * (COUNT)
    + array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
    , ...)
    |
    kmalloc(
    - sizeof(THING1) * sizeof(THING2) * COUNT
    + array3_size(COUNT, sizeof(THING1), sizeof(THING2))
    , ...)
    |
    kmalloc(
    - sizeof(THING1) * sizeof(THING2) * (COUNT)
    + array3_size(COUNT, sizeof(THING1), sizeof(THING2))
    , ...)
    |
    kmalloc(
    - sizeof(TYPE1) * sizeof(THING2) * COUNT
    + array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
    , ...)
    |
    kmalloc(
    - sizeof(TYPE1) * sizeof(THING2) * (COUNT)
    + array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
    , ...)
    )

    // 3-factor product, only identifiers, with redundant parens removed.
    @@
    identifier STRIDE, SIZE, COUNT;
    @@

    (
    kmalloc(
    - (COUNT) * STRIDE * SIZE
    + array3_size(COUNT, STRIDE, SIZE)
    , ...)
    |
    kmalloc(
    - COUNT * (STRIDE) * SIZE
    + array3_size(COUNT, STRIDE, SIZE)
    , ...)
    |
    kmalloc(
    - COUNT * STRIDE * (SIZE)
    + array3_size(COUNT, STRIDE, SIZE)
    , ...)
    |
    kmalloc(
    - (COUNT) * (STRIDE) * SIZE
    + array3_size(COUNT, STRIDE, SIZE)
    , ...)
    |
    kmalloc(
    - COUNT * (STRIDE) * (SIZE)
    + array3_size(COUNT, STRIDE, SIZE)
    , ...)
    |
    kmalloc(
    - (COUNT) * STRIDE * (SIZE)
    + array3_size(COUNT, STRIDE, SIZE)
    , ...)
    |
    kmalloc(
    - (COUNT) * (STRIDE) * (SIZE)
    + array3_size(COUNT, STRIDE, SIZE)
    , ...)
    |
    kmalloc(
    - COUNT * STRIDE * SIZE
    + array3_size(COUNT, STRIDE, SIZE)
    , ...)
    )

    // Any remaining multi-factor products, first at least 3-factor products,
    // when they're not all constants...
    @@
    expression E1, E2, E3;
    constant C1, C2, C3;
    @@

    (
    kmalloc(C1 * C2 * C3, ...)
    |
    kmalloc(
    - (E1) * E2 * E3
    + array3_size(E1, E2, E3)
    , ...)
    |
    kmalloc(
    - (E1) * (E2) * E3
    + array3_size(E1, E2, E3)
    , ...)
    |
    kmalloc(
    - (E1) * (E2) * (E3)
    + array3_size(E1, E2, E3)
    , ...)
    |
    kmalloc(
    - E1 * E2 * E3
    + array3_size(E1, E2, E3)
    , ...)
    )

    // And then all remaining 2 factors products when they're not all constants,
    // keeping sizeof() as the second factor argument.
    @@
    expression THING, E1, E2;
    type TYPE;
    constant C1, C2, C3;
    @@

    (
    kmalloc(sizeof(THING) * C2, ...)
    |
    kmalloc(sizeof(TYPE) * C2, ...)
    |
    kmalloc(C1 * C2 * C3, ...)
    |
    kmalloc(C1 * C2, ...)
    |
    - kmalloc
    + kmalloc_array
    (
    - sizeof(TYPE) * (E2)
    + E2, sizeof(TYPE)
    , ...)
    |
    - kmalloc
    + kmalloc_array
    (
    - sizeof(TYPE) * E2
    + E2, sizeof(TYPE)
    , ...)
    |
    - kmalloc
    + kmalloc_array
    (
    - sizeof(THING) * (E2)
    + E2, sizeof(THING)
    , ...)
    |
    - kmalloc
    + kmalloc_array
    (
    - sizeof(THING) * E2
    + E2, sizeof(THING)
    , ...)
    |
    - kmalloc
    + kmalloc_array
    (
    - (E1) * E2
    + E1, E2
    , ...)
    |
    - kmalloc
    + kmalloc_array
    (
    - (E1) * (E2)
    + E1, E2
    , ...)
    |
    - kmalloc
    + kmalloc_array
    (
    - E1 * E2
    + E1, E2
    , ...)
    )

    Signed-off-by: Kees Cook

    Kees Cook
     

26 May, 2017

1 commit

  • With the enhanced CPU hotplug lockdep coverage the following lockdep splat
    happens:

    ======================================================
    WARNING: possible circular locking dependency detected
    4.12.0-rc2+ #84 Tainted: G W
    ------------------------------------------------------
    cpuhp/1/15 is trying to acquire lock:
    flush_work+0x39/0x2f0

    but task is already holding lock:
    cpuhp_thread_fun+0x30/0x160

    which lock already depends on the new lock.

    the existing dependency chain (in reverse order) is:

    -> #2 (cpuhp_state){+.+.+.}:
    lock_acquire+0xb4/0x200
    cpuhp_kick_ap_work+0x72/0x330
    _cpu_down+0x8b/0x100
    do_cpu_down+0x3e/0x60
    cpu_down+0x10/0x20
    cpu_subsys_offline+0x14/0x20
    device_offline+0x88/0xb0
    online_store+0x4c/0xa0
    dev_attr_store+0x18/0x30
    sysfs_kf_write+0x45/0x60
    kernfs_fop_write+0x156/0x1e0
    __vfs_write+0x37/0x160
    vfs_write+0xca/0x1c0
    SyS_write+0x58/0xc0
    entry_SYSCALL_64_fastpath+0x23/0xc2

    -> #1 (cpu_hotplug_lock.rw_sem){++++++}:
    lock_acquire+0xb4/0x200
    cpus_read_lock+0x3d/0xb0
    apply_workqueue_attrs+0x17/0x50
    __alloc_workqueue_key+0x1e1/0x530
    scsi_host_alloc+0x373/0x480 [scsi_mod]
    ata_scsi_add_hosts+0xcb/0x130 [libata]
    ata_host_register+0x11a/0x2c0 [libata]
    ata_host_activate+0xf0/0x150 [libata]
    ahci_host_activate+0x13e/0x170 [libahci]
    ahci_init_one+0xa3a/0xd3f [ahci]
    local_pci_probe+0x45/0xa0
    work_for_cpu_fn+0x14/0x20
    process_one_work+0x1f9/0x690
    worker_thread+0x200/0x3d0
    kthread+0x138/0x170
    ret_from_fork+0x31/0x40

    -> #0 ((&wfc.work)){+.+.+.}:
    __lock_acquire+0x11e1/0x13e0
    lock_acquire+0xb4/0x200
    flush_work+0x5c/0x2f0
    work_on_cpu+0xa1/0xd0
    acpi_processor_get_throttling+0x3d/0x50
    acpi_processor_reevaluate_tstate+0x2c/0x50
    acpi_soft_cpu_online+0x69/0xd0
    cpuhp_invoke_callback+0xb4/0x8b0
    cpuhp_up_callbacks+0x36/0xc0
    cpuhp_thread_fun+0x14e/0x160
    smpboot_thread_fn+0x1e8/0x300
    kthread+0x138/0x170
    ret_from_fork+0x31/0x40

    other info that might help us debug this:

    Chain exists of:
    (&wfc.work) --> cpu_hotplug_lock.rw_sem --> cpuhp_state

    Possible unsafe locking scenario:

    CPU0 CPU1
    ---- ----
    lock(cpuhp_state);
    lock(cpu_hotplug_lock.rw_sem);
    lock(cpuhp_state);
    lock((&wfc.work));

    *** DEADLOCK ***

    1 lock held by cpuhp/1/15:
    cpuhp_thread_fun+0x30/0x160

    stack backtrace:
    CPU: 1 PID: 15 Comm: cpuhp/1 Tainted: G W 4.12.0-rc2+ #84
    Hardware name: Supermicro SYS-4048B-TR4FT/X10QBi, BIOS 1.1a 07/29/2015
    Call Trace:
    dump_stack+0x85/0xc4
    print_circular_bug+0x209/0x217
    __lock_acquire+0x11e1/0x13e0
    lock_acquire+0xb4/0x200
    ? lock_acquire+0xb4/0x200
    ? flush_work+0x39/0x2f0
    ? acpi_processor_start+0x50/0x50
    flush_work+0x5c/0x2f0
    ? flush_work+0x39/0x2f0
    ? acpi_processor_start+0x50/0x50
    ? mark_held_locks+0x6d/0x90
    ? queue_work_on+0x56/0x90
    ? trace_hardirqs_on_caller+0x154/0x1c0
    ? trace_hardirqs_on+0xd/0x10
    ? acpi_processor_start+0x50/0x50
    work_on_cpu+0xa1/0xd0
    ? find_worker_executing_work+0x50/0x50
    ? acpi_processor_power_exit+0x70/0x70
    acpi_processor_get_throttling+0x3d/0x50
    acpi_processor_reevaluate_tstate+0x2c/0x50
    acpi_soft_cpu_online+0x69/0xd0
    cpuhp_invoke_callback+0xb4/0x8b0
    ? lock_acquire+0xb4/0x200
    ? padata_replace+0x120/0x120
    cpuhp_up_callbacks+0x36/0xc0
    cpuhp_thread_fun+0x14e/0x160
    smpboot_thread_fn+0x1e8/0x300
    kthread+0x138/0x170
    ? sort_range+0x30/0x30
    ? kthread_create_on_node+0x70/0x70
    ret_from_fork+0x31/0x40

    The problem is that the work is scheduled on the current CPU from the
    hotplug thread associated with that CPU.

    It's not required to invoke these functions via the workqueue because the
    hotplug thread runs on the target CPU already.

    Check whether current is a per cpu thread pinned on the target CPU and
    invoke the function directly to avoid the workqueue.

    Signed-off-by: Thomas Gleixner
    Acked-by: Ingo Molnar
    Cc: Paul E. McKenney
    Cc: Peter Zijlstra
    Cc: Sebastian Siewior
    Cc: "Rafael J. Wysocki"
    Cc: Steven Rostedt
    Cc: linux-acpi@vger.kernel.org
    Cc: Len Brown
    Link: http://lkml.kernel.org/r/20170524081549.620489733@linutronix.de

    Thomas Gleixner
     

15 Apr, 2017

1 commit

  • acpi_processor_get_throttling() requires to invoke the getter function on
    the target CPU. This is achieved by temporarily setting the affinity of the
    calling user space thread to the requested CPU and reset it to the original
    affinity afterwards.

    That's racy vs. CPU hotplug and concurrent affinity settings for that
    thread resulting in code executing on the wrong CPU and overwriting the
    new affinity setting.

    acpi_processor_get_throttling() is invoked in two ways:

    1) The CPU online callback, which is already running on the target CPU and
    obviously protected against hotplug and not affected by affinity
    settings.

    2) The ACPI driver probe function, which is not protected against hotplug
    during modprobe.

    Switch it over to work_on_cpu() and protect the probe function against CPU
    hotplug.

    Signed-off-by: Thomas Gleixner
    Cc: Fenghua Yu
    Cc: Tony Luck
    Cc: Herbert Xu
    Cc: "Rafael J. Wysocki"
    Cc: Peter Zijlstra
    Cc: Benjamin Herrenschmidt
    Cc: Sebastian Siewior
    Cc: Lai Jiangshan
    Cc: linux-acpi@vger.kernel.org
    Cc: Viresh Kumar
    Cc: Michael Ellerman
    Cc: Tejun Heo
    Cc: "David S. Miller"
    Cc: Len Brown
    Link: http://lkml.kernel.org/r/20170412201042.785920903@linutronix.de
    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     

25 Dec, 2016

1 commit


20 Sep, 2016

1 commit


02 Jun, 2016

1 commit

  • Roland Dreier reports that one of his systems cannot boot because of
    the changes made by commit ac212b6980d8 (ACPI / processor: Use common
    hotplug infrastructure).

    The problematic part of it is the request_region() call in
    acpi_processor_get_info() that used to run at module init time before
    the above commit and now it runs much earlier. Unfortunately, the
    region(s) reserved by it fall into a range the PCI subsystem attempts
    to reserve for AHCI IO BARs. As a result, the PCI reservation fails
    and AHCI doesn't work, while previously the PCI reservation would
    be made before acpi_processor_get_info() and it would succeed.

    That request_region() call, however, was overlooked by commit
    ac212b6980d8, as it is not necessary for the enumeration of the
    processors. It only is needed when the ACPI processor driver
    actually attempts to handle them which doesn't happen before
    loading the ACPI processor driver module. Therefore that call
    should have been moved from acpi_processor_get_info() into that
    module.

    Address the problem by moving the request_region() call in question
    out of acpi_processor_get_info() and use the observation that the
    region reserved by it is only needed if the FADT-based CPU
    throttling method is going to be used, which means that it should
    be sufficient to invoke it from acpi_processor_get_throttling_fadt().

    Fixes: ac212b6980d8 (ACPI / processor: Use common hotplug infrastructure)
    Reported-by: Roland Dreier
    Tested-by: Roland Dreier
    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     

08 Jul, 2015

1 commit


27 Feb, 2014

1 commit

  • acpi_processor_set_throttling() uses set_cpus_allowed_ptr() to make
    sure that the (struct acpi_processor)->acpi_processor_set_throttling()
    callback will run on the right CPU. However, the function may be
    called from a worker thread already bound to a different CPU in which
    case that won't work.

    Make acpi_processor_set_throttling() use work_on_cpu() as appropriate
    instead of abusing set_cpus_allowed_ptr().

    Reported-and-tested-by: Jiri Olsa
    Signed-off-by: Lan Tianyu
    Cc: All applicable
    [rjw: Changelog]
    Signed-off-by: Rafael J. Wysocki

    Lan Tianyu
     

07 Dec, 2013

1 commit

  • Replace direct inclusions of , and
    , which are incorrect, with
    inclusions and remove some inclusions of those files that aren't
    necessary.

    First of all, , and
    should not be included directly from any files that are built for
    CONFIG_ACPI unset, because that generally leads to build warnings about
    undefined symbols in !CONFIG_ACPI builds. For CONFIG_ACPI set,
    includes those files and for CONFIG_ACPI unset it
    provides stub ACPI symbols to be used in that case.

    Second, there are ordering dependencies between those files that always
    have to be met. Namely, it is required that be included
    prior to so that the acpi_pci_root declarations the
    latter depends on are always there. And which provides
    basic ACPICA type declarations should always be included prior to any other
    ACPI headers in CONFIG_ACPI builds. That also is taken care of including
    as appropriate.

    Signed-off-by: Lv Zheng
    Cc: Greg Kroah-Hartman
    Cc: Matthew Garrett
    Cc: Tony Luck
    Cc: "H. Peter Anvin"
    Acked-by: Bjorn Helgaas (drivers/pci stuff)
    Acked-by: Konrad Rzeszutek Wilk (Xen stuff)
    Signed-off-by: Rafael J. Wysocki

    Lv Zheng
     

25 Mar, 2013

1 commit

  • This patch fixes following compiler warnings when build via make W=1:

    drivers/acpi/processor_throttling.c: In function ‘acpi_processor_throttling_init’:
    drivers/acpi/processor_throttling.c:216:40: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]

    Signed-off-by: Andy Shevchenko
    Signed-off-by: Rafael J. Wysocki

    Andy Shevchenko
     

31 Mar, 2012

1 commit

  • Using a u64 here creates an endian bug. We store a u32 number in the
    top byte which is a larger number than intended on big endian systems.
    There is no reason to use a 64 bit data type here, I guess it was just
    an oversight.

    I removed the initialization to zero as well. It's needed with a u64
    but with a u32, the variable gets initialized properly inside the call
    to acpi_os_read_port().

    Signed-off-by: Dan Carpenter
    Signed-off-by: Len Brown

    Dan Carpenter
     

02 May, 2011

1 commit

  • Merge reason: Pick up the following two fix commits.

    2be19102b7: x86, NUMA: Fix empty memblk detection in numa_cleanup_meminfo()
    765af22da8: x86-32, NUMA: Fix ACPI NUMA init broken by recent x86-64 change

    Scheduled NUMA init 32/64bit unification changes depend on these.

    Signed-off-by: Tejun Heo

    Tejun Heo
     

31 Mar, 2011

1 commit


29 Mar, 2011

1 commit


12 Jan, 2011

1 commit


11 Jan, 2011

2 commits


14 Dec, 2010

1 commit

  • Remove deprecated ACPI process procfs I/F for throttling control.

    This is because the t-state control should only be done in kernel,
    when system is in a overheating state.

    Now users can only change the processor t-state indirectly,
    by poking the cooling device sysfs I/F of the processor.

    Signed-off-by: Zhang Rui
    Signed-off-by: Len Brown

    Zhang Rui
     

16 Oct, 2010

1 commit


15 Aug, 2010

1 commit

  • Remove deprecated ACPI processor procfs I/F, including:
    /proc/acpi/processor/CPUX/power
    /proc/acpi/processor/CPUX/limit
    /proc/acpi/processor/CPUX/info

    /proc/acpi/processor/CPUX/throttling still exists,
    as we don't have sysfs I/F available for now.

    Signed-off-by: Zhang Rui
    Signed-off-by: Len Brown

    Zhang Rui
     

30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

15 Mar, 2010

1 commit


16 Feb, 2010

1 commit

  • Dan's list contains:

    drivers/acpi/processor_throttling.c +1139 acpi_processor_get_throttling_info(11) warning: variable derefenced before check 'pr'

    acpi_processor_get_throttling_info() is never called with pr == NULL.

    [ bart: the potential NULL pointer dereference was finally fixed in
    (much later than mine) commit 5cfa245 but my patch is still valid ]

    Reported-by: Dan Carpenter
    Signed-off-by: Bartlomiej Zolnierkiewicz
    Signed-off-by: Andrew Morton
    Signed-off-by: Len Brown

    Bartlomiej Zolnierkiewicz
     

28 Jan, 2010

1 commit


06 Nov, 2009

1 commit

  • If the NULL test on pr is needed, then the dereference should be after the
    NULL test.

    A simplified version of the semantic match that detects this problem is as
    follows (http://coccinelle.lip6.fr/):

    //
    @match exists@
    expression x, E;
    identifier fld;
    @@

    * x->fld
    ... when != \(x = E\|&x\)
    * x == NULL
    //

    Signed-off-by: Julia Lawall
    Signed-off-by: Andrew Morton
    Signed-off-by: Len Brown

    Julia Lawall
     

24 Sep, 2009

1 commit


19 Sep, 2009

1 commit


29 Aug, 2009

1 commit

  • Linux/ACPI core files using internal.h all PREFIX "ACPI: ",
    however, not all ACPI drivers use/want it -- and they
    should not have to #undef PREFIX to define their own.

    Add GPL commment to internal.h while we are there.

    This does not change any actual console output,
    asside from a whitespace fix.

    Signed-off-by: Len Brown

    Len Brown
     

27 Aug, 2009

2 commits

  • This failure is very common on many platforms. Handling it in the ACPI
    processor driver is enough, and we don't need a warning message unless
    CONFIG_ACPI_DEBUG is set.

    Based on a patch from Zhang Rui.

    Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13389

    Signed-off-by: Frans Pop
    Acked-by: Zhang Rui
    Cc: Len Brown
    Cc: "Rafael J. Wysocki"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Frans Pop
     
  • If the BIOS reports an invalid throttling state (which seems to be
    fairly common after system boot), a reset is done to state T0.
    Because of a check in acpi_processor_get_throttling_ptc(), the reset
    never actually gets executed, which results in the error reoccurring
    on every access of for example /proc/acpi/processor/CPU0/throttling.

    Add a 'force' option to acpi_processor_set_throttling() to ensure
    the reset really takes effect.

    Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13389

    This patch, together with the next one, fixes a regression introduced in
    2.6.30, listed on the regression list. They have been available for 2.5
    months now in bugzilla, but have not been picked up, despite various
    reminders and without any reason given.

    Google shows that numerous people are hitting this issue. The issue is in
    itself relatively minor, but the bug in the code is clear.

    The patches have been in all my kernels and today testing has shown that
    throttling works correctly with the patches applied when the system
    overheats (http://bugzilla.kernel.org/show_bug.cgi?id=13918#c14).

    Signed-off-by: Frans Pop
    Acked-by: Zhang Rui
    Cc: Len Brown
    Cc: "Rafael J. Wysocki"
    Cc: Rusty Russell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Frans Pop
     

24 Jun, 2009

1 commit


30 May, 2009

1 commit

  • Commit 4973b22a ("ACPI processor: reset the throttling state once it's
    invalid") introduced a new warning which prints a spurious newline.

    The ACPI_WARNING macro that is used already takes care of adding a
    newline, after adding ACPI_CA_VERSION to the message. Remove the newline
    to avoid the message getting split into two lines.

    Signed-off-by: Frans Pop
    Signed-off-by: Len Brown

    Frans Pop
     

16 May, 2009

2 commits


05 Apr, 2009

1 commit


04 Apr, 2009

2 commits


04 Jan, 2009

1 commit