From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-125.mta0.migadu.com [91.218.175.125]) (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 E7346387362 for ; Sat, 17 Oct 2026 02:26:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.125 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792203965; cv=none; b=LnAJiYi1Xs+d19LIcWAPBNEtXBNgIZeJYWJblIxOwC26/A8+70bolKmbg6sPjz6YEBqIYzKJr8Oq1sWThwWYldAX5yvhEf3FSHjs99jvBtjEycVjie9Q5HvsYbKtu2TO9wKq+32sV4W4k3dBRBK7gBxGxJBbQtf+P0QLNbxxiqc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792203965; c=relaxed/simple; bh=kT73SQ9qrNBz4JQaoCwZQm7pd4IOO4YKtSqNYA+Lw7U=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=VLrenO8vLzZ+pU0yaCsktBCEJSagoRAoTwhqHfK7UI52Quwi62Xwf1IVxuWM2lidIk4EvN8vKUc2IN/+NgzSQgYJFGJQ4Vk+I9I3gOggJDvyvIfGNE7RVV3SJCRR5S1LGBDmsVgYHD7MTNDYuVRITqxJlBmyL7WQ7d1ouPK90lo= 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=jPKauD8A; arc=none smtp.client-ip=91.218.175.125 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="jPKauD8A" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=kT73SQ9qrNBz4JQaoCwZQm7pd4IOO4YKtSqNYA+Lw7U=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1792203960; v=1; x=1792808760; b=jPKauD8AIHvxo3X9/Fm3sSHzHMe5+qfLBhsBokDqFJgwB7p862MKpb/YJ7V1l2E9evGlYDhV 0chKnX1Yet1G4c4ffLv1DYC54l9N+3QZYvdLl7kRGz3hlIsiQ6LFR3iujOK/55R6K4j42hAeWAd Mvg2eqCCUP3XlHq5KwvhiV30= X-Envelope-To: linux-kernel@vger.kernel.org Received: by mta11.migadu.com with ESMTPS id 67a546fd69196711; Sat, 17 Oct 2026 02:26:00 +0000 X-Mizu-Trace-ID: 67a546fd69196711 X-Migadu-Flow: FLOW_OUT Content-Type: text/plain; charset=us-ascii Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3901.100.1.1.12\)) Subject: Re: [PATCH] mm: warn on unaligned compound zone device ranges From: Muchun Song In-Reply-To: <20261016192111.cf4b6477a13a711248a8a079@linux-foundation.org> Date: Sat, 17 Oct 2026 10:25:42 +0800 Cc: Muchun Song , Mike Rapoport , Dan Williams , Vishal Verma , Dave Jiang , Alison Schofield , Joao Martins , Ritesh Harjani , linux-mm@kvack.org, nvdimm@lists.linux.dev, linux-cxl@vger.kernel.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <869C8763-FB8C-41B2-957E-0AD1B22FCC57@linux.dev> References: <20261016131334.3419393-1-songmuchun@bytedance.com> <20261016192111.cf4b6477a13a711248a8a079@linux-foundation.org> To: Andrew Morton X-Mailer: Apple Mail (2.3901.100.1.1.12) > On Oct 17, 2026, at 10:21, Andrew Morton = wrote: >=20 > On Fri, 16 Oct 2026 21:13:34 +0800 Muchun Song = wrote: >=20 >> A compound page of order N must start at a PFN aligned to 2^N pages. >> Therefore, a range used to initialize compound pages must start on a >> compound-page boundary and contain an integral number of compound = pages. >>=20 >> Two recent Device DAX bugs were caused by ranges that violated this >> invariant, but neither was detected by memmap_init_zone_device(). >>=20 >> Warn if the adjusted zone-device range violates this invariant so = future >> violations are reported when the compound pages are initialized. >>=20 >> ... >>=20 >> --- a/mm/mm_init.c >> +++ b/mm/mm_init.c >> @@ -1142,6 +1142,8 @@ void __ref memmap_init_zone_device(struct zone = *zone, >> if (!nr_pages) >> return; >>=20 >> + VM_WARN_ON(!IS_ALIGNED(start_pfn | nr_pages, = pfns_per_compound)); >=20 > Would VM_WARN_ON_ONCE() suffice? What I was thinking is that this function won't be called frequently, so = it won't encounter a large volume of log flushing. Therefore, I didn't use = the ONCE interface, and this way it can continue to catch similar issues. I'm OK if you prefer VM_WARN_ON_ONCE() though. Let me know what you = think. Thanks, Muchun >=20 >> + >> /* >> * Seed the reusable head-page template from the first real = struct >> * page. The normal page-init and refcount helpers must operate = on >>=20 >> base-commit: 63562804f25cb5b6f5e4f5e3a9f0d1c3c6868596 >> --=20 >> 2.54.0