On Wed, Aug 06, 2025 at 01:24:04PM +0530, Abhijit Gangurde wrote: > > On 8/2/25 01:51, Jakub Kicinski wrote: > > On Fri, 1 Aug 2025 14:00:14 -0300 Jason Gunthorpe wrote: > > > > Perhaps I misunderstand things, or otherwise am on the wrong track here. > > > > But this seems to open the possibility of users of ionic_adminq_post_wait(), > > > > outside the Ethernet driver, executing a wide range or admin commands. > > > > It seems to me that it would be nice to narrow that surface. > > > The kernel is monolithic, it is not normal to spend performance > > > aggressively policing APIs. > > > > > > mlx5 and other drivers already have interfaces almost exactly like this. > > Which is not to say that it's a good idea. > > Thank you for the feedback, and apologies for the delay. This discussion > prompted a thorough internal review. > Although a precedent for similar interfaces exists in other RDMA drivers, > the point is well-taken and we understand the concern about a wide API. To > address this, two potential approaches are being considered, > 1. The function can be documented as a privileged, clarifying that it > performs no input sanitization and making the caller responsible for device > access. > 2. Alternatively, a new, narrower function could be introduced specifically > for RDMA use that validates commands against an explicit allow list. > > We are open to either approach and would appreciate a guidance on the > preferred direction. I suggest you to take standard kernel coding pattern and create in-kernel API which suits your "in-kernel customers". There is no need in any "allow list" for in-kernel APIs. Let's don't bring complexity and defense programming style where it is not needed and here it is not needed. Thanks > > Abhijit > >
