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
next prev 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.