similar to: [PATCH 16/82] drm/nouveau/mmu: Refactor intentional wrap-around calculation

The functions nvkm_vmm_ctor() and nvkm_mmu_ptp_get() are not called outside of the file defining them so make them static. Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c | 2 +- drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 2 +- drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 3 --- 3 files changed, 2 insertions(+), 5

In an effort to separate intentional arithmetic wrap-around from unexpected wrap-around, we need to refactor places that depend on this kind of math. One of the most common code patterns of this is: VAR + value < VAR Notably, this is considered "undefined behavior" for signed and pointer types, which the kernel works around by using the -fno-strict-overflow option in the build[1]

These are based on 5.8.0-rc2 and intended for Ben Skeggs' nouveau tree. I believe the changes can be queued for 5.8-rcX after being reviewed. These were part of a larger series but I'm resending them separately as suggested by Jason Gunthorpe. https://lore.kernel.org/linux-mm/20200619215649.32297-1-rcampbell at nvidia.com/ Note that in order to exercise/test patch 2 here, you will need a

From: Thierry Reding <treding at nvidia.com> The gk20a (as well as all subsequent Tegra instantiations of the GPU) do in fact use the same apertures as regular GPUs. Prior to gv11b there are no checks in hardware for the aperture, so we get away with setting VRAM as the aperture for buffers that are actually in system memory. Signed-off-by: Thierry Reding <treding at nvidia.com> ---

On Tue, Sep 17, 2019 at 01:43:13PM +1000, Ben Skeggs wrote: > On Tue, 17 Sep 2019 at 01:18, Thierry Reding <thierry.reding at gmail.com> wrote: > > > > From: Thierry Reding <treding at nvidia.com> > > > > The gk20a (as well as all subsequent Tegra instantiations of the GPU) do > > in fact use the same apertures as regular GPUs. Prior to gv11b there are

On Tue, 17 Sep 2019 at 01:18, Thierry Reding <thierry.reding at gmail.com> wrote: > > From: Thierry Reding <treding at nvidia.com> > > The gk20a (as well as all subsequent Tegra instantiations of the GPU) do > in fact use the same apertures as regular GPUs. Prior to gv11b there are > no checks in hardware for the aperture, so we get away with setting VRAM > as the

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,

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 20/07/2023 01:14, Danilo Krummrich wrote: > Add infrastructure to keep track of GPU virtual address (VA) mappings > with a decicated VA space manager implementation. > > New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers > start implementing, allow userspace applications to request multiple and > arbitrary GPU VA mappings of buffer objects. The DRM GPU VA

[This feature addresses https://bugs.llvm.org/show_bug.cgi?id=37880 and https://github.com/KSPP/linux/issues/84.] Clang has been ramping up its support of the Linux kernel. We recently added "asm goto with outputs", a long requested feature. We want to continue building our relationship with the Linux community. KSPP is a project to improve security in the Linux kernel, through both

On Wed, Aug 16, 2023 at 05:34:43PM +0800, GONG, Ruiqi wrote: > From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> > > As suggested by Kees[1], replace the old-style 0-element array members > of multiple structs in ebtables.h with modern C99 flexible array. > > [1]: https://lore.kernel.org/all/5E8E0F9C-EE3F-4B0D-B827-DC47397E2A4A at kernel.org/ > > Link:

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); > > ^^^^^^^^^^^^^^^^^^^^ >

The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not

From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> As suggested by Kees[1], replace the old-style 0-element array members of multiple structs in ebtables.h with modern C99 flexible array. [1]: https://lore.kernel.org/all/5E8E0F9C-EE3F-4B0D-B827-DC47397E2A4A at kernel.org/ Link: https://github.com/KSPP/linux/issues/21 Signed-off-by: GONG, Ruiqi <gongruiqi1 at huawei.com>

On Fri, Jun 19, 2020 at 02:56:33PM -0700, Ralph Campbell wrote: > These patches apply to linux-5.8.0-rc1. Patches 1-3 should probably go > into 5.8, the others can be queued for 5.9. Patches 4-6 improve the HMM > self tests. Patch 7-8 prepare nouveau for the meat of this series which > adds support and testing for compound page mapping of system memory > (patches 9-11) and compound

From: Mihai Don?u <mdontu at bitdefender.com> This command is used to get kvm_regs and kvm_sregs structures, plus a list of struct kvm_msrs from a specific vCPU. While the kvm_regs and kvm_sregs structures are included with every event, this command allows reading any MSR and can be used as a quick way to read the state of any vCPU. Signed-off-by: Mihai Don?u <mdontu at

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 2/25/20 08:17, Jani Nikula wrote: > On Tue, 25 Feb 2020, "Gustavo A. R. Silva" <gustavo at embeddedor.com> wrote: >> The current codebase makes use of the zero-length array language >> extension to the C90 standard, but the preferred mechanism to declare >> variable-length types such as these ones is a flexible array member[1][2], >> introduced in C99:

From: Thierry Reding <treding at nvidia.com> Hi Ben, these are a couple of patches that are in preparation for adding GV11B support. The fundamental issue that these are trying to solve is that the GV11B is the first Tegra incarnation of the GPU where the aperture really matters. All prior generations would accept any of them. For dGPUs we usually allocate memory in VRAM, so the default

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a break statement instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva <gustavoars at kernel.org> --- drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c | 1 + 1 file changed, 1 insertion(+) diff --git