* Re: [PATCH 3/8] char: misc: Introduce misc_sync_register() [not found] ` <20260428160956.GC718365@nvidia.com> @ 2026-05-08 9:38 ` Tzung-Bi Shih 2026-05-08 11:54 ` Jason Gunthorpe 0 siblings, 1 reply; 4+ messages in thread From: Tzung-Bi Shih @ 2026-05-08 9:38 UTC (permalink / raw) To: Jason Gunthorpe Cc: Arnd Bergmann, Greg Kroah-Hartman, Benson Leung, linux-kernel, chrome-platform, Rafael J. Wysocki, Danilo Krummrich, Jonathan Corbet, Shuah Khan, Laurent Pinchart, Wolfram Sang, Johan Hovold, Paul E . McKenney, Dan Williams On Tue, Apr 28, 2026 at 01:09:56PM -0300, Jason Gunthorpe wrote: > On Mon, Apr 27, 2026 at 09:46:54PM +0800, Tzung-Bi Shih wrote: > > Introduce misc_sync_register() to support synchronous file operations > > for misc devices. This aims to prevent Use-After-Free errors when a > > device is deregistered while file operations are still in progress or > > files are open. > > > > It creates a synchronization context that wraps supported file > > operations and ensures the device is still registered before invoking > > the file operations. > > > > The minor number is deferred from being freed immediately on > > deregistration and is used as a primary key to search for the > > synchronization context in `misc_sync_ctx_list` after the device is > > unregistered. > > > > Performance impact: > > - All file operations are serialized by a global lock. > > - All file operations perform a linear search to find the corresponding > > miscdevice. > > This doesn't seem like a serious proposal, this is too much > performance cost. Thank you for the feedback. I understand your concerns about the performance cost, particularly regarding the global lock and linear search. This is indeed a serious proposal, and I've dedicated time to developing and testing it. Our primary goal is to address a real-world UAF issue we've encountered on our platforms by integrating a solution upstream, whether it uses revocable mechanism[1] or not, rather than carrying downstream patches. I see this as the cost for synchronizing file operations with misc driver registration, as previously mentioned in [2], which I believe is necessary to prevent the race conditions. I'm open to discussing potential optimizations or alternative approaches if you have suggestions. [1] https://lore.kernel.org/all/20260427135841.96266-10-tzungbi@kernel.org [2] https://lore.kernel.org/all/aTvTLpFmyVxanvYC@google.com ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 3/8] char: misc: Introduce misc_sync_register() 2026-05-08 9:38 ` [PATCH 3/8] char: misc: Introduce misc_sync_register() Tzung-Bi Shih @ 2026-05-08 11:54 ` Jason Gunthorpe 2026-05-09 9:40 ` Tzung-Bi Shih 0 siblings, 1 reply; 4+ messages in thread From: Jason Gunthorpe @ 2026-05-08 11:54 UTC (permalink / raw) To: Tzung-Bi Shih Cc: Arnd Bergmann, Greg Kroah-Hartman, Benson Leung, linux-kernel, chrome-platform, Rafael J. Wysocki, Danilo Krummrich, Jonathan Corbet, Shuah Khan, Laurent Pinchart, Wolfram Sang, Johan Hovold, Paul E . McKenney, Dan Williams On Fri, May 08, 2026 at 09:38:38AM +0000, Tzung-Bi Shih wrote: > I see this as the cost for synchronizing file operations with misc driver > registration, as previously mentioned in [2], which I believe is necessary > to prevent the race conditions. I'm open to discussing potential > optimizations or alternative approaches if you have suggestions. I think the past threads had many different ideas, I don't know why you choose to present this with something that is clearly acceptable.. The drivers ops lookup needs to be O(1) on the system call path. Everything else about this series is reasonable, but you need to pick a better way to do this. Jason ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 3/8] char: misc: Introduce misc_sync_register() 2026-05-08 11:54 ` Jason Gunthorpe @ 2026-05-09 9:40 ` Tzung-Bi Shih 2026-05-09 16:32 ` Jason Gunthorpe 0 siblings, 1 reply; 4+ messages in thread From: Tzung-Bi Shih @ 2026-05-09 9:40 UTC (permalink / raw) To: Jason Gunthorpe Cc: Arnd Bergmann, Greg Kroah-Hartman, Benson Leung, linux-kernel, chrome-platform, Rafael J. Wysocki, Danilo Krummrich, Jonathan Corbet, Shuah Khan, Laurent Pinchart, Wolfram Sang, Johan Hovold, Paul E . McKenney, Dan Williams On Fri, May 08, 2026 at 08:54:44AM -0300, Jason Gunthorpe wrote: > On Fri, May 08, 2026 at 09:38:38AM +0000, Tzung-Bi Shih wrote: > > > I see this as the cost for synchronizing file operations with misc driver > > registration, as previously mentioned in [2], which I believe is necessary > > to prevent the race conditions. I'm open to discussing potential > > optimizations or alternative approaches if you have suggestions. > > I think the past threads had many different ideas, I don't know why > you choose to present this with something that is clearly acceptable.. In previous discussions, we explored using `inode->i_cdev`[3], but that proved infeasible for misc devices[4]. Since all misc drivers share a single cdev, we cannot use that approach to store per-miscdevice context. This led us to the current design. [3] https://lore.kernel.org/all/20251021121536.GG316284@nvidia.com [4] https://lore.kernel.org/all/aQ1xfHuyg1y8eJQ_@google.com > > The drivers ops lookup needs to be O(1) on the system call path. Achieving O(1) lookup is currently infeasible for the misc subsystem. This is because misc devices use the minor number[5] as a search key to determine which miscdevice the file operation is tied to, which inherently involves a linear search. [5] https://elixir.bootlin.com/linux/v7.0/source/drivers/char/misc.c#L127 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 3/8] char: misc: Introduce misc_sync_register() 2026-05-09 9:40 ` Tzung-Bi Shih @ 2026-05-09 16:32 ` Jason Gunthorpe 0 siblings, 0 replies; 4+ messages in thread From: Jason Gunthorpe @ 2026-05-09 16:32 UTC (permalink / raw) To: Tzung-Bi Shih Cc: Arnd Bergmann, Greg Kroah-Hartman, Benson Leung, linux-kernel, chrome-platform, Rafael J. Wysocki, Danilo Krummrich, Jonathan Corbet, Shuah Khan, Laurent Pinchart, Wolfram Sang, Johan Hovold, Paul E . McKenney, Dan Williams On Sat, May 09, 2026 at 05:40:52PM +0800, Tzung-Bi Shih wrote: > > The drivers ops lookup needs to be O(1) on the system call path. > > Achieving O(1) lookup is currently infeasible for the misc subsystem. > This is because misc devices use the minor number[5] as a search key to > determine which miscdevice the file operation is tied to, which > inherently involves a linear search. So? It needs a solution, you can't just give up. Probably it will need driver changes, maybe focus on cdev_device_add() drivers first. Jason ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-05-09 16:32 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20260427134659.95181-1-tzungbi@kernel.org>
[not found] ` <20260427134659.95181-4-tzungbi@kernel.org>
[not found] ` <20260428160956.GC718365@nvidia.com>
2026-05-08 9:38 ` [PATCH 3/8] char: misc: Introduce misc_sync_register() Tzung-Bi Shih
2026-05-08 11:54 ` Jason Gunthorpe
2026-05-09 9:40 ` Tzung-Bi Shih
2026-05-09 16:32 ` Jason Gunthorpe
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox