* Re: [PATCH 4/6] scs: Move scs_overflow_check() out of architecture code
From: Will Deacon @ 2020-05-18 16:44 UTC (permalink / raw)
To: Kees Cook
Cc: Mark Rutland, Jann Horn, Peter Zijlstra, Catalin Marinas,
linux-kernel, Mark Rutland, Sami Tolvanen, kernel-team,
Ard Biesheuvel, linux-arm-kernel
In-Reply-To: <202005180823.A9C8925ED@keescook>
On Mon, May 18, 2020 at 08:31:49AM -0700, Kees Cook wrote:
> On Mon, May 18, 2020 at 02:32:31PM +0100, Mark Rutland wrote:
> > On Mon, May 18, 2020 at 02:23:47PM +0100, Will Deacon wrote:
> > > This is something I would like to revisit, but we need more
> > > information from Sami about why Android rejected the larger allocation
> > > size, since I don't think there's an awful lot of point merging this
> > > series if Android doesn't pick it up.
> >
> > Indeed. I'd certainly prefer the robustness of a VMAP'd SCS if we can do
> > that.
>
> For smaller devices, the memory overhead was too high. (i.e. 4x more
> memory allocated to kernel stacks -- 4k vs 1k per thread.)
I just don't see an extra 3k per thread as being a real issue (the main
stack is 16k already). Even just the CPU register state is around 1k.
But I'd be very keen to see numbers/performance data that proves me wrong.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 04/14] arm64: kvm: Add build rules for separate nVHE object files
From: David Brazdil @ 2020-05-18 16:42 UTC (permalink / raw)
To: Andrew Scull
Cc: Suzuki K Poulose, Catalin Marinas, linux-kernel, James Morse,
linux-arm-kernel, Marc Zyngier, David Brazdil, Will Deacon,
kvmarm, Julien Thierry
In-Reply-To: <20200518155553.GB147668@google.com>
On Mon, May 18, 2020 at 04:55:53PM +0100, Andrew Scull wrote:
> On Fri, May 15, 2020 at 11:58:31AM +0100, David Brazdil wrote:
> > diff --git a/arch/arm64/kernel/image-vars.h b/arch/arm64/kernel/image-vars.h
> > index 7f06ad93fc95..13850134fc28 100644
> > --- a/arch/arm64/kernel/image-vars.h
> > +++ b/arch/arm64/kernel/image-vars.h
> > @@ -51,4 +51,16 @@ __efistub__ctype = _ctype;
> >
> > #endif
> >
> > +#ifdef CONFIG_KVM
> > +
> > +/*
> > + * KVM nVHE code has its own symbol namespace prefixed by __hyp_text_, to
> > + * isolate it from the kernel proper. The following symbols are legally
> > + * accessed by it, therefore provide aliases to make them linkable.
> > + * Do not include symbols which may not be safely accessed under hypervisor
> > + * memory mappings.
> > + */
>
> nit: the prefix is not '__kvm_nvhe_' rather than '__hyp_text_'
Thanks, will fix in v3.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PING] [PATCH v2] arm: ptrace: Fix mask for thumb breakpoint hook
From: Russell King - ARM Linux admin @ 2020-05-18 16:39 UTC (permalink / raw)
To: Fredrik Strupe; +Cc: linux-kernel, linux-arm-kernel, Oleg Nesterov
In-Reply-To: <0afefde9-f121-c88c-2ceb-7c02f7561979@strupe.net>
On Mon, May 18, 2020 at 05:02:27PM +0200, Fredrik Strupe wrote:
> On 18.05.2020 16:18, Russell King - ARM Linux admin wrote:
> > On Mon, May 18, 2020 at 03:12:06PM +0200, Fredrik Strupe wrote:
> >> call_undef_hook() in traps.c applies the same instr_mask for both 16-bit
> >> and 32-bit thumb instructions. If instr_mask then is only 16 bits wide
> >> (0xffff as opposed to 0xffffffff), the first half-word of 32-bit thumb
> >> instructions will be masked out. This makes the function match 32-bit
> >> thumb instructions where the second half-word is equal to instr_val,
> >> regardless of the first half-word.
> >>
> >> The result in this case is that all undefined 32-bit thumb instructions
> >> with the second half-word equal to de01 (udf #1) work as breakpoints
> >> and will raise a SIGTRAP instead of a SIGILL, instead of just the one
> >> intended 16-bit instruction. An example of such an instruction is
> >> eaa0b650, which is unallocated according to Arm ARM and should raise a
> >> SIGILL, but instead raises a SIGTRAP.
> >
> > How can 0xeaa0b650 match 0xde01 when masked with 0xffff ?
> >
>
> Sorry, that is a typo; it should say 0xeaa0de01.
>
> For reference, this is similar to the problem with SETEND emulation that
> was fixed in commit fc2266011acc in the mainline kernel
> (or as discussed here: https://lkml.org/lkml/2020/4/8/274).
Thanks for the clarification. Please update the patch description and
put it in the patch system, thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 13/14] prctl.2: Add SVE prctls (arm64)
From: Dave Martin @ 2020-05-18 16:37 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arch, linux-man, Michael Kerrisk (man-pages),
linux-arm-kernel, Catalin Marinas
In-Reply-To: <20200513211153.GB28594@willie-the-truck>
On Wed, May 13, 2020 at 10:11:54PM +0100, Will Deacon wrote:
> On Wed, May 13, 2020 at 03:02:00PM +0100, Dave Martin wrote:
> > On Wed, May 13, 2020 at 01:01:12PM +0200, Michael Kerrisk (man-pages) wrote:
> > > On 5/13/20 12:46 PM, Dave Martin wrote:
> > > > On Wed, May 13, 2020 at 09:43:52AM +0100, Will Deacon wrote:
> > > >> On Tue, May 12, 2020 at 05:36:58PM +0100, Dave Martin wrote:
> > > > glibc explicitly has
> > > >
> > > > extern int prctl (int __option, ...);
> > > >
> > > > (and nobody has to write _exit(0, 0, 0, 0, 0, 0) after all.)
> > > >
> > > > Is there some agreed rationale for requiring redundant arguments to be
> > > > supplied explicitly as zero? For now there are likely to be few users
> > > > of this, so we _might_ get away with changing the behaviour here if it's
> > > > considered important enough.
> > >
> > > See above.
> >
> > So there is no bulletproof rationale for either approach, but the main
> > concern is inconsistency? Have I understood that right?
>
> I think it's all just an extension of "make sure unused parameters are 0"
> idiom which allows those bits to be safely repurposed for flags and things
> later on without the worry of existing applications getting away with
> passing junk.
I'd say that the explicit zeroing may give a false sense of safety, but
I sympathise with the intent.
At least, I think the explicit zeroing means that any resulting bugs are
more likely to be fixable in userspace.
> > I'll propose to get that written down in the kernel source somewhere
> > if so.
>
> That would be a really good idea, actually!
>
> > (From my end, the pros and cons of the two approaches seem superficial
> > but the inconsistency is indeed annoying. For PR_SVE_SET_VL, I think
> > the first example I looked at didn't zero the trailing arguments, so I
> > didn't either... but it's been upstream for several releases, so most
> > likely we're stuck with it.)
>
> FWIW, I wasn't blaming you for this. Just that these oversights aren't
> always apparent when reviewing patches, but become more clear when
> reviewing the documentation.
I'll have a think, so long as nobody implies that the SVE prctls are
"wrong" ;)
Adding comments in the code about how the implementation of those prctls
can and can't safely be extended would be sensible though. I'll try to
address that at some point.
> > > > There is no forwards compatibility problem with this prctl though,
> > > > because there are spare bits in arg2 which can "turn on" additional
> > > > args if needed.
> > > >
> > > > Also, it's implausible that PR_SVE_GET_VL will ever want an argument.
> > > >
> > > > There are still 2 billion unallocated prctl numbers, so new prctls can
> > > > always be added if there's ever a need to work around these limitations,
> > > > but it seems extremely unlikely.
>
> Oh, there are ways out, but had I noticed this during code review it
> would've been very easy just to enforce zero for the other args and be done
> with it.
Ack
> > > >>> +If
> > > >>> +.B PR_SVE_VL_INHERIT
> > > >>> +is also included in
> > > >>> +.IR arg2 ,
> > > >>> +it takes effect
> > > >>> +.I after
> > > >>> +this deferred change.
> > > >>
> > > >> I find this a bit hard to follow, since it's not clear to me whether the
> > > >> INHERIT flag is effectively set before or after the next execve(). In other
> > > >> words, if both PR_SVE_SET_VL_ONEXEC and PR_SVE_VL_INHERIT are specified,
> > > >> is the vector length preserved or reset on the next execve()?
> > > >
> > > > It makes no difference, because the ONEXEC handling takes priority over
> > > > the INHERIT handling. But either way INHERIT is never cleared by execve()
> > > > and will apply at subsequent execs().
> > > >
> > > > Explaining all this properly seems out of scope here. Maybe this should
> > > > be trimmed down rather than elaborated? Or perhaps just explain it in
> > > > terms of what the kernel does instead of futile attempts to make it
> > > > intuitive?
>
> Hmm, if we don't explain it in the man page then we should at least point
> people to somewhere where they can get the gory details, because I think
> they're necessary in order to use the prctl() request correctly. I'm still
> not confident that I understand the semantics of setting both
> PR_SVE_SET_VL_ONEXEC and PR_SVE_VL_INHERIT without reading the code, which
> may change.
>
> (I concede on all the spelling/grammar discussions ;)
Ultimately I aim to add another page, but for now would it be sufficient
to refer to Documentation/?
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/4] PCI, iommu: Factor 'untrusted' check for ATS enablement
From: Jean-Philippe Brucker @ 2020-05-18 16:36 UTC (permalink / raw)
To: Christoph Hellwig
Cc: ashok.raj, linux-pci, joro, alex.williamson, iommu, bhelgaas,
baolu.lu, will, dwmw2, linux-arm-kernel, robin.murphy
In-Reply-To: <20200515154351.GA6546@infradead.org>
On Fri, May 15, 2020 at 08:43:51AM -0700, Christoph Hellwig wrote:
> Can you please lift the untrusted flag into struct device? It really
> isn't a PCI specific concept, and we should not have code poking into
> pci_dev all over the iommu code.
I suppose that could go in a separate series once other buses need it?
The only methods for setting this bit at the moment apply to PCI ports.
(ACPI ExternalFacingPort and dt external-facing properties declared by
firmware).
Thanks,
Jean
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 14/14] prctl.2: Add PR_PAC_RESET_KEYS (arm64)
From: Will Deacon @ 2020-05-18 16:29 UTC (permalink / raw)
To: Dave Martin
Cc: linux-arch, linux-man, Catalin Marinas, mtk.manpages,
Amit Daniel Kachhap, Mark Rutland, linux-arm-kernel
In-Reply-To: <20200518161128.GB21779@arm.com>
On Mon, May 18, 2020 at 05:11:28PM +0100, Dave Martin wrote:
> How about summarising the key error cases here, and just putting a cross-
> reference in the ERRORS section rather than trying to describe them
> there? I really don't want to duplicate this stuff -- that will get
> unmaintanable, fast (if it hasn't already).
Makes sense to me.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/4] PCI, iommu: Factor 'untrusted' check for ATS enablement
From: Raj, Ashok @ 2020-05-18 16:29 UTC (permalink / raw)
To: David Woodhouse
Cc: Jean-Philippe Brucker, Ashok Raj, linux-pci, joro,
alex.williamson, Christoph Hellwig, iommu, bhelgaas, baolu.lu,
will, linux-arm-kernel, robin.murphy
In-Reply-To: <3ce5d02db49254e50883224771ffb35cf436845f.camel@infradead.org>
On Mon, May 18, 2020 at 04:47:17PM +0100, David Woodhouse wrote:
> On Fri, 2020-05-15 at 10:19 -0700, Raj, Ashok wrote:
> > Hi Christoph
> >
> > On Fri, May 15, 2020 at 08:43:51AM -0700, Christoph Hellwig wrote:
> > > Can you please lift the untrusted flag into struct device? It really
> > > isn't a PCI specific concept, and we should not have code poking into
> > > pci_dev all over the iommu code.
> >
> > Just for clarification: All IOMMU's today mostly pertain to only PCI devices
> > and for devices that aren't PCI like HPET for instance we give a PCI
> > identifier. Facilities like ATS for instance require the platform to have
> > an IOMMU.
> >
> > what additional problems does moving this to struct device solve?
>
> Even the Intel IOMMU supports ACPI devices for which there is no struct
> pci_dev; only a B/D/F in the ANDD record indicating which entry in the
> context table to use.
Yes, spaced out :-).. just don't work on those platforms on a daily
basis and its easy to forget :-(
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1] drivers/clocksource/arm_arch_timer: remove duplicate error message
From: Daniel Lezcano @ 2020-05-18 16:21 UTC (permalink / raw)
To: Dejin Zheng, mark.rutland, maz, tglx, linux-arm-kernel; +Cc: linux-kernel
In-Reply-To: <20200429153559.21189-1-zhengdejin5@gmail.com>
On 29/04/2020 17:35, Dejin Zheng wrote:
> it will print an error message by itself when acpi_gtdt_init()
> goes wrong. so remove the duplicate error message.
>
> Signed-off-by: Dejin Zheng <zhengdejin5@gmail.com>
Applied, thanks
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 14/14] prctl.2: Add PR_PAC_RESET_KEYS (arm64)
From: Dave Martin @ 2020-05-18 16:11 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arch, linux-man, Catalin Marinas, mtk.manpages,
Amit Daniel Kachhap, Mark Rutland, linux-arm-kernel
In-Reply-To: <20200513210022.GA28594@willie-the-truck>
On Wed, May 13, 2020 at 10:00:22PM +0100, Will Deacon wrote:
> On Wed, May 13, 2020 at 03:36:54PM +0100, Dave Martin wrote:
> > On Wed, May 13, 2020 at 08:25:31AM +0100, Will Deacon wrote:
> > > On Tue, May 12, 2020 at 05:36:59PM +0100, Dave Martin wrote:
> > > > +As a special case, if
> > > > +.I arg2
> > > > +is zero then all the keys are reset.
> > > > +Since new keys could be added in future,
> > > > +this is the recommended way to completely wipe the existing keys
> > > > +when creating a new execution context.
> > >
> > > I see what you're saying, but the keys are also reset on exec() iirc, so we
> > > don't want to encourage people to issue the prctl() unnecessarily
> > > immediately following an exec().
> >
> > I thought of saying that, then pulled it out again.
> >
> > How about:
> >
> > "[...] a new execution context within an existing process. Note that
> > execve() always resets all the keys as part of its operation, without
> > the need for this prctl() call. PR_PAC_RESET_KEYS is intended for
> > custom situations that do not involve execve(), such as creating a new
> > managed run-time sandbox."
> >
> > I deliberately don't say "thread" because that's probably libc's job.
> > I'll need to check glibc does, though. There may be issues with
> > pthreads semantics that mean we can't reset the keys there.
>
> That's better, but you may even be able to drop the "such as..." part, I
> reckon.
>
> > > > @@ -1920,6 +1960,27 @@ are not 0.
> > > > .B EINVAL
> > > > .I option
> > > > was
> > > > +.B PR_PAC_RESET_KEYS
> > > > +and
> > > > +.I arg2
> > > > +contains non-zero bits other than
> > > > +.BR
> > > > +.BR PR_PAC_APIAKEY ,
> > > > +.BR PR_PAC_APIBKEY ,
> > > > +.BR PR_PAC_APDAKEY ,
> > > > +.B PR_PAC_APDBKEY
> > > > +and
> > > > +.BR PR_PAC_APGAKEY ;
> > > > +or
> > > > +.IR arg3 ,
> > > > +.I arg4
> > > > +and
> > > > +.I arg5
> > > > +were not all zero.
> > >
> > > Do we care about other reasons for -EINVAL, such as the system not
> > > supporting pointer authentication?
> >
> > Again, I tried to catch that under the new "not supported by this
> > platform" wording in the earlier patch. Do you think that's sufficient,
> > or do we need something else here?
>
> As long as it's clear that the prctl() *can* fail and userspace can't just
> ignore the return value, then I'm happy. If it's not obvious, then spelling
> it out seems harmless to me.
OK, I'll try to figure out a way to capture this.
Since prctl is really the wild west when it comes to error codes I was
presuming that's it's best to say nothing and rely on people's common sense.
But I guess this isn't great either.
How about summarising the key error cases here, and just putting a cross-
reference in the ERRORS section rather than trying to describe them
there? I really don't want to duplicate this stuff -- that will get
unmaintanable, fast (if it hasn't already).
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V3 07/15] arch/kunmap_atomic: Consolidate duplicate code
From: Guenter Roeck @ 2020-05-18 16:11 UTC (permalink / raw)
To: Ira Weiny
Cc: Peter Zijlstra, Benjamin Herrenschmidt, Dave Hansen, dri-devel,
linux-mips, James E.J. Bottomley, Max Filippov, Paul Mackerras,
H. Peter Anvin, sparclinux, Dan Williams, Helge Deller, x86,
linux-csky, Christoph Hellwig, Ingo Molnar, linux-snps-arc,
linux-xtensa, Borislav Petkov, Al Viro, Andy Lutomirski,
Thomas Gleixner, linux-arm-kernel, Chris Zankel,
Thomas Bogendoerfer, linux-parisc, linux-kernel, Christian Koenig,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200518034938.GA3023182@iweiny-DESK2.sc.intel.com>
On Sun, May 17, 2020 at 08:49:39PM -0700, Ira Weiny wrote:
[ ... ]
> >
> > ---
> > # bad: [bdecf38f228bcca73b31ada98b5b7ba1215eb9c9] Add linux-next specific files for 20200515
> > # good: [2ef96a5bb12be62ef75b5828c0aab838ebb29cb8] Linux 5.7-rc5
> > git bisect start 'HEAD' 'v5.7-rc5'
> > # good: [3674d7aa7a8e61d993886c2fb7c896c5ef85e988] Merge remote-tracking branch 'crypto/master'
> > git bisect good 3674d7aa7a8e61d993886c2fb7c896c5ef85e988
> > # good: [87f6f21783522e6d62127cf33ae5e95f50874beb] Merge remote-tracking branch 'spi/for-next'
> > git bisect good 87f6f21783522e6d62127cf33ae5e95f50874beb
> > # good: [5c428e8277d5d97c85126387d4e00aa5adde4400] Merge remote-tracking branch 'staging/staging-next'
> > git bisect good 5c428e8277d5d97c85126387d4e00aa5adde4400
> > # good: [f68de67ed934e7bdef4799fd7777c86f33f14982] Merge remote-tracking branch 'hyperv/hyperv-next'
> > git bisect good f68de67ed934e7bdef4799fd7777c86f33f14982
> > # bad: [54acd2dc52b069da59639eea0d0c92726f32fb01] mm/memblock: fix a typo in comment "implict"->"implicit"
> > git bisect bad 54acd2dc52b069da59639eea0d0c92726f32fb01
> > # good: [784a17aa58a529b84f7cc50f351ed4acf3bd11f3] mm: remove the pgprot argument to __vmalloc
> > git bisect good 784a17aa58a529b84f7cc50f351ed4acf3bd11f3
> > # good: [6cd8137ff37e9a37aee2d2a8889c8beb8eab192f] khugepaged: replace the usage of system(3) in the test
> > git bisect good 6cd8137ff37e9a37aee2d2a8889c8beb8eab192f
> > # bad: [6987da379826ed01b8a1cf046b67cc8cc10117cc] sparc: remove unnecessary includes
> > git bisect bad 6987da379826ed01b8a1cf046b67cc8cc10117cc
> > # good: [bc17b545388f64c09e83e367898e28f60277c584] mm/hugetlb: define a generic fallback for is_hugepage_only_range()
> > git bisect good bc17b545388f64c09e83e367898e28f60277c584
> > # bad: [9b5aa5b43f957f03a1f4a9aff5f7924e2ebbc011] arch-kmap_atomic-consolidate-duplicate-code-checkpatch-fixes
> > git bisect bad 9b5aa5b43f957f03a1f4a9aff5f7924e2ebbc011
> > # good: [0941a38ff0790c1004270f952067a5918a4ba32d] arch/kmap: remove redundant arch specific kmaps
> > git bisect good 0941a38ff0790c1004270f952067a5918a4ba32d
> > # good: [56e635a64c2cbfa815c851af10e0f811e809977b] arch-kunmap-remove-duplicate-kunmap-implementations-fix
> > git bisect good 56e635a64c2cbfa815c851af10e0f811e809977b
> > # bad: [60f96b2233c790d4f1c49317643051f1670bcb29] arch/kmap_atomic: consolidate duplicate code
> > git bisect bad 60f96b2233c790d4f1c49317643051f1670bcb29
> > # good: [7b3708dc3bf72a647243064fe7ddf9a76248ddfd] {x86,powerpc,microblaze}/kmap: move preempt disable
> > git bisect good 7b3708dc3bf72a647243064fe7ddf9a76248ddfd
> > # first bad commit: [60f96b2233c790d4f1c49317643051f1670bcb29] arch/kmap_atomic: consolidate duplicate code
>
> I'm confused by this. This points to an earlier commit being bad?
>
Yes, you are correct. I was looking up the wrong commit; it had a similar
subject line. Sorry for the confusion.
Guenter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/9] clocksource/drivers/timer-atmel-tcb: add sama5d2 support
From: Daniel Lezcano @ 2020-05-18 16:03 UTC (permalink / raw)
To: Alexandre Belloni
Cc: kamel.bouhara, devicetree, Sebastian Andrzej Siewior,
linux-kernel, Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20200506080554.283177-1-alexandre.belloni@bootlin.com>
Hi Alexandre,
I would like to take the whole series but I need Rob's blessing for the
DT parts.
On 06/05/2020 10:05, Alexandre Belloni wrote:
> This series mainly adds sama5d2 support where we need to avoid using
> clock index 0 because that clock is never enabled by the driver.
>
> There is also a rework of the 32khz clock handling so it is not used for
> clockevents on 32 bit counter because the increased rate improves the
> resolution and doesn't have any drawback with that counter width. This
> replaces a patch that has been carried in the linux-rt tree for a while.
>
> Changes in v3:
> - Moved the child node documentation to the parent documentation
>
> Changes in v2:
> - Rebased on v5.7-rc1
> - Moved the binding documentation to its proper place
> - Added back the atmel,tcb-timer child node documentation
>
> Alexandre Belloni (8):
> dt-bindings: atmel-tcb: convert bindings to json-schema
> dt-bindings: microchip: atmel,at91rm9200-tcb: add sama5d2 compatible
> ARM: dts: at91: sama5d2: add TCB GCLK
> clocksource/drivers/timer-atmel-tcb: rework 32khz clock selection
> clocksource/drivers/timer-atmel-tcb: fill tcb_config
> clocksource/drivers/timer-atmel-tcb: stop using the 32kHz for
> clockevents
> clocksource/drivers/timer-atmel-tcb: allow selecting first divider
> clocksource/drivers/timer-atmel-tcb: add sama5d2 support
>
> Kamel Bouhara (1):
> ARM: at91: add atmel tcb capabilities
>
> .../devicetree/bindings/mfd/atmel-tcb.txt | 56 -------
> .../soc/microchip/atmel,at91rm9200-tcb.yaml | 150 ++++++++++++++++++
> arch/arm/boot/dts/sama5d2.dtsi | 12 +-
> drivers/clocksource/timer-atmel-tcb.c | 101 +++++++-----
> include/soc/at91/atmel_tcb.h | 5 +
> 5 files changed, 219 insertions(+), 105 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/mfd/atmel-tcb.txt
> create mode 100644 Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: vdso: Fix CFI info in sigreturn.
From: Dave Martin @ 2020-05-18 15:59 UTC (permalink / raw)
To: dankis01
Cc: mark.rutland, Tamas Zsoldos, Vincenzo.Frascino, linux-arm-kernel,
Daniel Kiss
In-Reply-To: <20200515162020.78169-1-daniel.kiss@arm.com>
On Fri, May 15, 2020 at 06:20:20PM +0200, dankis01 wrote:
> When the signal handler is called the registers set up as the return address
> points to the __kernel_rt_sigreturn. The NOP here is the placeholder of the
> branch and link instruction that "calls" the signal handler. In case of a
> return address the unwinder identifies the location of the caller because
> in some cases the return address might not exist. Since the .cfi_startproc
> is after the NOP, it won't be associated with any location and the
> unwinder will stop walking.
>
> This change corrects the generated EHFrames only.
This is a can of worms.
Which unwinder are you look at, and what do other unwinders do? Are you
sure the unwinder is doing something valid? Is this a newly observed
problem, or has it happened forever?
Why should there be any instruction that "calls" the signal handler?
In the case is a SIGSEGV the affected instruction is after the pc and
not before it; for an asynchronous signal and notion of a "calling"
instruction is nonsense.
Certainly I've seen correct unwinding through signal handlers with glibc
and gdb, but I hadn't tried everything...
>
> Signed-off-by: Daniel Kiss <daniel.kiss@arm.com>
> Signed-off-by: Tamas Zsoldos <tamas.zsoldos@arm.com>
> ---
> arch/arm64/kernel/vdso/sigreturn.S | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kernel/vdso/sigreturn.S b/arch/arm64/kernel/vdso/sigreturn.S
> index 12324863d5c2..5d50ee92faa4 100644
> --- a/arch/arm64/kernel/vdso/sigreturn.S
> +++ b/arch/arm64/kernel/vdso/sigreturn.S
> @@ -13,13 +13,13 @@
>
> .text
>
> - nop
> -SYM_FUNC_START(__kernel_rt_sigreturn)
> .cfi_startproc
> .cfi_signal_frame
> .cfi_def_cfa x29, 0
> .cfi_offset x29, 0 * 8
> .cfi_offset x30, 1 * 8
Hmm, recovering x29,x30 like this will be wrong if the signal handler
munges sigcontext in the meantime (say, doing some kind of userspace
context switch).
They should be pulled out of sigcontext instead really. AFAIK, that's
what ".cfi_signal_frame" is supposed to tell the unwinder. I'm not sure
why we have these additional, conflicting annotations here.
Any ideas, Will?
This probably isn't related to the bug here, but it would be good to
understand.
> + nop /* placeholder for bl signalhandler */
Will can correct me on this, but I seem to remember something about nop
being there for padding, so that there is a guaranteed gap between
unwind entries.
I can't remember the precise reasoning, but there are some nasty edge
cases connected with the fact that the linker can place another random
unwind block from another .o immediately before this one.
Cheers
---Dave
> +SYM_FUNC_START(__kernel_rt_sigreturn)
> mov x8, #__NR_rt_sigreturn
> svc #0
> .cfi_endproc
> --
> 2.17.1
[...]
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] ARM: Allow either FLATMEM or SPARSEMEM on the multiplatform build
From: Florian Fainelli @ 2020-05-18 15:58 UTC (permalink / raw)
To: Mike Rapoport
Cc: Doug Berger, Arnd Bergmann, sboyd, Kevin Cernekee, rmk+kernel,
Gregory Fong, linux-arm-kernel
In-Reply-To: <bc44ed27-7dd7-67b6-93cf-f6f575b59441@gmail.com>
On 5/7/2020 1:11 PM, Florian Fainelli wrote:
>
>
> On 5/7/2020 12:27 AM, Mike Rapoport wrote:
>> On Wed, May 06, 2020 at 04:50:09PM -0700, Florian Fainelli wrote:
>>> From: Gregory Fong <gregory.0xf0@gmail.com>
>>>
>>> ARMv7 chips with LPAE can often benefit from SPARSEMEM, as portions of
>>> system memory can be located deep in the 36-bit address space. Allow
>>> FLATMEM or SPARSEMEM to be selectable at compile time; FLATMEM remains
>>> the default.
>>>
>>> This is based on Kevin's "[PATCH 3/3] ARM: Allow either FLATMEM or
>>> SPARSEMEM on the multi-v7 build" from [1] and shamelessly rips off his
>>> commit message text above. As Arnd pointed out at [2] there doesn't
>>> seem to be any reason to tie this specifically to ARMv7, so this has
>>> been changed to apply to all multiplatform kernels.
>>>
>>> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/286837.html
>>> [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/298950.html
>>>
>>> Cc: Kevin Cernekee <cernekee@gmail.com>
>>> Tested-by: Stephen Boyd <sboyd@codeaurora.org>
>>> Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
>>> Signed-off-by: Doug Berger <opendmb@gmail.com>
>>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>>> ---
>>> arch/arm/Kconfig | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index 5986277296c3..7bb5264a9c3a 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -312,6 +312,8 @@ choice
>>> config ARCH_MULTIPLATFORM
>>> bool "Allow multiple platforms to be selected"
>>> depends on MMU
>>> + select ARCH_FLATMEM_ENABLE
>>> + select ARCH_SPARSEMEM_ENABLE
>>
>> The logic in mm/Kconfig is quite convoluted, so selecting
>> ARCH_SPARSEMEM_ENABLE will automatically make SPARSEMEM the only option.
>>
>> On top of this you would need to enable ARCH_SELECT_MEMORY_MODEL, e.g.
>> something like:
>
> Yes indeed, thanks that does allow me to select between flatmem and
> sparsemem from menuconfig correctly now.
Mike, do you want to make a formal submission to Russell's patch
tracker? If so, feel free to add:
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Thanks!
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/4] clk/soc: mediatek: mt8183: Bind clock driver from platform device
From: Matthias Brugger @ 2020-05-18 15:57 UTC (permalink / raw)
To: Chun-Kuang Hu, matthias.bgg
Cc: Kate Stewart, devicetree, Stephen Boyd, Greg Kroah-Hartman,
Michael Turquette, linux-kernel, Rob Herring,
moderated list:ARM/Mediatek SoC support, Allison Randal,
Enric Balletbo i Serra, mtk01761, Thomas Gleixner, linux-clk,
Linux ARM
In-Reply-To: <CAAOTY_9-_fy4oGTBLPsXkWJ2ihL7k2hzfwiTorit+YkNi_SeMw@mail.gmail.com>
On 18/05/2020 17:30, Chun-Kuang Hu wrote:
> Hi, Matthias:
>
> <matthias.bgg@kernel.org> 於 2020年5月18日 週一 下午7:32寫道：
>>
>> From: Matthias Brugger <matthias.bgg@gmail.com>
>>
>> The mmsys driver is now the top level entry point for the multimedia
>> system (mmsys), we bind the clock driver by creating a platform device.
>> We also bind the MediaTek DRM driver which is not yet implement and
>> therefor will errror out for now.
>
> You may need to let CONFIG_MTK_MMSYS depends on
> CONFIG_COMMON_CLK_MT8173_MMSYS || CONFIG_COMMON_CLK_MT8183_MMSYS
>
That will be fixed by:
https://patchwork.kernel.org/patch/11469521/
Otherwise this won't scale as we would need to add the SoCs using the mtk-mmsys
driver and this will be a lot if not all.
Regards,
Matthias
> Regards,
> Chun-Kuang.
>
>>
>> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
>> ---
>>
>> drivers/clk/mediatek/clk-mt8183-mm.c | 9 ++-------
>> drivers/soc/mediatek/mtk-mmsys.c | 8 ++++++++
>> 2 files changed, 10 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/clk/mediatek/clk-mt8183-mm.c b/drivers/clk/mediatek/clk-mt8183-mm.c
>> index 720c696b506d..9d60e09619c1 100644
>> --- a/drivers/clk/mediatek/clk-mt8183-mm.c
>> +++ b/drivers/clk/mediatek/clk-mt8183-mm.c
>> @@ -84,8 +84,9 @@ static const struct mtk_gate mm_clks[] = {
>>
>> static int clk_mt8183_mm_probe(struct platform_device *pdev)
>> {
>> + struct device *dev = &pdev->dev;
>> + struct device_node *node = dev->parent->of_node;
>> struct clk_onecell_data *clk_data;
>> - struct device_node *node = pdev->dev.of_node;
>>
>> clk_data = mtk_alloc_clk_data(CLK_MM_NR_CLK);
>>
>> @@ -95,16 +96,10 @@ static int clk_mt8183_mm_probe(struct platform_device *pdev)
>> return of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
>> }
>>
>> -static const struct of_device_id of_match_clk_mt8183_mm[] = {
>> - { .compatible = "mediatek,mt8183-mmsys", },
>> - {}
>> -};
>> -
>> static struct platform_driver clk_mt8183_mm_drv = {
>> .probe = clk_mt8183_mm_probe,
>> .driver = {
>> .name = "clk-mt8183-mm",
>> - .of_match_table = of_match_clk_mt8183_mm,
>> },
>> };
>>
>> diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
>> index cacafe23c823..783c3dd008b2 100644
>> --- a/drivers/soc/mediatek/mtk-mmsys.c
>> +++ b/drivers/soc/mediatek/mtk-mmsys.c
>> @@ -92,6 +92,10 @@ static const struct mtk_mmsys_driver_data mt8173_mmsys_driver_data = {
>> .clk_driver = "clk-mt8173-mm",
>> };
>>
>> +static const struct mtk_mmsys_driver_data mt8183_mmsys_driver_data = {
>> + .clk_driver = "clk-mt8183-mm",
>> +};
>> +
>> static unsigned int mtk_mmsys_ddp_mout_en(enum mtk_ddp_comp_id cur,
>> enum mtk_ddp_comp_id next,
>> unsigned int *addr)
>> @@ -339,6 +343,10 @@ static const struct of_device_id of_match_mtk_mmsys[] = {
>> .compatible = "mediatek,mt8173-mmsys",
>> .data = &mt8173_mmsys_driver_data,
>> },
>> + {
>> + .compatible = "mediatek,mt8183-mmsys",
>> + .data = &mt8183_mmsys_driver_data,
>> + },
>> { }
>> };
>>
>> --
>> 2.26.2
>>
>>
>> _______________________________________________
>> Linux-mediatek mailing list
>> Linux-mediatek@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 04/14] arm64: kvm: Add build rules for separate nVHE object files
From: Andrew Scull @ 2020-05-18 15:55 UTC (permalink / raw)
To: David Brazdil
Cc: Suzuki K Poulose, Catalin Marinas, linux-kernel, James Morse,
linux-arm-kernel, Marc Zyngier, Will Deacon, kvmarm,
Julien Thierry
In-Reply-To: <20200515105841.73532-5-dbrazdil@google.com>
On Fri, May 15, 2020 at 11:58:31AM +0100, David Brazdil wrote:
> diff --git a/arch/arm64/kernel/image-vars.h b/arch/arm64/kernel/image-vars.h
> index 7f06ad93fc95..13850134fc28 100644
> --- a/arch/arm64/kernel/image-vars.h
> +++ b/arch/arm64/kernel/image-vars.h
> @@ -51,4 +51,16 @@ __efistub__ctype = _ctype;
>
> #endif
>
> +#ifdef CONFIG_KVM
> +
> +/*
> + * KVM nVHE code has its own symbol namespace prefixed by __hyp_text_, to
> + * isolate it from the kernel proper. The following symbols are legally
> + * accessed by it, therefore provide aliases to make them linkable.
> + * Do not include symbols which may not be safely accessed under hypervisor
> + * memory mappings.
> + */
nit: the prefix is not '__kvm_nvhe_' rather than '__hyp_text_'
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH][v2] iommu: arm-smmu-v3: Copy SMMU table for kdump kernel
From: Will Deacon @ 2020-05-18 15:55 UTC (permalink / raw)
To: Prabhakar Kushwaha
Cc: gkulkarni, maz, bhsharma, kexec, helgaas, prabhakar.pkin,
robin.murphy, linux-arm-kernel
In-Reply-To: <1589251566-32126-1-git-send-email-pkushwaha@marvell.com>
On Mon, May 11, 2020 at 07:46:06PM -0700, Prabhakar Kushwaha wrote:
> An SMMU Stream table is created by the primary kernel. This table is
> used by the SMMU to perform address translations for device-originated
> transactions. Any crash (if happened) launches the kdump kernel which
> re-creates the SMMU Stream table. New transactions will be translated
> via this new table.
>
> There are scenarios, where devices are still having old pending
> transactions (configured in the primary kernel). These transactions
> come in-between Stream table creation and device-driver probe.
> As new stream table does not have entry for older transactions,
> it will be aborted by SMMU.
>
> Similar observations were found with PCIe-Intel 82576 Gigabit
> Network card. It sends old Memory Read transaction in kdump kernel.
> Transactions configured for older Stream table entries, that do not
> exist any longer in the new table, will cause a PCIe Completion Abort.
> Returned PCIe completion abort further leads to AER Errors from APEI
> Generic Hardware Error Source (GHES) with completion timeout.
> A network device hang is observed even after continuous
> reset/recovery from driver, Hence device is no more usable.
>
> So, If we are in a kdump kernel try to copy SMMU Stream table from
> primary/old kernel to preserve the mappings until the device driver
> takes over.
>
> Signed-off-by: Prabhakar Kushwaha <pkushwaha@marvell.com>
> ---
> Changes for v2: Used memremap in-place of ioremap
>
> V2 patch has been sanity tested.
Are you sure?
> V1 patch has been tested with
> A) PCIe-Intel 82576 Gigabit Network card in following
> configurations with "no AER error". Each iteration has
> been tested on both Suse kdump rfs And default Centos distro rfs.
>
> 1) with 2 level stream table
> ----------------------------------------------------
> SMMU | Normal Ping | Flood Ping
> -----------------------------------------------------
> Default Operation | 100 times | 10 times
> -----------------------------------------------------
> IOMMU bypass | 41 times | 10 times
> -----------------------------------------------------
>
> 2) with Linear stream table.
> -----------------------------------------------------
> SMMU | Normal Ping | Flood Ping
> ------------------------------------------------------
> Default Operation | 100 times | 10 times
> ------------------------------------------------------
> IOMMU bypass | 55 times | 10 times
> -------------------------------------------------------
>
> B) This patch is also tested with Micron Technology Inc 9200 PRO NVMe
> SSD card with 2 level stream table using "fio" in mixed read/write and
> only read configurations. It is tested for both Default Operation and
> IOMMU bypass mode for minimum 10 iterations across Centos kdump rfs and
> default Centos ditstro rfs.
>
> This patch is not full proof solution. Issue can still come
> from the point device is discovered and driver probe called.
> This patch has reduced window of scenario from "SMMU Stream table
> creation - device-driver" to "device discovery - device-driver".
> Usually, device discovery to device-driver is very small time. So
> the probability is very low.
>
> Note: device-discovery will overwrite existing stream table entries
> with both SMMU stage as by-pass.
>
>
> drivers/iommu/arm-smmu-v3.c | 36 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index 82508730feb7..d492d92c2dd7 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -1847,7 +1847,13 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
> break;
> case STRTAB_STE_0_CFG_S1_TRANS:
> case STRTAB_STE_0_CFG_S2_TRANS:
> - ste_live = true;
> + /*
> + * As kdump kernel copy STE table from previous
> + * kernel. It still may have valid stream table entries.
> + * Forcing entry as false to allow overwrite.
> + */
> + if (!is_kdump_kernel())
> + ste_live = true;
> break;
> case STRTAB_STE_0_CFG_ABORT:
> BUG_ON(!disable_bypass);
> @@ -3264,6 +3270,9 @@ static int arm_smmu_init_l1_strtab(struct arm_smmu_device *smmu)
> return -ENOMEM;
> }
>
> + if (is_kdump_kernel())
> + return 0;
> +
> for (i = 0; i < cfg->num_l1_ents; ++i) {
> arm_smmu_write_strtab_l1_desc(strtab, &cfg->l1_desc[i]);
> strtab += STRTAB_L1_DESC_DWORDS << 3;
> @@ -3272,6 +3281,23 @@ static int arm_smmu_init_l1_strtab(struct arm_smmu_device *smmu)
> return 0;
> }
>
> +static void arm_smmu_copy_table(struct arm_smmu_device *smmu,
> + struct arm_smmu_strtab_cfg *cfg, u32 size)
> +{
> + struct arm_smmu_strtab_cfg rdcfg;
> +
> + rdcfg.strtab_dma = readq_relaxed(smmu->base + ARM_SMMU_STRTAB_BASE);
> + rdcfg.strtab_base_cfg = readq_relaxed(smmu->base
> + + ARM_SMMU_STRTAB_BASE_CFG);
> +
> + rdcfg.strtab_dma &= STRTAB_BASE_ADDR_MASK;
> + rdcfg.strtab = memremap(rdcfg.strtab_dma, size, MEMREMAP_WB);
> +
> + memcpy_fromio(cfg->strtab, rdcfg.strtab, size);
> +
> + cfg->strtab_base_cfg = rdcfg.strtab_base_cfg;
Sorry, but this is unacceptable. These things were allocated by the DMA API
so you can't just memcpy them around and hope for the best.
Either you reinitialise the DMA masters you care about or you disable DMA. I
don't see a viable third option.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 2/6] arm/smmu: Add auxiliary domain support for arm-smmuv2
From: Rob Clark @ 2020-05-18 15:50 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arm-msm, Linux Kernel Mailing List,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Jordan Crouse, Robin Murphy,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20200518151838.GL32394@willie-the-truck>
On Mon, May 18, 2020 at 8:18 AM Will Deacon <will@kernel.org> wrote:
>
> On Wed, Mar 18, 2020 at 04:43:07PM -0700, Rob Clark wrote:
> > On Wed, Mar 18, 2020 at 3:48 PM Will Deacon <will@kernel.org> wrote:
> > > On Tue, Jan 28, 2020 at 03:16:06PM -0700, Jordan Crouse wrote:
> > > > Support auxiliary domains for arm-smmu-v2 to initialize and support
> > > > multiple pagetables for a single SMMU context bank. Since the smmu-v2
> > > > hardware doesn't have any built in support for switching the pagetable
> > > > base it is left as an exercise to the caller to actually use the pagetable.
> > > >
> > > > Aux domains are supported if split pagetable (TTBR1) support has been
> > > > enabled on the master domain. Each auxiliary domain will reuse the
> > > > configuration of the master domain. By default the a domain with TTBR1
> > > > support will have the TTBR0 region disabled so the first attached aux
> > > > domain will enable the TTBR0 region in the hardware and conversely the
> > > > last domain to be detached will disable TTBR0 translations. All subsequent
> > > > auxiliary domains create a pagetable but not touch the hardware.
> > > >
> > > > The leaf driver will be able to query the physical address of the
> > > > pagetable with the DOMAIN_ATTR_PTBASE attribute so that it can use the
> > > > address with whatever means it has to switch the pagetable base.
> > > >
> > > > Following is a pseudo code example of how a domain can be created
> > > >
> > > > /* Check to see if aux domains are supported */
> > > > if (iommu_dev_has_feature(dev, IOMMU_DEV_FEAT_AUX)) {
> > > > iommu = iommu_domain_alloc(...);
> > > >
> > > > if (iommu_aux_attach_device(domain, dev))
> > > > return FAIL;
> > > >
> > > > /* Save the base address of the pagetable for use by the driver
> > > > iommu_domain_get_attr(domain, DOMAIN_ATTR_PTBASE, &ptbase);
> > > > }
> > >
> > > I'm not really understanding what the pagetable base gets used for here and,
> > > to be honest with you, the whole thing feels like a huge layering violation
> > > with the way things are structured today. Why doesn't the caller just
> > > interface with io-pgtable directly?
> > >
> > > Finally, if we need to support context-switching TTBR0 for a live domain
> > > then that code really needs to live inside the SMMU driver because the
> > > ASID and TLB management necessary to do that safely doesn't belong anywhere
> > > else.
> >
> > We do in fact need live domain switching, that is really the whole
> > point. The GPU CP (command processor/parser) is directly updating
> > TTBR0 and triggering TLB flush, asynchronously from the CPU.
> >
> > And I think the answer about ASID is easy (on current hw).. it must be zero[*].
>
> Using ASID zero is really bad, because it means that you will end up sharing
> TLB entries with whichever device is using context bank 0.
>
> Is the SMMU only used by the GPU in your SoC?
>
yes, the snapdragon SoCs have two SMMU instances, one used by the GPU,
where ASID0/cb0 is the gpu itself, and another cb is the GMU
(basically power control for the gpu), and the second SMMU is
everything else.
BR,
-R
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RESEND] [PATCH v2 3/3] usb/ehci-platform: Set PM runtime as active on resume
From: Qais Yousef @ 2020-05-18 15:49 UTC (permalink / raw)
To: Alan Stern, Greg Kroah-Hartman
Cc: Oliver Neukum, Mathias Nyman, linux-usb, linux-kernel, Tony Prisk,
Qais Yousef, linux-arm-kernel
In-Reply-To: <20200518154931.6144-1-qais.yousef@arm.com>
Follow suit of ohci-platform.c and perform pm_runtime_set_active() on
resume.
ohci-platform.c had a warning reported due to the missing
pm_runtime_set_active() [1].
[1] https://lore.kernel.org/lkml/20200323143857.db5zphxhq4hz3hmd@e107158-lin.cambridge.arm.com/
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Qais Yousef <qais.yousef@arm.com>
CC: Tony Prisk <linux@prisktech.co.nz>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: Mathias Nyman <mathias.nyman@intel.com>
CC: Oliver Neukum <oneukum@suse.de>
CC: linux-arm-kernel@lists.infradead.org
CC: linux-usb@vger.kernel.org
CC: linux-kernel@vger.kernel.org
---
drivers/usb/host/ehci-platform.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index e4fc3f66d43b..e9a49007cce4 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -455,6 +455,10 @@ static int ehci_platform_resume(struct device *dev)
ehci_resume(hcd, priv->reset_on_resume);
+ pm_runtime_disable(dev);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+
if (priv->quirk_poll)
quirk_poll_init(priv);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RESEND] [PATCH v2 2/3] usb/xhci-plat: Set PM runtime as active on resume
From: Qais Yousef @ 2020-05-18 15:49 UTC (permalink / raw)
To: Alan Stern, Greg Kroah-Hartman
Cc: Oliver Neukum, Mathias Nyman, linux-usb, linux-kernel, Tony Prisk,
Qais Yousef, linux-arm-kernel
In-Reply-To: <20200518154931.6144-1-qais.yousef@arm.com>
Follow suit of ohci-platform.c and perform pm_runtime_set_active() on
resume.
ohci-platform.c had a warning reported due to the missing
pm_runtime_set_active() [1].
[1] https://lore.kernel.org/lkml/20200323143857.db5zphxhq4hz3hmd@e107158-lin.cambridge.arm.com/
Signed-off-by: Qais Yousef <qais.yousef@arm.com>
CC: Tony Prisk <linux@prisktech.co.nz>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: Mathias Nyman <mathias.nyman@intel.com>
CC: Oliver Neukum <oneukum@suse.de>
CC: linux-arm-kernel@lists.infradead.org
CC: linux-usb@vger.kernel.org
CC: linux-kernel@vger.kernel.org
---
drivers/usb/host/xhci-plat.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 1d4f6f85f0fe..05cafef702a9 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -407,7 +407,15 @@ static int __maybe_unused xhci_plat_resume(struct device *dev)
if (ret)
return ret;
- return xhci_resume(xhci, 0);
+ ret = xhci_resume(xhci, 0);
+ if (ret)
+ return ret;
+
+ pm_runtime_disable(dev);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+
+ return 0;
}
static int __maybe_unused xhci_plat_runtime_suspend(struct device *dev)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RESEND] [PATCH v2 1/3] usb/ohci-platform: Fix a warning when hibernating
From: Qais Yousef @ 2020-05-18 15:49 UTC (permalink / raw)
To: Alan Stern, Greg Kroah-Hartman
Cc: Oliver Neukum, Mathias Nyman, linux-usb, linux-kernel, Tony Prisk,
Qais Yousef, linux-arm-kernel
The following warning was observed when attempting to suspend to disk
using a USB flash as a swap device.
[ 111.779649] ------------[ cut here ]------------
[ 111.788382] URB (____ptrval____) submitted while active
[ 111.796646] WARNING: CPU: 3 PID: 365 at drivers/usb/core/urb.c:363 usb_submit_urb+0x3d8/0x590
[ 111.805417] Modules linked in:
[ 111.808584] CPU: 3 PID: 365 Comm: kworker/3:2 Not tainted 5.6.0-rc6-00002-gdfd1731f9a3e-dirty #545
[ 111.817796] Hardware name: ARM Juno development board (r2) (DT)
[ 111.823896] Workqueue: usb_hub_wq hub_event
[ 111.828217] pstate: 60000005 (nZCv daif -PAN -UAO)
[ 111.833156] pc : usb_submit_urb+0x3d8/0x590
[ 111.837471] lr : usb_submit_urb+0x3d8/0x590
[ 111.841783] sp : ffff800018de38b0
[ 111.845205] x29: ffff800018de38b0 x28: 0000000000000003
[ 111.850682] x27: ffff000970530b20 x26: ffff8000133fd000
[ 111.856159] x25: ffff8000133fd000 x24: ffff800018de3b38
[ 111.861635] x23: 0000000000000004 x22: 0000000000000c00
[ 111.867112] x21: 0000000000000000 x20: 00000000fffffff0
[ 111.872589] x19: ffff0009704e7a00 x18: ffffffffffffffff
[ 111.878065] x17: 00000000a7c8f4bc x16: 000000002af33de8
[ 111.883542] x15: ffff8000133fda88 x14: 0720072007200720
[ 111.889019] x13: 0720072007200720 x12: 0720072007200720
[ 111.894496] x11: 0000000000000000 x10: 00000000a5286134
[ 111.899973] x9 : 0000000000000002 x8 : ffff000970c837a0
[ 111.905449] x7 : 0000000000000000 x6 : ffff800018de3570
[ 111.910926] x5 : 0000000000000001 x4 : 0000000000000003
[ 111.916401] x3 : 0000000000000000 x2 : ffff800013427118
[ 111.921879] x1 : 9d4e965b4b7d7c00 x0 : 0000000000000000
[ 111.927356] Call trace:
[ 111.929892] usb_submit_urb+0x3d8/0x590
[ 111.933852] hub_activate+0x108/0x7f0
[ 111.937633] hub_resume+0xac/0x148
[ 111.941149] usb_resume_interface.isra.10+0x60/0x138
[ 111.946265] usb_resume_both+0xe4/0x140
[ 111.950225] usb_runtime_resume+0x24/0x30
[ 111.954365] __rpm_callback+0xdc/0x138
[ 111.958236] rpm_callback+0x34/0x98
[ 111.961841] rpm_resume+0x4a8/0x720
[ 111.965445] rpm_resume+0x50c/0x720
[ 111.969049] __pm_runtime_resume+0x4c/0xb8
[ 111.973276] usb_autopm_get_interface+0x28/0x60
[ 111.977948] hub_event+0x80/0x16d8
[ 111.981466] process_one_work+0x2a4/0x748
[ 111.985604] worker_thread+0x48/0x498
[ 111.989387] kthread+0x13c/0x140
[ 111.992725] ret_from_fork+0x10/0x18
[ 111.996415] irq event stamp: 354
[ 111.999756] hardirqs last enabled at (353): [<ffff80001019ea1c>] console_unlock+0x504/0x5b8
[ 112.008441] hardirqs last disabled at (354): [<ffff8000100a95d0>] do_debug_exception+0x1a8/0x258
[ 112.017479] softirqs last enabled at (350): [<ffff8000100818a4>] __do_softirq+0x4bc/0x568
[ 112.025984] softirqs last disabled at (343): [<ffff8000101145a4>] irq_exit+0x144/0x150
[ 112.034129] ---[ end trace dc96030b9cf6c8a3 ]---
The problem was tracked down to a missing call to
pm_runtime_set_active() on resume in ohci-platform.
Link: https://lore.kernel.org/lkml/20200323143857.db5zphxhq4hz3hmd@e107158-lin.cambridge.arm.com/
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Qais Yousef <qais.yousef@arm.com>
CC: Tony Prisk <linux@prisktech.co.nz>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: Mathias Nyman <mathias.nyman@intel.com>
CC: Oliver Neukum <oneukum@suse.de>
CC: linux-arm-kernel@lists.infradead.org
CC: linux-usb@vger.kernel.org
CC: linux-kernel@vger.kernel.org
---
drivers/usb/host/ohci-platform.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index 7addfc2cbadc..4a8456f12a73 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -299,6 +299,11 @@ static int ohci_platform_resume(struct device *dev)
}
ohci_resume(hcd, false);
+
+ pm_runtime_disable(dev);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+
return 0;
}
#endif /* CONFIG_PM_SLEEP */
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 0/4] PCI, iommu: Factor 'untrusted' check for ATS enablement
From: David Woodhouse @ 2020-05-18 15:47 UTC (permalink / raw)
To: Raj, Ashok, Christoph Hellwig
Cc: Jean-Philippe Brucker, linux-pci, joro, alex.williamson, iommu,
bhelgaas, baolu.lu, will, linux-arm-kernel, robin.murphy
In-Reply-To: <20200515171948.GC75440@otc-nc-03>
[-- Attachment #1.1: Type: text/plain, Size: 822 bytes --]
On Fri, 2020-05-15 at 10:19 -0700, Raj, Ashok wrote:
> Hi Christoph
>
> On Fri, May 15, 2020 at 08:43:51AM -0700, Christoph Hellwig wrote:
> > Can you please lift the untrusted flag into struct device? It really
> > isn't a PCI specific concept, and we should not have code poking into
> > pci_dev all over the iommu code.
>
> Just for clarification: All IOMMU's today mostly pertain to only PCI devices
> and for devices that aren't PCI like HPET for instance we give a PCI
> identifier. Facilities like ATS for instance require the platform to have
> an IOMMU.
>
> what additional problems does moving this to struct device solve?
Even the Intel IOMMU supports ACPI devices for which there is no struct
pci_dev; only a B/D/F in the ANDD record indicating which entry in the
context table to use.
[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] iomm/arm-smmu: Add stall implementation hook
From: Will Deacon @ 2020-05-18 15:45 UTC (permalink / raw)
To: Rob Clark, Robin Murphy, Sai Prakash Ranjan, Joerg Roedel,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Linux Kernel Mailing List, linux-arm-msm
In-Reply-To: <20200511173008.GA24282@jcrouse1-lnx.qualcomm.com>
On Mon, May 11, 2020 at 11:30:08AM -0600, Jordan Crouse wrote:
> On Fri, May 08, 2020 at 08:40:40AM -0700, Rob Clark wrote:
> > On Fri, May 8, 2020 at 8:32 AM Rob Clark <robdclark@gmail.com> wrote:
> > >
> > > On Thu, May 7, 2020 at 5:54 AM Will Deacon <will@kernel.org> wrote:
> > > >
> > > > On Thu, May 07, 2020 at 11:55:54AM +0100, Robin Murphy wrote:
> > > > > On 2020-05-07 11:14 am, Sai Prakash Ranjan wrote:
> > > > > > On 2020-04-22 01:50, Sai Prakash Ranjan wrote:
> > > > > > > Add stall implementation hook to enable stalling
> > > > > > > faults on QCOM platforms which supports it without
> > > > > > > causing any kind of hardware mishaps. Without this
> > > > > > > on QCOM platforms, GPU faults can cause unrelated
> > > > > > > GPU memory accesses to return zeroes. This has the
> > > > > > > unfortunate result of command-stream reads from CP
> > > > > > > getting invalid data, causing a cascade of fail.
> > > > >
> > > > > I think this came up before, but something about this rationale doesn't add
> > > > > up - we're not *using* stalls at all, we're still terminating faulting
> > > > > transactions unconditionally; we're just using CFCFG to terminate them with
> > > > > a slight delay, rather than immediately. It's really not clear how or why
> > > > > that makes a difference. Is it a GPU bug? Or an SMMU bug? Is this reliable
> > > > > (or even a documented workaround for something), or might things start
> > > > > blowing up again if any other behaviour subtly changes? I'm not dead set
> > > > > against adding this, but I'd *really* like to have a lot more confidence in
> > > > > it.
> > > >
> > > > Rob mentioned something about the "bus returning zeroes" before, but I agree
> > > > that we need more information so that we can reason about this and maintain
> > > > the code as the driver continues to change. That needs to be a comment in
> > > > the driver, and I don't think "but android seems to work" is a good enough
> > > > justification. There was some interaction with HUPCF as well.
> > >
> > > The issue is that there are multiple parallel memory accesses
> > > happening at the same time, for example CP (the cmdstream processor)
> > > will be reading ahead and setting things up for the next draw or
> > > compute grid, in parallel with some memory accesses from the shader
> > > which could trigger a fault. (And with faults triggered by something
> > > in the shader, there are *many* shader threads running in parallel so
> > > those tend to generate a big number of faults at the same time.)
> > >
> > > We need either CFCFG or HUPCF, otherwise what I have observed is that
> > > while the fault happens, CP's memory access will start returning
> > > zero's instead of valid cmdstream data, which triggers a GPU hang. I
> > > can't say whether this is something unique to qcom's implementation of
> > > the smmu spec or not.
> > >
> > > *Often* a fault is the result of the usermode gl/vk/cl driver bug,
> > > although I don't think that is an argument against fixing this in the
> > > smmu driver.. I've been carrying around a local patch to set HUPCF for
> > > *years* because debugging usermode driver issues is so much harder
> > > without. But there are some APIs where faults can be caused by the
> > > user's app on top of the usermode driver.
> > >
> >
> > Also, I'll add to that, a big wish of mine is to have stall with the
> > ability to resume later from a wq context. That would enable me to
> > hook in the gpu crash dump handling for faults, which would make
> > debugging these sorts of issues much easier. I think I posted a
> > prototype of this quite some time back, which would schedule a worker
> > on the first fault (since there are cases where you see 1000's of
> > faults at once), which grabbed some information about the currently
> > executing submit and some gpu registers to indicate *where* in the
> > submit (a single submit could have 100's or 1000's of draws), and then
> > resumed the iommu cb.
> >
> > (This would ofc eventually be useful for svm type things.. I expect
> > we'll eventually care about that too.)
>
> Rob is right about HUPCF. Due to the parallel nature of the command processor
> there is always a very good chance that a CP access is somewhere in the bus so
> any pagefault is usually a death sentence. The GPU context bank would always
> want HUPCF set to 1.
So this sounds like an erratum to me, and I'm happy to set HUPCF if we
detect the broken implementation. However, it will need an entry in
Documentation/arm64/silicon-errata.rst and a decent comment in the driver
to explain what we're doing and why.
Thanks,
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] i2c: mediatek: Add i2c ac-timing adjust support
From: Geert Uytterhoeven @ 2020-05-18 15:44 UTC (permalink / raw)
To: Qii Wang
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
srv_heupstream, Wolfram Sang, leilk.liu,
Linux Kernel Mailing List, linux-mediatek, Linux I2C, Linux ARM
In-Reply-To: <1589461844-15614-3-git-send-email-qii.wang@mediatek.com>
On Thu, May 14, 2020 at 3:13 PM Qii Wang <qii.wang@mediatek.com> wrote:
> This patch adds a algorithm to calculate some ac-timing parameters
> which can fully meet I2C Spec.
>
> Signed-off-by: Qii Wang <qii.wang@mediatek.com>
> ---
> drivers/i2c/busses/i2c-mt65xx.c | 328 +++++++++++++++++++++++++++++++++-------
> 1 file changed, 277 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
> index 0ca6c38a..7020618 100644
> --- a/drivers/i2c/busses/i2c-mt65xx.c
> +++ b/drivers/i2c/busses/i2c-mt65xx.c
> +/*
> + * Check and Calculate i2c ac-timing
> + *
> + * Hardware design:
> + * sample_ns = (1000000000 * (sample_cnt + 1)) / clk_src
> + * xxx_cnt_div = spec->min_xxx_ns / sample_ns
> + *
> + * Sample_ns is rounded down for xxx_cnt_div would be greater
> + * than the smallest spec.
> + * The sda_timing is chosen as the middle value between
> + * the largest and smallest.
> + */
> +static int mtk_i2c_check_ac_timing(struct mtk_i2c *i2c,
> + unsigned int clk_src,
> + unsigned int check_speed,
> + unsigned int step_cnt,
> + unsigned int sample_cnt)
> +{
> + const struct i2c_spec_values *spec;
> + unsigned int su_sta_cnt, low_cnt, high_cnt, max_step_cnt;
> + unsigned int sda_max, sda_min, clk_ns, max_sta_cnt = 0x3f;
> + long long sample_ns = (1000000000 * (sample_cnt + 1)) / clk_src;
So sample_ns is a 64-bit value. Is that really needed?
> + if (!i2c->dev_comp->timing_adjust)
> + return 0;
> +
> + if (i2c->dev_comp->ltiming_adjust)
> + max_sta_cnt = 0x100;
> +
> + spec = mtk_i2c_get_spec(check_speed);
> +
> + if (i2c->dev_comp->ltiming_adjust)
> + clk_ns = 1000000000 / clk_src;
> + else
> + clk_ns = sample_ns / 2;
> +
> + su_sta_cnt = DIV_ROUND_UP(spec->min_su_sta_ns, clk_ns);
> + if (su_sta_cnt > max_sta_cnt)
> + return -1;
> +
> + low_cnt = DIV_ROUND_UP(spec->min_low_ns, sample_ns);
So this is a 32-bit by 64-bit division (indeed, not 64-by-32!)
noreply@ellerman.id.au reports:
ERROR: modpost: "__udivdi3" [drivers/i2c/busses/i2c-mt65xx.ko] undefined!
ERROR: modpost: "__divdi3" [drivers/i2c/busses/i2c-mt65xx.ko] undefined!
for 32-bit builds.
> + max_step_cnt = mtk_i2c_max_step_cnt(check_speed);
> + if ((2 * step_cnt) > low_cnt && low_cnt < max_step_cnt) {
> + if (low_cnt > step_cnt) {
> + high_cnt = 2 * step_cnt - low_cnt;
> + } else {
> + high_cnt = step_cnt;
> + low_cnt = step_cnt;
> + }
> + } else {
> + return -2;
> + }
> +
> + sda_max = spec->max_hd_dat_ns / sample_ns;
> + if (sda_max > low_cnt)
> + sda_max = 0;
> +
> + sda_min = DIV_ROUND_UP(spec->min_su_dat_ns, sample_ns);
One more.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] usb/ohci-platform: Fix a warning when hibernating
From: Qais Yousef @ 2020-05-18 15:43 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Oliver Neukum, Mathias Nyman, linux-usb, Rafael J . Wysocki,
linux-kernel, Tony Prisk, Alan Stern, linux-arm-kernel
In-Reply-To: <20200518153312.GA1963214@kroah.com>
On 05/18/20 17:33, Greg Kroah-Hartman wrote:
> On Mon, May 18, 2020 at 11:19:40AM -0400, Alan Stern wrote:
> > On Mon, May 18, 2020 at 03:57:49PM +0100, Qais Yousef wrote:
> > > > For both this patch and the 3/3 patch (ehci-platform):
> > > >
> > > > Acked-by: Alan Stern <stern@rowland.harvard.edu>
> > >
> > > Thanks Alan. Did this make it through to any tree? I don't see it on next, nor
> > > on Linus. But it could be queued somewhere else.
> > >
> > > I have sent v2 to patch 2 (xhci) as a reply, so hopefully it wasn't missed.
> > > I can resend the whole series if necessary.
> >
> > Greg, what happened to this series? Did it just fall through the
> > cracks?
>
> No idea, it's not in my to-review queue, so maybe it got merged
> somewhere? If not, can someone resend it please?
Sure, I'll get it out ASAP.
Thanks
--
Qais Yousef
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/6] Clean up Shadow Call Stack patches for 5.8
From: Sami Tolvanen @ 2020-05-18 15:43 UTC (permalink / raw)
To: Will Deacon
Cc: Kees Cook, Jann Horn, Peter Zijlstra, Catalin Marinas, LKML,
Mark Rutland, kernel-team, Ard Biesheuvel, linux-arm-kernel
In-Reply-To: <20200518135228.GI32394@willie-the-truck>
On Mon, May 18, 2020 at 6:52 AM Will Deacon <will@kernel.org> wrote:
>
> On Fri, May 15, 2020 at 01:42:40PM -0700, Sami Tolvanen wrote:
> > On Fri, May 15, 2020 at 10:28 AM Will Deacon <will@kernel.org> wrote:
> > > Will Deacon (6):
> > > arm64: scs: Store absolute SCS stack pointer value in thread_info
> > > scs: Move accounting into alloc/free functions
> > > arm64: scs: Use 'scs_sp' register alias for x18
> > > scs: Move scs_overflow_check() out of architecture code
> > > scs: Remove references to asm/scs.h from core code
> > > scs: Move DEFINE_SCS macro into core code
> > >
> > > arch/Kconfig | 4 +--
> > > arch/arm64/include/asm/scs.h | 29 ++++------------
> > > arch/arm64/include/asm/thread_info.h | 4 +--
> > > arch/arm64/kernel/asm-offsets.c | 2 +-
> > > arch/arm64/kernel/entry.S | 10 +++---
> > > arch/arm64/kernel/head.S | 2 +-
> > > arch/arm64/kernel/process.c | 2 --
> > > arch/arm64/kernel/scs.c | 6 +---
> > > include/linux/scs.h | 16 +++++----
> > > kernel/sched/core.c | 3 ++
> > > kernel/scs.c | 52 +++++++++++++---------------
> > > 11 files changed, 55 insertions(+), 75 deletions(-)
> > >
> > > --
> > > 2.26.2.761.g0e0b3e54be-goog
> >
> > Thanks, Will. I tested these on my SCS tree and didn't run into any
> > issues. Looks good to me.
>
> Cheers, Sami. Can I add your 'Tested-by' to the patches, please?
Sure, please feel free to add Tested-by tags.
Sami
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox