From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mingming Cao Subject: Re: Corruption in "b_assoc_buffer" list of bufferhead structure. Date: Tue, 09 May 2006 14:13:46 -0700 Message-ID: <1147209226.4781.123.camel@localhost.localdomain> References: <446032AE.8030600@in.ibm.com> Reply-To: cmm@us.ibm.com Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org, srinivds@in.ibm.com Return-path: Received: from e34.co.us.ibm.com ([32.97.110.152]:29097 "EHLO e34.co.us.ibm.com") by vger.kernel.org with ESMTP id S1751015AbWEIVNs (ORCPT ); Tue, 9 May 2006 17:13:48 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k49LDmsP030896 for ; Tue, 9 May 2006 17:13:48 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k49LDm7r178882 for ; Tue, 9 May 2006 15:13:48 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k49LDl8X016056 for ; Tue, 9 May 2006 15:13:47 -0600 To: srinivasa In-Reply-To: <446032AE.8030600@in.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, 2006-05-09 at 11:41 +0530, srinivasa wrote: > Hi > I have got a oops in which "b_assoc_buffer" list of bufferhead is > getting corrupted with strange values. It looks like a race problem > ,which is not reproducable at everytime. > When I looked in to the code,I found that "b_assoc_buffer" list is > protected by a spinlock on "private_lock" of struct address_space. But > there is one situation,where I suspect the chance of corruption. that is > in try_to_free_buffers() of fs/buffer.c > When mapping becomes NULL, there is no lock protection and if 2 or more > processors passes this condition and executes drop_buffers() > simultaneously, there may be a chance of list corruption. > > So could somebody please explain whether this situation exists or not? Yes, the situation exists. Which kernel you are running now? It seems Badari has discovered the same issue and the patch that fixed the deference already made into mainline: http://marc.theaimsgroup.com/?l=linux-kernel&m=111464710927691&w=2 Thanks, Mingming > ====================================================================== > > int try_to_free_buffers(struct page *page) > { > struct address_space * const mapping = page->mapping; > struct buffer_head *buffers_to_free = NULL; > int ret = 0; > > BUG_ON(!PageLocked(page)); > if (PageWriteback(page)) > return 0; > > if (mapping == NULL) { /* can this still happen? */ <<<>>>>> > ret = drop_buffers(page, &buffers_to_free); > goto out; > } > > spin_lock(&mapping->private_lock); > ret = drop_buffers(page, &buffers_to_free); > if (ret) { > /* > * If the filesystem writes its buffers by hand (eg ext3) > * then we can have clean buffers against a dirty page. We > * clean the page here; otherwise later reattachment of > buffers > * could encounter a non-uptodate page, which is > unresolvable. > * This only applies in the rare case where > try_to_free_buffers > * succeeds but the page is not freed. > */ > clear_page_dirty(page); > } > spin_unlock(&mapping->private_lock); > ========================================================================================= > > > Thanks > Srinivasa DS > > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html