BUG? a suspected race bug at alloc_fd()

BUG? a suspected race bug at alloc_fd()

[홍신 shin hong]

Hi.  I am reporting a suspected race bug at alloc_fd() in Linux 2.6.30.4.

In alloc_fd(), spin_lock(&files->file_lock) synchronizes
the execution of its gurading code block(line 448~486 at fs/file.c).

However, by invocation of expand_files() at line 458,
spin_lock(&file->file_lock) can be released and re-taken
since expand_files() invokes expand_fdtable() and expand_fdtable()
release &files->file_lock and re-take the lock (line 206~208).

For this reason, the execution of alloc_fd() might result race condition
if other threads are scheduled between the lock releasing and re-taking.

Please examine the code and let me know your opinion.
Thank you.

Sincerely
Shin Hong

Re: BUG? a suspected race bug at alloc_fd()

[Matthew Wilcox]

On Fri, Aug 07, 2009 at 01:55:10PM +0900, ?????? shin hong wrote:
> In alloc_fd(), spin_lock(&files->file_lock) synchronizes
> the execution of its gurading code block(line 448~486 at fs/file.c).
> 
> However, by invocation of expand_files() at line 458,
> spin_lock(&file->file_lock) can be released and re-taken
> since expand_files() invokes expand_fdtable() and expand_fdtable()
> release &files->file_lock and re-take the lock (line 206~208).
> 
> For this reason, the execution of alloc_fd() might result race condition
> if other threads are scheduled between the lock releasing and re-taking.

        /*
         * If we needed to expand the fs array we
         * might have blocked - try again.
         */
        if (error)
                goto repeat;

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."