Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp303244pxb; Wed, 3 Nov 2021 04:36:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwIhbIt5db5210q7R9ak0/SbvHaDjwXFYFYEGQETnlbobCDYanrkXeciZLRI9OyowF3NTi1 X-Received: by 2002:aa7:cb92:: with SMTP id r18mr60181644edt.282.1635939406603; Wed, 03 Nov 2021 04:36:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635939406; cv=none; d=google.com; s=arc-20160816; b=C4FBys6gk8+O8KgrvkSJ2dvv17flZNPUzH/cMELAJ1X4s//I6kUDjriW0C+U0H9iwf u4dlymqSF34J/QJeV75LiJj7dYE8KkSsvhpubX6EEyr2hCMS4kGTAoo35MjGw+09/3Uo YPH7X6cvI34Jrv4LaKrHiuB+QYDFgD1r4DnBjWkMTZwa0LcZ8pNFZ57L2o6iYdwATw3r XPnoKQMjCMO812ysg3RBoq11oQNFBQ3gXOKVwVzL4Fryec7h/jdh4nTg2hZ8jL1uDSWv SGpTQ4QpKd9NjwimQuaMKeE7lqE1J45x5mpy29UPgLNQkNuc8rjoiyzNcfPjkvZjP6XA +yHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :organization:in-reply-to:subject:cc:to:from; bh=OtzaxnBhuqHwwBfMHjiaVMhiAJYHZ1AnchR5I6IkYyE=; b=JbuoAPpG6CzsES2isKqAgqMCt4oAjiVzZswAVQXzETfQjpELakEzOZfNKfCCzT4SZ2 ocsXKhDA0eq5XrO9rhTkEUCBva09gBzNZojH/I/9O1QWg5FuYgMmWkWZh1LgFCwgO9Yw 3mP4z4rosYzUBuOIrxicAvRARJLYvVzhzpi7w4YKx8wRf5YxYQl0FTkYaJIBfDnlCT4U meDc8RyVGo0ibLG6X7QDdjfl+DW6Q5lY9Bqco9ZaX87d48tFuGox8B3towoWl438gOl8 4VAjf0k2kNpK1Q3Ev6ppMElXzrEqpZjWik1dDLRpZNkiqKG8i6vznHOmdGJ0jwvsedho pEhQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b18si2754795ejh.638.2021.11.03.04.36.12; Wed, 03 Nov 2021 04:36:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231383AbhKCLeP (ORCPT + 99 others); Wed, 3 Nov 2021 07:34:15 -0400 Received: from mga11.intel.com ([192.55.52.93]:28521 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230112AbhKCLeO (ORCPT ); Wed, 3 Nov 2021 07:34:14 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10156"; a="228929237" X-IronPort-AV: E=Sophos;i="5.87,205,1631602800"; d="scan'208";a="228929237" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Nov 2021 04:31:31 -0700 X-IronPort-AV: E=Sophos;i="5.87,205,1631602800"; d="scan'208";a="501022434" Received: from bmagdala-mobl.ger.corp.intel.com (HELO localhost) ([10.251.215.42]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Nov 2021 04:31:27 -0700 From: Jani Nikula To: "Yuan\, Perry" , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter Cc: "dri-devel\@lists.freedesktop.org" , "linux-kernel\@vger.kernel.org" , "Huang\, Shimmer" , "Huang\, Ray" Subject: RE: [PATCH v2] drm/dp: Fix aux->transfer NULL pointer dereference on drm_dp_dpcd_access In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20211101061053.38173-1-Perry.Yuan@amd.com> <87a6iodnz7.fsf@intel.com> <87y267c5nc.fsf@intel.com> Date: Wed, 03 Nov 2021 13:31:25 +0200 Message-ID: <87wnlpbhma.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 03 Nov 2021, "Yuan, Perry" wrote: > [AMD Official Use Only] > > Hi Jani: > >> -----Original Message----- >> From: Jani Nikula >> Sent: Tuesday, November 2, 2021 4:40 PM >> To: Yuan, Perry ; Maarten Lankhorst >> ; Maxime Ripard ; >> Thomas Zimmermann ; David Airlie ; >> Daniel Vetter >> Cc: dri-devel@lists.freedesktop.org; linux-kernel@vger.kernel.org; Huang, >> Shimmer ; Huang, Ray >> Subject: RE: [PATCH v2] drm/dp: Fix aux->transfer NULL pointer dereference on >> drm_dp_dpcd_access >> >> [CAUTION: External Email] >> >> On Tue, 02 Nov 2021, "Yuan, Perry" wrote: >> > [AMD Official Use Only] >> > >> > Hi Jani: >> > Thanks for your comments. >> > >> >> -----Original Message----- >> >> From: Jani Nikula >> >> Sent: Monday, November 1, 2021 9:07 PM >> >> To: Yuan, Perry ; Maarten Lankhorst >> >> ; Maxime Ripard >> >> ; Thomas Zimmermann ; >> David >> >> Airlie ; Daniel Vetter >> >> Cc: Yuan, Perry ; >> >> dri-devel@lists.freedesktop.org; linux- kernel@vger.kernel.org; >> >> Huang, Shimmer ; Huang, Ray >> >> >> Subject: Re: [PATCH v2] drm/dp: Fix aux->transfer NULL pointer >> >> dereference on drm_dp_dpcd_access >> >> >> >> [CAUTION: External Email] >> >> >> >> On Mon, 01 Nov 2021, Perry Yuan wrote: >> >> > Fix below crash by adding a check in the drm_dp_dpcd_access which >> >> > ensures that aux->transfer was actually initialized earlier. >> >> >> >> Gut feeling says this is papering over a real usage issue somewhere >> >> else. Why is the aux being used for transfers before ->transfer has >> >> been set? Why should the dp helper be defensive against all kinds of >> misprogramming? >> >> >> >> >> >> BR, >> >> Jani. >> >> >> > >> > The issue was found by Intel IGT test suite, graphic by pass test case. >> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl >> > ab.freedesktop.org%2Fdrm%2Figt-gpu- >> tools&data=04%7C01%7CPerry.Yuan >> > %40amd.com%7C83d011acfe65437c0fa808d99ddc65b0%7C3dd8961fe4884e6 >> 08e11a8 >> > >> 2d994e183d%7C0%7C0%7C637714392203200313%7CUnknown%7CTWFpbGZsb >> 3d8eyJWIj >> > >> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100 >> 0&am >> > >> p;sdata=snPpRYLGeJtTpNGle1YHZAvevcABbgLkgOsffiNzQPw%3D&reserved >> =0 >> > normally use case will not see the issue. >> > To avoid this issue happy again when we run the test case , it will be nice to >> add a check before the transfer is called. >> > And we can see that it really needs to have a check here to make ITG &kernel >> happy. >> >> You're missing my point. What is the root cause? Why do you have the aux >> device or connector registered before ->transfer function is initialized. I don't >> think you should do that. >> >> BR, >> Jani. >> > > One potential IGT fix patch to resolve the test case failure is: > > tests/amdgpu/amd_bypass.c > data->pipe_crc = igt_pipe_crc_new(data->drm_fd, data->pipe_id, > - AMDGPU_PIPE_CRC_SOURCE_DPRX); > + INTEL_PIPE_CRC_SOURCE_AUTO); > The kernel panic error gone after change "dprx" to "auto" in the IGT test. > > In my view ,the IGT amdgpu bypass test will do some common setup work including crc piple, source. > When the IGT sets up a new CRC pipe capture source for amdgpu bypass test, the SOURCE was set as "dprx" instead of "auto" > It makes "amdgpu_dm_crtc_set_crc_source()" failed to set correct AUX and it's transfer function invalid . > The system I tested use HDMI port connected to monitor . > > amdgpu_dm_crtc_set_crc_source-> (aux = (aconn->port) ? &aconn->port->aux : &aconn->dm_dp_aux.aux;) > drm_dp_start_crc -> > drm_dp_dpcd_readb-> aux->transfer is NULL, issue here. > The fix will use the "auto" keyword, which will let the driver select a default source of frame CRCs for this CRTC. > > Correct me if have some wrong points. Apparently I'm completely failing to communicate my POV to you. If you have a kernel oops, the fix needs to be in the kernel, not IGT. The question is, why is it possible for IGT (or any userspace) to trigger AUX communication when the ->transfer function is not set? In my opinion, the kernel driver should not have exposed the interface at all if the ->transfer function is not set. The interface is useless without the ->transfer function. IMO, that's the bug. BR, Jani. > > Thank you! > Perry. > >> >> > >> > Perry. >> > >> >> >> >> > >> >> > BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD >> >> > 0 P4D 0 >> >> > Oops: 0010 [#1] SMP NOPTI >> >> > RIP: 0010:0x0 >> >> > Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. >> >> > RSP: 0018:ffffa8d64225bab8 EFLAGS: 00010246 >> >> > RAX: 0000000000000000 RBX: 0000000000000020 RCX: ffffa8d64225bb5e >> >> > RDX: ffff93151d921880 RSI: ffffa8d64225bac8 RDI: ffff931511a1a9d8 >> >> > RBP: ffffa8d64225bb10 R08: 0000000000000001 R09: ffffa8d64225ba60 >> >> > R10: 0000000000000002 R11: 000000000000000d R12: 0000000000000001 >> >> > R13: 0000000000000000 R14: ffffa8d64225bb5e R15: ffff931511a1a9d8 >> >> > FS: 00007ff8ea7fa9c0(0000) GS:ffff9317fe6c0000(0000) >> >> > knlGS:0000000000000000 >> >> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> >> > CR2: ffffffffffffffd6 CR3: 000000010d5a4000 CR4: 0000000000750ee0 >> >> > PKRU: 55555554 >> >> > Call Trace: >> >> > drm_dp_dpcd_access+0x72/0x110 [drm_kms_helper] >> >> > drm_dp_dpcd_read+0xb7/0xf0 [drm_kms_helper] >> >> > drm_dp_start_crc+0x38/0xb0 [drm_kms_helper] >> >> > amdgpu_dm_crtc_set_crc_source+0x1ae/0x3e0 [amdgpu] >> >> > crtc_crc_open+0x174/0x220 [drm] >> >> > full_proxy_open+0x168/0x1f0 >> >> > ? open_proxy_open+0x100/0x100 >> >> > do_dentry_open+0x156/0x370 >> >> > vfs_open+0x2d/0x30 >> >> > >> >> > v2: fix some typo >> >> > >> >> > Signed-off-by: Perry Yuan >> >> > --- >> >> > drivers/gpu/drm/drm_dp_helper.c | 4 ++++ >> >> > 1 file changed, 4 insertions(+) >> >> > >> >> > diff --git a/drivers/gpu/drm/drm_dp_helper.c >> >> > b/drivers/gpu/drm/drm_dp_helper.c index 6d0f2c447f3b..76b28396001a >> >> > 100644 >> >> > --- a/drivers/gpu/drm/drm_dp_helper.c >> >> > +++ b/drivers/gpu/drm/drm_dp_helper.c >> >> > @@ -260,6 +260,10 @@ static int drm_dp_dpcd_access(struct >> >> > drm_dp_aux >> >> *aux, u8 request, >> >> > msg.buffer = buffer; >> >> > msg.size = size; >> >> > >> >> > + /* No transfer function is set, so not an available DP connector */ >> >> > + if (!aux->transfer) >> >> > + return -EINVAL; >> >> > + >> >> > mutex_lock(&aux->hw_mutex); >> >> > >> >> > /* >> >> >> >> -- >> >> Jani Nikula, Intel Open Source Graphics Center >> >> -- >> Jani Nikula, Intel Open Source Graphics Center -- Jani Nikula, Intel Open Source Graphics Center