RE: [PATCH] Fix the race between the fget() and close()

2013-08-31 Thread Liu, Chuansheng
> -Original Message- > From: Al Viro [mailto:v...@ftp.linux.org.uk] On Behalf Of Al Viro > Sent: Saturday, August 31, 2013 3:36 PM > To: Liu, Chuansheng > Cc: Eric Dumazet; linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH] Fix the rac

Re: [PATCH] Fix the race between the fget() and close()

2013-08-31 Thread Al Viro
On Sat, Aug 31, 2013 at 07:01:33AM +, Liu, Chuansheng wrote: > My scenario is: > P1 files_struct refcount is 1, P2's is 1 also. > P1 get_files_struct(P2) > P1 install one file into P2's files_struct > P1 put_files_struct(P2) > > Then P1 and P2's files_struct refcount are 1, then when P1 is do

RE: [PATCH] Fix the race between the fget() and close()

2013-08-31 Thread Liu, Chuansheng
> -Original Message- > From: Al Viro [mailto:v...@ftp.linux.org.uk] On Behalf Of Al Viro > Sent: Saturday, August 31, 2013 2:48 PM > To: Liu, Chuansheng > Cc: Eric Dumazet; linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH] Fix the rac

Re: [PATCH] Fix the race between the fget() and close()

2013-08-30 Thread Al Viro
On Sat, Aug 31, 2013 at 05:53:11AM +, Liu, Chuansheng wrote: > I think I found one of possible race here(two processes P1 and P2): > P1 has the the files_struct pointer FILES1, P2 has the files_struct pointer > FILES2, > > When P1 open file, the new struct file pointer SHARE_FILE will be ins

RE: [PATCH] Fix the race between the fget() and close()

2013-08-30 Thread Liu, Chuansheng
Hello Al, > -Original Message- > From: Al Viro [mailto:v...@ftp.linux.org.uk] On Behalf Of Al Viro > Sent: Tuesday, August 27, 2013 8:49 AM > To: Liu, Chuansheng > Cc: Eric Dumazet; linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH] Fix th

RE: [PATCH] Fix the race between the fget() and close()

2013-08-26 Thread Liu, Chuansheng
Thanks Al. > -Original Message- > From: Al Viro [mailto:v...@ftp.linux.org.uk] On Behalf Of Al Viro > Sent: Tuesday, August 27, 2013 8:43 AM > To: Liu, Chuansheng > Cc: Eric Dumazet; linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH] Fi

Re: [PATCH] Fix the race between the fget() and close()

2013-08-26 Thread Al Viro
On Tue, Aug 27, 2013 at 01:42:47AM +0100, Al Viro wrote: > Might be buggered refcounting on struct file somewhere (i.e. extra fput() > done, > getting the file freed *before* close(), leaving a dangling pointer in > descriptor table). Might be memory corruption of some kind, slapping junk > point

Re: [PATCH] Fix the race between the fget() and close()

2013-08-26 Thread Al Viro
On Mon, Aug 26, 2013 at 11:56:43PM +, Liu, Chuansheng wrote: > Yes, the fix is really insane, I realized it after sent it. > But I think the race is there, right? Yes, in userland code. Depending on the timing, T3 might * issue ioctl() on old file if called before close() in T1

RE: [PATCH] Fix the race between the fget() and close()

2013-08-26 Thread Liu, Chuansheng
vger.kernel.org > Subject: Re: [PATCH] Fix the race between the fget() and close() > > On Tue, Aug 27, 2013 at 12:12:49AM +0800, Chuansheng Liu wrote: > > > > When one thread is calling sys_ioctl(), and another thread is calling > > sys_close(), current code has prote

Re: [PATCH] Fix the race between the fget() and close()

2013-08-26 Thread Eric Dumazet
On Tue, 2013-08-27 at 00:12 +0800, Chuansheng Liu wrote: > When one thread is calling sys_ioctl(), and another thread is calling > sys_close(), current code has protected most cases. > > But for the below case, it will cause issue: > T1T2

Re: [PATCH] Fix the race between the fget() and close()

2013-08-26 Thread Al Viro
On Tue, Aug 27, 2013 at 12:12:49AM +0800, Chuansheng Liu wrote: > > When one thread is calling sys_ioctl(), and another thread is calling > sys_close(), current code has protected most cases. > > But for the below case, it will cause issue: > T1T2

[PATCH] Fix the race between the fget() and close()

2013-08-25 Thread Chuansheng Liu
When one thread is calling sys_ioctl(), and another thread is calling sys_close(), current code has protected most cases. But for the below case, it will cause issue: T1T2 T3 sys_close(oldfile)sys_open(newfile)