linux-kernel - Re: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool

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]

Date:   Wed, 24 Jul 2019 11:03:12 +0100
From:   Robin Murphy <robin.murphy@....com>
To:     Jon Hunter <jonathanh@...dia.com>,
        Jose Abreu <Jose.Abreu@...opsys.com>,
        Lars Persson <lists@...h.nu>,
        Ilias Apalodimas <ilias.apalodimas@...aro.org>
Cc:     Joao Pinto <Joao.Pinto@...opsys.com>,
        Alexandre Torgue <alexandre.torgue@...com>,
        Maxime Ripard <maxime.ripard@...tlin.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-stm32@...md-mailman.stormreply.com" 
        <linux-stm32@...md-mailman.stormreply.com>,
        Chen-Yu Tsai <wens@...e.org>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        linux-tegra <linux-tegra@...r.kernel.org>,
        Giuseppe Cavallaro <peppe.cavallaro@...com>,
        "David S . Miller" <davem@...emloft.net>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH net-next 3/3] net: stmmac: Introducing support for Page
 Pool

On 23/07/2019 22:39, Jon Hunter wrote:
> 
> On 23/07/2019 14:19, Robin Murphy wrote:
> 
> ...
> 
>>>> Do you know if the SMMU interrupts are working correctly? If not, it's
>>>> possible that an incorrect address or mapping direction could lead to
>>>> the DMA transaction just being silently terminated without any fault
>>>> indication, which generally presents as inexplicable weirdness (I've
>>>> certainly seen that on another platform with the mix of an unsupported
>>>> interrupt controller and an 'imperfect' ethernet driver).
>>>
>>> If I simply remove the iommu node for the ethernet controller, then I
>>> see lots of ...
>>>
>>> [    6.296121] arm-smmu 12000000.iommu: Unexpected global fault, this
>>> could be serious
>>> [    6.296125] arm-smmu 12000000.iommu:         GFSR 0x00000002,
>>> GFSYNR0 0x00000000, GFSYNR1 0x00000014, GFSYNR2 0x00000000
>>>
>>> So I assume that this is triggering the SMMU interrupt correctly.
>>
>> According to tegra186.dtsi it appears you're using the MMU-500 combined
>> interrupt, so if global faults are being delivered then context faults
>> *should* also, but I'd be inclined to try a quick hack of the relevant
>> stmmac_desc_ops::set_addr callback to write some bogus unmapped address
>> just to make sure arm_smmu_context_fault() then screams as expected, and
>> we're not missing anything else.
> 
> I hacked the driver and forced the address to zero for a test and
> in doing so I see ...
> 
> [   10.440072] arm-smmu 12000000.iommu: Unhandled context fault: fsr=0x402, iova=0x00000000, fsynr=0x1c0011, cbfrsynra=0x14, cb=0
> 
> So looks like the interrupts are working AFAICT.

OK, that's good, thanks for confirming. Unfortunately that now leaves us 
with the challenge of figuring out how things are managing to go wrong 
*without* ever faulting... :)

I wonder if we can provoke the failure on non-IOMMU platforms with 
"swiotlb=force" - I have a few boxes I could potentially test that on, 
but sadly forgot my plan to bring one with me this morning.

Robin.