Message ID | 20240208184913.484340-3-mathieu.desnoyers@efficios.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-58565-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:50ea:b0:106:860b:bbdd with SMTP id r10csp381883dyd; Thu, 8 Feb 2024 10:54:31 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXHcftY7nN6oGC3Z06u/zcDuswxyk97j8gfCeJqjKez1KzhzpriOgD/r6dF4qdaAc4fsA+cR80ZEuzQ1Q+6TwCW99OkiA== X-Google-Smtp-Source: AGHT+IFF1UOeZ5UsawniqzgSUZjeXdtaQYjASryjQmUgE+RDBJM4Uk+E/dcht4RoJil1JEJZnNTO X-Received: by 2002:a17:906:b7cc:b0:a38:4dc0:22f9 with SMTP id fy12-20020a170906b7cc00b00a384dc022f9mr3519361ejb.4.1707418471012; Thu, 08 Feb 2024 10:54:31 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707418471; cv=pass; d=google.com; s=arc-20160816; b=m1Q68mPiRB5orQST35eiIkeOzTKFLec4OZ15BpFYr+TkJy3nSA6DP9R43JnMjDjj9g y7WORDJzzceRL4CQFAykrLgMzyIF3jGNeyGt6h/muq+9C5hFLhzx/ok8uE6msnKx/z50 YhVk8RLxXPsJRRHDnJZadt4B664J4w9eehuabtZApKjA5IHfj4W12D55XxqgxSgM1fni jvGD8ju+NpfgxJN/0dkH+byG382YvJ3NuArwjTAXp+mFWsPrrHKTYJ6b5Qus1rl25CTX jtP36rwjyZ43QeFMrmCbPrHHtZPeB0j5IKMhGcY3DDyIJHxlvanDr+PR4l8YpqL/b3Yf hlOA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=980dRtjhZ1sqASItbAJHswL4sSjsBCZ26JEnu08+RSE=; fh=DI9Qi/74wWLnf1HZySXasQrRy1Pqoj4NbvnN4BTovw8=; b=dzzlAHdPpLh1H12eZLgq1VwlGxGeDnrG0Lwp2VOWfPsqm+tPBo/n1/jRZUQOjC02fU FNxEoOzo0hKYoBkYnyTw3hr9yZQkcGFLIt67MN8DcC1WPnpbfLaq++TWJyUtGlXjqIdp 0EVjbDrh8vvCAuo1wBgMBRQErzmk1XvVTRAFUuSeVNrTNKM6zIrUagwpU9iz5jRXsfa0 vPX+sOoNQXcfIcPB5ODv3tQ/cN1aObUnJkZOItdURO5TQEGrX6emWqxZETZYD2e9n1E9 9hsb36plqIPTP8KiagAK1hrOQvq28knVmCEZECQS3TI5pZRf7XLRKOAPDnjJIgSIauyn 4Ajw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@efficios.com header.s=smtpout1 header.b=BHv82fq4; arc=pass (i=1 spf=pass spfdomain=efficios.com dkim=pass dkdomain=efficios.com dmarc=pass fromdomain=efficios.com); spf=pass (google.com: domain of linux-kernel+bounces-58565-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-58565-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com X-Forwarded-Encrypted: i=2; AJvYcCV+eCf8fp/af31WpcWRPfApyMGiO7JVnUWWnbjdx15PnaQCZ6u+QNGc1niMv7/C8iVWxDVOad53eytNqxPxgMWkKULhUg== Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id qq23-20020a17090720d700b00a384794ccb2si297861ejb.24.2024.02.08.10.54.30 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Feb 2024 10:54:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-58565-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@efficios.com header.s=smtpout1 header.b=BHv82fq4; arc=pass (i=1 spf=pass spfdomain=efficios.com dkim=pass dkdomain=efficios.com dmarc=pass fromdomain=efficios.com); spf=pass (google.com: domain of linux-kernel+bounces-58565-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-58565-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 5BD731F2CE35 for <ouuuleilei@gmail.com>; Thu, 8 Feb 2024 18:54:07 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 85C813F9E8; Thu, 8 Feb 2024 18:49:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b="BHv82fq4" Received: from smtpout.efficios.com (smtpout.efficios.com [167.114.26.122]) (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 B9DAF28DA6; Thu, 8 Feb 2024 18:49:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=167.114.26.122 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707418171; cv=none; b=mCH0TpSlR2b/YxkzZm8gDqfgYGhpMSLqVn5WQB945hgzj1x//GatZ7RlS8lFLrbTq0Qt9PQwoy/ECTTpc+vDc6Ay40KKWwPc6m0vYWSAfkmX93CTJJ2B3Is/r+831aptMmmdrHfWjoSjMOM9KJDBAnWYL+YhuXWkd78QrfQFKQk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707418171; c=relaxed/simple; bh=NdQ4OmFkV2+G2H8B4VkXTCxDeM+TIHeVIiPEQVlM7R8=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=dZmE4m25CT0W9UMGSw64YHJX/3T2qVIcCBlNeuWjiGhPGms3traG20FFh+PL0LQ+NxApw6iU2rpKyf2AGf9d5vL4CokvlXkhI7FUSMzjRUNZipf2LaWHf7Qm/bE2A5KeC2ZplE7ya/1HFHWJYP3I6PtjHRCAq/6l0qZKbxM8VJM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=efficios.com; spf=pass smtp.mailfrom=efficios.com; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b=BHv82fq4; arc=none smtp.client-ip=167.114.26.122 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=efficios.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=efficios.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com; s=smtpout1; t=1707418163; bh=NdQ4OmFkV2+G2H8B4VkXTCxDeM+TIHeVIiPEQVlM7R8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BHv82fq4hO859vusQup+/Ew3E/xkDIrfZ5htPvlriwUnHkvNeARgnnZMiSWHzApqW mBUnp7NhYcFC4sHncmcbqwbZiLufbXuPZ1mmrcc2XRx2OacMg8w1iMcNtrBwOoQ7t8 tlegoMFq/Kcq54d6KDuhbA+a5CHjBM14TYr6oFPdFcRGkfXiGVluKpmPuYTt++FmPu urOv+1cJgX+X7s/GbAlJpQacEjTwJqNEmsDVAUYaXnkKjRNrV7bXs2jN1Ij2VQhEwb /6iWsYm8EPA5tPa8SlmPXLVR3oPElZBuasrhf6GDfTwyLf9CcfdtgsPjHjkxUKokLX dtG+zbC42rI5A== Received: from thinkos.internal.efficios.com (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4TW5cg1khXzY5L; Thu, 8 Feb 2024 13:49:23 -0500 (EST) From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> To: Dan Williams <dan.j.williams@intel.com>, Arnd Bergmann <arnd@arndb.de>, Dave Chinner <david@fromorbit.com> Cc: linux-kernel@vger.kernel.org, Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Andrew Morton <akpm@linux-foundation.org>, Linus Torvalds <torvalds@linux-foundation.org>, Vishal Verma <vishal.l.verma@intel.com>, Dave Jiang <dave.jiang@intel.com>, Matthew Wilcox <willy@infradead.org>, Russell King <linux@armlinux.org.uk>, linux-arch@vger.kernel.org, linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-xfs@vger.kernel.org, dm-devel@lists.linux.dev, nvdimm@lists.linux.dev, linux-s390@vger.kernel.org, Alasdair Kergon <agk@redhat.com>, Mike Snitzer <snitzer@kernel.org>, Mikulas Patocka <mpatocka@redhat.com> Subject: [PATCH v4 02/12] nvdimm/pmem: Treat alloc_dax() -EOPNOTSUPP failure as non-fatal Date: Thu, 8 Feb 2024 13:49:03 -0500 Message-Id: <20240208184913.484340-3-mathieu.desnoyers@efficios.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240208184913.484340-1-mathieu.desnoyers@efficios.com> References: <20240208184913.484340-1-mathieu.desnoyers@efficios.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790358031091807852 X-GMAIL-MSGID: 1790358031091807852 |
Series |
Introduce cpu_dcache_is_aliasing() to fix DAX regression
|
|
Commit Message
Mathieu Desnoyers
Feb. 8, 2024, 6:49 p.m. UTC
In preparation for checking whether the architecture has data cache
aliasing within alloc_dax(), modify the error handling of nvdimm/pmem
pmem_attach_disk() to treat alloc_dax() -EOPNOTSUPP failure as non-fatal.
For the transition, consider that alloc_dax() returning NULL is the
same as returning -EOPNOTSUPP.
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing caches")
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Alasdair Kergon <agk@redhat.com>
Cc: Mike Snitzer <snitzer@kernel.org>
Cc: Mikulas Patocka <mpatocka@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-arch@vger.kernel.org
Cc: linux-cxl@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-mm@kvack.org
Cc: linux-xfs@vger.kernel.org
Cc: dm-devel@lists.linux.dev
Cc: nvdimm@lists.linux.dev
---
drivers/nvdimm/pmem.c | 26 ++++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)
Comments
Mathieu Desnoyers wrote: > In preparation for checking whether the architecture has data cache > aliasing within alloc_dax(), modify the error handling of nvdimm/pmem > pmem_attach_disk() to treat alloc_dax() -EOPNOTSUPP failure as non-fatal. > > For the transition, consider that alloc_dax() returning NULL is the > same as returning -EOPNOTSUPP. > > Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing caches") > Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> > Cc: Alasdair Kergon <agk@redhat.com> > Cc: Mike Snitzer <snitzer@kernel.org> > Cc: Mikulas Patocka <mpatocka@redhat.com> > Cc: Andrew Morton <akpm@linux-foundation.org> > Cc: Linus Torvalds <torvalds@linux-foundation.org> > Cc: Dan Williams <dan.j.williams@intel.com> > Cc: Vishal Verma <vishal.l.verma@intel.com> > Cc: Dave Jiang <dave.jiang@intel.com> > Cc: Matthew Wilcox <willy@infradead.org> > Cc: Arnd Bergmann <arnd@arndb.de> > Cc: Russell King <linux@armlinux.org.uk> > Cc: linux-arch@vger.kernel.org > Cc: linux-cxl@vger.kernel.org > Cc: linux-fsdevel@vger.kernel.org > Cc: linux-mm@kvack.org > Cc: linux-xfs@vger.kernel.org > Cc: dm-devel@lists.linux.dev > Cc: nvdimm@lists.linux.dev > --- > drivers/nvdimm/pmem.c | 26 ++++++++++++++------------ > 1 file changed, 14 insertions(+), 12 deletions(-) > > diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c > index 9fe358090720..f1d9f5c6dbac 100644 > --- a/drivers/nvdimm/pmem.c > +++ b/drivers/nvdimm/pmem.c > @@ -558,19 +558,21 @@ static int pmem_attach_disk(struct device *dev, > disk->bb = &pmem->bb; > > dax_dev = alloc_dax(pmem, &pmem_dax_ops); > - if (IS_ERR(dax_dev)) { > - rc = PTR_ERR(dax_dev); > - goto out; > + if (IS_ERR_OR_NULL(dax_dev)) { alloc_dax() should never return NULL. I.e. the lead in before this patch should fix this misunderstanding: diff --git a/include/linux/dax.h b/include/linux/dax.h index b463502b16e1..df2d52b8a245 100644 --- a/include/linux/dax.h +++ b/include/linux/dax.h @@ -86,11 +86,7 @@ static inline void *dax_holder(struct dax_device *dax_dev) static inline struct dax_device *alloc_dax(void *private, const struct dax_operations *ops) { - /* - * Callers should check IS_ENABLED(CONFIG_DAX) to know if this - * NULL is an error or expected. - */ - return NULL; + return ERR_PTR(-EOPNOTSUPP); } static inline void put_dax(struct dax_device *dax_dev) { > + rc = IS_ERR(dax_dev) ? PTR_ERR(dax_dev) : -EOPNOTSUPP; Then this ternary can be replaced with just a check of which PTR_ERR() value is being returned.
On 2024-02-08 16:32, Dan Williams wrote: > Mathieu Desnoyers wrote: >> In preparation for checking whether the architecture has data cache >> aliasing within alloc_dax(), modify the error handling of nvdimm/pmem >> pmem_attach_disk() to treat alloc_dax() -EOPNOTSUPP failure as non-fatal. >> >> For the transition, consider that alloc_dax() returning NULL is the >> same as returning -EOPNOTSUPP. >> >> Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing caches") >> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> >> Cc: Alasdair Kergon <agk@redhat.com> >> Cc: Mike Snitzer <snitzer@kernel.org> >> Cc: Mikulas Patocka <mpatocka@redhat.com> >> Cc: Andrew Morton <akpm@linux-foundation.org> >> Cc: Linus Torvalds <torvalds@linux-foundation.org> >> Cc: Dan Williams <dan.j.williams@intel.com> >> Cc: Vishal Verma <vishal.l.verma@intel.com> >> Cc: Dave Jiang <dave.jiang@intel.com> >> Cc: Matthew Wilcox <willy@infradead.org> >> Cc: Arnd Bergmann <arnd@arndb.de> >> Cc: Russell King <linux@armlinux.org.uk> >> Cc: linux-arch@vger.kernel.org >> Cc: linux-cxl@vger.kernel.org >> Cc: linux-fsdevel@vger.kernel.org >> Cc: linux-mm@kvack.org >> Cc: linux-xfs@vger.kernel.org >> Cc: dm-devel@lists.linux.dev >> Cc: nvdimm@lists.linux.dev >> --- >> drivers/nvdimm/pmem.c | 26 ++++++++++++++------------ >> 1 file changed, 14 insertions(+), 12 deletions(-) >> >> diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c >> index 9fe358090720..f1d9f5c6dbac 100644 >> --- a/drivers/nvdimm/pmem.c >> +++ b/drivers/nvdimm/pmem.c >> @@ -558,19 +558,21 @@ static int pmem_attach_disk(struct device *dev, >> disk->bb = &pmem->bb; >> >> dax_dev = alloc_dax(pmem, &pmem_dax_ops); >> - if (IS_ERR(dax_dev)) { >> - rc = PTR_ERR(dax_dev); >> - goto out; >> + if (IS_ERR_OR_NULL(dax_dev)) { > > alloc_dax() should never return NULL. I.e. the lead in before this patch > should fix this misunderstanding: > > diff --git a/include/linux/dax.h b/include/linux/dax.h > index b463502b16e1..df2d52b8a245 100644 > --- a/include/linux/dax.h > +++ b/include/linux/dax.h > @@ -86,11 +86,7 @@ static inline void *dax_holder(struct dax_device *dax_dev) > static inline struct dax_device *alloc_dax(void *private, > const struct dax_operations *ops) > { > - /* > - * Callers should check IS_ENABLED(CONFIG_DAX) to know if this > - * NULL is an error or expected. > - */ > - return NULL; > + return ERR_PTR(-EOPNOTSUPP); > } > static inline void put_dax(struct dax_device *dax_dev) > { > >> + rc = IS_ERR(dax_dev) ? PTR_ERR(dax_dev) : -EOPNOTSUPP; > > Then this ternary can be replaced with just a check of which PTR_ERR() > value is being returned. As you noted, I've introduced this as cleanups in later patches. I don't mind folding these into their respective per-driver commits and moving the alloc_dax() hunk earlier in the series. Thanks, Mathieu
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c index 9fe358090720..f1d9f5c6dbac 100644 --- a/drivers/nvdimm/pmem.c +++ b/drivers/nvdimm/pmem.c @@ -558,19 +558,21 @@ static int pmem_attach_disk(struct device *dev, disk->bb = &pmem->bb; dax_dev = alloc_dax(pmem, &pmem_dax_ops); - if (IS_ERR(dax_dev)) { - rc = PTR_ERR(dax_dev); - goto out; + if (IS_ERR_OR_NULL(dax_dev)) { + rc = IS_ERR(dax_dev) ? PTR_ERR(dax_dev) : -EOPNOTSUPP; + if (rc != -EOPNOTSUPP) + goto out; + } else { + set_dax_nocache(dax_dev); + set_dax_nomc(dax_dev); + if (is_nvdimm_sync(nd_region)) + set_dax_synchronous(dax_dev); + pmem->dax_dev = dax_dev; + rc = dax_add_host(dax_dev, disk); + if (rc) + goto out_cleanup_dax; + dax_write_cache(dax_dev, nvdimm_has_cache(nd_region)); } - set_dax_nocache(dax_dev); - set_dax_nomc(dax_dev); - if (is_nvdimm_sync(nd_region)) - set_dax_synchronous(dax_dev); - pmem->dax_dev = dax_dev; - rc = dax_add_host(dax_dev, disk); - if (rc) - goto out_cleanup_dax; - dax_write_cache(dax_dev, nvdimm_has_cache(nd_region)); rc = device_add_disk(dev, disk, pmem_attribute_groups); if (rc) goto out_remove_host;