Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 16 8月, 2019 3 次提交
  3. 30 7月, 2019 3 次提交
    • D
      platform/x86: asus-wmi: fix CPU fan control on recent products · e3168b87
      由 Daniel Drake 提交于 
      Previously, asus-wmi was using the AGFN interface and FAN_CTRL device
for CPU fan control. However, this code has been found to be not fully
working on some recent products, and having checked the spec, these
interfaces are marked as being removed from future products currently
in development.

The replacement appears to be the CPU_FAN device, added in spec version
8.3 (March 2014) and present on many modern Asus laptops.

Add support for this device, and use it whenever it is detected.
The older approach based on AGFN and FAN_CTRL is used as a fallback
on products that do not have such device.

Other than switching between automatic and full speed, there is
no fan speed control through this new interface.
Signed-off-by: NDaniel Drake <drake@endlessm.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      e3168b87
    • D
      platform/x86: asus-wmi: add a helper for device presence · f1fc0321
      由 Daniel Drake 提交于 
      Factor out the WLAN LED and lightbar LED presence checks into a
helper function, which will also be used by the upcoming CPU fan device
support.
Signed-off-by: NDaniel Drake <drake@endlessm.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      f1fc0321
    • D
      platform/x86: asus-wmi: cleanup AGFN fan handling · 2889ffcf
      由 Daniel Drake 提交于 
      The asus-wmi driver currently uses the "AGFN" interface and
the FAN_CTRL device for fan control. According to the spec, this
interface is very dated and marked as pending removal from products
currently in development.

Clean up the way that the AGFN fan is detected and handled, also
preparing the driver for the introduction of an alternate fan
control method needed to support recent Asus products.

Not anticipating further development of this interface, simplify
the code by dropping any notion of being able to control multiple
AGFN fans (this was already limited to just a single fan through only
exposing a single fan in sysfs).

Check for the presence of AGFN fans at probe time, simplifying the code
flow in asus_hwmon_sysfs_is_visible().
Signed-off-by: NDaniel Drake <drake@endlessm.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      2889ffcf
  5. 29 7月, 2019 1 次提交
  7. 18 7月, 2019 1 次提交
    • D
      platform/x86: asus: Rename "fan mode" to "fan boost mode" · 9af93db9
      由 Daniel Drake 提交于 
      The Asus WMI spec indicates that the function being controlled here
is called "Fan Boost Mode". The user-facing documentation also calls it
this.

The spec uses the term "fan mode" is used to refer to other things,
including functionality expected to appear on future products.
We missed this before as we are not dealing with the most readable of
specs, and didn't forsee any confusion around shortening the name.

Rename "fan mode" to "fan boost mode" to improve consistency with the
spec and to avoid a future naming conflict.

There is no interface breakage here since this has yet to be included
in an official kernel release. I also updated the kernel version listed
under ABI accordingly.
Signed-off-by: NDaniel Drake <drake@endlessm.com>
Acked-by: NYurii Pavlovskyi <yurii.pavlovskyi@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      9af93db9
  9. 03 7月, 2019 1 次提交
  11. 17 6月, 2019 12 次提交
  13. 12 6月, 2019 2 次提交
  15. 31 5月, 2019 1 次提交
  17. 09 5月, 2019 1 次提交
    • C
      platform/x86: asus-wmi: Add fn-lock mode switch support · 487579ba
      由 Chris Chiu 提交于 
      Some of latest ASUS laptops support new fn-lock mode switching.
This commit detect whether if the fn-lock option is enabled in
BIOS setting, and toggle the fn-lock mode via a new WMI DEVID
0x00100023 when the corresponding notify code captured.

The ASUS fn-lock mode switch is activated by pressing Fn+Esc.
When on, keys F1 to F12 behave as applicable, with meanings
defined by the application being used at the time. When off,
F1 to F12 directly triggers hardware features, well known audio
volume up/down, brightness up/down...etc, which were triggered
by holding down Fn key and F-keys.

Because there's no way to retrieve the fn-lock mode via existing
WMI methods per ASUS spec, driver need to initialize and keep the
fn-lock mode by itself.
Signed-off-by: NChris Chiu <chiu@endlessm.com>
Reviewed-by: NDaniel Drake <drake@endlessm.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      487579ba
  19. 24 2月, 2019 1 次提交
    • H
      platform/x86: asus-wmi: Allow loading on systems without the Asus Management GUID · c994611a
      由 Hans de Goede 提交于 
      hid-asus depends on asus-wmi through the asus_wmi_evaluate_method. Before
this commit asus-wmi, and thus hid-asus, could not be loaded on non-Asus
systems. This breaks using Asus bluetooth keyboards such as the Asus
T100CHI keyboard with non Asus systems.

This commit fixes this by allowing asus-wmi to load on systems without the
Asus Management GUID.

This is safe to do since all asus-wmi sub drivers use
asus_wmi_register_driver which also checks for the GUID.

This commit also improves the error messages in asus_wmi_register_driver
to include "ASUS" in their description to make them more clear. This is
important since we now rely on those errors when loaded on systems without
the Asus Management GUID.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>
      c994611a
  21. 07 11月, 2018 1 次提交
    • J
      platform/x86: asus-wmi: Tell the EC the OS will handle the display off hotkey · 78f3ac76
      由 João Paulo Rechi Vita 提交于 
      In the past, Asus firmwares would change the panel backlight directly
through the EC when the display off hotkey (Fn+F7) was pressed, and
only notify the OS of such change, with 0x33 when the LCD was ON and
0x34 when the LCD was OFF. These are currently mapped to
KEY_DISPLAYTOGGLE and KEY_DISPLAY_OFF, respectively.

Most recently the EC on Asus most machines lost ability to toggle the
LCD backlight directly, but unless the OS informs the firmware it is
going to handle the display toggle hotkey events, the firmware still
tries change the brightness through the EC, to no effect. The end result
is a long list (at Endless we counted 11) of Asus laptop models where
the display toggle hotkey does not perform any action. Our firmware
engineers contacts at Asus were surprised that there were still machines
out there with the old behavior.

Calling WMNB(ASUS_WMI_DEVID_BACKLIGHT==0x00050011, 2) on the _WDG device
tells the firmware that it should let the OS handle the display toggle
event, in which case it will simply notify the OS of a key press with
0x35, as shown by the DSDT excerpts bellow.

 Scope (_SB)
 {
     (...)

     Device (ATKD)
     {
         (...)

         Name (_WDG, Buffer (0x28)
         {
             /* 0000 */  0xD0, 0x5E, 0x84, 0x97, 0x6D, 0x4E, 0xDE, 0x11,
             /* 0008 */  0x8A, 0x39, 0x08, 0x00, 0x20, 0x0C, 0x9A, 0x66,
             /* 0010 */  0x4E, 0x42, 0x01, 0x02, 0x35, 0xBB, 0x3C, 0x0B,
             /* 0018 */  0xC2, 0xE3, 0xED, 0x45, 0x91, 0xC2, 0x4C, 0x5A,
             /* 0020 */  0x6D, 0x19, 0x5D, 0x1C, 0xFF, 0x00, 0x01, 0x08
         })
         Method (WMNB, 3, Serialized)
         {
             CreateDWordField (Arg2, Zero, IIA0)
             CreateDWordField (Arg2, 0x04, IIA1)
             Local0 = (Arg1 & 0xFFFFFFFF)

             (...)

             If ((Local0 == 0x53564544))
             {
                 (...)

                 If ((IIA0 == 0x00050011))
                 {
                     If ((IIA1 == 0x02))
                     {
                         ^^PCI0.SBRG.EC0.SPIN (0x72, One)
                         ^^PCI0.SBRG.EC0.BLCT = One
                     }

                     Return (One)
                 }
             }
             (...)
         }
         (...)
     }
     (...)
 }
 (...)

 Scope (_SB.PCI0.SBRG.EC0)
 {
     (...)

     Name (BLCT, Zero)

     (...)

     Method (_Q10, 0, NotSerialized)  // _Qxx: EC Query
     {
         If ((BLCT == Zero))
         {
             Local0 = One
             Local0 = RPIN (0x72)
             Local0 ^= One
             SPIN (0x72, Local0)
             If (ATKP)
             {
                 Local0 = (0x34 - Local0)
                 ^^^^ATKD.IANE (Local0)
             }
         }
         ElseIf ((BLCT == One))
         {
             If (ATKP)
             {
                 ^^^^ATKD.IANE (0x35)
             }
         }
     }
     (...)
 }
Signed-off-by: NJoão Paulo Rechi Vita <jprvita@endlessm.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      78f3ac76
  23. 31 10月, 2018 2 次提交
  25. 19 10月, 2018 1 次提交
  27. 19 9月, 2018 3 次提交
    • L
      PCI: hotplug: Embed hotplug_slot · 125450f8
      由 Lukas Wunner 提交于 
      When the PCI hotplug core and its first user, cpqphp, were introduced in
February 2002 with historic commit a8a2069f432c, cpqphp allocated a slot
struct for its internal use plus a hotplug_slot struct to be registered
with the hotplug core and linked the two with pointers:
https://git.kernel.org/tglx/history/c/a8a2069f432c

Nowadays, the predominant pattern in the tree is to embed ("subclass")
such structures in one another and cast to the containing struct with
container_of().  But it wasn't until July 2002 that container_of() was
introduced with historic commit ec4f214232cf:
https://git.kernel.org/tglx/history/c/ec4f214232cf

pnv_php, introduced in 2016, did the right thing and embedded struct
hotplug_slot in its internal struct pnv_php_slot, but all other drivers
cargo-culted cpqphp's design and linked separate structs with pointers.

Embedding structs is preferrable to linking them with pointers because
it requires fewer allocations, thereby reducing overhead and simplifying
error paths.  Casting an embedded struct to the containing struct
becomes a cheap subtraction rather than a dereference.  And having fewer
pointers reduces the risk of them pointing nowhere either accidentally
or due to an attack.

Convert all drivers to embed struct hotplug_slot in their internal slot
struct.  The "private" pointer in struct hotplug_slot thereby becomes
unused, so drop it.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>  # drivers/pci/hotplug/rpa*
Acked-by: Sebastian Ott <sebott@linux.ibm.com>        # drivers/pci/hotplug/s390*
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # drivers/platform/x86
Cc: Len Brown <lenb@kernel.org>
Cc: Scott Murray <scott@spiteful.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Oliver OHalloran <oliveroh@au1.ibm.com>
Cc: Gavin Shan <gwshan@linux.vnet.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: Corentin Chary <corentin.chary@gmail.com>
Cc: Darren Hart <dvhart@infradead.org>
      125450f8
    • L
      PCI: hotplug: Drop hotplug_slot_info · a7da2161
      由 Lukas Wunner 提交于 
      Ever since the PCI hotplug core was introduced in 2002, drivers had to
allocate and register a struct hotplug_slot_info for every slot:
https://git.kernel.org/tglx/history/c/a8a2069f432c

Apparently the idea was that drivers furnish the hotplug core with an
up-to-date card presence status, power status, latch status and
attention indicator status as well as notify the hotplug core of changes
thereof.  However only 4 out of 12 hotplug drivers bother to notify the
hotplug core with pci_hp_change_slot_info() and the hotplug core never
made any use of the information:  There is just a single macro in
pci_hotplug_core.c, GET_STATUS(), which uses the hotplug_slot_info if
the driver lacks the corresponding callback in hotplug_slot_ops.  The
macro is called when the user reads the attribute via sysfs.

Now, if the callback isn't defined, the attribute isn't exposed in sysfs
in the first place (see e.g. has_power_file()).  There are only two
situations when the hotplug_slot_info would actually be accessed:

* If the driver defines ->enable_slot or ->disable_slot but not
  ->get_power_status.

* If the driver defines ->set_attention_status but not
  ->get_attention_status.

There is no driver doing the former and just a single driver doing the
latter, namely pnv_php.c.  Amend it with a ->get_attention_status
callback.  With that, the hotplug_slot_info becomes completely unused by
the PCI hotplug core.  But a few drivers use it internally as a cache:

cpcihp uses it to cache the latch_status and adapter_status.
cpqhp uses it to cache the adapter_status.
pnv_php and rpaphp use it to cache the attention_status.
shpchp uses it to cache all four values.

Amend these drivers to cache the information in their private slot
struct.  shpchp's slot struct already contains members to cache the
power_status and adapter_status, so additional members are only needed
for the other two values.  In the case of cpqphp, the cached value is
only accessed in a single place, so instead of caching it, read the
current value from the hardware.

Caution:  acpiphp, cpci, cpqhp, shpchp, asus-wmi and eeepc-laptop
populate the hotplug_slot_info with initial values on probe.  That code
is herewith removed.  There is a theoretical chance that the code has
side effects without which the driver fails to function, e.g. if the
ACPI method to read the adapter status needs to be executed at least
once on probe.  That seems unlikely to me, still maintainers should
review the changes carefully for this possibility.

Rafael adds: "I'm not aware of any case in which it will break anything,
[...] but if that happens, it may be necessary to add the execution of
the control methods in question directly to the initialization part."
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>  # drivers/pci/hotplug/rpa*
Acked-by: Sebastian Ott <sebott@linux.ibm.com>        # drivers/pci/hotplug/s390*
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # drivers/platform/x86
Cc: Len Brown <lenb@kernel.org>
Cc: Scott Murray <scott@spiteful.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Oliver OHalloran <oliveroh@au1.ibm.com>
Cc: Gavin Shan <gwshan@linux.vnet.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: Corentin Chary <corentin.chary@gmail.com>
Cc: Darren Hart <dvhart@infradead.org>
      a7da2161
    • L
      PCI: hotplug: Constify hotplug_slot_ops · 81c4b5bf
      由 Lukas Wunner 提交于 
      Hotplug drivers cannot declare their hotplug_slot_ops const, making them
attractive targets for attackers, because upon registration of a hotplug
slot, __pci_hp_initialize() writes to the "owner" and "mod_name" members
in that struct.

Fix by moving these members to struct hotplug_slot and constify every
driver's hotplug_slot_ops except for pciehp.

pciehp constructs its hotplug_slot_ops at runtime based on the PCIe
port's capabilities, hence cannot declare them const.  It can be
converted to __write_rarely once that's mainlined:
http://www.openwall.com/lists/kernel-hardening/2016/11/16/3Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>  # drivers/pci/hotplug/rpa*
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # drivers/platform/x86
Cc: Len Brown <lenb@kernel.org>
Cc: Scott Murray <scott@spiteful.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Oliver OHalloran <oliveroh@au1.ibm.com>
Cc: Gavin Shan <gwshan@linux.vnet.ibm.com>
Cc: Sebastian Ott <sebott@linux.vnet.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: Corentin Chary <corentin.chary@gmail.com>
Cc: Darren Hart <dvhart@infradead.org>
      81c4b5bf
  29. 24 7月, 2018 1 次提交
    • L
      PCI: hotplug: Demidlayer registration with the core · 51bbf9be
      由 Lukas Wunner 提交于 
      When a hotplug driver calls pci_hp_register(), all steps necessary for
registration are carried out in one go, including creation of a kobject
and addition to sysfs.  That's a problem for pciehp once it's converted
to enable/disable the slot exclusively from the IRQ thread:  The thread
needs to be spawned after creation of the kobject (because it uses the
kobject's name), but before addition to sysfs (because it will handle
enable/disable requests submitted via sysfs).

pci_hp_deregister() does offer a ->release callback that's invoked
after deletion from sysfs and before destruction of the kobject.  But
because pci_hp_register() doesn't offer a counterpart, hotplug drivers'
->probe and ->remove code becomes asymmetric, which is error prone
as recently discovered use-after-free bugs in pciehp's ->remove hook
have shown.

In a sense, this appears to be a case of the midlayer antipattern:

   "The core thesis of the "midlayer mistake" is that midlayers are
    bad and should not exist.  That common functionality which it is
    so tempting to put in a midlayer should instead be provided as
    library routines which can [be] used, augmented, or ignored by
    each bottom level driver independently.  Thus every subsystem
    that supports multiple implementations (or drivers) should
    provide a very thin top layer which calls directly into the
    bottom layer drivers, and a rich library of support code that
    eases the implementation of those drivers.  This library is
    available to, but not forced upon, those drivers."
        --  Neil Brown (2009), https://lwn.net/Articles/336262/

The presence of midlayer traits in the PCI hotplug core might be ascribed
to its age:  When it was introduced in February 2002, the blessings of a
library approach might not have been well known:
https://git.kernel.org/tglx/history/c/a8a2069f432c

For comparison, the driver core does offer split functions for creating
a kobject (device_initialize()) and addition to sysfs (device_add()) as
an alternative to carrying out everything at once (device_register()).
This was introduced in October 2002:
https://git.kernel.org/tglx/history/c/8b290eb19962

The odd ->release callback in the PCI hotplug core was added in 2003:
https://git.kernel.org/tglx/history/c/69f8d663b595

Clearly, a library approach would not force every hotplug driver to
implement a ->release callback, but rather allow the driver to remove
the sysfs files, release its data structures and finally destroy the
kobject.  Alternatively, a driver may choose to remove everything with
pci_hp_deregister(), then release its data structures.

To this end, offer drivers pci_hp_initialize() and pci_hp_add() as a
split-up version of pci_hp_register().  Likewise, offer pci_hp_del()
and pci_hp_destroy() as a split-up version of pci_hp_deregister().

Eliminate the ->release callback and move its code into each driver's
teardown routine.

Declare pci_hp_deregister() void, in keeping with the usual kernel
pattern that enablement can fail, but disablement cannot.  It only
returned an error if the caller passed in a NULL pointer or a slot which
has never or is no longer registered or is sharing its name with another
slot.  Those would be bugs, so WARN about them.  Few hotplug drivers
actually checked the return value and those that did only printed a
useless error message to dmesg.  Remove that.

For most drivers the conversion was straightforward since it doesn't
matter whether the code in the ->release callback is executed before or
after destruction of the kobject.  But in the case of ibmphp, it was
unclear to me whether setting slot_cur->ctrl and slot_cur->bus_on to
NULL needs to happen before the kobject is destroyed, so I erred on
the side of caution and ensured that the order stays the same.  Another
nontrivial case is pnv_php, I've found the list and kref logic difficult
to understand, however my impression was that it is safe to delete the
list element and drop the references until after the kobject is
destroyed.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>  # drivers/platform/x86
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Cc: Scott Murray <scott@spiteful.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Gavin Shan <gwshan@linux.vnet.ibm.com>
Cc: Sebastian Ott <sebott@linux.vnet.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: Corentin Chary <corentin.chary@gmail.com>
Cc: Darren Hart <dvhart@infradead.org>
Cc: Andy Shevchenko <andy@infradead.org>
      51bbf9be
  31. 02 7月, 2018 2 次提交
  33. 31 5月, 2018 2 次提交
    • J
      platform/x86: asus-wmi: Fix NULL pointer dereference · cf48bf9e
      由 João Paulo Rechi Vita 提交于 
      Do not perform the rfkill cleanup routine when
(asus->driver->wlan_ctrl_by_user && ashs_present()) is true, since
nothing is registered with the rfkill subsystem in that case. Doing so
leads to the following kernel NULL pointer dereference:

  BUG: unable to handle kernel NULL pointer dereference at           (null)
  IP: [<ffffffff816c7348>] __mutex_lock_slowpath+0x98/0x120
  PGD 1a3aa8067
  PUD 1a3b3d067
  PMD 0

  Oops: 0002 [#1] PREEMPT SMP
  Modules linked in: bnep ccm binfmt_misc uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core hid_a4tech videodev x86_pkg_temp_thermal intel_powerclamp coretemp ath3k btusb btrtl btintel bluetooth kvm_intel snd_hda_codec_hdmi kvm snd_hda_codec_realtek snd_hda_codec_generic irqbypass crc32c_intel arc4 i915 snd_hda_intel snd_hda_codec ath9k ath9k_common ath9k_hw ath i2c_algo_bit snd_hwdep mac80211 ghash_clmulni_intel snd_hda_core snd_pcm snd_timer cfg80211 ehci_pci xhci_pci drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm xhci_hcd ehci_hcd asus_nb_wmi(-) asus_wmi sparse_keymap r8169 rfkill mxm_wmi serio_raw snd mii mei_me lpc_ich i2c_i801 video soundcore mei i2c_smbus wmi i2c_core mfd_core
  CPU: 3 PID: 3275 Comm: modprobe Not tainted 4.9.34-gentoo #34
  Hardware name: ASUSTeK COMPUTER INC. K56CM/K56CM, BIOS K56CM.206 08/21/2012
  task: ffff8801a639ba00 task.stack: ffffc900014cc000
  RIP: 0010:[<ffffffff816c7348>]  [<ffffffff816c7348>] __mutex_lock_slowpath+0x98/0x120
  RSP: 0018:ffffc900014cfce0  EFLAGS: 00010282
  RAX: 0000000000000000 RBX: ffff8801a54315b0 RCX: 00000000c0000100
  RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff8801a54315b4
  RBP: ffffc900014cfd30 R08: 0000000000000000 R09: 0000000000000002
  R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801a54315b4
  R13: ffff8801a639ba00 R14: 00000000ffffffff R15: ffff8801a54315b8
  FS:  00007faa254fb700(0000) GS:ffff8801aef80000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000000 CR3: 00000001a3b1b000 CR4: 00000000001406e0
  Stack:
   ffff8801a54315b8 0000000000000000 ffffffff814733ae ffffc900014cfd28
   ffffffff8146a28c ffff8801a54315b0 0000000000000000 ffff8801a54315b0
   ffff8801a66f3820 0000000000000000 ffffc900014cfd48 ffffffff816c73e7
  Call Trace:
   [<ffffffff814733ae>] ? acpi_ut_release_mutex+0x5d/0x61
   [<ffffffff8146a28c>] ? acpi_ns_get_node+0x49/0x52
   [<ffffffff816c73e7>] mutex_lock+0x17/0x30
   [<ffffffffa00a3bb4>] asus_rfkill_hotplug+0x24/0x1a0 [asus_wmi]
   [<ffffffffa00a4421>] asus_wmi_rfkill_exit+0x61/0x150 [asus_wmi]
   [<ffffffffa00a49f1>] asus_wmi_remove+0x61/0xb0 [asus_wmi]
   [<ffffffff814a5128>] platform_drv_remove+0x28/0x40
   [<ffffffff814a2901>] __device_release_driver+0xa1/0x160
   [<ffffffff814a29e3>] device_release_driver+0x23/0x30
   [<ffffffff814a1ffd>] bus_remove_device+0xfd/0x170
   [<ffffffff8149e5a9>] device_del+0x139/0x270
   [<ffffffff814a5028>] platform_device_del+0x28/0x90
   [<ffffffff814a50a2>] platform_device_unregister+0x12/0x30
   [<ffffffffa00a4209>] asus_wmi_unregister_driver+0x19/0x30 [asus_wmi]
   [<ffffffffa00da0ea>] asus_nb_wmi_exit+0x10/0xf26 [asus_nb_wmi]
   [<ffffffff8110c692>] SyS_delete_module+0x192/0x270
   [<ffffffff810022b2>] ? exit_to_usermode_loop+0x92/0xa0
   [<ffffffff816ca560>] entry_SYSCALL_64_fastpath+0x13/0x94
  Code: e8 5e 30 00 00 8b 03 83 f8 01 0f 84 93 00 00 00 48 8b 43 10 4c 8d 7b 08 48 89 63 10 41 be ff ff ff ff 4c 89 3c 24 48 89 44 24 08 <48> 89 20 4c 89 6c 24 10 eb 1d 4c 89 e7 49 c7 45 08 02 00 00 00
  RIP  [<ffffffff816c7348>] __mutex_lock_slowpath+0x98/0x120
   RSP <ffffc900014cfce0>
  CR2: 0000000000000000
  ---[ end trace 8d484233fa7cb512 ]---
  note: modprobe[3275] exited with preempt_count 2

https://bugzilla.kernel.org/show_bug.cgi?id=196467

Reported-by: red.f0xyz@gmail.com
Signed-off-by: NJoão Paulo Rechi Vita <jprvita@endlessm.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      cf48bf9e
    • J
      platform/x86: asus-wmi: Fix NULL pointer dereference · 32ffd6e8
      由 João Paulo Rechi Vita 提交于 
      Do not perform the rfkill cleanup routine when
(asus->driver->wlan_ctrl_by_user && ashs_present()) is true, since
nothing is registered with the rfkill subsystem in that case. Doing so
leads to the following kernel NULL pointer dereference:

  BUG: unable to handle kernel NULL pointer dereference at           (null)
  IP: [<ffffffff816c7348>] __mutex_lock_slowpath+0x98/0x120
  PGD 1a3aa8067
  PUD 1a3b3d067
  PMD 0

  Oops: 0002 [#1] PREEMPT SMP
  Modules linked in: bnep ccm binfmt_misc uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core hid_a4tech videodev x86_pkg_temp_thermal intel_powerclamp coretemp ath3k btusb btrtl btintel bluetooth kvm_intel snd_hda_codec_hdmi kvm snd_hda_codec_realtek snd_hda_codec_generic irqbypass crc32c_intel arc4 i915 snd_hda_intel snd_hda_codec ath9k ath9k_common ath9k_hw ath i2c_algo_bit snd_hwdep mac80211 ghash_clmulni_intel snd_hda_core snd_pcm snd_timer cfg80211 ehci_pci xhci_pci drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm xhci_hcd ehci_hcd asus_nb_wmi(-) asus_wmi sparse_keymap r8169 rfkill mxm_wmi serio_raw snd mii mei_me lpc_ich i2c_i801 video soundcore mei i2c_smbus wmi i2c_core mfd_core
  CPU: 3 PID: 3275 Comm: modprobe Not tainted 4.9.34-gentoo #34
  Hardware name: ASUSTeK COMPUTER INC. K56CM/K56CM, BIOS K56CM.206 08/21/2012
  task: ffff8801a639ba00 task.stack: ffffc900014cc000
  RIP: 0010:[<ffffffff816c7348>]  [<ffffffff816c7348>] __mutex_lock_slowpath+0x98/0x120
  RSP: 0018:ffffc900014cfce0  EFLAGS: 00010282
  RAX: 0000000000000000 RBX: ffff8801a54315b0 RCX: 00000000c0000100
  RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff8801a54315b4
  RBP: ffffc900014cfd30 R08: 0000000000000000 R09: 0000000000000002
  R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801a54315b4
  R13: ffff8801a639ba00 R14: 00000000ffffffff R15: ffff8801a54315b8
  FS:  00007faa254fb700(0000) GS:ffff8801aef80000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000000 CR3: 00000001a3b1b000 CR4: 00000000001406e0
  Stack:
   ffff8801a54315b8 0000000000000000 ffffffff814733ae ffffc900014cfd28
   ffffffff8146a28c ffff8801a54315b0 0000000000000000 ffff8801a54315b0
   ffff8801a66f3820 0000000000000000 ffffc900014cfd48 ffffffff816c73e7
  Call Trace:
   [<ffffffff814733ae>] ? acpi_ut_release_mutex+0x5d/0x61
   [<ffffffff8146a28c>] ? acpi_ns_get_node+0x49/0x52
   [<ffffffff816c73e7>] mutex_lock+0x17/0x30
   [<ffffffffa00a3bb4>] asus_rfkill_hotplug+0x24/0x1a0 [asus_wmi]
   [<ffffffffa00a4421>] asus_wmi_rfkill_exit+0x61/0x150 [asus_wmi]
   [<ffffffffa00a49f1>] asus_wmi_remove+0x61/0xb0 [asus_wmi]
   [<ffffffff814a5128>] platform_drv_remove+0x28/0x40
   [<ffffffff814a2901>] __device_release_driver+0xa1/0x160
   [<ffffffff814a29e3>] device_release_driver+0x23/0x30
   [<ffffffff814a1ffd>] bus_remove_device+0xfd/0x170
   [<ffffffff8149e5a9>] device_del+0x139/0x270
   [<ffffffff814a5028>] platform_device_del+0x28/0x90
   [<ffffffff814a50a2>] platform_device_unregister+0x12/0x30
   [<ffffffffa00a4209>] asus_wmi_unregister_driver+0x19/0x30 [asus_wmi]
   [<ffffffffa00da0ea>] asus_nb_wmi_exit+0x10/0xf26 [asus_nb_wmi]
   [<ffffffff8110c692>] SyS_delete_module+0x192/0x270
   [<ffffffff810022b2>] ? exit_to_usermode_loop+0x92/0xa0
   [<ffffffff816ca560>] entry_SYSCALL_64_fastpath+0x13/0x94
  Code: e8 5e 30 00 00 8b 03 83 f8 01 0f 84 93 00 00 00 48 8b 43 10 4c 8d 7b 08 48 89 63 10 41 be ff ff ff ff 4c 89 3c 24 48 89 44 24 08 <48> 89 20 4c 89 6c 24 10 eb 1d 4c 89 e7 49 c7 45 08 02 00 00 00
  RIP  [<ffffffff816c7348>] __mutex_lock_slowpath+0x98/0x120
   RSP <ffffc900014cfce0>
  CR2: 0000000000000000
  ---[ end trace 8d484233fa7cb512 ]---
  note: modprobe[3275] exited with preempt_count 2

https://bugzilla.kernel.org/show_bug.cgi?id=196467

Reported-by: red.f0xyz@gmail.com
Signed-off-by: NJoão Paulo Rechi Vita <jprvita@endlessm.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      32ffd6e8
  35. 23 4月, 2018 1 次提交
  37. 27 9月, 2017 1 次提交