2022-02-09 06:37:29

by Namhyung Kim

[permalink] [raw]
Subject: [PATCH 06/12] btrfs: change lockdep class size check using ks->names

With upcoming lock tracepoints config, it'd allow some lockdep
annotation code without enabling CONFIG_LOCKDEP actually. In that
config, size of the struct lock_class_key would be 0.

But it'd cause divide-by-zero in btrfs_set_buffer_lockdep_class() due
to ARRAY_SIZE macro. Let's change it to use ks->names[] instead. It
should have the same size as with ks->keys[].

Cc: Chris Mason <[email protected]>
Cc: Josef Bacik <[email protected]>
Cc: [email protected]
Acked-by: David Sterba <[email protected]>
Signed-off-by: Namhyung Kim <[email protected]>
---
fs/btrfs/disk-io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 87a5addbedf6..be41e35bee92 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -190,7 +190,7 @@ void btrfs_set_buffer_lockdep_class(u64 objectid, struct extent_buffer *eb,
{
struct btrfs_lockdep_keyset *ks;

- BUG_ON(level >= ARRAY_SIZE(ks->keys));
+ BUG_ON(level >= ARRAY_SIZE(ks->names));

/* find the matching keyset, id 0 is the default entry */
for (ks = btrfs_lockdep_keysets; ks->id; ks++)
--
2.35.0.263.gb82422642f-goog



2022-02-09 12:04:05

by David Sterba

[permalink] [raw]
Subject: Re: [PATCH 06/12] btrfs: change lockdep class size check using ks->names

On Tue, Feb 08, 2022 at 10:42:02AM -0800, Namhyung Kim wrote:
> With upcoming lock tracepoints config, it'd allow some lockdep
> annotation code without enabling CONFIG_LOCKDEP actually. In that
> config, size of the struct lock_class_key would be 0.
>
> But it'd cause divide-by-zero in btrfs_set_buffer_lockdep_class() due
> to ARRAY_SIZE macro. Let's change it to use ks->names[] instead. It
> should have the same size as with ks->keys[].
>
> Cc: Chris Mason <[email protected]>
> Cc: Josef Bacik <[email protected]>
> Cc: David Sterba <[email protected]>
> Cc: [email protected]
> Signed-off-by: Namhyung Kim <[email protected]>

Acked-by: David Sterba <[email protected]>