linux-stable.git/drivers/firmware/google, branch linux-4.9.y

firmware: google: Test spinlock on panic path to avoid lockups

2022-10-26T11:15:43+00:00

[ Upstream commit 3e081438b8e639cc76ef1a5ce0c1bd8a154082c7 ]

Currently the gsmi driver registers a panic notifier as well as
reboot and die notifiers. The callbacks registered are called in
atomic and very limited context - for instance, panic disables
preemption and local IRQs, also all secondary CPUs (not executing
the panic path) are shutdown.

With that said, taking a spinlock in this scenario is a dangerous
invitation for lockup scenarios. So, fix that by checking if the
spinlock is free to acquire in the panic notifier callback - if not,
bail-out and avoid a potential hang.

Fixes: 74c5b31c6618 ("driver: Google EFI SMI")
Cc: Andrew Morton 
Cc: Ard Biesheuvel 
Cc: David Gow 
Cc: Greg Kroah-Hartman 
Cc: Julius Werner 
Cc: Petr Mladek 
Reviewed-by: Evan Green 
Signed-off-by: Guilherme G. Piccoli 
Link: https://lore.kernel.org/r/20220909200755.189679-1-gpiccoli@igalia.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

gsmi: Fix bug in append_to_eventlog sysfs handler

2019-11-28T17:28:21+00:00

[ Upstream commit 655603de68469adaff16842ac17a5aec9c9ce89b ]

The sysfs handler should return the number of bytes consumed, which in the
case of a successful write is the entire buffer.  Also fix a bug where
param.data_len was being set to (count - (2 * sizeof(u32))) instead of just
(count - sizeof(u32)).  The latter is correct because we skip over the
leading u32 which is our param.type, but we were also incorrectly
subtracting sizeof(u32) on the line where we were actually setting
param.data_len:

	param.data_len = count - sizeof(u32);

This meant that for our example event.kernel_software_watchdog with total
length 10 bytes, param.data_len was just 2 prior to this change.

To test, successfully append an event to the log with gsmi sysfs.
This sample event is for a "Kernel Software Watchdog"

> xxd -g 1 event.kernel_software_watchdog
0000000: 01 00 00 00 ad de 06 00 00 00

> cat event.kernel_software_watchdog > /sys/firmware/gsmi/append_to_eventlog

> mosys eventlog list | tail -1
14 | 2012-06-25 10:14:14 | Kernl Event | Software Watchdog

Signed-off-by: Duncan Laurie 
Reviewed-by: Vadim Bendebury 
Reviewed-by: Stefan Reinauer 
Signed-off-by: Furquan Shaikh 
Tested-by: Furquan Shaikh 
Reviewed-by: Aaron Durbin 
Reviewed-by: Justin TerAvest 
[zwisler: updated changelog for 2nd bug fix and upstream]
Signed-off-by: Ross Zwisler 
Reviewed-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

firmware-gsmi: Delete an unnecessary check before the function call "dma_pool_destroy"

2016-09-09T15:08:45+00:00

The dma_pool_destroy() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
Cc: Greg KH 
Cc: Julia Lawall 
Cc: Mike Waychison 
Cc: Michel Lespinasse 
Signed-off-by: Matt Fleming

firmware: google memconsole driver fixes

2014-02-15T19:30:28+00:00

The google memconsole driver is currently broken upstream, as it tries
to read memory that is described as reserved in /proc/iomem, by
dereferencing a pointer obtained through phys_to_virt(). This triggers
a kernel fault as such regions are unmapped after early boot.

The proper workaround is to use ioremap_cache() / iounmap() around such
accesses.

As some unrelated changes, I also converted some printks to use pr_info()
and added some missing __init annotations.

Tested: booted dbg build, verified I could read /sys/firmware/log

Signed-off-by: Michel Lespinasse 
Acked-by: Mike Waychison 
Signed-off-by: Greg Kroah-Hartman

firmware: fix google/gsmi duplicate efivars_sysfs_init()

2014-02-15T19:29:56+00:00

Starting in commit e14ab23dde12b80db4c94b684a2e485b72b16af3,
efivars_sysfs_init() is called both by itself as an init function,
and by drivers/firmware/google/gsmi.c gsmi_init().

This results in runtime warnings such as the following:
[    5.651330] WARNING: at fs/sysfs/dir.c:530 sysfs_add_one+0xbd/0xe0()
[    5.657699] sysfs: cannot create duplicate filename '/firmware/gsmi/vars'

Fixing this by removing the redundant efivars_sysfs_init() call in
gsmi_init().

Tested: booted, checked that /firmware/gsmi/vars was still present and
showed the expected contents.

Signed-off-by: Michel Lespinasse 
Acked-by: Matt Fleming 
Acked-by: Mike Waychison 
Signed-off-by: Greg Kroah-Hartman

firmware/google: drop 'select EFI' to avoid recursive dependency

2014-01-28T05:02:40+00:00

The GOOGLE_SMI Kconfig symbol depends on DMI and selects EFI.  This
causes problems on other archs when introducing DMI support that depends
on EFI, as it results in a recursive dependency:

  arch/arm/Kconfig:1845:error: recursive dependency detected!
  arch/arm/Kconfig:1845:	symbol DMI depends on EFI

Fix by changing the 'select EFI' to a 'depends on EFI'.

Signed-off-by: Ard Biesheuvel 
Cc: David Rientjes 
Acked-by: Mike Waychison 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

DMA-API: firmware/google/gsmi.c: avoid direct access to DMA masks

2013-10-31T14:49:17+00:00

This driver doesn't need to directly access DMA masks if it uses the
platform_device_register_full() API rather than
platform_device_register_simple() - the former function can initialize
the DMA mask appropriately.

Signed-off-by: Russell King

drivers/firmware/google/gsmi.c: replace strict_strtoul() with kstrtoul()

2013-09-11T22:58:16+00:00

The use of strict_strtoul() is not preferred, because strict_strtoul() is
obsolete.  Thus, kstrtoul() should be used.

Signed-off-by: Jingoo Han 
Cc: Matt Fleming 
Cc: Tom Gundersen 
Cc: Mike Waychison 
Acked-by: Mike Waychison 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge tag 'v3.9' into efi-for-tip2

2013-04-30T10:42:13+00:00

Resolve conflicts for Ingo.

Conflicts:
	drivers/firmware/Kconfig
	drivers/firmware/efivars.c

Signed-off-by: Matt Fleming

efivars: efivar_entry API

2013-04-17T12:23:59+00:00

There isn't really a formal interface for dealing with EFI variables
or struct efivar_entry. Historically, this has led to various bits of
code directly accessing the generic EFI variable ops, which inherently
ties it to specific EFI variable operations instead of indirectly
using whatever ops were registered with register_efivars(). This lead
to the efivarfs code only working with the generic EFI variable ops
and not CONFIG_GOOGLE_SMI.

Encapsulate everything that needs to access '__efivars' inside an
efivar_entry_* API and use the new API in the pstore, sysfs and
efivarfs code.

Much of the efivars code had to be rewritten to use this new API. For
instance, it is now up to the users of the API to build the initial
list of EFI variables in their efivar_init() callback function. The
variable list needs to be passed to efivar_init() which allows us to
keep work arounds for things like implementation bugs in
GetNextVariable() in a central location.

Allowing users of the API to use a callback function to build the list
greatly benefits the efivarfs code which needs to allocate inodes and
dentries for every variable.  It previously did this in a racy way
because the code ran without holding the variable spinlock. Both the
sysfs and efivarfs code maintain their own lists which means the two
interfaces can be running simultaneously without interference, though
it should be noted that because no synchronisation is performed it is
very easy to create inconsistencies. efibootmgr doesn't currently use
efivarfs and users are likely to also require the old sysfs interface,
so it makes sense to allow both to be built.

Reviewed-by: Tom Gundersen 
Tested-by: Tom Gundersen 
Cc: Seiji Aguchi 
Cc: Matthew Garrett 
Cc: Jeremy Kerr 
Cc: Tony Luck 
Cc: Mike Waychison 
Signed-off-by: Matt Fleming