From: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
To: Sebastian Andrzej Siewior
<bigeasy-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Cc: Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Subject: Re: [PATCH 2/3] iommu/iova: don't disable preempt around this_cpu_ptr()
Date: Wed, 28 Jun 2017 11:22:05 +0200 [thread overview]
Message-ID: <20170628092205.GB30388@8bytes.org> (raw)
In-Reply-To: <20170627161648.30302-2-bigeasy-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
On Tue, Jun 27, 2017 at 06:16:47PM +0200, Sebastian Andrzej Siewior wrote:
> Commit 583248e6620a ("iommu/iova: Disable preemption around use of
> this_cpu_ptr()") disables preemption while accessing a per-CPU variable.
> This does keep lockdep quiet. However I don't see the point why it is
> bad if we get migrated after its access to another CPU.
> __iova_rcache_insert() and __iova_rcache_get() immediately locks the
> variable after obtaining it - before accessing its members.
> _If_ we get migrated away after retrieving the address of cpu_rcache
> before taking the lock then the *other* task on the same CPU will
> retrieve the same address of cpu_rcache and will spin on the lock.
>
> alloc_iova_fast() disables preemption while invoking
> free_cpu_cached_iovas() on each CPU. The function itself uses
> per_cpu_ptr() which does not trigger a warning (like this_cpu_ptr()
> does). It _could_ make sense to use get_online_cpus() instead but the we
> have a hotplug notifier for CPU down (and none for up) so we are good.
Does that really matter? The spin_lock disables irqs and thus avoids
preemption too. We also can't get rid of the irqsave lock here because
these locks are taken in the dma-api path which is used from interrupt
context.
Joerg
WARNING: multiple messages have this Message-ID (diff)
From: Joerg Roedel <joro@8bytes.org>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: tglx@linutronix.de, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 2/3] iommu/iova: don't disable preempt around this_cpu_ptr()
Date: Wed, 28 Jun 2017 11:22:05 +0200 [thread overview]
Message-ID: <20170628092205.GB30388@8bytes.org> (raw)
In-Reply-To: <20170627161648.30302-2-bigeasy@linutronix.de>
On Tue, Jun 27, 2017 at 06:16:47PM +0200, Sebastian Andrzej Siewior wrote:
> Commit 583248e6620a ("iommu/iova: Disable preemption around use of
> this_cpu_ptr()") disables preemption while accessing a per-CPU variable.
> This does keep lockdep quiet. However I don't see the point why it is
> bad if we get migrated after its access to another CPU.
> __iova_rcache_insert() and __iova_rcache_get() immediately locks the
> variable after obtaining it - before accessing its members.
> _If_ we get migrated away after retrieving the address of cpu_rcache
> before taking the lock then the *other* task on the same CPU will
> retrieve the same address of cpu_rcache and will spin on the lock.
>
> alloc_iova_fast() disables preemption while invoking
> free_cpu_cached_iovas() on each CPU. The function itself uses
> per_cpu_ptr() which does not trigger a warning (like this_cpu_ptr()
> does). It _could_ make sense to use get_online_cpus() instead but the we
> have a hotplug notifier for CPU down (and none for up) so we are good.
Does that really matter? The spin_lock disables irqs and thus avoids
preemption too. We also can't get rid of the irqsave lock here because
these locks are taken in the dma-api path which is used from interrupt
context.
Joerg
next prev parent reply other threads:[~2017-06-28 9:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-27 16:16 [PATCH 1/3] rbtree: include rcu.h because we use it Sebastian Andrzej Siewior
2017-06-27 16:16 ` [PATCH 2/3] iommu/iova: don't disable preempt around this_cpu_ptr() Sebastian Andrzej Siewior
[not found] ` <20170627161648.30302-2-bigeasy-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
2017-06-28 9:22 ` Joerg Roedel [this message]
2017-06-28 9:22 ` Joerg Roedel
[not found] ` <20170628092205.GB30388-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2017-06-28 9:31 ` Sebastian Andrzej Siewior
2017-06-28 9:31 ` Sebastian Andrzej Siewior
[not found] ` <20170628093154.ncrcvwretfcoizx3-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
2017-06-28 10:26 ` Joerg Roedel
2017-06-28 10:26 ` Joerg Roedel
[not found] ` <20170627161648.30302-1-bigeasy-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
2017-06-27 16:16 ` [PATCH 3/3] iommu/vt-d: don't disable preemption while accessing deferred_flush() Sebastian Andrzej Siewior
2017-06-27 16:16 ` Sebastian Andrzej Siewior
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=20170628092205.GB30388@8bytes.org \
--to=joro-zlv9swrftaidnm+yrofe0a@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=bigeasy-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
/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.