All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stepan Moskovchenko <stepanm-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
To: Joerg Roedel <joerg.roedel-5C7GfCeVMHo@public.gmane.org>
Cc: Ohad Ben-Cohen <ohad-Ix1uc/W3ht7QT0dZR+AlfA@public.gmane.org>,
	David Brown <davidb-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: OMAP and MSM IOMMU driver misbehavior
Date: Tue, 24 Jan 2012 11:14:27 -0800	[thread overview]
Message-ID: <4F1F0313.7040008@codeaurora.org> (raw)
In-Reply-To: <20120123140355.GA19255-5C7GfCeVMHo@public.gmane.org>

On 1/23/2012 6:03 AM, Joerg Roedel wrote:
> Hi,
>
> while reviewing another IOMMU driver again I came across a problem in
> the IOMMU drivers for OMAP and MSM platforms. In both drivers the
> 'domain_destroy with devices attached' case isn't handled correctly.
>
> OMAP driver seems not to track the devices attached to a domain at all.
> So when a domain is destroyed it can happen that the hardware still
> references old (and already freed) page-table pointers.
>
> MSM tracks devices in a domain, but does not automatically remove the
> devices from a domain that is about to be destroyed.
>
> Please tell me when I mis-read the code, otherwise please fix this in
> your drivers so that we can get consistent behavior for IOMMU-API
> users :-)
>
> Thanks,
>
> 	Joerg

Hello

I believe your analysis is correct, and it is a legitimate problem. The 
driver does keep a list of devices attached to a domain, so it should 
not be too hard to detach them. However, I have been quite occupied with 
other things lately, but I can try to get to it when I have some free 
time. Calling detach_dev on each element is what needs to happen in 
theory, but I feel like the main detach_dev code will need to be broken 
out to handle the locking properly. Still, it does not sound 
particularly difficult.

Steve

WARNING: multiple messages have this Message-ID (diff)
From: Stepan Moskovchenko <stepanm@codeaurora.org>
To: Joerg Roedel <joerg.roedel@amd.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>,
	David Brown <davidb@codeaurora.org>,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: OMAP and MSM IOMMU driver misbehavior
Date: Tue, 24 Jan 2012 11:14:27 -0800	[thread overview]
Message-ID: <4F1F0313.7040008@codeaurora.org> (raw)
In-Reply-To: <20120123140355.GA19255@amd.com>

On 1/23/2012 6:03 AM, Joerg Roedel wrote:
> Hi,
>
> while reviewing another IOMMU driver again I came across a problem in
> the IOMMU drivers for OMAP and MSM platforms. In both drivers the
> 'domain_destroy with devices attached' case isn't handled correctly.
>
> OMAP driver seems not to track the devices attached to a domain at all.
> So when a domain is destroyed it can happen that the hardware still
> references old (and already freed) page-table pointers.
>
> MSM tracks devices in a domain, but does not automatically remove the
> devices from a domain that is about to be destroyed.
>
> Please tell me when I mis-read the code, otherwise please fix this in
> your drivers so that we can get consistent behavior for IOMMU-API
> users :-)
>
> Thanks,
>
> 	Joerg

Hello

I believe your analysis is correct, and it is a legitimate problem. The 
driver does keep a list of devices attached to a domain, so it should 
not be too hard to detach them. However, I have been quite occupied with 
other things lately, but I can try to get to it when I have some free 
time. Calling detach_dev on each element is what needs to happen in 
theory, but I feel like the main detach_dev code will need to be broken 
out to handle the locking properly. Still, it does not sound 
particularly difficult.

Steve


  parent reply	other threads:[~2012-01-24 19:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-23 14:03 OMAP and MSM IOMMU driver misbehavior Joerg Roedel
2012-01-23 14:03 ` Joerg Roedel
     [not found] ` <20120123140355.GA19255-5C7GfCeVMHo@public.gmane.org>
2012-01-23 18:24   ` Ohad Ben-Cohen
2012-01-23 18:24     ` Ohad Ben-Cohen
2012-01-24 19:14   ` Stepan Moskovchenko [this message]
2012-01-24 19:14     ` Stepan Moskovchenko

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=4F1F0313.7040008@codeaurora.org \
    --to=stepanm-sgv2jx0feol9jmxxk+q4oq@public.gmane.org \
    --cc=davidb-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=joerg.roedel-5C7GfCeVMHo@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=ohad-Ix1uc/W3ht7QT0dZR+AlfA@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.