On Thu, Mar 30, 2023 at 08:45:52PM -0700, Luis Chamberlain wrote:
> diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
> index 291d4167fab8..00c9fcd90e1a 100644
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -1177,7 +1177,7 @@ static const struct {
> static struct ratelimit_state bld_ratelimit;
>
> static unsigned int sysctl_sld_mitigate = 1;
> -static DEFINE_SEMAPHORE(buslock_sem);
> +static DEFINE_MUTEX(buslock_sem);
>
> #ifdef CONFIG_PROC_SYSCTL
> static struct ctl_table sld_sysctls[] = {
> @@ -1315,7 +1315,7 @@ static void split_lock_init(void)
> static void __split_lock_reenable_unlock(struct work_struct *work)
> {
> sld_update_msr(true);
> - up(&buslock_sem);
> + mutex_unlock(&buslock_sem);
> }
>
> static DECLARE_DELAYED_WORK(sl_reenable_unlock, __split_lock_reenable_unlock);
^^^ clearly unsafe. __split_lock_reenable_unlock() is called as a
delayed_work(), ie not in the context of the mutex locker. lockdep
will freak out at this.
> @@ -351,12 +351,12 @@ virt_efi_set_variable_nonblocking(efi_char16_t *name, efi_guid_t *vendor,
> {
> efi_status_t status;
>
> - if (down_trylock(&efi_runtime_lock))
> + if (!mutex_trylock(&efi_runtime_lock))
> return EFI_NOT_READY;
looks to me like this can be called while we're oopsing. if that's in
non-process context, lockdep will get angry.
> @@ -149,10 +149,10 @@ EXPORT_SYMBOL_NS_GPL(efivar_lock, EFIVAR);
> */
> int efivar_trylock(void)
> {
> - if (down_trylock(&efivars_lock))
> + if (!mutex_trylock(&efivars_lock))
also can be called from oops context.
> @@ -228,7 +228,7 @@ adb_probe_task(void *x)
> do_adb_reset_bus();
> pr_debug("adb: finished probe task...\n");
>
> - up(&adb_probe_mutex);
> + mutex_unlock(&adb_probe_mutex);
adb_probe_task() can be called from a different context than the lock
holder.
> @@ -10594,7 +10594,7 @@ static bool bnx2x_prev_is_path_marked(struct bnx2x *bp)
> struct bnx2x_prev_path_list *tmp_list;
> bool rc = false;
>
> - if (down_trylock(&bnx2x_prev_sem))
> + if (!mutex_trylock(&bnx2x_prev_sem))
bet you this can be called from interrupt context.
this really isn't something to use coccinelle for.
