linux-kernel - Re: [PATCH 3/4] iommu/exynos: Add iommu driver for Exynos4 Platforms

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHQjnOPdsf-QB3st94WRSH325j8WPOLLe4rqv0WN1qK1KYWtmA@mail.gmail.com>
Date:	Tue, 27 Sep 2011 09:56:14 +0900
From:	KyongHo Cho <pullip.cho@...sung.com>
To:	Ohad Ben-Cohen <ohad@...ery.com>
Cc:	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-samsung-soc@...r.kernel.org" 
	<linux-samsung-soc@...r.kernel.org>,
	"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"joerg.roedel@....com" <joerg.roedel@....com>,
	이상현 <sanghyun75.lee@...sung.com>,
	김국진 <kgene.kim@...sung.com>,
	김영락 <younglak1004.kim@...sung.com>
Subject: Re: [PATCH 3/4] iommu/exynos: Add iommu driver for Exynos4 Platforms

On Tue, Sep 27, 2011 at 12:59 AM, Ohad Ben-Cohen <ohad@...ery.com> wrote:
> On Mon, Sep 26, 2011 at 5:48 PM, KyongHo Cho <pullip.cho@...sung.com> wrote:
>> I am sorry but I still think that
>> installing default fault handler is quite simple and straightforward.
>
> ... and abusing the IOMMU API.
>
> Please don't do that. Interfaces are written for specific goals, and
> this one was added for IOMMU users, not drivers. Just like all the
> other map/unmap/attach/... APIs.
>
> By using this from the IOMMU driver itself, you are adding burden on
> future development and evolution of this API. As use cases
> materialize, we will have to change it to support them, while
> considering existing use cases. Using this API inappropriately will
> make our life harder later on.
I didn't think about this case.
It can be a problem if IOMMU driver is dependent upon the change of
IOMMU API as you told above.

>
> Moreover, I'm really not sure how exactly are you going to use this.
>
> If you're having an IOMMU user which installs its own fault handler,
> then this is all moot since the default behavior you provide here will
> be overridden.
Yes, this is what I really want.
I wanted the IOMMU driver to provide default fault handler to its users
that does not provide fault handler for debugging purpose.
If a user want to handle MMU fault, IOMMU driver welcomes to overwrite
the existing 'default' fault handler.

> If you're not having an IOMMU user which installs its own fault
> handler, then just provide the default behavior in your irq handler,
> regardless whether you report the fault to the IOMMU core or not. Or
> only when it fails. and yes, we can provide different error values for
> different scenarios. it's not rocket science :).
>
> Really, there's a myriad of ways to do this right. Please explain your
> exact settings/use-case and I'll gladly help you find a clean
> solution.
>
Thank you.

As I explained before, MMU fault in our system is abnormal and
the situation cannot be recovered because mapping information is set up
completely before System MMU starts address translation with the mapping
information.
However we have to capture the MMU fault for debugging purpose.
That's why our fault handler just prints debugging messages and
generates kernel OOPS

A user of IOMMU may handle MMU faults due to the following reason:
 - Its IOMMU sees the virtual address space of the user process (IOMMU
refers the page table of CPU)
   and virtual memory region allocated by userspace is not filled with
physical memory.
   Device driver which is user of IOMMU does not call get_user_pages()
for the region but
   handle page fault generated by IOMMU.
 - A device driver working in the Monitor mode in ARM processors need
to protect a memory region
   from access in the Normal mode. If it happens, the device driver
must catch the situation,
   stop the current operation and inform the problem to the userspace.

For the above reasons, some user of IOMMU may override the default
fault handler.

> Thanks,
> Ohad.

Thanks and regards,
Cho KyongHo.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/