Re: [PATCH v6 02/13] user_events: Add minimal support for trace_event into ftrace

[Beau Belgrave <beaub@linux.microsoft.com>]

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@linux.microsoft.com> 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