From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E33E6C433E1 for ; Sat, 25 Jul 2020 02:38:11 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B486F2070E for ; Sat, 25 Jul 2020 02:38:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B486F2070E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=bugzilla.kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 727B26EA57; Sat, 25 Jul 2020 02:38:10 +0000 (UTC) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by gabe.freedesktop.org (Postfix) with ESMTPS id D91676EA57 for ; Sat, 25 Jul 2020 02:38:08 +0000 (UTC) From: bugzilla-daemon@bugzilla.kernel.org To: dri-devel@lists.freedesktop.org Subject: [Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail Date: Sat, 25 Jul 2020 02:38:07 +0000 X-Bugzilla-Reason: None X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: AssignedTo drivers_video-dri@kernel-bugs.osdl.org X-Bugzilla-Product: Drivers X-Bugzilla-Component: Video(DRI - non Intel) X-Bugzilla-Version: 2.5 X-Bugzilla-Keywords: X-Bugzilla-Severity: blocking X-Bugzilla-Who: mnrzk@protonmail.com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: drivers_video-dri@kernel-bugs.osdl.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: https://bugzilla.kernel.org/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #93 from mnrzk@protonmail.com --- (In reply to Nicholas Kazlauskas from comment #92) > This sounds very similar to a bug I fixed a year ago but that issue was with > freeing the dc_state. > > https://bugzilla.kernel.org/show_bug.cgi?id=204181 > > 1. Client requests non-blocking Commit #1, has a new dc_state #1, > state is swapped, commit tail is deferred to work queue > > 2. Client requests non-blocking Commit #2, has a new dc_state #2, > state is swapped, commit tail is deferred to work queue > > 3. Commit #2 work starts before Commit #1, commit tail finishes, > atomic state is cleared, dc_state #1 is freed > > 4. Commit #1 work starts after Commit #2, uses dc_state #1, NULL pointer > deref. > > This issue was fixed, but it occurred under similar conditions - heavy > system load and frequent pageflipping. > > However, in the case of dm_state things can't be solved in the same manner. > Commit #2 can't free Commit #1's commit - only the commit tail for Commit #1 > can free it along with the IOCTL caller. > > I don't know if this is going down any of the deadlock paths in DRM core > because that might trigger strange behavior as well with clearing/putting > the dm_state. > > If someone who can reproduce this issue can produce a dmesg log with the DRM > IOCTLs logged (I think drm.debug=0x54 should work) then I should be able to > examine the IOCTL sequence in more detail. Yes, this actually seems quite similar to that bug. Perhaps it's something like that bug but with dm_state instead? Also, some more observations I've made: While dm_state is encountering a use-after-free bug, it does not seem like state as a whole is. The KASAN bug report only states that reading from dm_state is invalid, but the same cannot be said about state. Furthermore, dm_state seems to be used in two separate commits and is being freed after one commit is complete. This creates a race between the two commits where the completion of one commit before the other calls dm_atomic_get_new_state causes a use-after-free. I think the bug works something like this. Keep in mind that I haven't worked with this code outside of this bug report so there may be a few misconceptions: 1. Client requests non-blocking Commit #1, has a new dm_state #1, state is swapped, commit tail is deferred to work queue 2. Client requests non-blocking Commit #2, has a new dm_state #2, state is swapped, commit tail is deferred to work queue 3. Commit #2 work starts before Commit #1, commit tail finishes, atomic state is cleared, dm_state #1 is freed 4. Commit #1 work starts after Commit #2, uses dm_state #1 (use-after-free), reads bad context pointer and dereferences freelist pointer instead. So I would agree that this is very similar to the dc_state bug (I even based that explanation on yours). Perhaps that bug you fixed also affected dm_state as a whole but only caused an issue with dc_state at the time? -- You are receiving this mail because: You are watching the assignee of the bug. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel