From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 E02C1227BB9 for ; Tue, 7 Jul 2026 10:02:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783418565; cv=none; b=MIk9JQAYjySY3w61GqT4TR7zncV2CNBsY4hA3HMzYnQvO3hDcAaTG6/V42Q2Z2ioqXNXCeIiY1w3DJphxv5nGnvAcelJUSLM+ih5MYcrx6w+YAeOD8ugHj6+lo7Iq80MeE1INl5hvP/lVjVYm7LYcXIWYluc82Kb/szJxtew7MU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783418565; c=relaxed/simple; bh=gC52koj86ejuy5R8k3v7zahddxqT+XeqrHmEOQEeZuc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bQTLX+47K2bLjmxlryZi07dJ3FszyxGQ2Noc2Vfju3HEu/meF8mNfQH05/NDCsWg9Oskx1K5vi8o/NqOnK1TMMwrk+gpxxTw504MNNirishj+KSUAAGJDznBD223u9PnAEDEWQTFCrmVVseUEESKHQn0S3/qTpY82Bnkbi/U8xk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=nqshw3Dx; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=XKrdZ/r7; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="nqshw3Dx"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="XKrdZ/r7" Date: Tue, 7 Jul 2026 12:02:41 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1783418562; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=eLnZYm2b0ntHPhEsRf4aDVEoqK/6RFpbXWmxke0pf4Q=; b=nqshw3Dxt/ytbMPS3MetsC8efKCQPuPD6E3Bs7TTVRtmJhdXgjs9TdnNimjL8qiorBsyLq G4JLBm/TNC1LjqkmXt9qBTh44Ls5QkFRmX4gpOQLq1FQos/qyTZpzWP8UQDHdhbWjnMHnx 5nP21hHsDIV7Qr9v1jlQ1EGU6w7vZ7WMRy2BTQFK++gtthyS60fk8DveGSm2s/kTO2la/E pe6SW19ggKm31D4NitoZB+/DZa//+p0ilRFXQo0E8fxS5xl6isgLTClNTHvzck4BX7lscX fg1NXfUXEPPa7mU07RH59mORIdL8nJbntnn0aZ/DP4bTVxO74jBzb+70hgGNjA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1783418562; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=eLnZYm2b0ntHPhEsRf4aDVEoqK/6RFpbXWmxke0pf4Q=; b=XKrdZ/r7/GVcv5GlSjvYOZ0nr89L00AZwXLXl4UCkx+aQC+b5OTBuK2RoJ1prdSWPMRbA5 tEQjnXJOCzUPBiAw== From: Sebastian Andrzej Siewior To: Sergey Senozhatsky Cc: Andrew Morton , Yosry Ahmed , Hillf Danton , Kairui Song , Minchan Kim , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v10 01/19] zram: sleepable entry locking Message-ID: <20260707100241.zaM2yrF5@linutronix.de> References: <20250303022425.285971-1-senozhatsky@chromium.org> <20250303022425.285971-2-senozhatsky@chromium.org> <20260707064030.D843llKh@linutronix.de> <20260707093024.DPG2lvt_@linutronix.de> 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=utf-8 Content-Disposition: inline In-Reply-To: On 2026-07-07 18:42:50 [+0900], Sergey Senozhatsky wrote: > On (26/07/07 11:30), Sebastian Andrzej Siewior wrote: > > > > > static void zram_slot_lock(struct zram *zram, u32 index) > > > > > { > > > > > - spin_lock(&zram->table[index].lock); > > > > > + unsigned long *lock = &zram->table[index].flags; > > > > > + > > > > > + mutex_acquire(slot_dep_map(zram, index), 0, 0, _RET_IP_); > > > > > + wait_on_bit_lock(lock, ZRAM_ENTRY_LOCK, TASK_UNINTERRUPTIBLE); > > > > > + lock_acquired(slot_dep_map(zram, index), _RET_IP_); > > > > > } > > > > > > > > Looking at this, is there a special need to have a lockdep map per > > > > table? Wouldn't it be enough to have one per zram? Logically you use the > > > > same __key so I don't think it makes much of a difference but you could > > > > lower the memory usage a bit by having less of those structs per zram. > > > > > > So the idea was to separate lockdep maps and keep them per-device > > > because various zram devices can be on different IO paths with very > > > different locking graphs. E.g. zram0 can be a swap device with all > > > the locks that swap layer has, while zram1 can be a "normal" block > > > device mounted with ext4 with all the locks that ext4/vfs bring. > > > > Ach so index will be 0 for zram0 and 1 for zram1? In that case it is > > different from what I assumed. But you use the same key so I think it > > will be the same lock from lockdep's point of view. Like it will > > complain if you do > > zram_slot_lock(zram, 0); > > zram_slot_lock(zram, 1); > > index is PAGE_SIZE granularity "block" of device that holds compressed > data. So they go from 0 to zram->disksize / PAGE_SIZE. Should I use > dedicated per device key as well? So it was what I assumed. With that one static key it should be one "lock-class" with several instances. So I don't think lockdep notices a difference between index == 0 and index == 1. If you have zram0 and zram1 and both have different lock chains which could result in a deadlock from theoretical point of view but not in reality because the zram0-swap never clash with zram1-ext4 then you should have a dynamic key. That means add it struct zram and register with lockdep_register_key() and assign with the lock as you did. Sebastian