From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?7ZmN7IugIHNoaW4gaG9uZw==?= Subject: a suspected race bug at locks_remove_flock() Date: Fri, 24 Jul 2009 16:55:17 +0900 Message-ID: <2014bcab0907240055x5292ccf2r61a3dcb137de8f91@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-f192.google.com ([209.85.210.192]:47986 "EHLO mail-yx0-f192.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751790AbZGXHzR (ORCPT ); Fri, 24 Jul 2009 03:55:17 -0400 Received: by yxe30 with SMTP id 30so315855yxe.33 for ; Fri, 24 Jul 2009 00:55:17 -0700 (PDT) Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hi. I found a suspected race condition bug at locks_remove_flocks() in fs/locks.c of recent Linux kernel. This bug is similar to the one reported in ChangeLog 2.6.24 (commit 85c59580b30c82aa771aa33b37217a6b6851bc14) and also to the one I report right before. During the execution of locks_remove_flock(), Big Kernel Lock(BKL) might be released and re-taken at the call site of locks_delete_lock() unintentionally due to the Releasing-On-Block semantics of BKL. This is because locks_delete_lock() can invoke kmem_cache_alloc() which can be blocked. BKL releasing an retaking may result race condition by breaking atomic execution of the code block guarded by lock_kernel() and unlock_kernelt(). Please examine the possbility of race condition of this code and let me know your opinion. Shin Hong