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
