From: Dmitry Safonov via iommu <iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
To: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
Cc: Dmitry Safonov
<0x7f454c46-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [RFC 0/3] iommu/iova: Unsafe locking in find_iova()
Date: Mon, 09 Jul 2018 18:57:49 +0100 [thread overview]
Message-ID: <1531159069.3205.63.camel@arista.com> (raw)
In-Reply-To: <20180706151321.sq25kc7otgjo3xvn-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
On Fri, 2018-07-06 at 17:13 +0200, Joerg Roedel wrote:
> On Fri, Jul 06, 2018 at 03:10:47PM +0100, Dmitry Safonov wrote:
> > Yes, as far as I can see, there are code-paths which may try to
> > handle
> > it at the same time:
> > o memory notifiers for hot-unplug (intel-iommu.c)
> > o drivers unloading calls free_iova(), which in the result calls
> > find_iova()
> > o I see at least one driver that frees iova during it's normal work
> > too: scif_rma.c:scif_free_window_offset()
>
> Yeah, but the IOVAs freed in the memory notifiers are just the ones
> for
> the direct-mapped RMRR regions requested by firmware, not the IOVAs
> allocated by any driver, so I think this shouldn't be a problem.
Ok, than drop it, please.
I thought that safer API + nice diffstat can justify the change, but
whatever %)
--
Thanks,
Dmitry
WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Safonov <dima@arista.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: linux-kernel@vger.kernel.org,
David Woodhouse <dwmw2@infradead.org>,
iommu@lists.linux-foundation.org,
Dmitry Safonov <0x7f454c46@gmail.com>
Subject: Re: [RFC 0/3] iommu/iova: Unsafe locking in find_iova()
Date: Mon, 09 Jul 2018 18:57:49 +0100 [thread overview]
Message-ID: <1531159069.3205.63.camel@arista.com> (raw)
In-Reply-To: <20180706151321.sq25kc7otgjo3xvn@8bytes.org>
On Fri, 2018-07-06 at 17:13 +0200, Joerg Roedel wrote:
> On Fri, Jul 06, 2018 at 03:10:47PM +0100, Dmitry Safonov wrote:
> > Yes, as far as I can see, there are code-paths which may try to
> > handle
> > it at the same time:
> > o memory notifiers for hot-unplug (intel-iommu.c)
> > o drivers unloading calls free_iova(), which in the result calls
> > find_iova()
> > o I see at least one driver that frees iova during it's normal work
> > too: scif_rma.c:scif_free_window_offset()
>
> Yeah, but the IOVAs freed in the memory notifiers are just the ones
> for
> the direct-mapped RMRR regions requested by firmware, not the IOVAs
> allocated by any driver, so I think this shouldn't be a problem.
Ok, than drop it, please.
I thought that safer API + nice diffstat can justify the change, but
whatever %)
--
Thanks,
Dmitry
next prev parent reply other threads:[~2018-07-09 17:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-21 18:08 [RFC 0/3] iommu/iova: Unsafe locking in find_iova() Dmitry Safonov via iommu
2018-06-21 18:08 ` Dmitry Safonov
2018-06-21 18:08 ` [RFC 1/3] iommu/iova: Find and split iova under rbtree's lock Dmitry Safonov
2018-06-21 18:08 ` [RFC 2/3] iommu/iova: Make free_iova() atomic Dmitry Safonov
2018-06-21 18:08 ` [RFC 3/3] iommu/iova: Remove find_iova() Dmitry Safonov
2018-07-03 18:59 ` [RFC 0/3] iommu/iova: Unsafe locking in find_iova() Dmitry Safonov
2018-07-06 13:16 ` Joerg Roedel
2018-07-06 14:10 ` Dmitry Safonov
[not found] ` <1530886247.3205.53.camel-nzgTgzXrdUbQT0dZR+AlfA@public.gmane.org>
2018-07-06 15:13 ` Joerg Roedel
2018-07-06 15:13 ` Joerg Roedel
[not found] ` <20180706151321.sq25kc7otgjo3xvn-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2018-07-09 17:57 ` Dmitry Safonov via iommu [this message]
2018-07-09 17:57 ` Dmitry Safonov
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=1531159069.3205.63.camel@arista.com \
--to=iommu-cuntk1mwbs9qetfly7kem3xjstq8ys+chz5vsktnxna@public.gmane.org \
--cc=0x7f454c46-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=dima-nzgTgzXrdUbQT0dZR+AlfA@public.gmane.org \
--cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
--cc=joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@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.