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:   Mon, 26 Oct 2020 00:29:00 -0400
From:   "Alex Xu (Hello71)" <alex_y_xu@yahoo.ca>
Subject: amdgpu crashes on OOM
To:     Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>,
        alexander.deucher@amd.com, Harry Wentland <harry.wentland@amd.com>,
        Leo Li <sunpeng.li@amd.com>, amd-gfx@lists.freedesktop.org
Cc:     linux-kernel@vger.kernel.org
MIME-Version: 1.0
Message-Id: <1603684905.h43s1t0y05.none@localhost>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
References: <1603684905.h43s1t0y05.none.ref@localhost>
Content-Length: 2209
Precedence: bulk

Hi,

I frequently encounter OOM on my system, mostly due to my own fault.=20
Recently, I noticed that not only does a swap storm happen and OOM=20
killer gets invoked, but the graphics output freezes permanently.=20
Checking the kernel messages, I see:

kworker/u24:4: page allocation failure: order:5, mode:0x40dc0(GFP_KERNEL|__=
GFP_COMP|__GFP_ZERO), nodemask=3D(null)
CPU: 6 PID: 279469 Comm: kworker/u24:4 Tainted: G        W         5.9.0-14=
732-g20b1adb60cf6 #2
Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B450 Pro4, BIO=
S P4.20 06/18/2020
Workqueue: events_unbound commit_work
Call Trace:
 ? dump_stack+0x57/0x6a
 ? warn_alloc.cold+0x69/0xcd
 ? __alloc_pages_direct_compact+0xfb/0x116
 ? __alloc_pages_slowpath.constprop.0+0x9c2/0xc14
 ? __alloc_pages_nodemask+0x143/0x167
 ? kmalloc_order+0x24/0x64
 ? dc_create_state+0x1a/0x4d
 ? amdgpu_dm_atomic_commit_tail+0x1b19/0x227d

followed by:

WARNING: CPU: 6 PID: 279469 at drivers/gpu/drm/amd/amdgpu/../display/amdgpu=
_dm/amdgpu_dm.c:7511 amdgpu_dm_atomic_commit_tail+0x217c/0x227d

followed by:

BUG: unable to handle page fault for address: 0000000000012480
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
[ ... ]
RIP: 0010:dc_resource_state_copy_construct+0x10/0x455
[ ... ]
Call Trace:
 ? amdgpu_dm_atomic_commit_tail+0x2193/0x227

This area of code is quite odd:

dc_state_temp =3D dc_create_state(dm->dc);
ASSERT(dc_state_temp);
dc_state =3D dc_state_temp;
dc_resource_state_copy_construct_current(dm->dc, dc_state);

This ASSERT macro is misleading: unless CONFIG_DEBUG_KERNEL_DC is set,=20
it is actually WARN_ON_ONCE(!(expr)). Therefore, this code fails to=20
allocate memory (causing a warning to be printed), prints another=20
warning that it failed, then proceeds to immediately dereference it,=20
crashing the thread (and the kernel if panic_on_oops is set).

While I am not by any means a graphics or kernel expert, it seems to me=20
like there should be a better solution than crashing. If nothing else,=20
the OOM killer should be invoked and the operation retried. We may lose=20
some frames or see some corruption, but that's far better than totally=20
breaking.

Thanks,
Alex.