On Sun, 03 Mar 2024, Timur Tabi wrote:
> On Sun, Mar 3, 2024 at 4:46 AM Duoming Zhou wrote:
>>
>> The kcalloc() in nouveau_dmem_evict_chunk() will return null if
>> the physical memory has run out. As a result, if we dereference
>> src_pfns, dst_pfns or dma_addrs, the null pointer dereference
On 2/20/24 22:58, Timur Tabi wrote:
Add the NVreg_RegistryDwords command line parameter, which allows
specifying additional registry keys to be sent to GSP-RM. This
allows additional configuration, debugging, and experimentation
with GSP-RM, which uses these keys to alter its behavior.
Note
If VM_BIND is enabled on the client the legacy submission ioctl can't be
used, however if a client tries to do so regardless it will return an
error. In this case the clients mutex remained unlocked leading to a
deadlock inside nouveau_drm_postclose or any other nouveau ioctl call.
Fixes:
Those are already de-facto UAPI, so let's just move it into the uapi
header.
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_abi16.c | 20 +++-
drivers/gpu/drm/nouveau/nouveau_abi16.h | 12
include/uapi/drm/nouveau_drm.h | 22
This is a note to let you know that I've just added the patch titled
drm/nouveau: don't fini scheduler before entity flush
to the 6.7-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
On Mon, Mar 04, 2024 at 06:01:46PM +0100, Danilo Krummrich wrote:
> This bug is present in v6.7 only, since the scheduler design has been
> re-worked in v6.8.
>
> Client scheduler entities must be flushed before an associated GPU
> scheduler is teared down. Otherwise the entitiy might still hold
On Mon, Mar 04, 2024 at 06:01:46PM +0100, Danilo Krummrich wrote:
> This bug is present in v6.7 only, since the scheduler design has been
> re-worked in v6.8.
Now queued up, thanks.
greg k-h
On Mon, Mar 04, 2024 at 07:10:56PM +0100, Danilo Krummrich wrote:
> On 3/4/24 18:55, Greg KH wrote:
> > On Mon, Mar 04, 2024 at 06:01:46PM +0100, Danilo Krummrich wrote:
> > > Cc: # v6.7 only
> > You say 6.7 only, but this commit is in 6.6, so why not 6.6 also?
>
> Good catch, I was sure I
On 3/1/24 04:42, Dave Airlie wrote:
From: Dave Airlie
It appears the client object tree has no locking unless I've missed
something else. Fix races around adding/removing client objects,
mostly vram bar mappings.
4562.099306] general protection fault, probably for non-canonical address
On 3/4/24 18:55, Greg KH wrote:
On Mon, Mar 04, 2024 at 06:01:46PM +0100, Danilo Krummrich wrote:
Cc: # v6.7 only
You say 6.7 only, but this commit is in 6.6, so why not 6.6 also?
Good catch, I was sure I originally merged this for 6.7. This fix should indeed
be applied to 6.6 as well.
This is a note to let you know that I've just added the patch titled
drm/nouveau: don't fini scheduler before entity flush
to the 6.6-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This bug is present in v6.7 only, since the scheduler design has been
re-worked in v6.8.
Client scheduler entities must be flushed before an associated GPU
scheduler is teared down. Otherwise the entitiy might still hold a
pointer to the scheduler's runqueue which is freed at scheduler tear
down
Reviewed-by: Lyude Paul
On Mon, 2024-03-04 at 19:31 +0100, Karol Herbst wrote:
> Those are already de-facto UAPI, so let's just move it into the uapi
> header.
>
> Signed-off-by: Karol Herbst
> ---
> drivers/gpu/drm/nouveau/nouveau_abi16.c | 20 +++-
>
Reviewed-by: Lyude Paul
On Mon, 2024-03-04 at 19:31 +0100, Karol Herbst wrote:
> If VM_BIND is enabled on the client the legacy submission ioctl can't be
> used, however if a client tries to do so regardless it will return an
> error. In this case the clients mutex remained unlocked leading to a
14 matches
Mail list logo
