On 7/23/21 2:24 PM, Al Viro wrote: > On Fri, Jul 23, 2021 at 02:10:40PM -0600, Jens Axboe wrote: >> On 7/23/21 1:00 PM, Al Viro wrote: >>> On Fri, Jul 23, 2021 at 11:56:29AM -0600, Jens Axboe wrote: >>> >>>> Will send out two patches for this. Note that I don't see this being a >>>> real issue, as we explicitly gave the ring fd to another task, and being >>>> that this is purely for read/write, it would result in -EFAULT anyway. >>> >>> You do realize that ->release() might come from seriously unexpected >>> places, right? E.g. recvmsg() by something that doesn't expect >>> SCM_RIGHTS attached to it will end up with all struct file references >>> stashed into the sucker dropped, and if by that time that's the last >>> reference - welcome to ->release() run as soon as recepient hits >>> task_work_run(). >>> >>> What's more, if you stash that into garbage for unix_gc() to pick, >>> *any* process closing an AF_UNIX socket might end up running your >>> ->release(). >>> >>> So you really do *not* want to spawn any threads there, let alone >>> possibly exfiltrating memory contents of happy recepient of your >>> present... >> >> Yes I know, and the iopoll was the exception - we don't do anything but >> cancel off release otherwise. > > Not saying you don't - I just want to have that in (searchable) archives. > Ideally we need that kind of stuff in Documentation/*, but having it > findable by google search is at least better than nothing... Agree, and I'll amend the commit to include a reference to it as well and expand the explanation a bit. The easier that kind of stuff is to find, the better. -- Jens Axboe
