From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: with ECARTIS (v1.0.0; list xfs); Thu, 09 Oct 2008 00:01:12 -0700 (PDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m997177f014324 for ; Thu, 9 Oct 2008 00:01:09 -0700 Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 54E84A190BB for ; Thu, 9 Oct 2008 00:02:45 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id HrG2jZ18QcxUMcXI for ; Thu, 09 Oct 2008 00:02:45 -0700 (PDT) Date: Thu, 9 Oct 2008 03:02:45 -0400 From: Christoph Hellwig Subject: Re: [PATCH 6/5]: XFS: Prevent use-after-free caused by synchronous inode reclaim 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 Content-Disposition: inline In-Reply-To: <20081009042134.GD9597@disturbed> Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com List-Id: xfs To: xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org 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.