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;
Date:   Fri, 24 Jul 2020 21:59:14 -0700
From:   Duncan <1i5t5.duncan@cox.net>
To:     Mazin Rezk <mnrzk@protonmail.com>
Cc:     Paul Menzel <pmenzel@molgen.mpg.de>,
        Kees Cook <keescook@chromium.org>,
        linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
        dri-devel@lists.freedesktop.org,
        Andrew Morton <akpm@linux-foundation.org>,
        Christian =?UTF-8?B?S8O2bmln?= <christian.koenig@amd.com>,
        Harry Wentland <Harry.Wentland@amd.com>,
        Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>,
        sunpeng.li@amd.com, Alexander Deucher <Alexander.Deucher@amd.com>,
        mphantomx@yahoo.com.br, regressions@leemhuis.info,
        anthony.ruhier@gmail.com
Subject: Re: [PATCH] amdgpu_dm: fix nonblocking atomic commit use-after-free
Message-ID: <20200724215914.6297cc7e@ws>
In-Reply-To: <_vGVoFJcOuoIAvGYtkyemUvqEFeZ-AdO4Jk8wsyVv3MwO-6NEVtULxnZzuBJNeHNkCsQ5Kxn5TPQ_VJ6qyj9wXXXX8v-hc3HptnCAu0UYsk=@protonmail.com>
References: <YIGsJ9LlFquvBI2iWPKhJwjKBwDUr_C-38oVpLJJHJ5rDCY_Zrrv392o6UPNxHoeQrcpLYC9U4fZdpD9ilz6Amg2IxkSexGLQMCQIBek8rc=@protonmail.com>
        <202007231524.A24720C@keescook>
        <a86cba0b-4513-e7c3-ae75-bb331433f664@molgen.mpg.de>
        <202007241016.922B094AAA@keescook>
        <3c92db94-3b62-a70b-8ace-f5e34e8f268f@molgen.mpg.de>
        <_vGVoFJcOuoIAvGYtkyemUvqEFeZ-AdO4Jk8wsyVv3MwO-6NEVtULxnZzuBJNeHNkCsQ5Kxn5TPQ_VJ6qyj9wXXXX8v-hc3HptnCAu0UYsk=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sat, 25 Jul 2020 03:03:52 +0000
Mazin Rezk <mnrzk@protonmail.com> wrote:

> > Am 24.07.20 um 19:33 schrieb Kees Cook:
> >  
> > > There was a fix to disable the async path for this driver that
> > > worked around the bug too, yes? That seems like a safer and more
> > > focused change that doesn't revert the SLUB defense for all
> > > users, and would actually provide a complete, I think, workaround
> 
> That said, I haven't seen the async disabling patch. If you could
> link to it, I'd be glad to test it out and perhaps we can use that
> instead.

I'm confused.  Not to put words in Kees' mouth; /I/ am confused (which
admittedly could well be just because I make no claims to be a
coder and am simply reading the bug and thread, but I'd appreciate some
"unconfusing" anyway).

My interpretation of the "async disabling" reference was that it was to
comment #30 on the bug:

https://bugzilla.kernel.org/show_bug.cgi?id=207383#c30

... which (if I'm not confused on this point too) appears to be yours.
There it was stated...

>>>>
I've also found that this bug exclusively occurs when commit_work is on
the workqueue. After forcing drm_atomic_helper_commit to run all of the
commits without adding to the workqueue and running the OS, the issue
seems to have disappeared.
<<<<

Would not forcing all commits to run directly, without placing them on
the workqueue, be "async disabling"?  That's what I /thought/ he was
referencing.

OTOH your base/context swap idea sounds like a possibly "less
disturbance" workaround, if it works, and given the point in the
commit cycle... (But if it's out Sunday it's likely too late to test
and get it in now anyway; if it's another week, tho...)

-- 
Duncan - No HTML messages please; they are filtered as spam.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman