From: Boris Brezillon <boris.brezillon@collabora.com>
To: Steven Price <steven.price@arm.com>
Cc: "Liviu Dudau" <liviu.dudau@arm.com>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Christian König" <christian.koenig@amd.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/6] drm/panthor: Driver-wide xxx_[un]lock -> [scoped_]guard replacement
Date: Mon, 18 May 2026 10:57:21 +0200 [thread overview]
Message-ID: <20260518105721.42ffa64c@fedora> (raw)
In-Reply-To: <5ab2d07c-74a4-4a2c-b145-6ed7b0060944@arm.com>
On Thu, 14 May 2026 14:16:37 +0100
Steven Price <steven.price@arm.com> wrote:
> On 13/05/2026 17:58, Boris Brezillon wrote:
> > Right now panthor is mixed bag of manual locks and guards. Let's
> > make that more consitent and thus encourage new submissions to go
> > for guards.
>
> I'm fine with encouraging guards for future code - but I'm a little wary
> of a big change like this - it's hard to review it and check that
> everything works the same.
I can try to split that up, but even after the split, it will still be
a pain to review.
> And it's a little dubious that the mechanical
> refactoring produces more readable code in some cases.
I agree, though the mix of guard()s and manual locks makes things even
harder to reason about, especially when they appear in the same
function/block. The very reason I ended up sending this series is
because, as part of the IRQ refactor, I decided to be a good citizen
and use guards when I could, and I realized how bad the partial
transition was in term of ergonomics: not only you have to think about
whether the function/block scope is what you want (that's basically
what guard provides, unless you used explicit scoped_guard()), but you
also have to think about the interactions with your other manual locks.
TLDR; I'd rather switch over to guards entirely, or go back to manual
locks, but the mix we have right now is far from ideal.
>
> That said I asked my friendly AI bot...
>
> [...]
>
> > @@ -3142,48 +3126,44 @@ panthor_mmu_reclaim_priv_bos(struct panthor_device *ptdev,
> > LIST_HEAD(remaining_vms);
> > LIST_HEAD(vms);
> >
> > - mutex_lock(&ptdev->reclaim.lock);
> > - list_splice_init(&ptdev->reclaim.vms, &vms);
> > + scoped_guard(mutex, &ptdev->reclaim.lock)
> > + list_splice_init(&ptdev->reclaim.vms, &vms);
> >
> > while (freed < nr_to_scan) {
> > struct panthor_vm *vm;
> >
> > - vm = list_first_entry_or_null(&vms, typeof(*vm),
> > - reclaim.lru_node);
> > - if (!vm)
> > - break;
> > -
> > - if (!kref_get_unless_zero(&vm->base.kref)) {
> > - list_del_init(&vm->reclaim.lru_node);
> > - continue;
> > + scoped_guard(mutex, &ptdev->reclaim.lock) {
> > + vm = list_first_entry_or_null(&vms, typeof(*vm),
> > + reclaim.lru_node);
> > + if (vm && !kref_get_unless_zero(&vm->base.kref)) {
> > + list_del_init(&vm->reclaim.lru_node);
> > + vm = NULL;
> > + }
> > }
> >
> > - mutex_unlock(&ptdev->reclaim.lock);
> > + if (!vm)
> > + break;
>
> ... and it said the above has changed behaviour.
>
> In the !kref_get_unless_zero() case you now assign vm = NULL which then
> leads to the 'break' case above. Previously we 'continue'd.
Oops, that one wasn't intended, indeed.
next prev parent reply other threads:[~2026-05-18 8:57 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-13 16:58 [PATCH 0/6] drm/panthor: Use guards Boris Brezillon
2026-05-13 16:58 ` [PATCH 1/6] drm/panthor: Driver-wide xxx_[un]lock -> [scoped_]guard replacement Boris Brezillon
2026-05-14 13:16 ` Steven Price
2026-05-14 17:09 ` Chia-I Wu
2026-05-18 8:43 ` Boris Brezillon
2026-05-20 15:26 ` Steven Price
2026-05-20 15:43 ` Boris Brezillon
2026-05-18 8:57 ` Boris Brezillon [this message]
2026-05-18 23:50 ` [Linaro-mm-sig] " Chia-I Wu
2026-05-13 16:58 ` [PATCH 2/6] dma-resv: Define guards for context-less dma_resv locks Boris Brezillon
2026-05-14 18:23 ` Chia-I Wu
2026-05-18 7:10 ` Christian König
2026-05-18 9:14 ` Boris Brezillon
2026-05-18 12:18 ` Christian König
2026-05-18 14:15 ` Boris Brezillon
2026-05-21 8:36 ` Christian König
2026-05-21 8:54 ` Boris Brezillon
2026-05-21 9:01 ` Boris Brezillon
2026-05-21 12:19 ` Christian König
2026-05-21 12:14 ` Christian König
2026-05-20 15:26 ` Steven Price
2026-05-13 16:58 ` [PATCH 3/6] drm: Define a conditional guard for drm_dev_{enter,exit}() Boris Brezillon
2026-05-14 18:34 ` Chia-I Wu
2026-05-14 18:34 ` [PATCH 3/6] drm: Define a conditional guard for drm_dev_{enter, exit}() Chia-I Wu
2026-05-18 8:28 ` [PATCH 3/6] drm: Define a conditional guard for drm_dev_{enter,exit}() Boris Brezillon
2026-05-18 9:16 ` Christian König
2026-05-18 9:35 ` Boris Brezillon
2026-05-13 16:58 ` [PATCH 4/6] drm/panthor: Use guards for resv locking Boris Brezillon
2026-05-14 18:35 ` Chia-I Wu
2026-05-13 16:58 ` [PATCH 5/6] drm/panthor: Use the drm_dev_access guard Boris Brezillon
2026-05-14 18:36 ` Chia-I Wu
2026-05-13 16:58 ` [PATCH 6/6] drm/panthor: Add a new guard for our custom resume_and_get() PM helper Boris Brezillon
2026-05-14 18:39 ` Chia-I Wu
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=20260518105721.42ffa64c@fedora \
--to=boris.brezillon@collabora.com \
--cc=airlied@gmail.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=liviu.dudau@arm.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=simona@ffwll.ch \
--cc=steven.price@arm.com \
--cc=sumit.semwal@linaro.org \
--cc=tzimmermann@suse.de \
/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.