From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 120A12E1EE0 for ; Wed, 17 Jun 2026 02:18:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781662715; cv=none; b=BtytDWIkXkCzEkpvbz5iiYzDytLLGpTE5RRPzf3WUcbeRsd6MPyau0f2wfGun3RyJhRH8FRbCIJCcHlDKyjWgyelKoOc2cxqxFxxf9RHBU1GEAzzBsGNYW3auSkr7TOAUPPrJPKWO9dtAE4/Xhv4j0BS5dqbe2NP9n0cBX3RP8c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781662715; c=relaxed/simple; bh=Oi+nBItIdsNJxJWvQYkDC8uqPlGHdHXn9q/rGJuETFk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=nG9QDcXsjb666w6mVqNyDH8j0lFd+N06zNjdQXqqIVTSNYSPpZJImd2BKOB2rGDUrsZU6KINVc8ON9p1pP8/auFx9cR0DW6L91HJxtRkakLv5OzKqcd43Vf5DXSXKTF4agT+ppp9xKLpWoiXVjM5hP3RUC6pGsbLNGSYgkKEaso= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=Np3vjqjt; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="Np3vjqjt" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=HkKhP5dgWoNLgZ860E6q6vUvnofK+KTQ8ZVRLSCljDg=; b=Np3vjqjtw2ZLTul/KSyGkcjLMC yV3inZ0BaexoioE7KKqggbpP0jSnISe4DKocTaDxWbA0Zg7RpezmPTR+X9MkMTMpSjamVK1NWpYb+ IXvQ2Bv+d0lSMoQGo3SvNaWSg1orzuJTFWPWGKNxGFQHcVlhrPFndCU9TEa3DB/TJmYrXbGZ6lMiH HfAMmvhNCj43jlk42OKqiBSoLvOfrjYoQRCCbYFouV2Lx9sRtuM2rX6GzhKt/6sCumYIhXft+yQbM /TJOsjZJd4JbNazOTxP6enqku9/9bZswCkSM4Ppz7fS/X5ZJYjkgP1CJDp65mQX05Fbbq35TB0gos Jm2bPXUQ==; Received: from willy by casper.infradead.org with local (Exim 4.99.1 #2 (Red Hat Linux)) id 1wZfrB-0000000BpkM-3YpQ; Wed, 17 Jun 2026 02:18:22 +0000 Date: Wed, 17 Jun 2026 03:18:21 +0100 From: Matthew Wilcox To: Jinjiang Tu Cc: Rik van Riel , ziy@nvidia.com, linux-kernel@vger.kernel.org, kernel-team@meta.com, Andrew Morton , David Hildenbrand , Lorenzo Stoakes , Hugh Dickins , Baolin Wang , "Liam R. Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , linux-mm@kvack.org Subject: Re: [PATCH] mm: khugepaged: free xarray nodes left behind by failed collapse_file() Message-ID: References: <20260616145413.1491961-1-riel@surriel.com> <8a4caadc-f414-4874-97d4-2fbaebe2af39@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8a4caadc-f414-4874-97d4-2fbaebe2af39@huawei.com> On Wed, Jun 17, 2026 at 10:00:59AM +0800, Jinjiang Tu wrote: > > 在 2026/6/16 23:29, Matthew Wilcox 写道: > > On Tue, Jun 16, 2026 at 10:54:13AM -0400, Rik van Riel wrote: > > > syzkaller reproduces it trivially with MADV_COLLAPSE on a sparse shmem > > > mapping (collapse aborts with SCAN_TRUNCATED because the range is empty), > > > and also via slab fault injection, which forces xas_create_range() down > > > the xas_nomem() path before the same abort. kmemleak then reports the > > > 576-byte struct xa_node objects allocated in xas_alloc()/xas_nomem(). > > I think the ways to produce this problem are sufficiently rare/unlikely > > I can reproduce it easily with following steps. [1] > 1) create file /tmp/test_madvise_collapse and ftruncate to 4MB size, and > then mmap the file > 2) memset for the first 2MB > 3) madvise(MADV_COLLAPSE) for the second 2MB > 4) unlink the file Yes, but is there a problem? That is, do we need to clear this up before we get to clear_inode()?