From: Dan Carpenter <dan.carpenter@linaro.org>
To: Minu Jin <s9430939@naver.com>
Cc: parthiban.veerasooran@microchip.com,
christian.gromm@microchip.com, gregkh@linuxfoundation.org,
linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: most: dim2: fix a race condition in complete_all_mbos()
Date: Fri, 6 Feb 2026 10:20:51 +0300 [thread overview]
Message-ID: <aYWWUwHJyAXOp9Ak@stanley.mountain> (raw)
In-Reply-To: <20260205160231.1543828-1-s9430939@naver.com>
On Fri, Feb 06, 2026 at 01:02:31AM +0900, Minu Jin wrote:
> The current implementation of complete_all_mbos() repeatedly acquires
> and releases the spinlock in loop. This causes lock contention.
>
> This patch refactors the function to use list_replace_init(), moving all
> entries to a local list. This removes the loop-based locking approach
> and significantly reduces lock contention.
>
> Signed-off-by: Minu Jin <s9430939@naver.com>
The subject talks about race conditions but the commit message talks
about reducing lock contention. It does obviously reduce lock
contention (althought I don't think anyone has benchmarked it to see
if it matters) but does it prevent a race condition? Let's review:
This complete_all_mbos() function is called when we do a
most_stop_channel() and we ->poison_channel().
The list heads are &hdm_ch->started_list and &hdm_ch->pending_list. I
feel like if we add something to the list while we are also freeing
items from the list then we are toasted. In service_done_flag(), we
delete items from the list but deleting items is fine in this context.
We add things to the ->pending_list in enqueue() and
service_done_flag(). We move things from the ->pending_list to the
->started_list in try_start_dim_transfer(). So if any of those three
functions can be run at the same time as complete_all_mbos() we are in
trouble.
The hdm_enqueue_thread() function calls enqueue() until
kthread_should_stop(). The most_stop_channel() function calls
kthread_stop(c->hdm_enqueue_task) before doing the ->poison_channel()
so that's fine.
The service_done_flag() and try_start_dim_transfer() functions are
called from dim2_task_irq(). When do we stop taking interrupts? To be
honest, I don't know. I thought we had to call disable_irq()?
So that's the question, when do we disable IRQs in this driver? I
would have assumed it was in most_stop_channel() but I can't see it,
but I'm also not very familiar with this code.
Let's answer this question and then either add a Fixes tag or say that
there doesn't appear to be a race condition.
regards,
dan carpenter
next prev parent reply other threads:[~2026-02-06 7:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-05 16:02 [PATCH] staging: most: dim2: fix a race condition in complete_all_mbos() Minu Jin
2026-02-06 7:20 ` Dan Carpenter [this message]
2026-02-06 18:04 ` Minu Jin
2026-02-07 11:55 ` Greg KH
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=aYWWUwHJyAXOp9Ak@stanley.mountain \
--to=dan.carpenter@linaro.org \
--cc=christian.gromm@microchip.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=parthiban.veerasooran@microchip.com \
--cc=s9430939@naver.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox