Displaying 20 results from an estimated 1000 matches similar to: "[PATCH AUTOSEL 5.4 379/459] drm/nouveau/mmu: fix comptag memory leak"
2020 Feb 14
0
[PATCH AUTOSEL 5.5 441/542] drm/nouveau/mmu: fix comptag memory leak
From: Ben Skeggs <bskeggs at redhat.com>
[ Upstream commit 35e4909b6a2b4005ced3c4238da60d926b78fdea ]
Signed-off-by: Ben Skeggs <bskeggs at redhat.com>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
drivers/gpu/drm/nouveau/nvkm/core/memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/core/memory.c
2020 Feb 14
0
[PATCH AUTOSEL 4.19 208/252] drm/nouveau/mmu: fix comptag memory leak
From: Ben Skeggs <bskeggs at redhat.com>
[ Upstream commit 35e4909b6a2b4005ced3c4238da60d926b78fdea ]
Signed-off-by: Ben Skeggs <bskeggs at redhat.com>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
drivers/gpu/drm/nouveau/nvkm/core/memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/core/memory.c
2019 May 17
4
drm/nouveau/core/memory: kmemleak 684 new suspected memory leaks
Hello,
5.1.0-next-20190517
I'm looking at quite a lot of kmemleak reports coming from
drm/nouveau/core/memory, all of which are:
unreferenced object 0xffff8deec27c4ac0 (size 16):
comm "Web Content", pid 5309, jiffies 4309675011 (age 68.076s)
hex dump (first 16 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
2017 Dec 08
3
[PATCH] drm/nouveau/imem/nv50: fix incorrect use of refcount API
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)) {
...
refcount_inc(&iobj->maps);
}
i.e., it calls refcount_inc() to increment the
2017 Dec 18
1
[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
2017 Dec 18
0
[PATCH] drm/nouveau/imem/nv50: fix incorrect use of refcount API
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)) {
2020 May 14
0
[PATCH AUTOSEL 5.6 32/62] virtio-blk: handle block_device_operations callbacks after hot unplug
From: Stefan Hajnoczi <stefanha at redhat.com>
[ Upstream commit 90b5feb8c4bebc76c27fcaf3e1a0e5ca2d319e9e ]
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
2020 May 14
0
[PATCH AUTOSEL 4.19 22/31] virtio-blk: handle block_device_operations callbacks after hot unplug
From: Stefan Hajnoczi <stefanha at redhat.com>
[ Upstream commit 90b5feb8c4bebc76c27fcaf3e1a0e5ca2d319e9e ]
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
2020 May 14
0
[PATCH AUTOSEL 4.14 31/39] virtio-blk: handle block_device_operations callbacks after hot unplug
From: Stefan Hajnoczi <stefanha at redhat.com>
[ Upstream commit 90b5feb8c4bebc76c27fcaf3e1a0e5ca2d319e9e ]
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
2020 May 14
0
[PATCH AUTOSEL 5.4 29/49] virtio-blk: handle block_device_operations callbacks after hot unplug
From: Stefan Hajnoczi <stefanha at redhat.com>
[ Upstream commit 90b5feb8c4bebc76c27fcaf3e1a0e5ca2d319e9e ]
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
2015 Nov 11
0
[PATCH] instmem/gk20a: use DMA API CPU mapping
On 11/11/2015 06:07 PM, Alexandre Courbot wrote:
> Commit 69c4938249fb ("drm/nouveau/instmem/gk20a: use direct CPU access")
> tried to be smart while using the DMA-API by managing the CPU mappings of
> buffers allocated with the DMA-API by itself. In doing so, it relied
> on dma_to_phys() which is an architecture-private function not
> available everywhere. This broke the
2015 Nov 11
2
[PATCH] instmem/gk20a: use DMA API CPU mapping
Commit 69c4938249fb ("drm/nouveau/instmem/gk20a: use direct CPU access")
tried to be smart while using the DMA-API by managing the CPU mappings of
buffers allocated with the DMA-API by itself. In doing so, it relied
on dma_to_phys() which is an architecture-private function not
available everywhere. This broke the build on several architectures.
Since there is no reliable and portable
2020 Feb 13
1
[PATCH 1/4] drm/nouveau/kms/nv50-: Probe SOR caps for DP interlacing support
Hi,
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.5.3, v5.4.19, v4.19.103, v4.14.170, v4.9.213, v4.4.213.
v5.5.3: Failed to apply! Possible dependencies:
5ff0cb1ce253 ("drm/nouveau/kms/nv50-: Use less encoders by
2017 Feb 23
0
[PATCH] drm/nouveau: gk20a: Turn instmem lock into mutex
On Mon, Jan 30, 2017 at 09:03:07PM +0100, Thierry Reding wrote:
> From: Thierry Reding <treding at nvidia.com>
>
> The gk20a implementation of instance memory uses vmap()/vunmap() to map
> memory regions into the kernel's virtual address space. These functions
> may sleep, so protecting them by a spin lock is not safe. This triggers
> a warning if the
2017 Jan 30
2
[PATCH] drm/nouveau: gk20a: Turn instmem lock into mutex
From: Thierry Reding <treding at nvidia.com>
The gk20a implementation of instance memory uses vmap()/vunmap() to map
memory regions into the kernel's virtual address space. These functions
may sleep, so protecting them by a spin lock is not safe. This triggers
a warning if the DEBUG_ATOMIC_SLEEP Kconfig option is enabled. Fix this
by using a mutex instead.
Signed-off-by: Thierry Reding
2015 Oct 26
2
[PATCH] instmem/gk20a: exclusively acquire instobjs
Although I would not have expected this to happen, we seem to run into
race conditions if instobjs are accessed concurrently. Use a global lock
for safety.
Signed-off-by: Alexandre Courbot <acourbot at nvidia.com>
---
drm/nouveau/nvkm/subdev/instmem/gk20a.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drm/nouveau/nvkm/subdev/instmem/gk20a.c
2017 Feb 24
1
[PATCH] drm/nouveau: gk20a: Turn instmem lock into mutex
On 02/24/2017 01:20 AM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Mon, Jan 30, 2017 at 09:03:07PM +0100, Thierry Reding wrote:
>> From: Thierry Reding <treding at nvidia.com>
>>
>> The gk20a implementation of instance memory uses vmap()/vunmap() to map
>> memory regions into the kernel's virtual address space. These functions
>>
2015 Nov 04
0
[PATCH] instmem/gk20a: exclusively acquire instobjs
On 10/26/2015 03:54 PM, Alexandre Courbot wrote:
> Although I would not have expected this to happen, we seem to run into
> race conditions if instobjs are accessed concurrently. Use a global lock
> for safety.
I wouldn't expect this to be an issue either.
Before merging such a large hammer of a fix, I'd strongly prefer to see
at least a better justification for why this is
2019 Sep 16
0
[PATCH 1/2] drm/nouveau: tegra: Fix NULL pointer dereference
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
2023 Dec 14
1
[PATCH] drm/nouveau: Fixup gk20a instobj hierarchy
On 08/12/2023 10:46, Thierry Reding wrote:
> From: Thierry Reding <treding at nvidia.com>
>
> Commit 12c9b05da918 ("drm/nouveau/imem: support allocations not
> preserved across suspend") uses container_of() to cast from struct
> nvkm_memory to struct nvkm_instobj, assuming that all instance objects
> are derived from struct nvkm_instobj. For the gk20a family