On 5/25/2026 1:06 PM, Greg KH wrote:
On Mon, May 25, 2026 at 11:30:43AM +0800, Jianping Li wrote:
On 5/22/2026 3:03 PM, Greg KH wrote:
On Fri, May 22, 2026 at 02:55:29PM +0800, Jianping Li wrote:
On 5/15/2026 9:36 PM, Dmitry Baryshkov wrote:
On Fri, May 15, 2026 at 08:42:14PM +0800, Jianping Li wrote:
From: Ekansh Gupta<[email protected]>
fastrpc_req_munmap_impl() is called to unmap any buffer. The buffer is
getting removed from the list after it is unmapped from DSP. This can
create potential race conditions if any other thread removes the entry
from list while unmap operation is ongoing. Remove the entry before
How can it remove the entry from the list?
Multiple threads sharing the same file descriptor may invoke unmap concurrently.
multiple threads sharing the same file descriptor is a horrible
userspace bug. If you do that, you get what you deserve :)
thanks,
greg k-h
I agree that concurrent unmap on the same buffer from multiple threads
is a userspace bug.
However, the fastrpc driver is exposed via ioctl, and any userspace
(including any random apk) can map directly and then call multiple unmap.
So there is no userspace selinux permissions settings on the fasterpc
device node at all?
This patch is not intended to support incorrect userspace usage,
but to ensure that the driver remains robust against invalid or
racy inputs.
Isn't control to this device an "admin only" thing?
thanks,
greg k-h
Hi Greg,
Thanks for the feedback.
Yes there is sepolicy.
I’ll collect more details around the expected userspace model and
access restrictions for this interface, and better justify whether
this needs kernel-side handling.
For now, I’ll drop this patch from the current series and revisit it
with additional context in a separate submission.
Thanks,
Jianping
