On Fri, Apr 16, 2021 at 05:19:50AM +0000, Al Viro wrote: > On Thu, Apr 01, 2021 at 12:40:34PM +0200, Christian Brauner wrote: > > and see whether all of them can be switched to simply using > > receive_fd(). I did a completely untested rough sketch to illustrate > > what I meant by using binder and devpts Xie seems to have just picked > > those two. But the change is obviously only worth it if all or nearly > > all callers can be switched over without risk of regression. > > It would most likely simplify quite a few codepaths though especially in > > the error paths since we can get rid of put_unused_fd() cleanup. > > > > But it requires buy in from others obviously. > > Opening a file can have non-trivial side effects; reserving a descriptor > can't. Moreover, if you look at the second hit in your list, you'll see > that we do *NOT* want that combined thing there - fd_install() is > completely irreversible, so we can't do that until we made sure the > reply (struct vtpm_proxy_new_dev) has been successfully copied to > userland. No, your receive_fd_user() does not cover that. > > There's a bunch of other cases like that - the next ones on your list > are drivers/dma-buf/sw_sync.c and drivers/dma-buf/sync_file.c, etc. FWIW, pretty much all ioctls that return descriptor as part of a structure stored to user-supplied address tend to be that way; some don't have any other output fields (in which case they probably would've been better off with just passing the descriptor as return value of ioctl(2)). Those might be served by that receive_fd_user() helper; anything that has several outputs won't be. The same goes for anything that has hard-to-undo operations as part of what they need to do: reserve fd set file up do hard-to-undo stuff install into descriptor table is the only feasible order of operations - reservation can fail, so it must go before the hard-to-undo part and install into descriptor table can't be undone at all, so it must come last. Looks like e.g. drivers/virt/nitro_enclaves/ne_misc_dev.c case might be of that sort... _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
