From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Wilcox Subject: Re: BUG? a suspected race bug at alloc_fd() Date: Fri, 7 Aug 2009 05:08:12 -0600 Message-ID: <20090807110812.GR3711@parisc-linux.org> References: <2014bcab0908062155n6973cb7cg43bc5dcb19261a72@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org To: ?????? shin hong Return-path: Received: from palinux.external.hp.com ([192.25.206.14]:39974 "EHLO mail.parisc-linux.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757494AbZHGLIM (ORCPT ); Fri, 7 Aug 2009 07:08:12 -0400 Content-Disposition: inline In-Reply-To: <2014bcab0908062155n6973cb7cg43bc5dcb19261a72@mail.gmail.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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."