All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.