All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	 linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
	Minchan Kim <minchan@kernel.org>,
	 Sergey Senozhatsky <senozhatsky@chromium.org>,
	Jens Axboe <axboe@kernel.dk>
Subject: Re: [PATCH 2/2] zram: Use a custom key for each zram object.
Date: Fri, 24 Jul 2026 12:24:26 +0900	[thread overview]
Message-ID: <amLYsq36Qm4Isj63@google.com> (raw)
In-Reply-To: <20260714141300.3945672-3-bigeasy@linutronix.de>

Hello, sorry for the delay

On (26/07/14 16:13), Sebastian Andrzej Siewior wrote:
> Each struct zram uses the same key for its struct lockdep_map which is
> used for locking analysis.
> According to Sergey the lock chains might be different if zram1 is used
> for and zram2 is for ext4. This might lead to false dead lock reports if

    ^^ swap  (a minor nit)

> it mixes a zram1 chain with a zram2. This can be avoided if each lockmap
> gets its own unique key.c
> 
> Use a dynamic lock_class_key for the table_lock_map.
> 

[..]

>  static bool zram_meta_alloc(struct zram *zram, u64 disksize)
> @@ -1999,7 +1993,8 @@ static bool zram_meta_alloc(struct zram *zram, u64 disksize)
>  	if (!huge_class_size)
>  		huge_class_size = zs_huge_class_size(zram->mem_pool);
>  
> -	slot_lock_init(zram);
> +	lockdep_register_key(&zram->table_lock_key);
> +	lockdep_init_map(&zram->table_lock_map, "zram->table[index].lock", &zram->table_lock_key, 0);

So I wonder if we can give distinct name, given that it's per-device
now: "zram%d->table[index].lock" and use zram->disk->first_minor (which
is a unique device id).

If you are too busy I can just send a trivial follow up patch.
Let me know what you prefer.


Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Tested-by: Sergey Senozhatsky <senozhatsky@chromium.org>

  reply	other threads:[~2026-07-24  3:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-14 14:12 [PATCH 0/2] zram: lockmap tweaks Sebastian Andrzej Siewior
2026-07-14 14:12 ` [PATCH 1/2] zram: Move lockmap to be per-zram instead per table Sebastian Andrzej Siewior
2026-07-24  3:25   ` Sergey Senozhatsky
2026-07-14 14:13 ` [PATCH 2/2] zram: Use a custom key for each zram object Sebastian Andrzej Siewior
2026-07-24  3:24   ` Sergey Senozhatsky [this message]
2026-07-24  7:52     ` Sergey Senozhatsky
2026-07-24  3:26 ` [PATCH 0/2] zram: lockmap tweaks Sergey Senozhatsky
2026-07-24  3:31 ` Sergey Senozhatsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=amLYsq36Qm4Isj63@google.com \
    --to=senozhatsky@chromium.org \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=bigeasy@linutronix.de \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=minchan@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.