From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DCD0013AD03 for ; Fri, 4 Oct 2024 10:50:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728039047; cv=none; b=b97mVIRR3b6IqelTpOZl4H6SX3tG5Le/0mvfg/ja87uYwPoDsxQYnvjtMP/BrX2Kjh+tMw4w4GY2jrzNHIbFq+SSDDgN2EgOHxcxgM72hvAiuZ7fLhRh72qKXqP0Ere3rHeaA0TVIPRbkTW15k08UF1QzhA7sGoSecFZ/tURtSE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728039047; c=relaxed/simple; bh=r6rL3L5eTw5B0T8Ujpsb9LXOrepEYcMhL1hmLv1gie4=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=cw8eTxVADSwId0qXNoSz7UViY/DdoV1CHVpcgsfZK02eG1vhfJ186SbXZONFaw9mTTFZgTW5qTgKiw/FFg3bs/6K4UlfIfrjMQjWuz/A98C3uA8wFF/qWnKyRvfvbwEoLnEaDDXXAXUZmNHeP35KmAf+mIowf/viOLCmHxQVjYs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=GdOo/AxX; arc=none smtp.client-ip=192.198.163.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="GdOo/AxX" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1728039046; x=1759575046; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=r6rL3L5eTw5B0T8Ujpsb9LXOrepEYcMhL1hmLv1gie4=; b=GdOo/AxX9nSQCoCbtRCTn2kaMOMfV2VhtEtsGwnkSog9SqSMzVqgKJhT 3oChd6aeh8yqfU/4w1zlEka5kU535/3+XPPkFvkLVFl9I1XTmvAjwgWoz crGH6IP1bzKhNUpgJDOk+Bbzh3yzEf2X7MUK+8H1Tc6tefFOPcL5cpfnp 2s5+tC/mdV6J3+rwfff9SdVawkmurkZ8yZJLlEtErN3oFjkUeg0SDYj7y D40KeaAvh3mvyFgwpwSR54k46CzLAMVBCSNe1G+BDQ06EhGw9X1zmSPTZ +MB4432doI0ld/hpLRzw87faAfCKkfpwK/7RGb3yQ+3YFnkW3zfsgqS6n w==; X-CSE-ConnectionGUID: 1gPdD9cISDCIrMutl90Y+g== X-CSE-MsgGUID: 6zEzzXDFR5Kzq/qel6js6w== X-IronPort-AV: E=McAfee;i="6700,10204,11214"; a="27141832" X-IronPort-AV: E=Sophos;i="6.11,177,1725346800"; d="scan'208";a="27141832" Received: from orviesa005.jf.intel.com ([10.64.159.145]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Oct 2024 03:50:44 -0700 X-CSE-ConnectionGUID: dGyipNc9TmmqCR0NFbAMCQ== X-CSE-MsgGUID: 8hET29gKTpmKLsqOju4K6Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,177,1725346800"; d="scan'208";a="79438667" Received: from pgcooper-mobl3.ger.corp.intel.com (HELO [10.245.245.128]) ([10.245.245.128]) by orviesa005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Oct 2024 03:50:41 -0700 Message-ID: Subject: Re: [PATCH RESEND] locking/ww_mutex: Adjust to lockdep nest_lock requirements From: Thomas =?ISO-8859-1?Q?Hellstr=F6m?= To: Peter Zijlstra Cc: intel-xe@lists.freedesktop.org, Ingo Molnar , Will Deacon , Waiman Long , Boqun Feng , Maarten Lankhorst , Christian =?ISO-8859-1?Q?K=F6nig?= , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Date: Fri, 04 Oct 2024 12:50:27 +0200 In-Reply-To: <20241004101601.GQ18071@noisy.programming.kicks-ass.net> References: <20241002125611.361001-1-thomas.hellstrom@linux.intel.com> <20241004101601.GQ18071@noisy.programming.kicks-ass.net> Autocrypt: addr=thomas.hellstrom@linux.intel.com; prefer-encrypt=mutual; keydata=mDMEZaWU6xYJKwYBBAHaRw8BAQdAj/We1UBCIrAm9H5t5Z7+elYJowdlhiYE8zUXgxcFz360SFRob21hcyBIZWxsc3Ryw7ZtIChJbnRlbCBMaW51eCBlbWFpbCkgPHRob21hcy5oZWxsc3Ryb21AbGludXguaW50ZWwuY29tPoiTBBMWCgA7FiEEbJFDO8NaBua8diGTuBaTVQrGBr8FAmWllOsCGwMFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQuBaTVQrGBr/yQAD/Z1B+Kzy2JTuIy9LsKfC9FJmt1K/4qgaVeZMIKCAxf2UBAJhmZ5jmkDIf6YghfINZlYq6ixyWnOkWMuSLmELwOsgPuDgEZaWU6xIKKwYBBAGXVQEFAQEHQF9v/LNGegctctMWGHvmV/6oKOWWf/vd4MeqoSYTxVBTAwEIB4h4BBgWCgAgFiEEbJFDO8NaBua8diGTuBaTVQrGBr8FAmWllOsCGwwACgkQuBaTVQrGBr/P2QD9Gts6Ee91w3SzOelNjsus/DcCTBb3fRugJoqcfxjKU0gBAKIFVMvVUGbhlEi6EFTZmBZ0QIZEIzOOVfkaIgWelFEH Organization: Intel Sweden AB, Registration Number: 556189-6027 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.4 (3.50.4-1.fc39) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Fri, 2024-10-04 at 12:16 +0200, Peter Zijlstra wrote: > On Wed, Oct 02, 2024 at 02:56:11PM +0200, Thomas Hellstr=C3=B6m wrote: > > When using mutex_acquire_nest() with a nest_lock, lockdep refcounts > > the > > number of acquired lockdep_maps of mutexes of the same class, and > > also > > keeps a pointer to the first acquired lockdep_map of a class. That > > pointer > > is then used for various comparison-, printing- and checking > > purposes, > > but there is no mechanism to actively ensure that lockdep_map stays > > in > > memory. Instead, a warning is printed if the lockdep_map is freed > > and > > there are still held locks of the same lock class, even if the > > lockdep_map > > itself has been released. > >=20 > > In the context of WW/WD transactions that means that if a user > > unlocks > > and frees a ww_mutex from within an ongoing ww transaction, and > > that > > mutex happens to be the first ww_mutex grabbed in the transaction, > > such a warning is printed and there might be a risk of a UAF. >=20 > I'm assuming you actually hit this? Yes, but there was a change merged to drm_exec, a main ww_mutex user that makes it less likely to happen. (Unlocking in reverse unless the user explicitly requests an unlock which will be a more common use-case moving forward). >=20 > Anyway, work around seems sane enough, thanks! Thanks, Thomas