linux-kernel - Re: [PATCH v1 2/2] iommu/tegra-smmu: Revert workaround that was needed for Nyan Big Chromebook

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: <YIZocTpPPM0vF4Wk@orome.fritz.box>
Date:   Mon, 26 Apr 2021 09:14:57 +0200
From:   Thierry Reding <thierry.reding@...il.com>
To:     Dmitry Osipenko <digetx@...il.com>
Cc:     Guillaume Tucker <guillaume.tucker@...labora.com>,
        Nicolin Chen <nicoleotsuka@...il.com>,
        Joerg Roedel <joro@...tes.org>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Krishna Reddy <vdumpa@...dia.com>,
        Will Deacon <will@...nel.org>,
        iommu@...ts.linux-foundation.org, linux-tegra@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 2/2] iommu/tegra-smmu: Revert workaround that was
 needed for Nyan Big Chromebook

On Sat, Apr 24, 2021 at 11:27:10PM +0300, Dmitry Osipenko wrote:
> 23.04.2021 18:23, Dmitry Osipenko пишет:
> > 23.04.2021 18:01, Guillaume Tucker пишет:
> >> On 02/04/2021 15:40, Dmitry Osipenko wrote:
> >>> 01.04.2021 11:55, Nicolin Chen пишет:
> >>>> On Mon, Mar 29, 2021 at 02:32:56AM +0300, Dmitry Osipenko wrote:
> >>>>> The previous commit fixes problem where display client was attaching too
> >>>>> early to IOMMU during kernel boot in a multi-platform kernel configuration
> >>>>> which enables CONFIG_ARM_DMA_USE_IOMMU=y. The workaround that helped to
> >>>>> defer the IOMMU attachment for Nyan Big Chromebook isn't needed anymore,
> >>>>> revert it.
> >>>>
> >>>> Sorry for the late reply. I have been busy with downstream tasks.
> >>>>
> >>>> I will give them a try by the end of the week. Yet, probably it'd
> >>>> be better to include Guillaume also as he has the Nyan platform.
> >>>>
> >>>
> >>> Indeed, thanks. Although, I'm pretty sure that it's the same issue which
> >>> I reproduced on Nexus 7.
> >>>
> >>> Guillaume, could you please give a test to these patches on Nyan Big?
> >>> There should be no EMEM errors in the kernel log with this patches.
> >>>
> >>> https://patchwork.ozlabs.org/project/linux-tegra/list/?series=236215
> >>
> >> So sorry for the very late reply.  I have tried the patches but
> >> hit some issues on linux-next, it's not reaching a login prompt
> >> with next-20210422.  So I then tried with next-20210419 which
> >> does boot but shows the IOMMU error:
> >>
> >> <6>[    2.995341] tegra-dc 54200000.dc: Adding to iommu group 1
> >> <4>[    3.001070] Failed to attached device 54200000.dc to IOMMU_mapping  
> >>
> >>   https://lava.collabora.co.uk/scheduler/job/3570052#L1120
> >>
> >> The branch I'm using with the patches applied can be found here:
> >>
> >>   https://gitlab.collabora.com/gtucker/linux/-/commits/next-20210419-nyan-big-drm-read/
> >>
> >> Hope this helps, let me know if you need anything else to be
> >> tested.
> > 
> > 
> > Hello Guillaume,
> > 
> > The current linux-next doesn't boot on all ARM (AFAIK), the older
> > next-20210413 works. The above message should be unrelated to the boot
> > problem. It should be okay to ignore that message as it should be
> > harmless in yours case.
> > 
> 
> Although, the 20210419 should be good.
> 
> Thierry, do you know what those SOR and Nouveau issues are about?

There's a use-after-free (though it's really a use-before-init) issue in
linux-next at the moment, but a fix has been suggested. The fix for this
along with an additional leak plug is here:

	http://patchwork.ozlabs.org/project/linux-tegra/list/?series=240569

I'm not aware of any Nouveau issues. What version and platform are those
happening on? Are there any logs? I can't seem to find them in this
thread.

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)