NetBSD Problem Report #58180

From www@netbsd.org  Sun Apr 21 02:57:53 2024
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 194531A9238
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 21 Apr 2024 02:57:53 +0000 (UTC)
Message-Id: <20240421025752.183EC1A923B@mollari.NetBSD.org>
Date: Sun, 21 Apr 2024 02:57:52 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: render nodes are busted
X-Send-Pr-Version: www-1.0

>Number:         58180
>Category:       kern
>Synopsis:       render nodes are busted
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Apr 21 03:00:00 +0000 2024
>Closed-Date:    Fri Apr 26 20:31:55 +0000 2024
>Last-Modified:  Fri Apr 26 20:31:55 +0000 2024
>Originator:     Taylor R Campbell
>Release:        current, 10
>Organization:
The /net/dri/renderBSD
>Environment:
>Description:
1. stat returns the wrong st_rdev for render nodes.  For example, for the render node for card N, it returns 64*2 + 64*2 + N, when it should just return 64*2 + N.

2. NetBSD's libdrm has no way to discover the bus that the render node is on, which it insists on knowing for some reason, because it gets that out of DRM_IOCTL_GET_UNIQUE but DRM_IOCTL_GET_UNIQUE is forbidden to render nodes.
>How-To-Repeat:
try to use /dev/dri/renderD<N>
>Fix:
1. return dminor->index, not 64*dminor->type + dminor->index -- the addition of 64*dminor->type is baked into dminor->index already

2. allow DRM_IOCTL_GET_UNIQUE on render nodes -- it doesn't leak anything interesting

>Release-Note:

>Audit-Trail:

State-Changed-From-To: open->needs-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Sun, 21 Apr 2024 03:04:45 +0000
State-Changed-Why:
fixes committed to HEAD
need pullup-10
maybe pullup-9 but patch isn't clean for DRM_IOCTL_GET_UNIQUE, owing to
locking changes


From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/58180 CVS commit: src/sys/external/bsd/drm2/drm
Date: Sun, 21 Apr 2024 03:02:40 +0000

 Module Name:	src
 Committed By:	riastradh
 Date:		Sun Apr 21 03:02:39 UTC 2024

 Modified Files:
 	src/sys/external/bsd/drm2/drm: drm_cdevsw.c

 Log Message:
 drm(4): Fix st_rdev in stat.

 dminor->index already has the 64*type adjustment, as allocated in
 drm_minor_alloc.

 PR kern/58180


 To generate a diff of this commit:
 cvs rdiff -u -r1.30 -r1.31 src/sys/external/bsd/drm2/drm/drm_cdevsw.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/58180 CVS commit: src/sys/external/bsd/drm2/dist/drm
Date: Sun, 21 Apr 2024 03:02:51 +0000

 Module Name:	src
 Committed By:	riastradh
 Date:		Sun Apr 21 03:02:51 UTC 2024

 Modified Files:
 	src/sys/external/bsd/drm2/dist/drm: drm_ioctl.c

 Log Message:
 drm: Allow DRM_IOCTL_GET_UNIQUE on render nodes.

 On NetBSD, libdrm uses this to discover what kind of bus the device
 is on, without which it refuses to expose the render node at all,
 rendering it useless.  With this change, libdrm is able to use render
 nodes on NetBSD.

 Since this is just reading out information about the bus type and
 bus/dev/func numbers, I don't think it's problematic to expose to
 render nodes.

 This requires tweaking the access path to the master.

 PR kern/58180


 To generate a diff of this commit:
 cvs rdiff -u -r1.24 -r1.25 src/sys/external/bsd/drm2/dist/drm/drm_ioctl.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: coypu@sdf.org
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/58180 (render nodes are busted)
Date: Mon, 22 Apr 2024 02:14:43 +0000

 Please do not backport this change. Having render nodes working better
 is an indicator for DRI3 working, and it is currently broken.
 I've attempted to get base MesaLib to use DRI3, and when it did, it
 caused my Intel GPU to hang.

 Backporting this change means more things will attempt to use DRI3.
 Perhaps modular Xorg will hit the same breakage.

 Let's leave this change in -current for now.

State-Changed-From-To: needs-pullups->closed
State-Changed-By: maya@NetBSD.org
State-Changed-When: Fri, 26 Apr 2024 20:31:55 +0000
State-Changed-Why:
Avoiding pulling up, dri3 is not stable, and this change might result in something like pkgsrc mesa using dri3 more.


>Unformatted:

Home	PR Database Search