linux-kernel - __mutex_lock_common() unlikely very likely

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170118155824.689a9996@gandalf.local.home>
Date:   Wed, 18 Jan 2017 15:58:24 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Chris Wilson <chris@...is-wilson.co.uk>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>
Subject: __mutex_lock_common() unlikely very likely

Chris,

My branch tracer flagged the unlikely in __mutex_lock_common() as
always hit. That's the:

	if (use_ww_ctx) {
		[...]
		if (unlikely(ww_ctx == READ_ONCE(ww->ctx)))
			return -EALREADY;
	}

This is hit 100% of the time, and its coming from the drm logic:

for example:

<stack trace>
 => drm_atomic_get_crtc_state
 => drm_atomic_helper_duplicate_state
 => intel_modeset_init
 => i915_driver_load
 => i915_pci_probe
 => local_pci_probe
 => pci_device_probe
 => driver_probe_device
 => __driver_attach
 => bus_for_each_dev
 => driver_attach
 => bus_add_driver
 => driver_register
 => __pci_register_driver
 => ext4_has_free_clusters
 => do_one_initcall
 => do_init_module
 => load_module
 => SYSC_init_module
 => SyS_init_module
 => entry_SYSCALL_64_fastpath

This is happening on 3 boxes of mine running normal loads (servers,
email, facebook, etc).

Commit 0422e83d84ae2 says:

    Recursive locking for ww_mutexes was originally conceived as an
    exception. However, it is heavily used by the DRM atomic modesetting
    code. Currently, the recursive deadlock is checked after we have queued
    up for a busy-spin and as we never release the lock, we spin until
    kicked, whereupon the deadlock is discovered and reported.

Should this be converted to a likely?

-- Steve