Received-SPF: pass (google.com: domain of linux-kernel+bounces-130838-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Wed, 3 Apr 2024 19:33:04 -0700
From: Dan Williams <dan.j.williams@intel.com>
To: Vishal Verma <vishal.l.verma@intel.com>, Dan Williams
	<dan.j.williams@intel.com>, Dave Jiang <dave.jiang@intel.com>, "Alison
 Schofield" <alison.schofield@intel.com>, Andrew Morton
	<akpm@linux-foundation.org>
CC: <linux-mm@kvack.org>, <nvdimm@lists.linux.dev>,
	<linux-cxl@vger.kernel.org>, <linux-kernel@vger.kernel.org>, Vishal Verma
	<vishal.l.verma@intel.com>
Subject: Re: [PATCH] dax/bus.c: replace WARN_ON_ONCE() with lockdep asserts
Message-ID: <660e116027bf6_24596294ba@dwillia2-mobl3.amr.corp.intel.com.notmuch>
References: <20240402-vv-dax_abi_fixes-v1-1-c3e0fdbafba5@intel.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20240402-vv-dax_abi_fixes-v1-1-c3e0fdbafba5@intel.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?HVgr02F+itSUfqlvh/z8q/MinH54dxtPHkZVBbhvgCLR24Fp4qQUnEUNfkO7?=
 =?us-ascii?Q?PWIaOuRHkkJwBUYRG+xZv4daQfak9IYQMSj+Hv/ihawvBMlUb/pLRnnWC3xg?=
 =?us-ascii?Q?6CuixuyO7VGBU6AgiGXTycy1atilK2YXcZMFBEM5VYPBvqIzJjs1771NLwQ6?=
 =?us-ascii?Q?NzuRE0C5ccZZADKILeVLEAkKyEfum+z21qPIP0NR1l7qbkloySinxe6hxy5F?=
 =?us-ascii?Q?S2CuZ0HJSfhYJ1gxmiX05EouaBNwPOdzP1vsSTxyMgndFAXEF6nUT6vcCDKL?=
 =?us-ascii?Q?Sj0ETtOUgmlFzBdfkElB33hUJEYMB9a0ZczvlIpMoVTJC3PNNhlr70bWS6z0?=
 =?us-ascii?Q?gEhKyNqLRYAHLEBnu7xyvLwtKze2An9Q2Je1YaaffWOTfxfrPhaMzGGKdBAC?=
 =?us-ascii?Q?y7Ydv6aVx7p52ZkoG4d3bkdHgdh8OgFiWxNrC0NuLNJ2BS92aAXy166BHAHs?=
 =?us-ascii?Q?68m2b+U3p9QtjuaSf+JdyFwjFb5qJ/tieKDdwIEO09o9vmyxMfqcVOXfzSTf?=
 =?us-ascii?Q?PCf6OI6DGeMFLOvSPaxmpY2/KgImXqkpIYf53jwHK4aDwn8sXTyC/oNfT+5e?=
 =?us-ascii?Q?MjgL4Vd5j3NKI8PtxfQVssNzPSJWfQGFA3gFdUTAhkjUp7BSalsST5RefkyS?=
 =?us-ascii?Q?0Zjzr9P6ZKekS6nZHuEOilqLvQQlwWInMfgdaRWKXEFLlHhQohm7GocDkek3?=
 =?us-ascii?Q?uaAi0P3GapLy6V0nKh17/JsOriyK/ToCgssrzjoh5b4lppUBRUVnBAKJfJZO?=
 =?us-ascii?Q?Z6hbZxxKernVBbPDgrPUZveQ7tolZLVODH9rZNm22BzZ1bFWuIOzSWp2N+dT?=
 =?us-ascii?Q?7RU9xASOW7cvBrkES29rNgwP3MRvW36RK+ZtFVzitL5Jgc1WmxTIELC+VOvK?=
 =?us-ascii?Q?EGa9bdJBeFdHOY2vG+rJutvEmqxQvCm0wJg/12ANmClhfV597X+ZsIgygB56?=
 =?us-ascii?Q?Rgrxi8YGXuEdL77rRYznUdV8HkXec/lRJZmYYnu7YMwX4MedjSWdHKdBgAz2?=
 =?us-ascii?Q?IrTUiI1qFesBagVwsPE+iW8wmGcRzvZ76KolqYIS6842eXu4seVYluL41Xon?=
 =?us-ascii?Q?hOqm69w4i4W0t59djcy5lhhJA3qCmt8Yl1leV3CCxtUPU4HK09/dH5jhyHaX?=
 =?us-ascii?Q?CzvgrgVkqu3g0JQMUZbeud+ygxLGDKZRV1xN1+O9VtxEbTnmd95ihsXRlvGF?=
 =?us-ascii?Q?ucbgdJsWtBewISHNYaFtQ7Wo0cBSkYwzSoY/OtjdPC5ZpJVAf2W29WnC3v/V?=
 =?us-ascii?Q?Nk1jmdc+6sZuiBUWLmb8U1knIIMeVVxvUjGO5RSvCADczRWwzJlS+NXaDHWg?=
 =?us-ascii?Q?VmpSN9BYfxSA82mdHGpnKaNBzmLdwiW8MoqOuUcKqEpwoyjkXL5et7hfqpgX?=
 =?us-ascii?Q?Utn/IRmF9SauUacw/wZ5J+5PYJL6z4is/CY5KGatUykZPd4ZT2L5g+55RZHZ?=
 =?us-ascii?Q?H7DlDuAkU6WIoyfD7S1Uq0IvZ+UUhRezwyjnkSpmq+CJ35g/c8Wfa3OQ8Umc?=
 =?us-ascii?Q?d+kdsjE6c6s/l4FbnekJytW1NkRhBUfnH/ZuB+5Dx4hEm5BzJiEg4NLdFpx/?=
 =?us-ascii?Q?NAZCswncOg3SRdYnAkk/xPuvm84e9BK/ZrfZK27V0p3F1QkMQ3GH3Zxqwj1J?=
 =?us-ascii?Q?ZA=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 0ac027ca-81af-4b26-162b-08dc544f8f72
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Apr 2024 02:33:06.6859
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: nWmJJspzewh1K6qZX5eQ5HO3UihY7Y2K+NK8/BFaHb2+uiMflJwQcOQXllQJ714lPvMyFa1FbIjArnf5JuBvcvIpKMAzfOKuDpAoiz9wlw0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR11MB7737
X-OriginatorOrg: intel.com

Vishal Verma wrote:
> In [1], Dan points out that all of the WARN_ON_ONCE() usage in the
> referenced patch should be replaced with lockdep_assert_held(_write)().
> 
> Replace those, and additionally, replace a couple of other
> WARN_ON_ONCE() introduced in the same patch for actual failure
> cases (i.e. when acquiring a semaphore fails in a remove / unregister
> path) with dev_WARN_ONCE() as is the precedent here.

/me goes to look why failures are warned vs bubbling up the error...

> 
> Recall that previously, unregistration paths was implicitly protected by
> overloading the device lock, which the patch in [1] sought to remove.
> This meant adding a semaphore acquisition in these unregistration paths.
> Since that can fail, and it doesn't make sense to return errors from
> these paths, retain the two instances of (now) dev_WARN_ONCE().
> 
> Link: https://lore.kernel.org/r/65f0b5ef41817_aa222941a@dwillia2-mobl3.amr.corp.intel.com.notmuch [1]
> Fixes: c05ae9d85b47 ("dax/bus.c: replace driver-core lock usage by a local rwsem")
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Reported-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
> ---
>  drivers/dax/bus.c | 23 +++++++++++++----------
>  1 file changed, 13 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
> index 797e1ebff299..d89c8c3b62f7 100644
> --- a/drivers/dax/bus.c
> +++ b/drivers/dax/bus.c
[..]
> @@ -726,7 +728,8 @@ static void unregister_dax_mapping(void *data)

..and realizes that is hunk is confused.

>  	if (rwsem_is_locked(&dax_region_rwsem))
>  		return __unregister_dax_mapping(data);

This is bug. Either it is safe to call this without the lock held, or it
must be safe to always acquire the lock. Anything else means the caller
needs to be refactored. Conditional locking is an indicator of a deeper
problem with code organization.

Yes, this was not part of the fixup, but the changelog led me here
because no WARNs should remain at the end of this effort.

I think the confusion results from replace *all* device_lock() when some
device_lock() is still needed.

> -	if (WARN_ON_ONCE(down_write_killable(&dax_region_rwsem) != 0))
> +	if (dev_WARN_ONCE(data, down_write_killable(&dax_region_rwsem) != 0,
> +			  "unable to acquire region rwsem\n"))

In a context like this that cannot return an error directly to the user
process making the request, like in a sysfs operation handler, then the
locking cannot worry about signals. This would become an uncoditional
down_write() lock. So down_write_killable() is typically for request
contexts where there is a user process waiting for a result. For
contexts like async driver probing where we might be in a kernel thread,
and definitely in functions that return 'void', it is a bug to use
fallible locks.