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 BDA56E7719A for ; Sat, 11 Jan 2025 12:13:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EB9886B007B; Sat, 11 Jan 2025 07:13:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E6A1A6B0082; Sat, 11 Jan 2025 07:13:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D59276B0083; Sat, 11 Jan 2025 07:13:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id B85576B007B for ; Sat, 11 Jan 2025 07:13:42 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 196B4AE926 for ; Sat, 11 Jan 2025 12:13:42 +0000 (UTC) X-FDA: 82995061884.25.FF48031 Received: from mail115-171.sinamail.sina.com.cn (mail115-171.sinamail.sina.com.cn [218.30.115.171]) by imf28.hostedemail.com (Postfix) with ESMTP id 74FD0C000F for ; Sat, 11 Jan 2025 12:13:38 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; spf=pass (imf28.hostedemail.com: domain of hdanton@sina.com designates 218.30.115.171 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736597620; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5CKEODz86fiUvVuBhUtT03OuTI4JEyQ+dvZ4JglTymw=; b=YLxklFR2UZSdy/qpuMh1ARnOg1qrNSbeWB6+vTpcooieIx5/MRIro3Dfig1o6mMcjGWS93 mxXlxDyvw8TCY0PafMDYUZ1oH8LKAuK3P47ebF9R1d7qOOJ3he1SMC+EQPgu93qUj6VQFw O0xchmvDtt6mieCHGItQpdndFCil6o8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736597620; a=rsa-sha256; cv=none; b=DWCjjnvWSMUwcJC0f+5LpjnErGDr8YDRTBECRTO7Lh3q8l/Lo3fg0uVF8uebzWCC7ieoZI H9gx1jbA6K+WLdOa9oaKofazsUrXSIG+pvu28CoWaOTC85/3fohY4Aszp3T8XRNruy/BTF GIf3y+4Cn197z7BxqzMF9uO3xooGV8A= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; spf=pass (imf28.hostedemail.com: domain of hdanton@sina.com designates 218.30.115.171 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([113.118.71.135]) by sina.com (10.185.250.24) with ESMTP id 6782606A00004DAB; Sat, 11 Jan 2025 20:13:32 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 54552710748401 X-SMAIL-UIID: 3491548A1AD94689BFB8E65143949F1B-20250111-201332-1 From: Hillf Danton To: Suren Baghdasaryan Cc: akpm@linux-foundation.org, peterz@infradead.org, willy@infradead.org, hannes@cmpxchg.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH v9 10/17] refcount: introduce __refcount_{add|inc}_not_zero_limited Date: Sat, 11 Jan 2025 20:13:18 +0800 Message-ID: <20250111121320.1656-1-hdanton@sina.com> In-Reply-To: References: <20250111042604.3230628-1-surenb@google.com> <20250111042604.3230628-11-surenb@google.com> <20250111063152.1638-1-hdanton@sina.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 74FD0C000F X-Stat-Signature: qufkjosgpt9fp5mcsmjec4g16xps56hq X-Rspam-User: X-HE-Tag: 1736597618-262537 X-HE-Meta: U2FsdGVkX19doO2I1KIP2j2tiawexuPhNj1c3eJtZXKBjzMLNERyu0uaYclatHpBT/HCX+5L/k+ZkpD6lpG94id8Fkard94UMgaEskeBVS9dECRXbuRaQqbCb1Gea8z3JHx7EvzR+r4HA765mmW5WE2NIwhctqwIcu7OPbHL/9zKRIJmNWIu4OsfbfcDRmKj1/KOZJne1kYvh9ss44oJ3euqQHrNP53nM5EOYcxrGDwkxWB98Yznf9LdftirF+bxUX2YmQvNHt2CL/SupI+8hNWVgvUBlshVKZyuSbWGphBJCZdi9zZXwHUk6Y4xkt6n46ytQdbkmTaZebQXz6MkwU2BtX1B87tKSgf8EhBBGUggyhF4mxWuSy8cNJXU0uJktWCpj/Gy4OOclDXWVysgrd8Fvsk9nRRtKhx7PDmIHTUwGFPcvFBU5Zb3z/5ZtmRns5MOZMQUzzKQt+taY8uyCt8gzXlbjICYC0TL/hhW2ByoKA9oCGoNC9HWNH/kigly6OaywNfK4MnnfJefTF2OXlDnNiUgcYzOi1kYs8ETkPD3itStRi9X8FOdbRzpQVs9dFSknCDyg1arwEhWdkxYsiMD8sqxiIcxxxO215Bi2ouFsD46eftj3/xmYoJE8KKivY/jlzjrmlBCm1PUdWxUEi9bR+emRcg3bejgSFyJjl0kmIj0X/kxhxhaFPYEyHlvkp6mbXWcZg3NG/mr7Wb4BLgqBhRJUg8AhIeJqn0thNOglZC18hxIU56CI2YRw8NZrJ0K7nGOF22ZcZ/97LZ93OKckB1I98U+PQPHq1jRbWwWKjcVJYnkgDM562/MZwjcxF99WWPjZjLRBSBrukyH9q5OBdjeJZ5SI6Sp8H/PVcCuHhGWV3a8wdymHLt6Tb3kMeI8DQuYehqxpjCUYyCBGoexP0e1AqePFYtfmUwqURtKHzDJsAAPZMbwyec+xhuoKsVWCi/CagWfxCEKhvh NaoQEALx tvcaHUhnhNpQ6htbAnbY/1UmBBnV3K7xDRRH0K/Zcw0hkLF3O4A+o+zE4VXW5ktNkdFHSIfX9QNnqt8xDNfb/HPUiUDJjqc0BfhYl7UlXgH/fjxIK/o50FS0CRMpgdivMbNEmWec0O2qCY0eObHX6pRx+PwEkguxmhWevF4/LXJP0vaKQ00jKKL2Ouzzu/aE4FFfdI3KbdhQBSAfOocjFjpdiqCLzPmZpjBR0G1YmsbvTOMqvd0Y6aSnxrw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.025859, 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 Sat, 11 Jan 2025 01:59:41 -0800 Suren Baghdasaryan > On Fri, Jan 10, 2025 at 10:32 PM Hillf Danton wrote: > > On Fri, 10 Jan 2025 20:25:57 -0800 Suren Baghdasaryan > > > -bool __refcount_add_not_zero(int i, refcount_t *r, int *oldp) > > > +bool __refcount_add_not_zero_limited(int i, refcount_t *r, int *oldp, > > > + int limit) > > > { > > > int old = refcount_read(r); > > > > > > do { > > > if (!old) > > > break; > > > + > > > + if (statically_true(limit == INT_MAX)) > > > + continue; > > > + > > > + if (i > limit - old) { > > > + if (oldp) > > > + *oldp = old; > > > + return false; > > > + } > > > } while (!atomic_try_cmpxchg_relaxed(&r->refs, &old, old + i)); > > > > The acquire version should be used, see atomic_long_try_cmpxchg_acquire() > > in kernel/locking/rwsem.c. > > This is how __refcount_add_not_zero() is already implemented and I'm > only adding support for a limit. If you think it's implemented wrong > then IMHO it should be fixed separately. > Two different things - refcount has nothing to do with locking at the first place, while what you are adding to the mm directory is something that replaces rwsem, so from the locking POV you have to mark the boundaries of the locking section.