All of lore.kernel.org
 help / color / mirror / Atom feed
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: Fri, 06 Jul 2018 15:10:47 +0100	[thread overview]
Message-ID: <1530886247.3205.53.camel@arista.com> (raw)
In-Reply-To: <20180706131611.h3w2kdinmjguikgo@8bytes.org>

On Fri, 2018-07-06 at 15:16 +0200, Joerg Roedel wrote:
> On Thu, Jun 21, 2018 at 07:08:20PM +0100, Dmitry Safonov wrote:
> > find_iova() looks to be using a bad locking practice: it locks the
> > returned iova only for the search time.  And looking in code, the
> > element can be removed from the tree and freed under rbtree lock.
> > That
> > happens during memory hot-unplug and cleanup on module
> > removal.  Here
> > I cleanup users of the function and delete it.
> 
> But this is only a problem if more than one code-path uses tries to
> handle a given iova at the same time, no?

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()

So, I decided to fix the interface while it's not widely used instead
of all callers.
Looks worth for me even as it's all corner-cases like unplugging the
memory.

Anyway, just found it while some college wrote a debug sysfs interface
for iovas and used find_iova().
So, if you think it's not worth to change - that's fine for me, but I
thought I'll nip this in the bud, preventing other people to misuse it.

-- 
Thanks,
             Dmitry

  reply	other threads:[~2018-07-06 14:10 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 [this message]
     [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
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=1530886247.3205.53.camel@arista.com \
    --to=dima@arista.com \
    --cc=0x7f454c46@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.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.