[PATCH AUTOSEL 5.10 01/22] drm/radeon: Fix integer overflow in radeon_cs_parser_init

[PATCH AUTOSEL 5.10 01/22] drm/radeon: Fix integer overflow in radeon_cs_parser_init

[Sasha Levin]

From: hackyzh002 <hackyzh002@gmail.com>

[ Upstream commit f828b681d0cd566f86351c0b913e6cb6ed8c7b9c ]

The type of size is unsigned, if size is 0x40000000, there will be an
integer overflow, size will be zero after size *= sizeof(uint32_t),
will cause uninitialized memory to be referenced later

Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: hackyzh002 <hackyzh002@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/gpu/drm/radeon/radeon_cs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c b/drivers/gpu/drm/radeon/radeon_cs.c
index a78b60b62caf2..87a57e5588a28 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -271,7 +271,8 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void *data)
 {
 	struct drm_radeon_cs *cs = data;
 	uint64_t *chunk_array_ptr;
-	unsigned size, i;
+	u64 size;
+	unsigned i;
 	u32 ring = RADEON_CS_RING_GFX;
 	s32 priority = 0;
 
-- 
2.39.2

[PATCH AUTOSEL 5.10 13/22] drm/amdgpu: install stub fence into potential unused fence pointers

[Sasha Levin]

From: Lang Yu <Lang.Yu@amd.com>

[ Upstream commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 ]

When using cpu to update page tables, vm update fences are unused.
Install stub fence into these fence pointers instead of NULL
to avoid NULL dereference when calling dma_fence_wait() on them.

Suggested-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Lang Yu <Lang.Yu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 45b1f00c59680..c19f472ec60da 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2155,6 +2155,7 @@ struct amdgpu_bo_va *amdgpu_vm_bo_add(struct amdgpu_device *adev,
 	amdgpu_vm_bo_base_init(&bo_va->base, vm, bo);
 
 	bo_va->ref_count = 1;
+	bo_va->last_pt_update = dma_fence_get_stub();
 	INIT_LIST_HEAD(&bo_va->valids);
 	INIT_LIST_HEAD(&bo_va->invalids);
 
@@ -2867,7 +2868,8 @@ int amdgpu_vm_init(struct amdgpu_device *adev, struct amdgpu_vm *vm,
 		vm->update_funcs = &amdgpu_vm_cpu_funcs;
 	else
 		vm->update_funcs = &amdgpu_vm_sdma_funcs;
-	vm->last_update = NULL;
+
+	vm->last_update = dma_fence_get_stub();
 	vm->last_unlocked = dma_fence_get_stub();
 
 	mutex_init(&vm->eviction_lock);
@@ -3042,7 +3044,7 @@ int amdgpu_vm_make_compute(struct amdgpu_device *adev, struct amdgpu_vm *vm,
 		vm->update_funcs = &amdgpu_vm_sdma_funcs;
 	}
 	dma_fence_put(vm->last_update);
-	vm->last_update = NULL;
+	vm->last_update = dma_fence_get_stub();
 	vm->is_compute_context = true;
 
 	if (vm->pasid) {
-- 
2.39.2

Re: [PATCH AUTOSEL 5.10 13/22] drm/amdgpu: install stub fence into potential unused fence pointers

[Chia-I Wu]

On Sun, Jul 23, 2023 at 6:24 PM Sasha Levin <sashal@kernel.org> wrote:
>
> From: Lang Yu <Lang.Yu@amd.com>
>
> [ Upstream commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 ]
>
> When using cpu to update page tables, vm update fences are unused.
> Install stub fence into these fence pointers instead of NULL
> to avoid NULL dereference when calling dma_fence_wait() on them.
>
> Suggested-by: Christian König <christian.koenig@amd.com>
> Signed-off-by: Lang Yu <Lang.Yu@amd.com>
> Reviewed-by: Christian König <christian.koenig@amd.com>
> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)

We start getting this warning spew on chromeos, likely from
dma_fence_is_later because the stub fence is on a different timeline:

[  273.334767] WARNING: CPU: 1 PID: 13383 at
include/linux/dma-fence.h:478 amdgpu_sync_keep_later+0x95/0xbd
[  273.334769] Modules linked in: snd_seq_dummy snd_seq snd_seq_device
bridge stp llc tun vhost_vsock vhost vhost_iotlb
vmw_vsock_virtio_transport_common vsock 8021q veth lzo_rle
lzo_compress zram uinput snd_acp_sof_mach snd_acp_mach snd_soc_dmic
xt_cgroup rfcomm xt_MASQUERADE cmac algif_hash algif_skcipher af_alg
btusb btrtl btintel btbcm rtw89_8852ae rtw89_pci rtw89_8852a
rtw89_core snd_sof_amd_renoir snd_sof_xtensa_dsp snd_sof_amd_acp
snd_acp_pci snd_acp_config snd_soc_acpi snd_pci_acp3x snd_sof_pci
snd_sof snd_hda_codec_hdmi snd_sof_utils snd_hda_intel mac80211
snd_intel_dspcfg snd_hda_codec cros_ec_typec snd_hwdep roles
snd_hda_core typec snd_soc_rt5682s snd_soc_rt1019 snd_soc_rl6231
ip6table_nat i2c_piix4 fuse bluetooth ecdh_generic ecc cfg80211
iio_trig_sysfs cros_ec_lid_angle cros_ec_sensors cros_ec_sensors_core
industrialio_triggered_buffer kfifo_buf industrialio cros_ec_sensorhub
r8153_ecm cdc_ether usbnet r8152 mii uvcvideo videobuf2_vmalloc
videobuf2_memops videobuf2_v4l2
[  273.334795]  videobuf2_common joydev
[  273.334799] CPU: 1 PID: 13383 Comm: chrome:cs0 Tainted: G        W
       5.10.192-23384-g3d3f0f0c5e4f #1
fe1e7e3b7510aa7b8e01701478119255f825a36f
[  273.334800] Hardware name: Google Dewatt/Dewatt, BIOS
Google_Dewatt.14500.347.0 03/30/2023
[  273.334802] RIP: 0010:amdgpu_sync_keep_later+0x95/0xbd
[  273.334804] Code: 00 00 b8 01 00 00 00 f0 0f c1 43 38 85 c0 74 26
8d 48 01 09 c1 78 24 49 89 1e 5b 41 5e 5d c3 cc cc cc cc e8 4a 94 ac
ff eb ce <0f> 0b 49 8b 06 48 85 c0 75 af eb c2 be 02 00 00 00 48 8d 7b
38 e8
[  273.334805] RSP: 0018:ffffb222c1817b50 EFLAGS: 00010293
[  273.334807] RAX: ffffffff89bfc838 RBX: ffff8aa425e9ed00 RCX: 0000000000000000
[  273.334808] RDX: ffff8aa426156a98 RSI: ffff8aa425e9ed00 RDI: ffff8aa432518918
[  273.334810] RBP: ffffb222c1817b60 R08: ffff8aa43ca6c0a0 R09: ffff8aa33af3c9a0
[  273.334811] R10: fffffcf8c5986600 R11: ffffffff87a00fce R12: 0000000000000098
[  273.334812] R13: 00000000005e2a00 R14: ffff8aa432518918 R15: 0000000000000000
[  273.334814] FS:  00007e70f8694640(0000) GS:ffff8aa4e6080000(0000)
knlGS:0000000000000000
[  273.334816] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  273.334817] CR2: 00007e70ea049020 CR3: 0000000178e6e000 CR4: 0000000000750ee0
[  273.334818] PKRU: 55555554
[  273.334819] Call Trace:
[  273.334822]  ? __warn+0xa3/0x131
[  273.334824]  ? amdgpu_sync_keep_later+0x95/0xbd
[  273.334826]  ? report_bug+0x97/0xfa
[  273.334829]  ? handle_bug+0x41/0x66
[  273.334832]  ? exc_invalid_op+0x1b/0x72
[  273.334835]  ? asm_exc_invalid_op+0x12/0x20
[  273.334837]  ? native_sched_clock+0x9a/0x9a
[  273.334840]  ? amdgpu_sync_keep_later+0x95/0xbd
[  273.334843]  amdgpu_sync_vm_fence+0x23/0x39
[  273.334846]  amdgpu_cs_ioctl+0x1782/0x1e56
[  273.334851]  ? amdgpu_cs_report_moved_bytes+0x5f/0x5f
[  273.334854]  drm_ioctl_kernel+0xdf/0x150
[  273.334858]  drm_ioctl+0x1f5/0x3d2
[  273.334928]  ? amdgpu_cs_report_moved_bytes+0x5f/0x5f
[  273.334932]  amdgpu_drm_ioctl+0x49/0x81
[  273.334935]  __x64_sys_ioctl+0x7d/0xc8
[  273.334937]  do_syscall_64+0x42/0x54
[  273.334939]  entry_SYSCALL_64_after_hwframe+0x4a/0xaf
[  273.334941] RIP: 0033:0x7e70ff797649
[  273.334943] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10
c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00
00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1d 48 8b 45 c8 64 48 2b 04 25 28
00 00
[  273.334945] RSP: 002b:00007e70f8693170 EFLAGS: 00000246 ORIG_RAX:
0000000000000010
[  273.334947] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007e70ff797649
[  273.334948] RDX: 00007e70f8693248 RSI: 00000000c0186444 RDI: 0000000000000013
[  273.334950] RBP: 00007e70f86931c0 R08: 00007e70f8693350 R09: 00007e70f8693340
[  273.334951] R10: 000000000000000a R11: 0000000000000246 R12: 00000000c0186444
[  273.334952] R13: 00007e70f8693380 R14: 00007e70f8693248 R15: 0000000000000013
[  273.334954] ---[ end trace fc066a0fcea39e8c ]---

Re: [PATCH AUTOSEL 5.10 13/22] drm/amdgpu: install stub fence into potential unused fence pointers

[Christian König]

Am 30.08.23 um 20:53 schrieb Chia-I Wu:
> On Sun, Jul 23, 2023 at 6:24 PM Sasha Levin <sashal@kernel.org> wrote:
>> From: Lang Yu <Lang.Yu@amd.com>
>>
>> [ Upstream commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 ]
>>
>> When using cpu to update page tables, vm update fences are unused.
>> Install stub fence into these fence pointers instead of NULL
>> to avoid NULL dereference when calling dma_fence_wait() on them.
>>
>> Suggested-by: Christian König <christian.koenig@amd.com>
>> Signed-off-by: Lang Yu <Lang.Yu@amd.com>
>> Reviewed-by: Christian König <christian.koenig@amd.com>
>> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++++--
>>   1 file changed, 4 insertions(+), 2 deletions(-)
> We start getting this warning spew on chromeos

Yeah because the older kernels still kept track of the last VM fence in 
the syncobj.

This patch here should probably not have been back ported.

Why was that done anyway? The upstream commit doesn't have a CC stable 
and this is only a bug fix for a new feature not present on older kernels.

Regards,
Christian.


> , likely from
> dma_fence_is_later because the stub fence is on a different timeline:
>
> [  273.334767] WARNING: CPU: 1 PID: 13383 at
> include/linux/dma-fence.h:478 amdgpu_sync_keep_later+0x95/0xbd
> [  273.334769] Modules linked in: snd_seq_dummy snd_seq snd_seq_device
> bridge stp llc tun vhost_vsock vhost vhost_iotlb
> vmw_vsock_virtio_transport_common vsock 8021q veth lzo_rle
> lzo_compress zram uinput snd_acp_sof_mach snd_acp_mach snd_soc_dmic
> xt_cgroup rfcomm xt_MASQUERADE cmac algif_hash algif_skcipher af_alg
> btusb btrtl btintel btbcm rtw89_8852ae rtw89_pci rtw89_8852a
> rtw89_core snd_sof_amd_renoir snd_sof_xtensa_dsp snd_sof_amd_acp
> snd_acp_pci snd_acp_config snd_soc_acpi snd_pci_acp3x snd_sof_pci
> snd_sof snd_hda_codec_hdmi snd_sof_utils snd_hda_intel mac80211
> snd_intel_dspcfg snd_hda_codec cros_ec_typec snd_hwdep roles
> snd_hda_core typec snd_soc_rt5682s snd_soc_rt1019 snd_soc_rl6231
> ip6table_nat i2c_piix4 fuse bluetooth ecdh_generic ecc cfg80211
> iio_trig_sysfs cros_ec_lid_angle cros_ec_sensors cros_ec_sensors_core
> industrialio_triggered_buffer kfifo_buf industrialio cros_ec_sensorhub
> r8153_ecm cdc_ether usbnet r8152 mii uvcvideo videobuf2_vmalloc
> videobuf2_memops videobuf2_v4l2
> [  273.334795]  videobuf2_common joydev
> [  273.334799] CPU: 1 PID: 13383 Comm: chrome:cs0 Tainted: G        W
>         5.10.192-23384-g3d3f0f0c5e4f #1
> fe1e7e3b7510aa7b8e01701478119255f825a36f
> [  273.334800] Hardware name: Google Dewatt/Dewatt, BIOS
> Google_Dewatt.14500.347.0 03/30/2023
> [  273.334802] RIP: 0010:amdgpu_sync_keep_later+0x95/0xbd
> [  273.334804] Code: 00 00 b8 01 00 00 00 f0 0f c1 43 38 85 c0 74 26
> 8d 48 01 09 c1 78 24 49 89 1e 5b 41 5e 5d c3 cc cc cc cc e8 4a 94 ac
> ff eb ce <0f> 0b 49 8b 06 48 85 c0 75 af eb c2 be 02 00 00 00 48 8d 7b
> 38 e8
> [  273.334805] RSP: 0018:ffffb222c1817b50 EFLAGS: 00010293
> [  273.334807] RAX: ffffffff89bfc838 RBX: ffff8aa425e9ed00 RCX: 0000000000000000
> [  273.334808] RDX: ffff8aa426156a98 RSI: ffff8aa425e9ed00 RDI: ffff8aa432518918
> [  273.334810] RBP: ffffb222c1817b60 R08: ffff8aa43ca6c0a0 R09: ffff8aa33af3c9a0
> [  273.334811] R10: fffffcf8c5986600 R11: ffffffff87a00fce R12: 0000000000000098
> [  273.334812] R13: 00000000005e2a00 R14: ffff8aa432518918 R15: 0000000000000000
> [  273.334814] FS:  00007e70f8694640(0000) GS:ffff8aa4e6080000(0000)
> knlGS:0000000000000000
> [  273.334816] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [  273.334817] CR2: 00007e70ea049020 CR3: 0000000178e6e000 CR4: 0000000000750ee0
> [  273.334818] PKRU: 55555554
> [  273.334819] Call Trace:
> [  273.334822]  ? __warn+0xa3/0x131
> [  273.334824]  ? amdgpu_sync_keep_later+0x95/0xbd
> [  273.334826]  ? report_bug+0x97/0xfa
> [  273.334829]  ? handle_bug+0x41/0x66
> [  273.334832]  ? exc_invalid_op+0x1b/0x72
> [  273.334835]  ? asm_exc_invalid_op+0x12/0x20
> [  273.334837]  ? native_sched_clock+0x9a/0x9a
> [  273.334840]  ? amdgpu_sync_keep_later+0x95/0xbd
> [  273.334843]  amdgpu_sync_vm_fence+0x23/0x39
> [  273.334846]  amdgpu_cs_ioctl+0x1782/0x1e56
> [  273.334851]  ? amdgpu_cs_report_moved_bytes+0x5f/0x5f
> [  273.334854]  drm_ioctl_kernel+0xdf/0x150
> [  273.334858]  drm_ioctl+0x1f5/0x3d2
> [  273.334928]  ? amdgpu_cs_report_moved_bytes+0x5f/0x5f
> [  273.334932]  amdgpu_drm_ioctl+0x49/0x81
> [  273.334935]  __x64_sys_ioctl+0x7d/0xc8
> [  273.334937]  do_syscall_64+0x42/0x54
> [  273.334939]  entry_SYSCALL_64_after_hwframe+0x4a/0xaf
> [  273.334941] RIP: 0033:0x7e70ff797649
> [  273.334943] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10
> c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00
> 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1d 48 8b 45 c8 64 48 2b 04 25 28
> 00 00
> [  273.334945] RSP: 002b:00007e70f8693170 EFLAGS: 00000246 ORIG_RAX:
> 0000000000000010
> [  273.334947] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007e70ff797649
> [  273.334948] RDX: 00007e70f8693248 RSI: 00000000c0186444 RDI: 0000000000000013
> [  273.334950] RBP: 00007e70f86931c0 R08: 00007e70f8693350 R09: 00007e70f8693340
> [  273.334951] R10: 000000000000000a R11: 0000000000000246 R12: 00000000c0186444
> [  273.334952] R13: 00007e70f8693380 R14: 00007e70f8693248 R15: 0000000000000013
> [  273.334954] ---[ end trace fc066a0fcea39e8c ]---

Re: [PATCH AUTOSEL 5.10 13/22] drm/amdgpu: install stub fence into potential unused fence pointers

[Greg KH]

On Wed, Aug 30, 2023 at 11:53:29AM -0700, Chia-I Wu wrote:
> On Sun, Jul 23, 2023 at 6:24 PM Sasha Levin <sashal@kernel.org> wrote:
> >
> > From: Lang Yu <Lang.Yu@amd.com>
> >
> > [ Upstream commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 ]
> >
> > When using cpu to update page tables, vm update fences are unused.
> > Install stub fence into these fence pointers instead of NULL
> > to avoid NULL dereference when calling dma_fence_wait() on them.
> >
> > Suggested-by: Christian König <christian.koenig@amd.com>
> > Signed-off-by: Lang Yu <Lang.Yu@amd.com>
> > Reviewed-by: Christian König <christian.koenig@amd.com>
> > Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
> > Signed-off-by: Sasha Levin <sashal@kernel.org>
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> We start getting this warning spew on chromeos, likely from
> dma_fence_is_later because the stub fence is on a different timeline:
> 
> [  273.334767] WARNING: CPU: 1 PID: 13383 at
> include/linux/dma-fence.h:478 amdgpu_sync_keep_later+0x95/0xbd
> [  273.334769] Modules linked in: snd_seq_dummy snd_seq snd_seq_device
> bridge stp llc tun vhost_vsock vhost vhost_iotlb
> vmw_vsock_virtio_transport_common vsock 8021q veth lzo_rle
> lzo_compress zram uinput snd_acp_sof_mach snd_acp_mach snd_soc_dmic
> xt_cgroup rfcomm xt_MASQUERADE cmac algif_hash algif_skcipher af_alg
> btusb btrtl btintel btbcm rtw89_8852ae rtw89_pci rtw89_8852a
> rtw89_core snd_sof_amd_renoir snd_sof_xtensa_dsp snd_sof_amd_acp
> snd_acp_pci snd_acp_config snd_soc_acpi snd_pci_acp3x snd_sof_pci
> snd_sof snd_hda_codec_hdmi snd_sof_utils snd_hda_intel mac80211
> snd_intel_dspcfg snd_hda_codec cros_ec_typec snd_hwdep roles
> snd_hda_core typec snd_soc_rt5682s snd_soc_rt1019 snd_soc_rl6231
> ip6table_nat i2c_piix4 fuse bluetooth ecdh_generic ecc cfg80211
> iio_trig_sysfs cros_ec_lid_angle cros_ec_sensors cros_ec_sensors_core
> industrialio_triggered_buffer kfifo_buf industrialio cros_ec_sensorhub
> r8153_ecm cdc_ether usbnet r8152 mii uvcvideo videobuf2_vmalloc
> videobuf2_memops videobuf2_v4l2
> [  273.334795]  videobuf2_common joydev
> [  273.334799] CPU: 1 PID: 13383 Comm: chrome:cs0 Tainted: G        W
>        5.10.192-23384-g3d3f0f0c5e4f #1
> fe1e7e3b7510aa7b8e01701478119255f825a36f
> [  273.334800] Hardware name: Google Dewatt/Dewatt, BIOS
> Google_Dewatt.14500.347.0 03/30/2023
> [  273.334802] RIP: 0010:amdgpu_sync_keep_later+0x95/0xbd
> [  273.334804] Code: 00 00 b8 01 00 00 00 f0 0f c1 43 38 85 c0 74 26
> 8d 48 01 09 c1 78 24 49 89 1e 5b 41 5e 5d c3 cc cc cc cc e8 4a 94 ac
> ff eb ce <0f> 0b 49 8b 06 48 85 c0 75 af eb c2 be 02 00 00 00 48 8d 7b
> 38 e8
> [  273.334805] RSP: 0018:ffffb222c1817b50 EFLAGS: 00010293
> [  273.334807] RAX: ffffffff89bfc838 RBX: ffff8aa425e9ed00 RCX: 0000000000000000
> [  273.334808] RDX: ffff8aa426156a98 RSI: ffff8aa425e9ed00 RDI: ffff8aa432518918
> [  273.334810] RBP: ffffb222c1817b60 R08: ffff8aa43ca6c0a0 R09: ffff8aa33af3c9a0
> [  273.334811] R10: fffffcf8c5986600 R11: ffffffff87a00fce R12: 0000000000000098
> [  273.334812] R13: 00000000005e2a00 R14: ffff8aa432518918 R15: 0000000000000000
> [  273.334814] FS:  00007e70f8694640(0000) GS:ffff8aa4e6080000(0000)
> knlGS:0000000000000000
> [  273.334816] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [  273.334817] CR2: 00007e70ea049020 CR3: 0000000178e6e000 CR4: 0000000000750ee0
> [  273.334818] PKRU: 55555554
> [  273.334819] Call Trace:
> [  273.334822]  ? __warn+0xa3/0x131
> [  273.334824]  ? amdgpu_sync_keep_later+0x95/0xbd
> [  273.334826]  ? report_bug+0x97/0xfa
> [  273.334829]  ? handle_bug+0x41/0x66
> [  273.334832]  ? exc_invalid_op+0x1b/0x72
> [  273.334835]  ? asm_exc_invalid_op+0x12/0x20
> [  273.334837]  ? native_sched_clock+0x9a/0x9a
> [  273.334840]  ? amdgpu_sync_keep_later+0x95/0xbd
> [  273.334843]  amdgpu_sync_vm_fence+0x23/0x39
> [  273.334846]  amdgpu_cs_ioctl+0x1782/0x1e56
> [  273.334851]  ? amdgpu_cs_report_moved_bytes+0x5f/0x5f
> [  273.334854]  drm_ioctl_kernel+0xdf/0x150
> [  273.334858]  drm_ioctl+0x1f5/0x3d2
> [  273.334928]  ? amdgpu_cs_report_moved_bytes+0x5f/0x5f
> [  273.334932]  amdgpu_drm_ioctl+0x49/0x81
> [  273.334935]  __x64_sys_ioctl+0x7d/0xc8
> [  273.334937]  do_syscall_64+0x42/0x54
> [  273.334939]  entry_SYSCALL_64_after_hwframe+0x4a/0xaf
> [  273.334941] RIP: 0033:0x7e70ff797649
> [  273.334943] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10
> c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00
> 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1d 48 8b 45 c8 64 48 2b 04 25 28
> 00 00
> [  273.334945] RSP: 002b:00007e70f8693170 EFLAGS: 00000246 ORIG_RAX:
> 0000000000000010
> [  273.334947] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007e70ff797649
> [  273.334948] RDX: 00007e70f8693248 RSI: 00000000c0186444 RDI: 0000000000000013
> [  273.334950] RBP: 00007e70f86931c0 R08: 00007e70f8693350 R09: 00007e70f8693340
> [  273.334951] R10: 000000000000000a R11: 0000000000000246 R12: 00000000c0186444
> [  273.334952] R13: 00007e70f8693380 R14: 00007e70f8693248 R15: 0000000000000013
> [  273.334954] ---[ end trace fc066a0fcea39e8c ]---

Thanks, I'll go revert this now.

greg k-h

Re: [PATCH AUTOSEL 5.10 13/22] drm/amdgpu: install stub fence into potential unused fence pointers

[Greg KH]

On Thu, Aug 31, 2023 at 12:27:27PM +0200, Christian König wrote:
> Am 30.08.23 um 20:53 schrieb Chia-I Wu:
> > On Sun, Jul 23, 2023 at 6:24 PM Sasha Levin <sashal@kernel.org> wrote:
> > > From: Lang Yu <Lang.Yu@amd.com>
> > > 
> > > [ Upstream commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 ]
> > > 
> > > When using cpu to update page tables, vm update fences are unused.
> > > Install stub fence into these fence pointers instead of NULL
> > > to avoid NULL dereference when calling dma_fence_wait() on them.
> > > 
> > > Suggested-by: Christian König <christian.koenig@amd.com>
> > > Signed-off-by: Lang Yu <Lang.Yu@amd.com>
> > > Reviewed-by: Christian König <christian.koenig@amd.com>
> > > Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
> > > Signed-off-by: Sasha Levin <sashal@kernel.org>
> > > ---
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++++--
> > >   1 file changed, 4 insertions(+), 2 deletions(-)
> > We start getting this warning spew on chromeos
> 
> Yeah because the older kernels still kept track of the last VM fence in the
> syncobj.
> 
> This patch here should probably not have been back ported.
> 
> Why was that done anyway? The upstream commit doesn't have a CC stable and
> this is only a bug fix for a new feature not present on older kernels.

It is part of the AUTOSEL process.

Re: [PATCH AUTOSEL 5.10 13/22] drm/amdgpu: install stub fence into potential unused fence pointers

[Christian König]

Am 31.08.23 um 12:56 schrieb Greg KH:
> On Thu, Aug 31, 2023 at 12:27:27PM +0200, Christian König wrote:
>> Am 30.08.23 um 20:53 schrieb Chia-I Wu:
>>> On Sun, Jul 23, 2023 at 6:24 PM Sasha Levin <sashal@kernel.org> wrote:
>>>> From: Lang Yu <Lang.Yu@amd.com>
>>>>
>>>> [ Upstream commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 ]
>>>>
>>>> When using cpu to update page tables, vm update fences are unused.
>>>> Install stub fence into these fence pointers instead of NULL
>>>> to avoid NULL dereference when calling dma_fence_wait() on them.
>>>>
>>>> Suggested-by: Christian König <christian.koenig@amd.com>
>>>> Signed-off-by: Lang Yu <Lang.Yu@amd.com>
>>>> Reviewed-by: Christian König <christian.koenig@amd.com>
>>>> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>>>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>>>> ---
>>>>    drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++++--
>>>>    1 file changed, 4 insertions(+), 2 deletions(-)
>>> We start getting this warning spew on chromeos
>> Yeah because the older kernels still kept track of the last VM fence in the
>> syncobj.
>>
>> This patch here should probably not have been back ported.
>>
>> Why was that done anyway? The upstream commit doesn't have a CC stable and
>> this is only a bug fix for a new feature not present on older kernels.
> It is part of the AUTOSEL process.

Could we prevent patches from being backported by adding a Fixes: tag?

Thanks,
Christian.

Re: [PATCH AUTOSEL 5.10 13/22] drm/amdgpu: install stub fence into potential unused fence pointers

[Greg KH]

On Thu, Aug 31, 2023 at 03:26:28PM +0200, Christian König wrote:
> Am 31.08.23 um 12:56 schrieb Greg KH:
> > On Thu, Aug 31, 2023 at 12:27:27PM +0200, Christian König wrote:
> > > Am 30.08.23 um 20:53 schrieb Chia-I Wu:
> > > > On Sun, Jul 23, 2023 at 6:24 PM Sasha Levin <sashal@kernel.org> wrote:
> > > > > From: Lang Yu <Lang.Yu@amd.com>
> > > > > 
> > > > > [ Upstream commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 ]
> > > > > 
> > > > > When using cpu to update page tables, vm update fences are unused.
> > > > > Install stub fence into these fence pointers instead of NULL
> > > > > to avoid NULL dereference when calling dma_fence_wait() on them.
> > > > > 
> > > > > Suggested-by: Christian König <christian.koenig@amd.com>
> > > > > Signed-off-by: Lang Yu <Lang.Yu@amd.com>
> > > > > Reviewed-by: Christian König <christian.koenig@amd.com>
> > > > > Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
> > > > > Signed-off-by: Sasha Levin <sashal@kernel.org>
> > > > > ---
> > > > >    drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++++--
> > > > >    1 file changed, 4 insertions(+), 2 deletions(-)
> > > > We start getting this warning spew on chromeos
> > > Yeah because the older kernels still kept track of the last VM fence in the
> > > syncobj.
> > > 
> > > This patch here should probably not have been back ported.
> > > 
> > > Why was that done anyway? The upstream commit doesn't have a CC stable and
> > > this is only a bug fix for a new feature not present on older kernels.
> > It is part of the AUTOSEL process.
> 
> Could we prevent patches from being backported by adding a Fixes: tag?

Yes, that will show exactly where the patch should be backported to.

thanks,

greg k-h

Re: [PATCH AUTOSEL 5.10 13/22] drm/amdgpu: install stub fence into potential unused fence pointers

[Chia-I Wu]

On Thu, Aug 31, 2023 at 7:01 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Thu, Aug 31, 2023 at 03:26:28PM +0200, Christian König wrote:
> > Am 31.08.23 um 12:56 schrieb Greg KH:
> > > On Thu, Aug 31, 2023 at 12:27:27PM +0200, Christian König wrote:
> > > > Am 30.08.23 um 20:53 schrieb Chia-I Wu:
> > > > > On Sun, Jul 23, 2023 at 6:24 PM Sasha Levin <sashal@kernel.org> wrote:
> > > > > > From: Lang Yu <Lang.Yu@amd.com>
> > > > > >
> > > > > > [ Upstream commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 ]
> > > > > >
> > > > > > When using cpu to update page tables, vm update fences are unused.
> > > > > > Install stub fence into these fence pointers instead of NULL
> > > > > > to avoid NULL dereference when calling dma_fence_wait() on them.
> > > > > >
> > > > > > Suggested-by: Christian König <christian.koenig@amd.com>
> > > > > > Signed-off-by: Lang Yu <Lang.Yu@amd.com>
> > > > > > Reviewed-by: Christian König <christian.koenig@amd.com>
> > > > > > Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
> > > > > > Signed-off-by: Sasha Levin <sashal@kernel.org>
> > > > > > ---
> > > > > >    drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++++--
> > > > > >    1 file changed, 4 insertions(+), 2 deletions(-)
> > > > > We start getting this warning spew on chromeos
> > > > Yeah because the older kernels still kept track of the last VM fence in the
> > > > syncobj.
> > > >
> > > > This patch here should probably not have been back ported.
> > > >
> > > > Why was that done anyway? The upstream commit doesn't have a CC stable and
> > > > this is only a bug fix for a new feature not present on older kernels.
> > > It is part of the AUTOSEL process.
> >
> > Could we prevent patches from being backported by adding a Fixes: tag?
>
> Yes, that will show exactly where the patch should be backported to.
This is also AUTOSEL'ed to 5.15.  That might need a revert as well,
depending on when the amdgpu feature landed.


>
> thanks,
>
> greg k-h

Re: [PATCH AUTOSEL 5.10 13/22] drm/amdgpu: install stub fence into potential unused fence pointers

[Christian König]

Am 31.08.23 um 20:55 schrieb Chia-I Wu:
> On Thu, Aug 31, 2023 at 7:01 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>> On Thu, Aug 31, 2023 at 03:26:28PM +0200, Christian König wrote:
>>> Am 31.08.23 um 12:56 schrieb Greg KH:
>>>> On Thu, Aug 31, 2023 at 12:27:27PM +0200, Christian König wrote:
>>>>> Am 30.08.23 um 20:53 schrieb Chia-I Wu:
>>>>>> On Sun, Jul 23, 2023 at 6:24 PM Sasha Levin <sashal@kernel.org> wrote:
>>>>>>> From: Lang Yu <Lang.Yu@amd.com>
>>>>>>>
>>>>>>> [ Upstream commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 ]
>>>>>>>
>>>>>>> When using cpu to update page tables, vm update fences are unused.
>>>>>>> Install stub fence into these fence pointers instead of NULL
>>>>>>> to avoid NULL dereference when calling dma_fence_wait() on them.
>>>>>>>
>>>>>>> Suggested-by: Christian König <christian.koenig@amd.com>
>>>>>>> Signed-off-by: Lang Yu <Lang.Yu@amd.com>
>>>>>>> Reviewed-by: Christian König <christian.koenig@amd.com>
>>>>>>> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>>>>>>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>>>>>>> ---
>>>>>>>     drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++++--
>>>>>>>     1 file changed, 4 insertions(+), 2 deletions(-)
>>>>>> We start getting this warning spew on chromeos
>>>>> Yeah because the older kernels still kept track of the last VM fence in the
>>>>> syncobj.
>>>>>
>>>>> This patch here should probably not have been back ported.
>>>>>
>>>>> Why was that done anyway? The upstream commit doesn't have a CC stable and
>>>>> this is only a bug fix for a new feature not present on older kernels.
>>>> It is part of the AUTOSEL process.
>>> Could we prevent patches from being backported by adding a Fixes: tag?
>> Yes, that will show exactly where the patch should be backported to.
> This is also AUTOSEL'ed to 5.15.  That might need a revert as well,
> depending on when the amdgpu feature landed.

Both the feature and the bug fix landed in 6.5.

The bug fix should have never been backported to any older kernel at all 
as far as I can see.

Regards,
Christian.

>
>
>> thanks,
>>
>> greg k-h

Re: [PATCH AUTOSEL 5.10 13/22] drm/amdgpu: install stub fence into potential unused fence pointers

[Eddie Chapman]

On 01/09/2023 07:02, Christian König wrote:
> Am 31.08.23 um 20:55 schrieb Chia-I Wu:
>> On Thu, Aug 31, 2023 at 7:01 AM Greg KH <gregkh@linuxfoundation.org> 
>> wrote:
>>> On Thu, Aug 31, 2023 at 03:26:28PM +0200, Christian König wrote:
>>>> Am 31.08.23 um 12:56 schrieb Greg KH:
>>>>> On Thu, Aug 31, 2023 at 12:27:27PM +0200, Christian König wrote:
>>>>>> Am 30.08.23 um 20:53 schrieb Chia-I Wu:
>>>>>>> On Sun, Jul 23, 2023 at 6:24 PM Sasha Levin <sashal@kernel.org> 
>>>>>>> wrote:
>>>>>>>> From: Lang Yu <Lang.Yu@amd.com>
>>>>>>>>
>>>>>>>> [ Upstream commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 ]
>>>>>>>>
>>>>>>>> When using cpu to update page tables, vm update fences are unused.
>>>>>>>> Install stub fence into these fence pointers instead of NULL
>>>>>>>> to avoid NULL dereference when calling dma_fence_wait() on them.
>>>>>>>>
>>>>>>>> Suggested-by: Christian König <christian.koenig@amd.com>
>>>>>>>> Signed-off-by: Lang Yu <Lang.Yu@amd.com>
>>>>>>>> Reviewed-by: Christian König <christian.koenig@amd.com>
>>>>>>>> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>>>>>>>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>>>>>>>> ---
>>>>>>>>     drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++++--
>>>>>>>>     1 file changed, 4 insertions(+), 2 deletions(-)
>>>>>>> We start getting this warning spew on chromeos
>>>>>> Yeah because the older kernels still kept track of the last VM 
>>>>>> fence in the
>>>>>> syncobj.
>>>>>>
>>>>>> This patch here should probably not have been back ported.
>>>>>>
>>>>>> Why was that done anyway? The upstream commit doesn't have a CC 
>>>>>> stable and
>>>>>> this is only a bug fix for a new feature not present on older 
>>>>>> kernels.
>>>>> It is part of the AUTOSEL process.
>>>> Could we prevent patches from being backported by adding a Fixes: tag?
>>> Yes, that will show exactly where the patch should be backported to.
>> This is also AUTOSEL'ed to 5.15.  That might need a revert as well,
>> depending on when the amdgpu feature landed.
> 
> Both the feature and the bug fix landed in 6.5.
> 
> The bug fix should have never been backported to any older kernel at all 
> as far as I can see.
> 
> Regards,
> Christian.

I can confirm I've also started to get this warning hundreds of times 
per second having upgraded from 5.15.123 to 5.15.130. There's also a 
report from someone else of exactly the same on 5.15.128, here:
https://gitlab.freedesktop.org/drm/amd/-/issues/2820

Eddie

Re: [PATCH AUTOSEL 5.10 13/22] drm/amdgpu: install stub fence into potential unused fence pointers

[Bryan Jennings]

This is also causing log spam on 5.15.  It was included in 5.15.128 as 
commit 4921792e04f2125b5eadef9dbe9417a8354c7eff.  I encountered this and 
found https://gitlab.freedesktop.org/drm/amd/-/issues/2820 while 
researching the problem.

Re: [PATCH AUTOSEL 5.10 13/22] drm/amdgpu: install stub fence into potential unused fence pointers

[Greg KH]

On Sun, Sep 10, 2023 at 03:43:01PM -0500, Bryan Jennings wrote:
> This is also causing log spam on 5.15.  It was included in 5.15.128 as
> commit 4921792e04f2125b5eadef9dbe9417a8354c7eff.  I encountered this and
> found https://gitlab.freedesktop.org/drm/amd/-/issues/2820 while researching
> the problem.

Now reverted, thanks.

greg k-h

Re: [PATCH AUTOSEL 5.10 13/22] drm/amdgpu: install stub fence into potential unused fence pointers

[Greg KH]

On Sun, Sep 10, 2023 at 03:43:01PM -0500, Bryan Jennings wrote:
> This is also causing log spam on 5.15.  It was included in 5.15.128 as
> commit 4921792e04f2125b5eadef9dbe9417a8354c7eff.  I encountered this and
> found https://gitlab.freedesktop.org/drm/amd/-/issues/2820 while researching
> the problem.

Confused, what should we do here?

Re: [PATCH AUTOSEL 5.10 13/22] drm/amdgpu: install stub fence into potential unused fence pointers

[Christian König]

Am 07.10.23 um 11:50 schrieb Greg KH:
> On Sun, Sep 10, 2023 at 03:43:01PM -0500, Bryan Jennings wrote:
>> This is also causing log spam on 5.15.  It was included in 5.15.128 as
>> commit 4921792e04f2125b5eadef9dbe9417a8354c7eff.  I encountered this and
>> found https://gitlab.freedesktop.org/drm/amd/-/issues/2820 while researching
>> the problem.
> Confused, what should we do here?

If this patch was backported to even more older kernels then please 
revert that immediately!

This patch was part of a new feature and can only work correctly with a 
bunch of prerequisites. If you don't have those prerequisites in your 
branch then it might actually cause random memory corruptions through 
device DMA.

And we should probably talk about why this patch was automatically 
selected for backporting in the first place? There is no mention that 
this is a fix or should be backported in the commit message or patch 
itself whatsoever.

Without the WARN_ON() which started to spam the logs that could have 
gone south pretty quickly. Random data corruption without any indicator 
what's causing it is not really funny.

Regards,
Christian.

Re: [PATCH AUTOSEL 5.10 13/22] drm/amdgpu: install stub fence into potential unused fence pointers

[Greg KH]

On Mon, Oct 09, 2023 at 02:46:40PM +0200, Christian König wrote:
> Am 07.10.23 um 11:50 schrieb Greg KH:
> > On Sun, Sep 10, 2023 at 03:43:01PM -0500, Bryan Jennings wrote:
> > > This is also causing log spam on 5.15.  It was included in 5.15.128 as
> > > commit 4921792e04f2125b5eadef9dbe9417a8354c7eff.  I encountered this and
> > > found https://gitlab.freedesktop.org/drm/amd/-/issues/2820 while researching
> > > the problem.
> > Confused, what should we do here?
> 
> If this patch was backported to even more older kernels then please revert
> that immediately!

It only went to 5.10 and 5.15 and has been reverted from both of them
now.

thanks,

greg k-h