On Thu, Dec 09, 2021 at 02:57:38PM -0500, Steven Rostedt wrote: > On Thu, 9 Dec 2021 11:42:35 -0800 > Beau Belgrave <beaub@xxxxxxxxxxxxxxxxxxx> wrote: > > > User program task: > > CPU0: ioctl(fd, REG) > > CPU1: close(fd) > > > > IE: Some program registers and then immediately calls close on the file. > > If the CPU migrates right between the 2 and the close swaps, it is > > possible this could occur. > > > > This could be attempted in tight loops maliciously as well. > > > > I assume with a mutex there that some barrier is imposed to ensure > > correct reads in this condition? (By virtue of the mutex acquire/check) > > But as I stated before, the ioctl() uses fdget() which will prevent he > close from calling the release. Even if they get swapped. If close goes > first and starts down the path of the release, then the ioctl is guaranteed > to return -EBADF. If it gets the fd, then close will be a nop, and the exit > of the ioctl will call the release. > > If this wasn't the case, then the race I was concerned about would be an > issue. > > Because we are both confused by this, add the mutex! :-) > > -- Steve Agreed, I will add the mutex. :) I guess I am being paranoid about an architecture that does not have automatic cache consistency and while the write / read don't happen at the exact time, they happen close together. Close enough that one CPU reads the old value from a cache line and gets it wrong. I don't believe that is possible on Intel, but I don't know if it's possible on other architectures (especially older ones). Thanks, -Beau
|