From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 6/5]: XFS: Prevent use-after-free caused by synchronous inode reclaim Date: Thu, 9 Oct 2008 03:02:45 -0400 Message-ID: <20081009070245.GA16621@infradead.org> References: <1223416332-7026-1-git-send-email-david@fromorbit.com> <20081009042134.GD9597@disturbed> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org Return-path: Received: from bombadil.infradead.org ([18.85.46.34]:44492 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755511AbYJIHCq (ORCPT ); Thu, 9 Oct 2008 03:02:46 -0400 Content-Disposition: inline In-Reply-To: <20081009042134.GD9597@disturbed> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Oct 09, 2008 at 03:21:34PM +1100, Dave Chinner wrote: > Folks, > > The following patch fixes a use after free I just found. > It appears that switching between SLAB and SLUB seems to > turn off slab/slub memory poisoning, so i d??dn't realise > I'd be running for some time without poisoning turned on. > Once I turned poisoning back on I found this use-after-free > immediately on the first unmount trying to reclaim a clean > realtime bitmap inode. > > With this patch, the netire patchset that I posted yesterday > passes xfsqa with memory poisoning turned on. Looks good. > + XFS_STATS_INC(vn_reclaim); > + if (xfs_reclaim(ip)) > + panic("%s: cannot reclaim 0x%p\n", __func__, inode); Eventually we should kill the return value from xfs_reclaim and just put an assert directly into it. In fact given that xfs_reclaim is quite OS dependent we might just merge the content directly into destroy_inode.