From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=74.125.82.170 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792894640; b=oUNtFlOBHQt+iFidjvQkv3YhK1pJfgSE9Lqh36vSygVRxuqgUr3lyXIr9zcJt8z/Hogo qx07J5KzKr/r3SjJJIF9s66vppPxqzvsBP4nRyMJJBJ+y+2UID5EldHx2aok3hBVpmRbY 1GA7pHE1XTdo8SM/8RZ32KsnBXNFzToXe6zgd+olY1mtL0X9lCORESEI3clMmOnM9dpPh 737iKf3xyZCVVP/CgOMH3+663WhlAdCgHplwqVfXlNk8fIQUrUw2Y9QSodWZxWWAd0+tC set786m6o/TKX3efqGkBXqdYqKyT5f0eht1f9XNoUAVEcQOS4Q3U5DZjCBQmZ1qfyPg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792894640; h=DMARC-Filter:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Gm-Gg:X-Received:Received: From:To:Cc:Subject:In-Reply-To:Date:Message-ID:References; bh=59O6YsOe2ZdqTEDOrhAn775YQJaCvGOavb/hzAN0T1U=; b=Ydht1bArqtTj+QFqHlEJyEFZYLC8Y6jVfO7fP3tGj6XLGVk9dBOkcgyKd93CEMRR8weg zo+pxzAgg+Z1FCMYteRVV6947gdD0F6s9GLSZADoDMii9kG/1AfLchKdH6nSYIs4yv+Db Fdk1ubjDaLLM9bvlZq9yMo2bMdCMk002OLB9OwEpS/I9tZEExOyY8icm1YfAyrxn72j1h 8BNrxQjD69Grgml1aGg8vGeARldxOoR3zuw3rBG4qszpTp5ATWVD16cNUs+1DKY5VC4sC MkvEAgtvp83+2mWoKHVZtDL0vU3BABW4mfIMoFnyhKcA9QIfjChtszGzzRDwARMNtYg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20251104 header.b=gNV5pj8w; arc=none smtp.remote-ip=74.125.82.170 Received: from mail-dy1-f170.google.com (mail-dy1-f170.google.com [74.125.82.170]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B4908606A322 for ; Sun, 25 Oct 2026 02:17:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org B4908606A322 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20251104 header.b=gNV5pj8w Received: by mail-dy1-f170.google.com with SMTP id 5a478bee46e88-33fb4680717so3222155eec.1 for ; Sat, 24 Oct 2026 19:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1792894639; x=1793499439; darn=vger.kernel.org; h=references:message-id:date:in-reply-to:subject:cc:to:from:from:to :cc:subject:date:message-id:reply-to:content-type; bh=59O6YsOe2ZdqTEDOrhAn775YQJaCvGOavb/hzAN0T1U=; b=gNV5pj8wvyqTFd7GT3mqJNxxHaMp++gpshfwksnecbSIJyjTxKBy1INB12+h1tG1vJ TfQo9m1tMSvHdOHNHXZWI8AUho60rXmoV1FcZWEGEJQX2VHMkKYsG8+OHtfvMdaNFZDf KT4Xik4kCy3zFWfrLIuy8jcbolNC71nrdK+Rv0h4JH2FWrqidWHkO4DzcPArWNJclVU7 NOAjQf0A8qRwGhg7QHX7LrkTWsj6MOOgEcVlhuSvfI8RUvuaf2sg12bQk9tWE0DmEWo6 JpdK6g8I1gV3+j+j1xZGvsfYzdMks+9louxLyXH6GOQJPkjPJXexM/eyivAnsDAWhG2K Vwig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792894639; x=1793499439; h=references:message-id:date:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=59O6YsOe2ZdqTEDOrhAn775YQJaCvGOavb/hzAN0T1U=; b=0sldZfGyYYAFtVxR6lySLav94WlHXhT3wWA73xVjWzKH05TQfZTeP+VwoeA+owUubx nUUPcpiCosq20q78fIaQGPNcOm9tBeWy+zTxHufro6F76evqtUP1JrsMqxGHz4mzxOIm ypnXQL7KyjXwIGosvXYQjKM6PD1IZD9luNJdLoDsW98nOjHwJSGZYomG9TAQiBddqY4K pfCytqs0Bst+luHMOuZctZwxCFx4g4uAhRPLOUlXmavXAf2CQ5EQ10CNQYP0DPnJn8C5 VKhSasYwbGJ4lB4IwLUR1dHJoNf4gVH4xdrRJkqQLtFSFxdtccDsBRG0zR2fNZfqPe27 Jmrg== X-Forwarded-Encrypted: i=1; AKwUvByBnU5GwxwLtmLoRTKzmqZ8ZoSPsACpFolZkbBR4LZyfBM6J+QxlCEOb0mrwvppgjs2gCrN/XskMRmpEAk=@vger.kernel.org X-Gm-Message-State: AFq9FYJIcSB82O/tR2PbavFmIli17EX5mRSzsDAdsEcCyl7YuBbGZ8US eorwODjWzgnHGP6bcsf4DotGJ8865XlZXg9+T/l6u4lAFHuWJ3jylvom X-Gm-Gg: AYBFou1lFpwECmSoe7b7/FcbDWH/HOy/2hCXLlHxpq1lomV6tLFs4iEm024y+krlKhs aLwIZI4A3ZRkhy3IxLDlJBMLRavSu4UEOwEemjXQ5rmPi2qegRU1C5fz7kThz7OV9ftyYcKr96O 4MrkaWGaWUflEjHMpBefbfDt9ie74HWoobYKTyTp2rwQ4fuPgFnAfSqoQEjjSu+IGLHhTsGZq7a qixgagrGOm8JLlKkDmCGcJN1AYgrEhlQWasFCBNTDP2zTzcfLDHPOs7jQl+9PZW1xxKqZjqtjry iQ5Id5WwhjhvmGzMSm+jvLF0te1++c0UJcuP6QT14zq27z6Hpw4CbIQ/vxQq8n/kWIf5/TWkDhb 3T12dIaqSA+dHF9NJ/WJHkPm4UoUlAeI41J+i6yrJ51O1Bz1I5C03JcISh0lfZjEGKnB6Dpqe7e 0pjSeZ3hJc0MYWwqXfEXsivfYMQAWdP0MJjdXdolVGS2pi6IFgwvlqBf0iJVJkWpgUzHjrZrPBp fPmC1nMevBXYYjKY7XQsZwID9HoRSVCwZpwzn6kWR9LWh2smFcS7g== X-Received: by 2002:a05:693c:2d86:b0:35c:707b:acba with SMTP id 5a478bee46e88-369e8369d86mr7944429eec.3.1792894638749; Sat, 24 Oct 2026 19:17:18 -0700 (PDT) Received: from pve-server ([49.205.216.49]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-369e8d812d6sm12003945eec.10.2026.10.24.19.17.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 24 Oct 2026 19:17:17 -0700 (PDT) From: Ritesh Harjani (IBM) To: Andrew Morton , Muchun Song Cc: Dan Williams , Vishal Verma , Dave Jiang , Alison Schofield , Joao Martins , nvdimm@lists.linux.dev, linux-cxl@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Muchun Song Subject: Re: [PATCH v5] dax/bus: Fix Device DAX range alignment validation In-Reply-To: <20261024183853.6803ce81788636e94d8c16a4@linux-foundation.org> Date: Sun, 25 Oct 2026 07:40:03 +0530 Message-ID: References: <20261024112555.2476001-1-songmuchun@bytedance.com> <20261024183853.6803ce81788636e94d8c16a4@linux-foundation.org> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Andrew Morton writes: > On Sat, 24 Oct 2026 19:25:55 +0800 Muchun Song wrote: > >> Only range sizes are currently validated against dev_dax->align. A >> dynamic device can therefore select a large-page alignment and allocate a >> range whose start is not naturally aligned. >> >> Sashiko found that memmap_init_zone_device() could then initialize the >> struct pages with a large-page order for a physical range that is not >> naturally aligned. A subsequent write to a userspace mapping then >> triggered a kernel panic in testing. >> >> The automatic resize path can also split a size-aligned request across >> arbitrary free gaps. When devices with different alignments fragment a >> region, this can extend a range by less than the device alignment. A later >> allocation then fails, leaving the failed resize partially applied. >> >> Initialize the device alignment before its first allocation. Validate both >> the start and size of allocated and adjusted ranges. Use the same >> aligned-gap iterator for free-space accounting and range allocation so the >> pre-check and allocation path cannot diverge. Skip unusable gaps and >> serialize size validation with alignment updates. >> >> Static Device DAX already has a pre-populated pgmap whose full range was >> validated against memremap_compat_align(). Its usable data range may begin >> after namespace metadata, so require only dev_dax->align for static >> devices. Dynamic Device DAX builds its pgmap from the allocated ranges and >> must continue to satisfy both alignments. > > Thanks. This is now a must-have for 7.4. > > I suggest that the changelog mention that the bug becomes hittable once > your series "mm: Unify device DAX and HugeTLB vmemmap population paths" > exposes it. That's > > 4b77739fe789 ("mm/sparse-vmemmap: drop VMEMMAP_POPULATE_DAX"). > > I intend to send this to Linus next week. > > Maybe also a Fixes: 4b77739fe789. That series didn't create the bug, > but this data provides notification to people who are backporting this > series (unlikely) "hey, you need to add this fix as well". > > Also > Reported-by: Ritesh Harjani (IBM) > Closes: https://lore.kernel.org/wlrkqqvg.ritesh.list@gmail.com I think, the fix for the issue (the one that I reported) is a different patch [1]. And I did give my tested by there. [1]: https://lore.kernel.org/all/20261016054914.2601510-1-songmuchun@bytedance.com/ > > I don't believe that Ritesh has tested this? He wasn't cc'ed... Nopes, I haven't. But I am looking into another open issue on Power which this series exposes. So while at it, I can test this as well. Thanks for the cc' -ritesh