From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) (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 385722FD1B5 for ; Wed, 14 Jan 2026 17:36:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768412197; cv=none; b=Jw2gkmHROE7ER4fJZbLqQI4VdGyOHvyT1v6axvNdDkaybmCnF09mrMRmlwjVCcoBRo1Jnx3b8eNXTu+9hhBg72WkchQAQxOlsVLMCnyufBHRfzALmBNZ7pBjM0lH4Oi+pORatU3arTFMjan6X5Z1xllPOZFMblHdJB/DTZ8ijj4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768412197; c=relaxed/simple; bh=kiL1vI/3XAUWl4aE2fDFyGqz7AzrKtHTl9V5sXFpytI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=V8TA/5ICnuV1v7Nx37xaMihG/5hdFWGWZP626dSz6AfTMkOKoXI9vVrPLRDs/45WlFPzf5hiIPMpmfL8TY0/ZgtbelJjQpuwyxrExfIFID6spyR+3XhegjcPwbBDVMFPazeDJ08NxLz2VVGhPYUxIZGpwNmuX8i29A5nfq63zow= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=JrHV57V+; arc=none smtp.client-ip=209.85.222.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="JrHV57V+" Received: by mail-qk1-f177.google.com with SMTP id af79cd13be357-8b2ec756de0so6313685a.3 for ; Wed, 14 Jan 2026 09:36:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1768412195; x=1769016995; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=figB8dzHwd2D0XvRaWeBpTz4+U95P61NoReY1arrqU0=; b=JrHV57V+TkKzL1+/Du7WAZr3Kgjh8CzhskHGmeKTC9mRiwdwYU3NmoofHK0t2riBXO 9DF+8qDaflAuViw0jCJ+17XeJef2jx1LHwaVeANg1GeVXp8QGfbdjkx9Qne2iotunCPT 8z31aho5HhUF7BDcIgVoslHuh43euciccmHfOwiZkm0auxskfPYcNq53ep7VHUJE2CXO Gi+lxyh5LOIgBifqUVoIBGRl6/8jYd6ZELRukZ8fOXmnkdJI1Y70uyXVyBpcP+EclT/T tniL+/HUG7va/RINmzw5M3GFzK2batceRfqy2X0D1jE+cmB+aJg8LCA0kWU6SYcVpELl 2KkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768412195; x=1769016995; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=figB8dzHwd2D0XvRaWeBpTz4+U95P61NoReY1arrqU0=; b=rTKkTRwjMjNyzw1/NwHVxcdFS4TLHHROpiAQkyOQ+0HydMMTl8E0AQAd9wKnSte07z TOMuSXpvtqYrT/f2DM61IjAYvswqxJcG//RqSz6O0rlBW3+cJRwpUP0JJe5mtm6dl4VR F3RQfNDkYMMzvXIBMOoFYCyUT81WOUyLsFhXBydOyba+5DzrReariW9FyAKzdMbSHOuQ EuchCeqlR33ULXdUUct/WE4lbcWQHzQAlClFiucLkynq+7Z82C0H/nQJJ4ykaO4qzUXP zl1up/oH7TE0KtZvd3kYGC0T+2vOctn/3+Xk3nEazrVX1HKNrwMiSSAIHaDAtnjV4YHt 6kiA== X-Forwarded-Encrypted: i=1; AJvYcCUitj1dI2mdM1iKrRAkGk/Hh8pmUrbT6e4BK+yScBMqItC2SkCd9t4XWYD5A5BGh8aMnpoqE5TtQibHXbQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yy5frqvzrtp53NTUF+G3neRRW8XysJKf0YkR0pUrsNG3NSvy2k4 m4wmaByjHoMTKD4ye/ipsSe8KvQ+DeE0BH1z5on/EDnEEo9y5NH/COJujBM05V2Vons= X-Gm-Gg: AY/fxX4nJ7EyVngjl1SpXv+YRfbSucO8ze9QOHy3IMvy+yzGYMHZB2jnU+Xtj2ipc0T MMQXntnh5V41QKnnfoKUenH19ba+78BZHNuqHe4t7f64FhrVeIPdNa838qKPuA6/yMSmixCuq3o e8Gal2LuVqnIPdyyiqWsQZEP4Kyk6LipN+swJf+Kjkv/Df0YwCThHNFc6ekOfDcwrokl/zIUgxS dRmEjPpxClP0+OolJTtv6tLy/vTN4HP0kX8qRjF9dafw9Ed9I1HgEeb6XVLqqqG8TG700YXkjkH 5HrkMz9O57lzThaQmX7sBibAzR0szNiIGEvKl4KgcKbY07ygn+levAwg8gmOtPw4pj5GWtmhwtw KpQvfLx52hP39x1JsNeXuYS7iB6IjuLi+KhVN0AGZ7P0vlh0wAtcSxZnAltWsoNluZJpNhrjBMV O9qN7xRLZr3vS1r2Mfz6rM70gfexV/Um3Bvyu5MWf1kTdH05kC7rCkRnEZXoKcAOn5rw4I0A== X-Received: by 2002:a05:620a:4502:b0:8b9:7a1a:8c73 with SMTP id af79cd13be357-8c52fb90a04mr537400485a.46.1768412195222; Wed, 14 Jan 2026 09:36:35 -0800 (PST) Received: from gourry-fedora-PF4VCD3F (pool-96-255-20-138.washdc.ftas.verizon.net. [96.255.20.138]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8c530a6bdbdsm200764785a.10.2026.01.14.09.36.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Jan 2026 09:36:34 -0800 (PST) Date: Wed, 14 Jan 2026 12:36:02 -0500 From: Gregory Price To: "David Hildenbrand (Red Hat)" Cc: linux-mm@kvack.org, linux-cxl@vger.kernel.org, nvdimm@lists.linux.dev, linux-kernel@vger.kernel.org, virtualization@lists.linux.dev, kernel-team@meta.com, dan.j.williams@intel.com, vishal.l.verma@intel.com, dave.jiang@intel.com, mst@redhat.com, jasowang@redhat.com, xuanzhuo@linux.alibaba.com, eperezma@redhat.com, osalvador@suse.de, akpm@linux-foundation.org, Hannes Reinecke Subject: Re: [PATCH 8/8] dax/kmem: add memory notifier to block external state changes Message-ID: References: <20260114085201.3222597-1-gourry@gourry.net> <20260114085201.3222597-9-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=us-ascii Content-Disposition: inline In-Reply-To: On Wed, Jan 14, 2026 at 10:44:08AM +0100, David Hildenbrand (Red Hat) wrote: > On 1/14/26 09:52, Gregory Price wrote: > > Add a memory notifier to prevent external operations from changing the > > online/offline state of memory blocks managed by dax_kmem. This ensures > > state changes only occur through the driver's hotplug sysfs interface, > > providing consistent state tracking and preventing races with auto-online > > policies or direct memory block sysfs manipulation. > > > > The notifier uses a transition protocol with memory barriers: > > - Before initiating a state change, set target_state then in_transition > > - Use a barrier to ensure target_state is visible before in_transition > > - The notifier checks in_transition, then uses barrier before reading > > target_state to ensure proper ordering on weakly-ordered architectures > > > > The notifier callback: > > - Returns NOTIFY_DONE for non-overlapping memory (not our concern) > > - Returns NOTIFY_BAD if in_transition is false (block external ops) > > - Validates the memory event matches target_state (MEM_GOING_ONLINE > > for online operations, MEM_GOING_OFFLINE for offline/unplug) > > - Returns NOTIFY_OK only for driver-initiated operations with matching > > target_state > > > > This prevents scenarios where: > > - Auto-online policies re-online memory the driver is trying to offline > > Is this still a problem when using offline_and_remove_memory() ? > I just remembered another reason I did this: echo offline > memoryN/state This leaves the dax/hotplug state in an inconsistent state. if you do the above for every block in a dax region, `daxN.M/hotplug` still shows up as online. This just hard-locks the state to consistent (unless an online/offline fails along with its rollback). The additional complexity seemed warranted for that, but if you're happy to leave users to their footguns I'm not going to argue it. --- I just realized this breaks the current ndctl pattern and would force ndctl to convert to `hotplug` since memory block onlining will fail. ~Gregory