On Wed, 2018-12-26 at 21:56 +0800, Jia-Ju Bai wrote: > In drivers/fsi/fsi-sbefifo.c, the functions sbefifo_user_release(), > sbefifo_user_read() and sbefifo_user_write() may be concurrently executed.
So after refreshing my mind, looking at the code and talking with Al, I really dont' see what race you are trying to fix here. read/write should never be concurrent with release for a given file and the stuff we are protecting here is local to the file instance. Do you have an actual problem you observed ? Cheers, Ben. > sbefifo_user_release() > sbefifo_release_command() > vfree(user->pending_cmd); > > sbefifo_user_read() > mutex_lock(); > rc = __sbefifo_submit(sbefifo, user->pending_cmd, ...); > > sbefifo_user_write() > mutex_lock(); > user->pending_cmd = user->cmd_page; > user->pending_cmd = vmalloc(len); > > Thus, possible concurrency use-after-free bugs may occur in > sbefifo_user_release(). > > To fix these bugs, the calls to mutex_lock() and mutex_unlock() are > added in sbefifo_user_release(). > > > Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com> > --- > drivers/fsi/fsi-sbefifo.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/fsi/fsi-sbefifo.c b/drivers/fsi/fsi-sbefifo.c > index d92f5b87c251..e278a9014b8f 100644 > --- a/drivers/fsi/fsi-sbefifo.c > +++ b/drivers/fsi/fsi-sbefifo.c > @@ -900,8 +900,10 @@ static int sbefifo_user_release(struct inode *inode, > struct file *file) > if (!user) > return -EINVAL; > > + mutex_lock(&user->file_lock); > sbefifo_release_command(user); > free_page((unsigned long)user->cmd_page); > + mutex_unlock(&user->file_lock); > kfree(user); > > return 0;
