From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A1A0C021BE for ; Thu, 27 Feb 2025 13:04:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AA8486B008A; Thu, 27 Feb 2025 08:04:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A58556B008C; Thu, 27 Feb 2025 08:04:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 91F416B0092; Thu, 27 Feb 2025 08:04:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 777156B008A for ; Thu, 27 Feb 2025 08:04:27 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id D25C21A057B for ; Thu, 27 Feb 2025 13:04:26 +0000 (UTC) X-FDA: 83165743332.28.1BB35B9 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by imf18.hostedemail.com (Postfix) with ESMTP id E90001C000C for ; Thu, 27 Feb 2025 13:04:24 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=ZBtauBZn; spf=pass (imf18.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.174 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740661465; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ZY3lPWTmNqZZsigW6fCcCa9W0h1dzQbk+JMMnksNz2M=; b=WCNZpBSPutrkKFv7lAUHOQhmRaD4G52KsdJvW3MhcKeuJHVxuIY8/w5+GAg7jlA00gfMwo 3csPBPyrGk/7hufmztNScaUhJJDzcHmhu4uApnLtJwHvWYe9EID0iGOyhXzEm8hyxNHbzP YiKVMDdEVXGU5qfngDFgVRUZWGOoNVQ= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=ZBtauBZn; spf=pass (imf18.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.174 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740661465; a=rsa-sha256; cv=none; b=VuuvRQDCYWIp5iqLKEi8BDMhhOIvwjUpTo0y2JW/NpKRWK22/kF6QxZ+KLZUKihaozzWtB CktoFACKGZgAsNE/XHpJEFxKA9O9+eEddSdz8jNPp1z1Onv4/EuuIObVkzOyTPgMTSqTEO pXad019Wi4++Azng903Nh9bYEuECE3o= Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-22349dc31bcso14334015ad.3 for ; Thu, 27 Feb 2025 05:04:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1740661464; x=1741266264; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ZY3lPWTmNqZZsigW6fCcCa9W0h1dzQbk+JMMnksNz2M=; b=ZBtauBZnRKbnH0eBzBOYcjNhL0UEBscPW1WTb+FWAwJ100moVJlhMh47lB9DJH7Jue Qnt4dDj5BcIt3LrXntQswAd+h0SIHCW5w+0u6rZKz/OQpvUzvZJdxWPHxh/SCH4gwLRc uWerjP9uNVxdzN2akZTZ1debNegh+3e50RuaE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740661464; x=1741266264; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ZY3lPWTmNqZZsigW6fCcCa9W0h1dzQbk+JMMnksNz2M=; b=vO7EmIIbGRV9StPEPG8VHy2NdJ0Wa4V9lo2TQRUjRB//vpqj9pEU6/6GtScl8TZv3W jx0i8DzKrIJXoPNYGSFKwN0Ue1OX6Oiuzl085XmgvF7JO5r9i5z0nRfOOgt7ykjR/AhE XfpvI2FTiiNfBuXRGpJ7inYiJd/+dBI3PoORQKz+LkXd0lUrXgH7n+IaIREM6BeMBgaF xnAsLjcKa3qyJAtU6cGNJOQNRbSGru4lQhSAoV92wvIVUfO7JGnU2BT9HVpiVTuqeu42 t9OzCE4Vk+LtbF1Xll3d0jOdPtIG9WSTAufu+oD/Bnt5YVwZapGj+FNZVc53lnHDGFD6 Qbnw== X-Forwarded-Encrypted: i=1; AJvYcCWpQPM+ie4lFUu3hwLnIhanOSqFLCB+bmNw4N37RPODOn5lO9QT2ht9AaS0g0b7noklgH8zHY7+Lw==@kvack.org X-Gm-Message-State: AOJu0YxaZSqSqv1jfaUNrtMNXR7Ib01PcK0KOMEdxYHPxl5oXlQ7uOE9 GeAs6LD6cpk1iYJlXX+ZxaxzKUwIpNnjUiuj8hT3hJTS0e8ml6ghGTEt3m7EUA== X-Gm-Gg: ASbGncs+92iir6/5sllsY4bMymmwvSqH8Y9ztza3TG4XyWFr2nx/3i0b0kyJJIuYk4P jpG60A74qBU1DOO33k2omGAeJP5/u7RxnAUbBqyR7DvfepmJVgClbEQtnagFO5v5YWxvMzw8g2I Qgq0TDDOhMAmQMXb0/HbuM4NZVodaZcc9CkJuLM4EjRAScZBrzGoIXOEnyQNKp8zg2qvoIiii53 7waJwE2HSVyqeh9GriyMu+qPiTcexpR3hEEJNLSBngHp38G5mhAZcjNx5W5W6No5BckuKiK2hML 1s1NCTdccEXdIJO9Nyz9pfTXxGJ1Tg== X-Google-Smtp-Source: AGHT+IFNvd0ElV4B1D48R80ma4vVr+h2GufsMAxOmLWTJtIzhmY2T9t1CiXv7N665sHiIvewZmOTJw== X-Received: by 2002:a05:6a20:7286:b0:1ee:afa2:4e86 with SMTP id adf61e73a8af0-1eef5559342mr49520291637.28.1740661463832; Thu, 27 Feb 2025 05:04:23 -0800 (PST) Received: from google.com ([2401:fa00:8f:203:a9c0:1bc1:74e3:3e31]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7349fe48865sm1520971b3a.50.2025.02.27.05.04.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Feb 2025 05:04:23 -0800 (PST) Date: Thu, 27 Feb 2025 22:04:16 +0900 From: Sergey Senozhatsky To: Sebastian Andrzej Siewior Cc: Andrew Morton , Yosry Ahmed , Hillf Danton , Kairui Song , Minchan Kim , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Sergey Senozhatsky Subject: Re: [PATCH v8 01/17] zram: sleepable entry locking Message-ID: References: <20250221222958.2225035-1-senozhatsky@chromium.org> <20250221222958.2225035-2-senozhatsky@chromium.org> <20250224081956.knanS8L_@linutronix.de> <20250227120532.OsZr4v2A@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: E90001C000C X-Stat-Signature: qa9cyfbz569b9r4tdpxrbjwt3qjnae6j X-HE-Tag: 1740661464-649075 X-HE-Meta: U2FsdGVkX1+ksKsDXxxtuhGaIs35+pcGZUvY15fD7sW9B7ix9UD1Wno+99VBSyGd0Ai0JQQpVwg/7LX02y+fO+gGEtO65jcHA/yyXXzv6osWDjOzMYxbrv3IP7/dBZC67jIfrdvWGex8LuZ6EwK4q8TgfkCbJDvkPFfUpyANNrA36/5M3lVSSCCxXBATmX2iCslia/wT+QagvlkxlCbb7EvxfGZ6GzHHARkStqX802GGIEqisqhbq3TK3c4cCMk/AJzumhQf3VLUE/Xl556Jn7EvWD7faloIujsVjgE6A4vc9020L/0DTdiBKuGXNq6XRrHf9lyhFmPsU8+kgbdWtHrrRFR2jcVzWyzhJcAiXvE7Whn0xriaPeeC60TAsN+ra9YMRaSfn49xqZuvmudQU+5SAW/ZI2S2pfDSP2/VNYQrn8JmQZBJ4GUKHCcEuLUtKpGpbQ54Xi+onbKPEXrcTkEH60l0ScmC8SiPYR9SJhmE7JfzxwdFsEZY6GDt8UwvI+bME1MyYIaMw6aZGvb3vaRERNdSzE6tFw8/EgQ9I3yaNEzyyhkdHps0tu/tQ2+v+0e06YdOuxQ3GLD7H6zDjdEKtxf1m/fZ6uyDAOGK/P/JLMASIv1PXOGV9A+wb7/692I8JJe/ecDL+FQr/S4yIne77WMVCeFh6lx6A5fQoq1t0RP5ZCiqo0VFUUn5J5nCo6ktm+Awxe4Bz6zRlHzTugC0e2aAiTaNiozmhJ8B1plKP59bzbnHhh+SwOWfAGmMi9bDT333zqH9MguDxAVj7PSLIt89k7byNFSs1q86vW9uagXLupSv8L4umuLO7oECngku1nNM4kzQaVngXHyjIiG/ZcFHNEo4T8iebHKiaLNfVxTT4jJGabXjnbSGmh59M+jrp8ksCMyPhKpnfE96ZIcB4+VcOMEWo0UpwIEXBUJCCiZb0FVnyY9TlybJgAMjsnfLmL4DWvUi51zYkja yIjAyeJp 5FFa8U2rK9ZdcIXxufrgG64f2tW9OQBFQNtxEOJzhAX4Muqz/W1SEMVW0c9gbezzNDY4OSsiMuBkfcfmZqAHNJuFWiQVpkLLDTVed2Qqv1v6CQE3I+uHJMW29mxNkI1iA50nNdyJcVmSZbdU3dJuhQE8l8k9Kn3Kb0ok5korIPn0LG9xMLQUgJ4vfOYEcxk66xcjibLDqU7hvPNJHiqEeroO5PxOTSSjbwT2INK48wlnSCIlnlQ1F9O/XFWPr0NO1TtEiRjGLirVc0Z4SGf/3PoP5vjeCo+bHgAZeT8sBJ4vI+lYyN2/IV6dW8sCsFKsMeNALD+QrJ42gskOsiSc02R9+epGl1nCDegmEe/g3CyamQJo= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000120, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On (25/02/27 21:42), Sergey Senozhatsky wrote: > > ach. Got it. What about > > > > | static void zram_slot_lock_init(struct zram *zram, u32 index) > > | { > > | static struct lock_class_key __key; > > | > > | lockdep_init_map(slot_dep_map(zram, index), > > | "zram->table[index].lock", > > | &__key, 0); > > | } > > > > So every lock coming from zram belongs to the same class. Otherwise each > > lock coming from zram_slot_lock_init() would belong to a different class > > and for lockdep it would look like they are different locks. But they > > are used always in the same way. > > I see. I thought that they key was "shared" between zram meta table > entries because the key is per-zram device, which sort of made sense > (we can have different zram devices in a system - one swap, a bunch > mounted with various file-systems on them). So the lock class is registered dynamically for each zram device zram_add() lockdep_register_key(&zram->lock_class); and then we use that zram->lock_class to init zram->table entries. We unregister the lock_class during each zram device destruction zram_remove() lockdep_unregister_key(&zram->lock_class); Does this still put zram->table entries into different lock classes?