Received-SPF: pass (google.com: domain of linux-kernel+bounces-48349-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <20231113204809.4052009-1-aahringo@redhat.com>
In-Reply-To: <20231113204809.4052009-1-aahringo@redhat.com>
From: Alexander Aring <aahringo@redhat.com>
Date: Thu, 1 Feb 2024 09:59:41 -0500
Message-ID: <CAK-6q+hh_A0Ldwsmmy0BdagDotNBV=Xgk35ZZQ3DAzB9OXwLgw@mail.gmail.com>
Subject: Re: [PATCHv2 1/2] refcount: introduce __refcount_dec_and_lock macro
To: peterz@infradead.org
Cc: will@kernel.org, gfs2@lists.linux.dev, boqun.feng@gmail.com, 
	mark.rutland@arm.com, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Mon, Nov 13, 2023 at 3:48=E2=80=AFPM Alexander Aring <aahringo@redhat.co=
m> wrote:
>
> This patch adds the __refcount_dec_and_lock macro to generate code for a
> lock specific refcount_dec_and_lock implementation. Existing
> refcount_dec_and_lock implementation are updated to use the new
> __refcount_dec_and_lock macro. In future other lock implementation can
> added to use the refcount_dec_and_lock trick to only hold the lock when
> the refcount is going to be zero. Per subsystem own lock implementation
> can use the macro as well to provide such implementation for their own
> locking type.
>

ping? :)

Any chance to bring this upstream?

- Alex