From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?7ZmN7IugIHNoaW4gaG9uZw==?= Subject: BUG? a suspected race bug at alloc_fd() Date: Fri, 7 Aug 2009 13:55:10 +0900 Message-ID: <2014bcab0908062155n6973cb7cg43bc5dcb19261a72@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit To: linux-fsdevel@vger.kernel.org Return-path: Received: from mail-yx0-f175.google.com ([209.85.210.175]:33795 "EHLO mail-yx0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750766AbZHGEzK (ORCPT ); Fri, 7 Aug 2009 00:55:10 -0400 Received: by yxe5 with SMTP id 5so1684364yxe.33 for ; Thu, 06 Aug 2009 21:55:10 -0700 (PDT) Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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