linux-stable.git/drivers/base, branch v5.4.60

driver core: Avoid binding drivers to dead devices

2020-08-21T11:05:26+00:00

commit 654888327e9f655a9d55ad477a9583e90e8c9b5c upstream.

Commit 3451a495ef24 ("driver core: Establish order of operations for
device_add and device_del via bitflag") sought to prevent asynchronous
driver binding to a device which is being removed.  It added a
per-device "dead" flag which is checked in the following code paths:

* asynchronous binding in __driver_attach_async_helper()
*  synchronous binding in device_driver_attach()
* asynchronous binding in __device_attach_async_helper()

It did *not* check the flag upon:

*  synchronous binding in __device_attach()

However __device_attach() may also be called asynchronously from:

deferred_probe_work_func()
  bus_probe_device()
    device_initial_probe()
      __device_attach()

So if the commit's intention was to check the "dead" flag in all
asynchronous code paths, then a check is also necessary in
__device_attach().  Add the missing check.

Fixes: 3451a495ef24 ("driver core: Establish order of operations for device_add and device_del via bitflag")
Signed-off-by: Lukas Wunner 
Cc: stable@vger.kernel.org # v5.1+
Cc: Alexander Duyck 
Link: https://lore.kernel.org/r/de88a23a6fe0ef70f7cfd13c8aea9ab51b4edab6.1594214103.git.lukas@wunner.de
Signed-off-by: Greg Kroah-Hartman

PM: wakeup: Show statistics for deleted wakeup sources again

2020-07-31T16:39:32+00:00

commit e976eb4b91e906f20ec25b20c152d53c472fc3fd upstream.

After commit 00ee22c28915 (PM / wakeup: Use seq_open() to show wakeup
stats), print_wakeup_source_stats(m, &deleted_ws) is not called from
wakeup_sources_stats_seq_show() any more.

Because deleted_ws is one of the wakeup sources, it should be shown
too, so add it to the end of all other wakeup sources.

Signed-off-by: zhuguangqing 
[ rjw: Subject & changelog ]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Florian Fainelli 
Signed-off-by: Greg Kroah-Hartman

regmap: debugfs: check count when read regmap file

2020-07-31T16:39:32+00:00

commit 74edd08a4fbf51d65fd8f4c7d8289cd0f392bd91 upstream.

When executing the following command, we met kernel dump.
dmesg -c > /dev/null; cd /sys;
for i in `ls /sys/kernel/debug/regmap/* -d`; do
	echo "Checking regmap in $i";
	cat $i/registers;
done && grep -ri "0x02d0" *;

It is because the count value is too big, and kmalloc fails. So add an
upper bound check to allow max size `PAGE_SIZE << (MAX_ORDER - 1)`.

Signed-off-by: Peng Fan 
Link: https://lore.kernel.org/r/1584064687-12964-1-git-send-email-peng.fan@nxp.com
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

regmap: dev_get_regmap_match(): fix string comparison

2020-07-29T08:18:37+00:00

[ Upstream commit e84861fec32dee8a2e62bbaa52cded6b05a2a456 ]

This function is used by dev_get_regmap() to retrieve a regmap for the
specified device. If the device has more than one regmap, the name parameter
can be used to specify one.

The code here uses a pointer comparison to check for equal strings. This
however will probably always fail, as the regmap->name is allocated via
kstrdup_const() from the regmap's config->name.

Fix this by using strcmp() instead.

Signed-off-by: Marc Kleine-Budde 
Link: https://lore.kernel.org/r/20200703103315.267996-1-mkl@pengutronix.de
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

regmap: debugfs: Don't sleep while atomic for fast_io regmaps

2020-07-22T07:33:04+00:00

[ Upstream commit 299632e54b2e692d2830af84be51172480dc1e26 ]

If a regmap has "fast_io" set then its lock function uses a spinlock.
That doesn't work so well with the functions:
* regmap_cache_only_write_file()
* regmap_cache_bypass_write_file()

Both of the above functions have the pattern:
1. Lock the regmap.
2. Call:
   debugfs_write_file_bool()
     copy_from_user()
       __might_fault()
         __might_sleep()

Let's reorder things a bit so that we do all of our sleepable
functions before we grab the lock.

Fixes: d3dc5430d68f ("regmap: debugfs: Allow writes to cache state settings")
Signed-off-by: Douglas Anderson 
Link: https://lore.kernel.org/r/20200715164611.1.I35b3533e8a80efde0cec1cc70f71e1e74b2fa0da@changeid
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

regmap: fix alignment issue

2020-07-16T06:16:32+00:00

[ Upstream commit 53d860952c8215cf9ae1ea33409c8cb71ad6ad3d ]

The assembly and disassembly of data to be sent to or received from
a device invoke functions regmap_format_XX() and regmap_parse_XX()
that extract or insert data items from or into a buffer, using
assignments. In some cases the functions are called with a buffer
pointer with an odd address. On architectures with strict alignment
requirements this can result in a kernel crash. The assignments
have been replaced by functions that take alignment into account.

Signed-off-by: Jens Thoms Toerring 
Link: https://lore.kernel.org/r/20200531095300.GA27570@toerring.de
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

regmap: Fix memory leak from regmap_register_patch

2020-06-30T19:36:56+00:00

[ Upstream commit 95b2c3ec4cb1689db2389c251d39f64490ba641c ]

When a register patch is registered the reg_sequence is copied but the
memory allocated is never freed. Add a kfree in regmap_exit to clean it
up.

Fixes: 22f0d90a3482 ("regmap: Support register patch sets")
Signed-off-by: Charles Keepax 
Link: https://lore.kernel.org/r/20200617152129.19655-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

drivers: base: Fix NULL pointer exception in __platform_driver_probe() if a driver developer is foolish

2020-06-24T15:50:24+00:00

[ Upstream commit 388bcc6ecc609fca1b4920de7dc3806c98ec535e ]

If platform bus driver registration is failed then, accessing
platform bus spin lock (&drv->driver.bus->p->klist_drivers.k_lock)
in __platform_driver_probe() without verifying the return value
__platform_driver_register() can lead to NULL pointer exception.

So check the return value before attempting the spin lock.

One such example is below:

For a custom usecase, I have intentionally failed the platform bus
registration and I expected all the platform device/driver
registrations to fail gracefully. But I came across this panic
issue.

[    1.331067] BUG: kernel NULL pointer dereference, address: 00000000000000c8
[    1.331118] #PF: supervisor write access in kernel mode
[    1.331163] #PF: error_code(0x0002) - not-present page
[    1.331208] PGD 0 P4D 0
[    1.331233] Oops: 0002 [#1] PREEMPT SMP
[    1.331268] CPU: 3 PID: 1 Comm: swapper/0 Tainted: G        W         5.6.0-00049-g670d35fb0144 #165
[    1.331341] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
[    1.331406] RIP: 0010:_raw_spin_lock+0x15/0x30
[    1.331588] RSP: 0000:ffffc9000001be70 EFLAGS: 00010246
[    1.331632] RAX: 0000000000000000 RBX: 00000000000000c8 RCX: 0000000000000001
[    1.331696] RDX: 0000000000000001 RSI: 0000000000000092 RDI: 0000000000000000
[    1.331754] RBP: 00000000ffffffed R08: 0000000000000501 R09: 0000000000000001
[    1.331817] R10: ffff88817abcc520 R11: 0000000000000670 R12: 00000000ffffffed
[    1.331881] R13: ffffffff82dbc268 R14: ffffffff832f070a R15: 0000000000000000
[    1.331945] FS:  0000000000000000(0000) GS:ffff88817bd80000(0000) knlGS:0000000000000000
[    1.332008] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    1.332062] CR2: 00000000000000c8 CR3: 000000000681e001 CR4: 00000000003606e0
[    1.332126] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    1.332189] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    1.332252] Call Trace:
[    1.332281]  __platform_driver_probe+0x92/0xee
[    1.332323]  ? rtc_dev_init+0x2b/0x2b
[    1.332358]  cmos_init+0x37/0x67
[    1.332396]  do_one_initcall+0x7d/0x168
[    1.332428]  kernel_init_freeable+0x16c/0x1c9
[    1.332473]  ? rest_init+0xc0/0xc0
[    1.332508]  kernel_init+0x5/0x100
[    1.332543]  ret_from_fork+0x1f/0x30
[    1.332579] CR2: 00000000000000c8
[    1.332616] ---[ end trace 3bd87f12e9010b87 ]---
[    1.333549] note: swapper/0[1] exited with preempt_count 1
[    1.333592] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
[    1.333736] Kernel Offset: disabled

Note, this can only be triggered if a driver errors out from this call,
which should never happen.  If it does, the driver needs to be fixed.

Signed-off-by: Kuppuswamy Sathyanarayanan 
Link: https://lore.kernel.org/r/20200408214003.3356-1-sathyanarayanan.kuppuswamy@linux.intel.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

x86/speculation: Add Special Register Buffer Data Sampling (SRBDS) mitigation

2020-06-10T18:24:57+00:00

commit 7e5b3c267d256822407a22fdce6afdf9cd13f9fb upstream

SRBDS is an MDS-like speculative side channel that can leak bits from the
random number generator (RNG) across cores and threads. New microcode
serializes the processor access during the execution of RDRAND and
RDSEED. This ensures that the shared buffer is overwritten before it is
released for reuse.

While it is present on all affected CPU models, the microcode mitigation
is not needed on models that enumerate ARCH_CAPABILITIES[MDS_NO] in the
cases where TSX is not supported or has been disabled with TSX_CTRL.

The mitigation is activated by default on affected processors and it
increases latency for RDRAND and RDSEED instructions. Among other
effects this will reduce throughput from /dev/urandom.

* Enable administrator to configure the mitigation off when desired using
  either mitigations=off or srbds=off.

* Export vulnerability status via sysfs

* Rename file-scoped macros to apply for non-whitelist table initializations.

 [ bp: Massage,
   - s/VULNBL_INTEL_STEPPING/VULNBL_INTEL_STEPPINGS/g,
   - do not read arch cap MSR a second time in tsx_fused_off() - just pass it in,
   - flip check in cpu_set_bug_bits() to save an indentation level,
   - reflow comments.
   jpoimboe: s/Mitigated/Mitigation/ in user-visible strings
   tglx: Dropped the fused off magic for now
 ]

Signed-off-by: Mark Gross 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Tony Luck 
Reviewed-by: Pawan Gupta 
Reviewed-by: Josh Poimboeuf 
Tested-by: Neelima Krishnan 
Signed-off-by: Greg Kroah-Hartman

component: Silence bind error on -EPROBE_DEFER

2020-05-27T15:46:31+00:00

[ Upstream commit 7706b0a76a9697021e2bf395f3f065c18f51043d ]

If a component fails to bind due to -EPROBE_DEFER we should not log an
error as this is not a real failure.

Fixes messages like:
vc4-drm soc:gpu: failed to bind 3f902000.hdmi (ops vc4_hdmi_ops): -517
vc4-drm soc:gpu: master bind failed: -517

Signed-off-by: James Hilliard 
Link: https://lore.kernel.org/r/20200411190241.89404-1-james.hilliard1@gmail.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin