linux-kernel - Re: [RFC] iommu: arm-smmu: stall support

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <32e3ab2c-a996-c805-2a0d-a2e85deb3a50@arm.com>
Date:   Fri, 22 Sep 2017 11:02:53 +0100
From:   Jean-Philippe Brucker <jean-philippe.brucker@....com>
To:     Joerg Roedel <joro@...tes.org>, Rob Clark <robdclark@...il.com>
Cc:     linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Will Deacon <Will.Deacon@....com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC] iommu: arm-smmu: stall support

On 22/09/17 10:02, Joerg Roedel wrote:
> On Tue, Sep 19, 2017 at 10:23:43AM -0400, Rob Clark wrote:
>> I would like to decide in the IRQ whether or not to queue work or not,
>> because when we get a gpu fault, we tend to get 1000's of gpu faults
>> all at once (and I really only need to handle the first one).  I
>> suppose that could also be achieved by having a special return value
>> from the fault handler to say "call me again from a wq"..
>>
>> Note that in the drm driver I already have a suitable wq to queue the
>> work, so it really doesn't buy me anything to have the iommu driver
>> toss things off to a wq for me.  Might be a different situation for
>> other drivers (but I guess mostly other drivers are using iommu API
>> indirectly via dma-mapping?)
> 
> Okay, so since you are the only user for now, we don't need a
> work-queue. But I still want the ->resume call-back to be hidden in the
> iommu code and not be exposed to users.
> 
> We already have per-domain fault-handlers, so the best solution for now
> is to call ->resume from report_iommu_fault() when the fault-handler
> returns a special value.

The problem is that report_iommu_fault is called from IRQ context by the
SMMU driver, so the device driver callback cannot sleep.

So if the device driver needs to be able to sleep between fault report and
resume, as I understand Rob needs for writing debugfs, we can either:

* call report_iommu_fault from higher up, in a thread or workqueue.
* split the fault reporting as this patch proposes. The exact same
  mechanism is needed for the vSVM work by Intel: in order to inject fault
  into the guest, they would like to have an atomic notifier registered by
  VFIO for passing down the Page Request, and a new function in the IOMMU
  API to resume/complete the fault.

Thanks,
Jean