From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-52.mta0.migadu.com [91.218.175.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E848281AA8 for ; Tue, 18 Aug 2026 04:31:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787027515; cv=none; b=UOmwL+NYxEZnA+ZQNPITkViF8D6AF5v74vxI5I/AcJShUX3nTG+fKC3yHVv3pV3/047F/AHklz1Rr00qptsYDEijyKP0KxRRbIaIj5cVWgH+xLu51ePwtdw/Nz+dlqA0CfZT8FZau+miMSx/8g6mqgWnVKcaRVbOhTz2hT0uEsw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787027515; c=relaxed/simple; bh=b2qJdvQbeH43yX00jUqynKJ+7oIe65NCighffZRb504=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=gzl/TZgDFQD7sqP9fnArly/kH+jhI8aP/E1sw2O2pIf5tNV470s3ggPA5ySJps9FRNiHhqKsVeAHlupQevkuNAntLMPznsd+GnfCrgMhwgOrvzdTZQgjEbJUUTKQY4vfSt15R4UVdx78fiacR1WOVFDRzoTf0ZayOGhOagKXYsQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=e4ATKDYZ; arc=none smtp.client-ip=91.218.175.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="e4ATKDYZ" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=b2qJdvQbeH43yX00jUqynKJ+7oIe65NCighffZRb504=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1787027509; v=1; x=1787632309; b=e4ATKDYZRRBpiIBraQ6Y6pnNIBi/wB282vQcEHlmrFMMl/HxRl1c4ghdKKG/GbPXW3MU5ZUI lRAQZZb5iWwarg6u4dkBVMGv61Ic5DKUjanJq40EHTH/RafWRhTR4L8FdtG5ilL/TY/Ly8Rcf7G JuQOKwl4JJAspdo5kLF7w3g4= X-Envelope-To: linux-kernel@vger.kernel.org Received: from localhost (2602:fce1:44f:115e::) by smtp.migadu.com with ESMTPS id 64c7aa18bce6ebfa; Tue, 18 Aug 2026 04:31:48 +0000 X-Migadu-Flow: FLOW_OUT From: Lance Yang To: gourry@gourry.net Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, akpm@linux-foundation.org, david@kernel.org, ljs@kernel.org, ziy@nvidia.com, baolin.wang@linux.alibaba.com, liam@infradead.org, nico.pache@linux.dev, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, usama.arif@linux.dev, vbabka@kernel.org, jannh@google.com, matthew.brost@intel.com, joshua.hahnjy@gmail.com, rakie.kim@sk.com, byungchul@sk.com, ying.huang@linux.alibaba.com, apopple@nvidia.com, balbirs@nvidia.com, Lance Yang Subject: Re: [PATCH v2 0/3] mm: reject zone device folios in more folio walkers Date: Tue, 18 Aug 2026 12:31:43 +0800 Message-Id: <20260818043143.22297-1-lance.yang@linux.dev> X-Mailer: git-send-email 2.39.3 (Apple Git-146) In-Reply-To: <20260817220810.1175596-1-gourry@gourry.net> References: <20260817220810.1175596-1-gourry@gourry.net> 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-Transfer-Encoding: 8bit On Mon, Aug 17, 2026 at 06:08:07PM -0400, Gregory Price wrote: >Several LRU-oriented mm walkers resolve the folio backing a PMD entry >(or a physical pfn) and then reclaim, age, migrate, or lazyfree it >without ever checking for ZONE_DEVICE memory. > >This series adds missing folio_is_zone_device() rejections, matching >the checks that comparable walkers already perform. > >- mm/huge_memory, mm/madvise: the !pmd_present branch above these sites > only filters device-private entries (which are non-present). > > A present zone device PMD (e.g. device-coherent) would still reach the > folio and be lazyfreed / aged / paged out. Add an explicit check. > >- mm/mempolicy: queue_folios_pmd() can see a present zone device PMD > (e.g. device-coherent) and queue it for migration. > >No crash reproducer - this is a correctness/hardening cleanup found by >inspection. All checks are placed after the folio is resolved and before >it is acted upon, on paths that already hold the relevant page-table lock, >so no locking or refcount changes are involved. Cool! Gave the whole series a spin on x86_64 QEMU with a PMD-mapped device-coherent THP. Without these patches, partial MADV_FREE and MADV_COLD reliably hit a kernel panic in remove_migration_pte(), while mbind(MPOL_MF_MOVE | MPOL_MF_STRICT) returned -EIO. With v2, all three worked fine, PMD mapping stayed intact, and data checked out :) Note that both kernels used the same small change to the in-kernel HMM test driver, allowing its coherent device memory to be allocated as 2 MB folios so the PMD-mapped test case could be exercised. Tested-by: Lance Yang