From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 BC9BA231830 for ; Sat, 25 Jul 2026 04:43:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784954589; cv=none; b=BJAvlFUreBwRFUt1iScuVdCfwdg4TAP3IGy6p18EPAD10UGJFtbZcaNPfjKzxksx9PwTha5n4KZlV8MtiTBEBc7UPHQrp1lpMH6+U94mhtoimfCATIas7hLyL3FyYjSbcO90h0S3Ili1QYAGRbRqWOY1OyAMXqCOf8Ra5rvIP90= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784954589; c=relaxed/simple; bh=28BaOu/REliw9W6vfxfzcsREcrj2lLH1n27lKkl4EHs=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=BKEmeirGUGbrPA4V7M3RF3xXmR/Xu5uNe0Xm1M72XdOSeVNiN6BSt5IoqvENnElwNBIXc7vvS5Bbzq4xLVL4GoCNgLnC6rGzR/CI1rv6fVnkhAxpvCV3+VgzRtHNrdVY25wOHmf1mgPG0opGgMIKF9GOdItwUCWi+6mYAWJPMNY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=YYLVcaSB; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="YYLVcaSB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DAE541F000E9; Sat, 25 Jul 2026 04:43:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1784954588; bh=1u/LUYrvJduI+Esv/eZmDncR/EueSm9YSJbi69UyDUo=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=YYLVcaSBRG4xJEz/Rj5RCArRccKxu5I83sxBKYg3SUXDyDQhQTIBKKyXfAHw3V+wK dccoYnxI9aXpX9Y0V18K+LBC60yXhl4bgOYwB9RefCtlhO2bnYg3P8SZaUnldUjzqb fuboSj9kpm3xEEKLqoDRmbXzubxavL0mWbSzVfnc= Date: Fri, 24 Jul 2026 21:43:07 -0700 From: Andrew Morton To: Arvind Yadav Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, david@kernel.org, matthew.brost@intel.com, joshua.hahnjy@gmail.com, ziy@nvidia.com, rakie.kim@sk.com, byungchul@sk.com, gourry@gourry.net, ying.huang@linux.alibaba.com, apopple@nvidia.com, Balbir Singh Subject: Re: [PATCH v2] mm/migrate_device: Clear stale mapping after freeing swapcache Message-Id: <20260724214307.a50ed52cf78fdc73bc42f9bf@linux-foundation.org> In-Reply-To: <20260724082702.2531024-1-arvind.yadav@intel.com> References: <20260724082702.2531024-1-arvind.yadav@intel.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 24 Jul 2026 13:57:02 +0530 Arvind Yadav wrote: > __migrate_device_pages() reads the folio mapping before calling > folio_free_swap(). When folio_free_swap() succeeds, the folio is removed > from the swap cache, but the saved mapping still points to swap_space. > > Passing the stale mapping to folio_migrate_mapping() makes it take the > mapped-folio path after the swapcache reference has been dropped. This can > cause an invalid swap_space lock access followed by a folio reference > count BUG. > > Refresh the saved mapping after folio_free_swap() so the current folio > state is used during migration. > Thanks. AI review might have found an issue with this. And one possible pre-existing issue in the code which Alistair and Balbir worked on. https://sashiko.dev/#/patchset/20260724082702.2531024-1-arvind.yadav@intel.com