From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
Christoph Hellwig <hch@lst.de>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Petr Mladek <pmladek@suse.com>,
Rob Clark <robdclark@chromium.org>,
John Ogness <john.ogness@linutronix.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dma-debug: defer __dma_entry_alloc_check_leak() printk output
Date: Wed, 16 Aug 2023 01:52:25 +0900 [thread overview]
Message-ID: <20230815165225.GF907732@google.com> (raw)
In-Reply-To: <b6d28992-5adc-5df0-91e5-7fd0571b1465@arm.com>
On (23/08/15 17:42), Robin Murphy wrote:
> On 15/08/2023 4:26 pm, Sergey Senozhatsky wrote:
> > __dma_entry_alloc_check_leak() calls printk -> serial console
> > output (qcom geni) and grabs port->lock under free_entries_lock,
> > which is a conflicting locking dependency chain as qcom_geni IRQ
> > handler can call into dma-debug code and grab free_entries_lock
> > under port->lock.
> >
> > Use deferred printk in __dma_entry_alloc_check_leak() so that we
> > don't acquire serial console's port->lock under free_entries_lock.
>
> Hmm, the print really doesn't need to be under the lock anyway, it only
> needs to key off whether the "num_free_entries == 0" condition was hit or
> not.
I thought about it, briefly. __dma_entry_alloc_check_leak() reads
global nr_total_entries / nr_prealloc_entries which are updated
(inc/dec) under free_entries_lock, so I didn't want to move
__dma_entry_alloc_check_leak() outside of free_entries_lock scope.
next prev parent reply other threads:[~2023-08-15 16:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-15 15:26 [PATCH] dma-debug: defer __dma_entry_alloc_check_leak() printk output Sergey Senozhatsky
2023-08-15 15:37 ` Rob Clark
2023-08-15 16:42 ` Robin Murphy
2023-08-15 16:52 ` Sergey Senozhatsky [this message]
2023-08-15 16:58 ` Sergey Senozhatsky
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=20230815165225.GF907732@google.com \
--to=senozhatsky@chromium.org \
--cc=hch@lst.de \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=pmladek@suse.com \
--cc=robdclark@chromium.org \
--cc=robin.murphy@arm.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 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.