similar to: [PATCH v3] drm/nouveau/nvif: Avoid build error due to potential integer overflows

Trying to build parisc:allmodconfig with gcc 12.x or later results in the following build error. drivers/gpu/drm/nouveau/nvif/object.c: In function 'nvif_object_mthd': drivers/gpu/drm/nouveau/nvif/object.c:161:9: error: 'memcpy' accessing 4294967264 or more bytes at offsets 0 and 32 overlaps 6442450881 bytes at offset -2147483617 [-Werror=restrict] 161 | memcpy(data,

On 5/18/24 10:32, Kees Cook wrote: > On Sat, May 18, 2024 at 06:54:36PM +0200, Christophe JAILLET wrote: >> (adding linux-hardening at vger.kernel.org) >> >> >> Le 18/05/2024 ? 16:37, Guenter Roeck a ?crit?: >>> Trying to build parisc:allmodconfig with gcc 12.x or later results >>> in the following build error. >>> >>>

On Sat, May 18, 2024 at 06:54:36PM +0200, Christophe JAILLET wrote: > (adding linux-hardening at vger.kernel.org) > > > Le 18/05/2024 ? 16:37, Guenter Roeck a ?crit?: > > Trying to build parisc:allmodconfig with gcc 12.x or later results > > in the following build error. > > > > drivers/gpu/drm/nouveau/nvif/object.c: In function 'nvif_object_mthd':

(adding linux-hardening at vger.kernel.org) Le 18/05/2024 ? 16:37, Guenter Roeck a ?crit?: > Trying to build parisc:allmodconfig with gcc 12.x or later results > in the following build error. > > drivers/gpu/drm/nouveau/nvif/object.c: In function 'nvif_object_mthd': > drivers/gpu/drm/nouveau/nvif/object.c:161:9: error: > 'memcpy' accessing 4294967264 or more

Trying to build parisc:allmodconfig with gcc 12.x or later results in the following build error. drivers/gpu/drm/nouveau/nvif/object.c: In function 'nvif_object_mthd': drivers/gpu/drm/nouveau/nvif/object.c:161:9: error: 'memcpy' accessing 4294967264 or more bytes at offsets 0 and 32 overlaps 6442450881 bytes at offset -2147483617 [-Werror=restrict] 161 | memcpy(data,

On Sat, 2024-05-18 at 11:23 -0700, Guenter Roeck wrote: > On 5/18/24 10:32, Kees Cook wrote: > [] > > I think the INT_MAX test is actually better in this case because > > nvif_object_ioctl()'s size argument is u32: > > > > ret = nvif_object_ioctl(object, args, sizeof(*args) + size, NULL); > > ^^^^^^^^^^^^^^^^^^^^ >

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:

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

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 > >

hey, I'm seeing an Oops when nouveau loads (see below). I've verified that this is because both device->chip and device->name are NULL prior to the strncpy()s at the end of nvkm_udevice_info(). Bisect shows that this started happening after: commit 24d5ff40a732633dceab68c6559ba723784f4a68 Author: Karol Herbst <kherbst at redhat.com> Date: Tue Apr 28 18:54:02 2020 +0200

I hit this while testing HMM with nouveau on linux-5.5-rc5. I'm not a lockdep expert but my understanding of this is that an invalidation callback could potentially call kzalloc(GFP_KERNEL) which could cause another invalidation and recursively deadlock. Looking at the drivers/gpu/drm/nouveau/nvkm/ layer, I do see a number of places where GFP_KERNEL is used for allocations and I don't see

kmemleak report: unreferenced object 0xffff9071c65644e0 (size 96): comm "systemd-udevd", pid 347, jiffies 4294898424 (age 810.828s) hex dump (first 32 bytes): 02 01 00 00 00 00 00 00 00 00 10 00 02 04 00 00 ................ 00 00 00 00 00 00 a0 86 00 00 00 00 00 00 00 00 ................ backtrace: [<000000007c0d0ac3>] __kmalloc+0x337/0x500

On Fri, 2020-10-23 at 11:01 +0200, Sebastian Andrzej Siewior wrote: > On 2020-10-22 07:28:20 [+0200], Mike Galbraith wrote: > > I've only as yet seen nouveau lockdep gripage when firing up one of my > > full distro KVM's. > > Could you please check !RT with the `threadirqs' command line option? I > don't think RT is doing here anything different (except for

On Fri, Jun 15, 2018 at 3:56 PM Nick Desaulniers <ndesaulniers at google.com> wrote: > > Similar to commit 0bf8bf50eddc ("module: Remove > const attribute from alias for MODULE_DEVICE_TABLE") > > Fixes many -Wduplicate-decl-specifier warnings due to the combination of > const typeof() of already const variables. > > Signed-off-by: Nick Desaulniers

One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct nvif_mmu_kind_v0 { ... __u8 data[]; }; Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes. So, replace

Similar to commit 0bf8bf50eddc ("module: Remove const attribute from alias for MODULE_DEVICE_TABLE") Fixes many -Wduplicate-decl-specifier warnings due to the combination of const typeof() of already const variables. Signed-off-by: Nick Desaulniers <ndesaulniers at google.com> --- Changes since v1: added additional space after statements.

Similar to commit 0bf8bf50eddc ("module: Remove const attribute from alias for MODULE_DEVICE_TABLE") Fixes many -Wduplicate-decl-specifier warnings due to the combination of const typeof() of already const variables. Signed-off-by: Nick Desaulniers <ndesaulniers at google.com> --- drivers/gpu/drm/nouveau/include/nvif/object.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

On Fri, 23 Oct 2020 14:07:13 +0200 Mike Galbraith wrote: > On Fri, 2020-10-23 at 11:01 +0200, Sebastian Andrzej Siewior wrote: > > On 2020-10-22 07:28:20 [+0200], Mike Galbraith wrote: > > > I've only as yet seen nouveau lockdep gripage when firing up one of my > > > full distro KVM's. > > > > Could you please check !RT with the `threadirqs'

Hi Christophe, s/fix some error handling in 'ls_ucode_img_load_gr/plug memory leak in ls_ucode_img_load_gr() error path/ On 8 May 2017 at 08:46, Christophe JAILLET <christophe.jaillet at wanadoo.fr> wrote: > The last goto looks spurious because it releases less resources than the > previous one. > Add a new label in order to free the memory allocated by the 'kmemdup'

On 8 June 2015 at 06:40, Samuel Pitoiset <samuel.pitoiset at gmail.com> wrote: > This commit introduces the NVIF_IOCTL_NEW_V0_PERFMON class which will be > used in order to query domains, signals and sources. This separates the > querying and the counting interface. Hey Samuel, I've merged patches 1-4 already, I've got some comments on this one, but after they're solved