Skip to content

[RFC] Determine Blob map_access permissions via fcntl instead of relying on defaults#42

Merged
gurchetansingh merged 2 commits intomagma-gpu:mainfrom
valpackett:val/wxpknlppools
Mar 3, 2026
Merged

[RFC] Determine Blob map_access permissions via fcntl instead of relying on defaults#42
gurchetansingh merged 2 commits intomagma-gpu:mainfrom
valpackett:val/wxpknlppools

Conversation

@valpackett
Copy link
Copy Markdown
Collaborator

@valpackett valpackett commented Feb 21, 2026

In libkrun, we've had quite a bit of trouble with these permissions, since with the introduction of PipeWire support the mode for shm/memfd was changed to RW, but that ended up crashing Wayland clients when the compositor would send us sealed-but-RDWR FDs (e.g. Smithay-based niri), so I've debugged that and added a check for the seals, and later discovered that wlroots-based compositors send RDONLY-but-not-write-sealed FDs and we'd still map these as RW and explode…

I'm not 100% sure if RW in this kind of mapping is necessary for PipeWire SHM streaming, interestingly #36 here does not change this (cc @dorindabassey — does PW just work with READ mappings for you?)… but once we start doing more interesting things like exporting dmabufs via PW things should definitely get more, well, interesting (I don't expect screen capture dmabufs to be writable heh). In any case relying on hardcoded defaults seems inherently limited.


As the bulk of this is Mesa code, I'd like to just get initial review here, if this all seems good and correct I'll prepare a merge request for Mesa.

Also: only compile tested for now.

valpackett and others added 2 commits February 21, 2026 03:15
[XXX: This will be sent to Mesa]

Signed-off-by: Val Packett <val@invisiblethingslab.com>
Instead of relying on defaults, use the newly available detection function
for the map access mode that takes into account the fd mode and the seals.

Signed-off-by: Val Packett <val@invisiblethingslab.com>
@dorindabassey
Copy link
Copy Markdown

Hi @valpackett I've been testing muvm with X11 clients like xeyes which doesn't really exercise PipeWire SHM streaming directly.
Whether PW works with READ mappings? I tested with muvm and pw-play --verbose /usr/share/sounds/alsa/Front_Left.wav PipeWire successfully initializes streams and gets to paused state without crashing, so I assume with that the SHM buffer mapping is working. But I don't have a complete audio sink setup to test actual streaming end-to-end.

@gurchetansingh gurchetansingh self-requested a review February 23, 2026 15:30
Copy link
Copy Markdown
Collaborator

@gurchetansingh gurchetansingh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks terrific, looks ready to merge when out of RFC mode.

@valpackett
Copy link
Copy Markdown
Collaborator Author

Finally runtime-tested, and now submitted the Mesa part to Mesa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40132

@gurchetansingh gurchetansingh marked this pull request as ready for review March 3, 2026 21:47
@gurchetansingh gurchetansingh merged commit a4b891f into magma-gpu:main Mar 3, 2026
7 checks passed
@valpackett valpackett deleted the val/wxpknlppools branch March 4, 2026 00:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants