From patchwork Wed Feb 15 16:13:50 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Thomas Hellstrom X-Patchwork-Id: 13141843 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DCBC2C636D7 for ; Wed, 15 Feb 2023 16:14:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 42F2E6B0073; Wed, 15 Feb 2023 11:14:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3B7E76B0074; Wed, 15 Feb 2023 11:14:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 20ABA6B0075; Wed, 15 Feb 2023 11:14:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 05E6A6B0073 for ; Wed, 15 Feb 2023 11:14:38 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id C32531401EB for ; Wed, 15 Feb 2023 16:14:37 +0000 (UTC) X-FDA: 80470024194.24.9A2A414 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by imf09.hostedemail.com (Postfix) with ESMTP id 8197414001B for ; Wed, 15 Feb 2023 16:14:35 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=WZ3+Bqhv; spf=none (imf09.hostedemail.com: domain of thomas.hellstrom@linux.intel.com has no SPF policy when checking 134.134.136.31) smtp.mailfrom=thomas.hellstrom@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676477675; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=NPGWynUR7H4gKoWIhfFM4jq0MI6H6raebVO/4/P65I8=; b=ROlu/nThq+StvuFLM5dW4azHpRpEd97MjiyTt5h1hX65c1nEOANKO8ertKLVfBI52jOOsW O/elYFTRjLOwUDRQBt/C9uHOr0d0LXF03P0bs7ifAcxqgkNZX/H6EbqtdaQC8p2rAv2OPC M8zBEbocDZc1cKTMAWzCpYJXUi3MLKM= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=WZ3+Bqhv; spf=none (imf09.hostedemail.com: domain of thomas.hellstrom@linux.intel.com has no SPF policy when checking 134.134.136.31) smtp.mailfrom=thomas.hellstrom@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676477675; a=rsa-sha256; cv=none; b=fMm4nAnHUg839qsrW7dm4OJkd17Z4W1WMN3w1YtbbTFMseJqWIOJpZkUOlTFM8Co5OcZNd FA4sYZfB7uFT2fzx9S6BSil4I6QxvX+8zvfsIgT3YLRA696ybc8mYVh5EMXkqSvc4DcJwi PzLNFRsNIPBmXJWsGsRNpiB9PMqP3sQ= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1676477675; x=1708013675; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=f+jziJqtg2tHO1sm8YICg4x70AohpDQ+/WN+2ra+cxA=; b=WZ3+BqhvDQav9cGI7KxbANMpJfa5U3uql3CAZfYpCZhnE3cgTbXrtlvR R4kNp/qINyFgXR1RqmE+b5gbk8RVa9lvga4TmtWZCxURoF+3LIXW/8lMr niDKqZLbzJ8YYWhsXReoKxPRhSuUsUaWivdouRUyp/usWvUcokAhSEyU+ 7RBBPIUmUzav8SGZNZviehsBRpIO6h1gti7YC72wqnh03OTt9DxuDvtSL JWCU7UofDm3kgmpkSmjNX2WTgjun/HD2LOBXrvR+eZZQs4wtWOyUbJvOI gzHaYFaCPl8dI8AxuFTMWfVGlZjLMFrseqKD1TlvFDD7xDWSEebRj6nib w==; X-IronPort-AV: E=McAfee;i="6500,9779,10622"; a="393870668" X-IronPort-AV: E=Sophos;i="5.97,300,1669104000"; d="scan'208";a="393870668" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Feb 2023 08:14:34 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10622"; a="758471994" X-IronPort-AV: E=Sophos;i="5.97,300,1669104000"; d="scan'208";a="758471994" Received: from auliel-mobl1.ger.corp.intel.com (HELO thellstr-mobl1.intel.com) ([10.249.254.14]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Feb 2023 08:14:27 -0800 From: =?utf-8?q?Thomas_Hellstr=C3=B6m?= To: dri-devel@lists.freedesktop.org Cc: =?utf-8?q?Thomas_Hellstr=C3=B6m?= , =?utf-8?q?Christian_K=C3=B6nig?= , Daniel Vetter , Huang Rui , Alex Deucher , Felix Kuehling , Philip Yang , Qiang Yu , Matthew Auld , Nirmoy Das , Tvrtko Ursulin , Anshuman Gupta , Ramalingam C , Arunpravin Paneer Selvam , Andrew Morton , "Matthew Wilcox (Oracle)" , Miaohe Lin , David Hildenbrand , Johannes Weiner , Peter Xu , NeilBrown , Dave Airlie , Dave Hansen , linux-graphics-maintainer@vmware.com, linux-mm@kvack.org, intel-gfx@lists.freedesktop.org Subject: [RFC PATCH 01/16] drm/ttm: Fix a NULL pointer dereference Date: Wed, 15 Feb 2023 17:13:50 +0100 Message-Id: <20230215161405.187368-2-thomas.hellstrom@linux.intel.com> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20230215161405.187368-1-thomas.hellstrom@linux.intel.com> References: <20230215161405.187368-1-thomas.hellstrom@linux.intel.com> MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 8197414001B X-Stat-Signature: t6ste4trq13wxmwdabg4odwq63woeuwa X-HE-Tag: 1676477675-376180 X-HE-Meta: U2FsdGVkX1/yMYCJtUAmiVX8mQeCME12qiCugFDmgpIAsh6XQAlZB2M9RLNwAd0ss8+uwT+sfGKVIVizkoe8me5VUdXmukwYUr7PMbPGOEoqZ99S4m5OBmSTasXk99JrrXr1rkhSnzNrdJBgA8Xj9WbFJaUzuV8gaNGWd7Nq4qmYcR1fOk/n7oQTNdUuvDFpVABY0wPKWqCZJQUxm4NsQEyr+X6Re/trmPDfWHkvJ81tyr4p9wF5Yy/zAeS96vaaSJhmcF+9yOhx4rfmkJDWruwk8U5KKfW58rbfNlU41zYkwsJgbgUb8DYrunVZPNu+Wuna6pKnSqoLkc9KioexhYeA8EVXi6prw378RyKDIvBhJTa1Ld8RLVe1/p5yvhlnTJkff3H3x8sS3kOTX1fJZN3SVzzitCHNu0Vd/w9S2voGNabWTC7KdvWa5JXJLRPMu6owgnu/hfB1nbRcnkKKDasOT8bM+OW4kwpu1Qw0DWazmMEZLTPs3fZAfBVwM0HVCbAYWauLzU4L90cHeMWsYwU75eHmOHDu3KoZgOhTJV+Hv0Pj0OX8sryJzjiaCynffZKWNI4E63NFjOR+4P1dbTh9+xAZqAPX8sZT08fmSp1iYNkDHUjk5x7iO7yCceQAlzsHbDilAw3RCmChCc0UbI7EZ4eJDU7oxZbvx5Q6eMfkIEh5G2CWB4Hk93wFnSiOZmC/bFQ9jcdhUUgyjctSwybWskwN+Ivoyi3OW4BRnjLPOU+LEiQXoBUc6K7rthFRmFoDwEq4MlniIKeo1VQp7et2uN6zndui9Bj5J5MaAKLVlJHJrL77AD6CwEWULnO6+pMY0Ft6Fmiu11B4WF0oIPEg4i01LLbalW4/bwwEAGp0pG5i4f6UotJpqw1ku++iT+5cMTG6QsE9blwL/d0YxVU7mTtiz9dw1txCxK6FE4jJnrMVTGse0NSpWPC8hevjovp2d6bmEfTIujE8Dto gHwu/esv n2L/mD450a5I5KOX4+mpRO10kxDow56fFnsUdnxeHfNHZqux2xdlXzUW4XqjLbZb19q1LByTblPYFviFXfHw5Tf5jmu5SXkuTNoOIe79crlI3UeMThxNKIiIZexX8eGxR8CuNYOsxbvtApEdvdQYzFQVwpUM8J+H/fSTX1rGsCPidHksBgI/14JmS9K1PWESWH04flw8V5+Qpq6wHiq8a5AQN2QSZcGAYhZYcc5Qk1+VQmVRrUnYjfK53tSHig9e5LScv6tY7VF3uNu49GAn2fMTekQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: The LRU mechanism may look up a resource in the process of being removed from an object. The locking rules here are a bit unclear but it looks currently like res->bo assignment is protected by the LRU lock, whereas bo->resource is protected by the object lock, while *clearing* of bo->resource is also protected by the LRU lock. This means that if we check that bo->resource points to the LRU resource under the LRU lock we should be safe. So perform that check before deciding to swap out a bo. That avoids dereferencing a NULL bo->resource in ttm_bo_swapout(). Fixes: 6a9b02899402 ("drm/ttm: move the LRU into resource handling v4") Cc: Christian König Cc: Daniel Vetter Cc: Christian Koenig Cc: Huang Rui Cc: Alex Deucher Cc: Felix Kuehling Cc: Philip Yang Cc: Qiang Yu Cc: Matthew Auld Cc: Nirmoy Das Cc: Tvrtko Ursulin Cc: "Thomas Hellström" Cc: Anshuman Gupta Cc: Ramalingam C Cc: Arunpravin Paneer Selvam Cc: dri-devel@lists.freedesktop.org Signed-off-by: Thomas Hellström Reviewed-by: Christian König --- drivers/gpu/drm/ttm/ttm_device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c index c7a1862f322a..ae2f19dc9f81 100644 --- a/drivers/gpu/drm/ttm/ttm_device.c +++ b/drivers/gpu/drm/ttm/ttm_device.c @@ -158,7 +158,7 @@ int ttm_device_swapout(struct ttm_device *bdev, struct ttm_operation_ctx *ctx, struct ttm_buffer_object *bo = res->bo; uint32_t num_pages; - if (!bo) + if (!bo || bo->resource != res) continue; num_pages = PFN_UP(bo->base.size);