similar to: [PATCH] drm/nouveau: unpin pushbuffer bo before destroying it

On Fri, May 26, 2023 at 5:11?AM Karol Herbst <kherbst at redhat.com> wrote: > > 1ba6113a90a0 removed a lot of the kernel GPU channel, but method 0x128 > was important as otherwise the GPU spams us with `CACHE_ERROR` messages. > > We use the blit subchannel inside our vblank handling, so we should keep > at least this part. > > v2: Only do it for NV11+ GPUs > >

1ba6113a90a0 removed a lot of the kernel GPU channel, but method 0x128 was important as otherwise the GPU spams us with `CACHE_ERROR` messages. We use the blit subchannel inside our vblank handling, so we should keep at least this part. v2: Only do it for NV11+ GPUs Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/201 Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev

Unprivileged user can crash kernel by using DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC ioctl. This was reported by trinity[1] fuzzer. [ 71.073906] nouveau 0000:01:00.0: crashme[1329]: channel failed to initialise, -17 [ 71.081730] BUG: kernel NULL pointer dereference, address: 00000000000000a0 [ 71.088928] #PF: supervisor read access in kernel mode [ 71.094059] #PF: error_code(0x0000) - not-present

On Sun, Nov 15, 2020 at 6:43 PM Salvatore Bonaccorso <carnil at debian.org> wrote: > > Hi, > > On Fri, Aug 28, 2020 at 11:28:46AM +0200, Frantisek Hrbata wrote: > > Unprivileged user can crash kernel by using DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC > > ioctl. This was reported by trinity[1] fuzzer. > > > > [ 71.073906] nouveau 0000:01:00.0: crashme[1329]:

Hi, On Fri, Aug 28, 2020 at 11:28:46AM +0200, Frantisek Hrbata wrote: > Unprivileged user can crash kernel by using DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC > ioctl. This was reported by trinity[1] fuzzer. > > [ 71.073906] nouveau 0000:01:00.0: crashme[1329]: channel failed to initialise, -17 > [ 71.081730] BUG: kernel NULL pointer dereference, address: 00000000000000a0 > [

1ba6113a90a0 removed a lot of the kernel GPU channel, but method 0x128 was important as otherwise the GPU spams us with `CACHE_ERROR` messages. We use the blit subchannel inside our vblank handling, so we should keep at least this part. Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/201 Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") Signed-off-by:

Reduces object size ~4kb Joe Perches (2): drm/nouveau: Add new logging function nv_cli_printk drm/nouveau: Convert NV_PRINTK macros and uses to new nv_cli_<level> macros drivers/gpu/drm/nouveau/nouveau_abi16.c | 2 +- drivers/gpu/drm/nouveau/nouveau_chan.c | 12 +++---- drivers/gpu/drm/nouveau/nouveau_drm.c | 21 +++++++++++ drivers/gpu/drm/nouveau/nouveau_drv.h | 44

Hi there, Resending these now that they've had some more polish and testing, and I heard that Ben's vacation is over :-) These patches work as a starting point for more explicit error mechanisms and better robustness. At the moment, when a job hangs or faults, it seems that nouveau doesn't quite know how to handle the situation and often results in a hang. Some of these situations

It has been a couple of months since v4 - apologies for this. v4 has not received many comments, but this version addresses them and makes a new attempt at pushing the critical bit for GK20A and Nouveau on ARM in general. As a reminder, this series addresses the memory coherency issue that we are seeing on ARM platforms. Contrary to x86 which invalidates the PCI caches whenever a write is made by

Upcoming mobile Kepler GPUs (such as GK20A) use the platform bus instead of PCI to which Nouveau is tightly dependent. This patch allows Nouveau to handle platform devices by: - abstracting PCI-dependent functions that were typically used for resource querying and page mapping, - introducing a nv_device_is_pci() function that allows to make PCI-dependent code conditional, - providing a

Commit "drm/nouveau: port all engines to new engine module format" changed IB size calculation to be less wasteful, but didn't take into account already existing off-by-one bugs :). So: - ib_max is the last entry, so we need to +1 when calculating number of free entries - nv50_dma_wait already does +1 (for FIRE_RING), so we don't need another +1 on nouveau_gem_ioctl_pushbuf

This will otherwise cause a lockdep splat if reservations were a real lock type, so warn when nouveau forgets to unpin a buffer, and fix up the ones I've hit. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c b/drivers/gpu/drm/nouveau/nouveau_abi16.c index cc79c79..acc6b08 100644 ---

This will otherwise cause a lockdep splat, so warn when nouveau forgets to unpin a buffer, and fix up the ones I've hit. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/nouveau_abi16.c | 1 + drivers/gpu/drm/nouveau/nouveau_fbcon.c | 1 + drivers/gpu/drm/nouveau/nouveau_gem.c | 3 ++- drivers/gpu/drm/nouveau/nouveau_prime.c |

It can help to remove any ambiguity about which options were passed to Nouveau, especially in case the user had some options set in /etc/modprobe.d/*.conf that he forgot about, as they won't appear in a dmesg. Signed-off-by: Pierre Moreau <pierre.morrow at free.fr> --- drm/nouveau_chan.c | 2 +- drm/nouveau_chan.h | 2 ++ drm/nouveau_connector.c | 6 +++---

nouveau_fence_emit() can fail before and after initializing the dma-fence and hence before and after initializing the dma-fence' kref. In order to avoid nouveau_fence_emit() potentially failing before dma-fence initialization pass the channel to nouveau_fence_new() already and perform the required check before even allocating the fence. While at it, restore the original behavior of

This is the first set of patches to make Nouveau work on Tegra. Those are only the obvious correctness fixes, a lot of optimization work remains to be done, but at least it's enough to get accel working and let the machine survive a piglit run. A new BO flag is introduced to allow userspace to hint the kernel about possible optimizations. Lucas Stach (6): drm/ttm: recognize ARM arch in

Another revision of this patchset critical for GK20A to operate. Previous attempts were exclusively using either TTM's regular page allocator or the DMA API one. Both have their advantages and drawbacks: the page allocator is fast but requires explicit synchronization on non-coherent architectures, whereas the DMA allocator always returns coherent memory, but is also slower, creates a

On Mon, Feb 10, 2014 at 8:50 PM, Thierry Reding <thierry.reding at gmail.com> wrote: > On Mon, Feb 10, 2014 at 02:53:00PM +0900, Alexandre Courbot wrote: > [...] >> diff --git a/drivers/gpu/drm/nouveau/core/engine/device/base.c b/drivers/gpu/drm/nouveau/core/engine/device/base.c > [...] >> +resource_size_t >> +nv_device_resource_start(struct nouveau_device *device,

Upcoming mobile Kepler GPUs (such as GK20A) use the platform bus instead of PCI to which Nouveau is tightly dependent. This patch allows Nouveau to handle platform devices by: - abstracting PCI-dependent functions that were typically used for resource querying and page mapping, - introducing a nv_device_is_pci() function that allows to make PCI-dependent code conditional, - providing a

abi16->handles is a u64, so make sure to use 1ULL << val when modifying. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Noticed this when doing the previous patch. I'm not sure whether this affects 64-bit builds or not, didn't care to look at the assembly or check the standard. drivers/gpu/drm/nouveau/nouveau_abi16.c | 4 ++-- 1 file changed, 2 insertions(+), 2