similar to: [PATCH] drm/nouveau/imem/nv50: fix incorrect use of refcount API

Hey Ard, It seems that Ben already committed a similar patch to his tree (see [0]). I do not know whether he is planning to have it part of a pull request of fixes for 4.15. Best regards, Pierre [0]: https://github.com/skeggsb/nouveau/commit/9068f1df2394f0e4ab2b2a28cac06b462fe0a0aa On 2017-12-18 — 09:27, Ard Biesheuvel wrote: > On 8 December 2017 at 19:30, Ard Biesheuvel <ard.biesheuvel

On 8 December 2017 at 19:30, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote: > Commit be55287aa5b ("drm/nouveau/imem/nv50: embed nvkm_instobj directly > into nv04_instobj") introduced some new calls to the refcount api to > the nv50 mapping code. In one particular instance, it does the > following: > > if (!refcount_inc_not_zero(&iobj->maps)) {

From: Thierry Reding <treding at nvidia.com> Fill in BAR2 callbacks for instance memory. There's no BAR2 on Tegra GPUs, but buffers are all in system memory anyway, so just return the plain address. Signed-off-by: Thierry Reding <treding at nvidia.com> --- .../drm/nouveau/nvkm/subdev/instmem/gk20a.c | 30 +++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git

From: Thierry Reding <treding at nvidia.com> Hi Ben, I messed up the ordering of patches in my tree a bit, so these two fixes got separated from the others. I don't consider these particularily urgent because the crash that the first one fixes only happens on gp10b which we don't enable by default yet and the second patch fixes a crash that only happens on module unload (or driver

This v4 is now a 3 piece series, after Alexandre pointed out that both GF 100 and NV50 are affected by the same issue, and that a related issue has been solved already for Tegra in commit 9d0394c6bed5 ("drm/nouveau/instmem/gk20a: set DMA mask early"). The issue that this series addresses is the fact that the Nouveau driver invokes the DMA API before setting the DMA mask. In both cases

This v4 is now a 3 piece series (since v4), after Alexandre pointed out that both GF 100 and NV50 are affected by the same issue, and that a related issue has been solved already for Tegra in commit 9d0394c6bed5 ("drm/nouveau/instmem/gk20a: set DMA mask early"). The issue that this series addresses is the fact that the Nouveau driver invokes the DMA API before setting the DMA mask. In

The 100c08 scratch page is mapped using dma_map_page() before the TTM layer has had a chance to set the DMA mask. This means we are still running with the default of 32 when this code executes, and this causes problems for platforms with no memory below 4 GB (such as AMD Seattle) So move the dma_map_page() to the .init hook, and set the streaming DMA mask based on the MMU subdev parameters before

Ard Biesheuvel <ard.biesheuvel at linaro.org> writes: > The 100c08 scratch page is mapped using dma_map_page() before the TTM > layer has had a chance to set the DMA mask. This means we are still > running with the default of 32 when this code executes, and this causes > problems for platforms with no memory below 4 GB (such as AMD Seattle) > > So move the dma_map_page()

https://bugs.freedesktop.org/show_bug.cgi?id=100431 Bug ID: 100431 Summary: nv50: memory corruption due to use-after-free of dma_fence Product: xorg Version: unspecified Hardware: ARM OS: Linux (All) Status: NEW Severity: major Priority: medium Component:

The 100c08 scratch page is mapped using dma_map_page() before the TTM layer has had a chance to set the DMA mask. This means we are still running with the default of 32 when this code executes, and this causes problems for platforms with no memory below 4 GB (such as AMD Seattle) So move the dma_map_page() to the .init hook, and set the streaming DMA mask based on the MMU subdev parameters before

On 15 July 2016 at 07:52, Alexandre Courbot <gnurou at gmail.com> wrote: > On Fri, Jul 8, 2016 at 1:59 AM, Ard Biesheuvel > <ard.biesheuvel at linaro.org> wrote: >> The 100c08 scratch page is mapped using dma_map_page() before the TTM >> layer has had a chance to set the DMA mask. This means we are still >> running with the default of 32 when this code executes,

On 7 October 2016 at 09:12, Alexandre Courbot <gnurou at gmail.com> wrote: > On Fri, Oct 7, 2016 at 12:49 AM, Ard Biesheuvel > <ard.biesheuvel at linaro.org> wrote: >> This v4 is now a 3 piece series (since v4), after Alexandre pointed out that >> both GF 100 and NV50 are affected by the same issue, and that a related issue >> has been solved already for Tegra

On Mon, Sep 26, 2016 at 9:32 PM, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote: > Some subdevices (i.e., fb/nv50.c and fb/gf100.c) map a scratch page using > dma_map_page() way before the TTM layer has had a chance to set the DMA > mask. This may prevent the driver from loading at all on platforms whose > system memory is not covered by the default DMA mask of 32-bit (i.e.,

The 100c08 scratch page is mapped using dma_map_page() before the TTM layer has had a chance to set the DMA mask. This means we are still running with the default of 32 when this code executes, and this causes problems for platforms with no memory below 4 GB (such as AMD Seattle) So move the dma_map_page() to the .init hook, and set the streaming DMA mask based on the MMU subdev parameters before

https://bugs.freedesktop.org/show_bug.cgi?id=100545 Bug ID: 100545 Summary: BUG: null pointer dereference dma_fence_wait_timeout from nouveau_drm_ioctl (linux 4.10.5) Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Keywords: have-backtrace

A userspace process holding a file descriptor to a virtio_blk device can still invoke block_device_operations after hot unplug. This leads to a use-after-free accessing vblk->vdev in virtblk_getgeo() when ioctl(HDIO_GETGEO) is invoked: BUG: unable to handle kernel NULL pointer dereference at 0000000000000090 IP: [<ffffffffc00e5450>] virtio_check_driver_offered_feature+0x10/0x90

A userspace process holding a file descriptor to a virtio_blk device can still invoke block_device_operations after hot unplug. This leads to a use-after-free accessing vblk->vdev in virtblk_getgeo() when ioctl(HDIO_GETGEO) is invoked: BUG: unable to handle kernel NULL pointer dereference at 0000000000000090 IP: [<ffffffffc00e5450>] virtio_check_driver_offered_feature+0x10/0x90

vhost is currently broken on the some ARM configs. The reason is that the ring element addresses are passed between components with different alignments assumptions. Thus, if guest selects a pointer and host then gets and dereferences it, then alignment assumed by the host's compiler might be greater than the actual alignment of the pointer. compiler on the host from assuming pointer is

vhost is currently broken on the some ARM configs. The reason is that the ring element addresses are passed between components with different alignments assumptions. Thus, if guest selects a pointer and host then gets and dereferences it, then alignment assumed by the host's compiler might be greater than the actual alignment of the pointer. compiler on the host from assuming pointer is

On 20 October 2017 at 09:24, Ingo Molnar <mingo at kernel.org> wrote: > > * Thomas Garnier <thgarnie at google.com> wrote: > >> Change the assembly code to use only relative references of symbols for the >> kernel to be PIE compatible. >> >> Position Independent Executable (PIE) support will allow to extended the >> KASLR randomization range below