* Re: [PATCH 1/2] KVM: arm/arm64: vgic: Use the appropriate TRACE_INCLUDE_PATH
From: Marc Zyngier @ 2019-09-11 15:37 UTC (permalink / raw)
To: Zenghui Yu
Cc: suzuki.poulose, linux-kernel, Masahiro Yamada, james.morse,
julien.thierry.kdev, wanghaibin.wang, kvmarm, linux-arm-kernel
In-Reply-To: <1568169216-12632-2-git-send-email-yuzenghui@huawei.com>
On Wed, 11 Sep 2019 03:33:35 +0100,
Zenghui Yu <yuzenghui@huawei.com> wrote:
>
> Commit 49dfe94fe5ad ("KVM: arm/arm64: Fix TRACE_INCLUDE_PATH") fixes
> TRACE_INCLUDE_PATH to the correct relative path to the define_trace.h
> and explains why did the old one work.
>
> The same fix should be applied to virt/kvm/arm/vgic/trace.h.
>
> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
> Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Applied to -next with Masahiro's RB.
Thanks,
M.
--
Jazz is not dead, it just smells funny.
_______________________________________________
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] KVM: arm/arm64: Print the EC hex value with its exact width
From: Marc Zyngier @ 2019-09-11 15:35 UTC (permalink / raw)
To: Zenghui Yu
Cc: suzuki.poulose, linux-kernel, james.morse, julien.thierry.kdev,
wanghaibin.wang, kvmarm, linux-arm-kernel
In-Reply-To: <e013e828-5e61-8c07-510f-6cb4c59367cf@huawei.com>
On Wed, 11 Sep 2019 10:19:05 +0100,
Zenghui Yu <yuzenghui@huawei.com> wrote:
>
> Hi Marc,
>
> On 2019/9/11 16:31, Marc Zyngier wrote:
> > On Wed, 11 Sep 2019 03:33:36 +0100,
> > Zenghui Yu <yuzenghui@huawei.com> wrote:
> >>
> >> EC is the bits [31:26] of ESR_ELx on arm64 (HSR on arm). Print the
> >> hex value with its exact width (8).
> >>
> >> Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
> >> ---
> >> virt/kvm/arm/trace.h | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/virt/kvm/arm/trace.h b/virt/kvm/arm/trace.h
> >> index 204d210d01c2..022b0a060034 100644
> >> --- a/virt/kvm/arm/trace.h
> >> +++ b/virt/kvm/arm/trace.h
> >> @@ -42,7 +42,7 @@ TRACE_EVENT(kvm_exit,
> >> __entry->vcpu_pc = vcpu_pc;
> >> ),
> >> - TP_printk("%s: HSR_EC: 0x%04x (%s), PC: 0x%08lx",
> >> + TP_printk("%s: HSR_EC: 0x%02x (%s), PC: 0x%08lx",
> >> __print_symbolic(__entry->ret, kvm_arm_exception_type),
> >> __entry->esr_ec,
> >> __print_symbolic(__entry->esr_ec, kvm_arm_exception_class),
> >
> > Although you're right that 8 bits ought to be enough, this is a change
> > to the output of the tracepoint, which userspace could (does?) parse.
>
> Well-written userspace tools should only parse the low 8 bits (if they
> do parse). But even if the high bits are parsed, they're always 0.
> So I don't think this change will have a bad impact on userspace.
The problem is that we don't only cater for well written SW. We also
support the broken stuff, unfortunately.
Thanks,
M.
--
Jazz is not dead, it just smells funny.
_______________________________________________
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] mm/kasan: dump alloc and free stack for page allocator
From: Qian Cai @ 2019-09-11 15:19 UTC (permalink / raw)
To: Walter Wu
Cc: linux-arm-kernel, wsd_upstream, Arnd Bergmann, linux-mm,
Andrey Konovalov, linux-mediatek, linux-kernel, kasan-dev,
Martin Schwidefsky, Alexander Potapenko, Vlastimil Babka,
Matthias Brugger, Andrey Ryabinin, Andrew Morton, Dmitry Vyukov
In-Reply-To: <20190911083921.4158-1-walter-zh.wu@mediatek.com>
> On Sep 11, 2019, at 4:39 AM, Walter Wu <walter-zh.wu@mediatek.com> wrote:
>
> This patch is KASAN's report adds the alloc/free stack for page allocator
> in order to help programmer to see memory corruption caused by the page.
>
> By default, KASAN doesn't record alloc or free stack for page allocator.
> It is difficult to fix up the page use-after-free or double-free issue.
>
> We add the following changing:
> 1) KASAN enable PAGE_OWNER by default to get the alloc stack of the page.
> 2) Add new feature option to get the free stack of the page.
>
> The new feature KASAN_DUMP_PAGE depends on DEBUG_PAGEALLOC, it will help
> to record free stack of the page, it is very helpful for solving the page
> use-after-free or double-free issue.
>
> When KASAN_DUMP_PAGE is enabled then KASAN's report will show the last
> alloc and free stack of the page, it should be:
>
> BUG: KASAN: use-after-free in kmalloc_pagealloc_uaf+0x70/0x80
> Write of size 1 at addr ffffffc0d60e4000 by task cat/115
> ...
> prep_new_page+0x1c8/0x218
> get_page_from_freelist+0x1ba0/0x28d0
> __alloc_pages_nodemask+0x1d4/0x1978
> kmalloc_order+0x28/0x58
> kmalloc_order_trace+0x28/0xe0
> kmalloc_pagealloc_uaf+0x2c/0x80
> page last free stack trace:
> __free_pages_ok+0x116c/0x1630
> __free_pages+0x50/0x78
> kfree+0x1c4/0x250
> kmalloc_pagealloc_uaf+0x38/0x80
>
> Changes since v1:
> - slim page_owner and move it into kasan
> - enable the feature by default
>
> Changes since v2:
> - enable PAGE_OWNER by default
> - use DEBUG_PAGEALLOC to get page information
>
> cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> cc: Vlastimil Babka <vbabka@suse.cz>
> cc: Andrey Konovalov <andreyknvl@google.com>
> Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> ---
> lib/Kconfig.kasan | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
> index 4fafba1a923b..4d59458c0c5a 100644
> --- a/lib/Kconfig.kasan
> +++ b/lib/Kconfig.kasan
> @@ -41,6 +41,7 @@ config KASAN_GENERIC
> select SLUB_DEBUG if SLUB
> select CONSTRUCTORS
> select STACKDEPOT
> + select PAGER_OWNER
> help
> Enables generic KASAN mode.
> Supported in both GCC and Clang. With GCC it requires version 4.9.2
> @@ -63,6 +64,7 @@ config KASAN_SW_TAGS
> select SLUB_DEBUG if SLUB
> select CONSTRUCTORS
> select STACKDEPOT
> + select PAGER_OWNER
> help
> Enables software tag-based KASAN mode.
> This mode requires Top Byte Ignore support by the CPU and therefore
> @@ -135,6 +137,19 @@ config KASAN_S390_4_LEVEL_PAGING
> to 3TB of RAM with KASan enabled). This options allows to force
> 4-level paging instead.
>
> +config KASAN_DUMP_PAGE
> + bool "Dump the last allocation and freeing stack of the page"
> + depends on KASAN
> + select DEBUG_PAGEALLOC
> + help
> + By default, KASAN enable PAGE_OWNER only to record alloc stack
> + for page allocator. It is difficult to fix up page use-after-free
> + or double-free issue.
> + This feature depends on DEBUG_PAGEALLOC, it will extra record
> + free stack of page. It is very helpful for solving the page
> + use-after-free or double-free issue.
> + This option will have a small memory overhead.
> +
> config TEST_KASAN
> tristate "Module for testing KASAN for bug detection"
> depends on m && KASAN
> —
The new config looks redundant and confusing. It looks to me more of a document update
in Documentation/dev-tools/kasan.txt to educate developers to select PAGE_OWNER and
DEBUG_PAGEALLOC if needed.
_______________________________________________
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: fix function types in COND_SYSCALL
From: Mark Rutland @ 2019-09-11 15:15 UTC (permalink / raw)
To: Sami Tolvanen
Cc: Catalin Marinas, Will Deacon, Kees Cook, linux-arm-kernel,
linux-kernel
In-Reply-To: <20190910224044.100388-1-samitolvanen@google.com>
On Tue, Sep 10, 2019 at 03:40:44PM -0700, Sami Tolvanen wrote:
> Define a weak function in COND_SYSCALL instead of a weak alias to
> sys_ni_syscall, which has an incompatible type. This fixes indirect
> call mismatches with Control-Flow Integrity (CFI) checking.
>
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
This looks correct to me, builds fine, and I asume has been tested, so FWIW:
Acked-by: Mark Rutland <mark.rutland@arm.com>
In looking at this, I came to the conclusion that we can drop the ifdeffery
around our SYSCALL_DEFINE0(), COND_SYSCALL(), and SYS_NI(), which I evidently
cargo-culted from x86 (where the ifdeffery is actually necessary).
I can send a follow up for that.
Thanks,
Mark.
> ---
> arch/arm64/include/asm/syscall_wrapper.h | 15 ++++++++++++---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/include/asm/syscall_wrapper.h b/arch/arm64/include/asm/syscall_wrapper.h
> index 507d0ee6bc69..06d880b3526c 100644
> --- a/arch/arm64/include/asm/syscall_wrapper.h
> +++ b/arch/arm64/include/asm/syscall_wrapper.h
> @@ -8,6 +8,8 @@
> #ifndef __ASM_SYSCALL_WRAPPER_H
> #define __ASM_SYSCALL_WRAPPER_H
>
> +struct pt_regs;
> +
> #define SC_ARM64_REGS_TO_ARGS(x, ...) \
> __MAP(x,__SC_ARGS \
> ,,regs->regs[0],,regs->regs[1],,regs->regs[2] \
> @@ -35,8 +37,11 @@
> ALLOW_ERROR_INJECTION(__arm64_compat_sys_##sname, ERRNO); \
> asmlinkage long __arm64_compat_sys_##sname(const struct pt_regs *__unused)
>
> -#define COND_SYSCALL_COMPAT(name) \
> - cond_syscall(__arm64_compat_sys_##name);
> +#define COND_SYSCALL_COMPAT(name) \
> + asmlinkage long __weak __arm64_compat_sys_##name(const struct pt_regs *regs) \
> + { \
> + return sys_ni_syscall(); \
> + }
>
> #define COMPAT_SYS_NI(name) \
> SYSCALL_ALIAS(__arm64_compat_sys_##name, sys_ni_posix_timers);
> @@ -70,7 +75,11 @@
> #endif
>
> #ifndef COND_SYSCALL
> -#define COND_SYSCALL(name) cond_syscall(__arm64_sys_##name)
> +#define COND_SYSCALL(name) \
> + asmlinkage long __weak __arm64_sys_##name(const struct pt_regs *regs) \
> + { \
> + return sys_ni_syscall(); \
> + }
> #endif
>
> #ifndef SYS_NI
> --
> 2.23.0.162.g0b9fbb3734-goog
>
_______________________________________________
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 v9 0/8] stg mail -e --version=v9 \
From: Alexander Duyck @ 2019-09-11 15:12 UTC (permalink / raw)
To: Michal Hocko
Cc: Yang Zhang, Pankaj Gupta, kvm list, David Hildenbrand,
Catalin Marinas, lcapitulino, linux-mm, Alexander Duyck, will,
Andrea Arcangeli, virtio-dev, Michael S. Tsirkin, Matthew Wilcox,
Wang, Wei W, ying.huang, Rik van Riel, Konrad Rzeszutek Wilk,
Dan Williams, linux-arm-kernel, Oscar Salvador,
Nitesh Narayan Lal, Dave Hansen, LKML, Paolo Bonzini,
Andrew Morton, Fengguang Wu, Kirill A. Shutemov
In-Reply-To: <20190911113619.GP4023@dhcp22.suse.cz>
On Wed, Sep 11, 2019 at 4:36 AM Michal Hocko <mhocko@kernel.org> wrote:
>
> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> [...]
> > We don't put any limitations on the allocator other then that it needs to
> > clean up the metadata on allocation, and that it cannot allocate a page
> > that is in the process of being reported since we pulled it from the
> > free_list. If the page is a "Reported" page then it decrements the
> > reported_pages count for the free_area and makes sure the page doesn't
> > exist in the "Boundary" array pointer value, if it does it moves the
> > "Boundary" since it is pulling the page.
>
> This is still a non-trivial limitation on the page allocation from an
> external code IMHO. I cannot give any explicit reason why an ordering on
> the free list might matter (well except for page shuffling which uses it
> to make physical memory pattern allocation more random) but the
> architecture seems hacky and dubious to be honest. It shoulds like the
> whole interface has been developed around a very particular and single
> purpose optimization.
How is this any different then the code that moves a page that will
likely be merged to the tail though?
In our case the "Reported" page is likely going to be much more
expensive to allocate and use then a standard page because it will be
faulted back in. In such a case wouldn't it make sense for us to want
to keep the pages that don't require faults ahead of those pages in
the free_list so that they are more likely to be allocated? All we are
doing with the boundary list is preventing still resident pages from
being deferred behind pages that would require a page fault to get
access to.
> I remember that there was an attempt to report free memory that provided
> a callback mechanism [1], which was much less intrusive to the internals
> of the allocator yet it should provide a similar functionality. Did you
> see that approach? How does this compares to it? Or am I completely off
> when comparing them?
>
> [1] mostly likely not the latest version of the patchset
> http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com
There have been a few comparisons between this patch set and the ones
from Wei Wang. In regards to the one you are pointing to the main
difference is that I am not permanently locking memory. Basically what
happens is that the iterator will take the lock, pull a few pages,
release the lock while reporting them, and then take the lock to
return those pages, grab some more, and repeat.
I was actually influenced somewhat by the suggestions that patchset
received, specifically I believe it resembles something like what was
suggested by Linus in response to v35 of that patch set:
https://lore.kernel.org/linux-mm/CA+55aFzqj8wxXnHAdUTiOomipgFONVbqKMjL_tfk7e5ar1FziQ@mail.gmail.com/
Basically where the feature Wei Wang was working on differs from this
patch set is that I need this to run continually, his only needed to
run periodically as he was just trying to identify free pages at a
fixed point in time. My goal is to identify pages that have been freed
since the last time I reported them. To do that I need a flag in the
page to identify those pages, and an iterator in the form of a
boundary pointer so that I can incrementally walk through the list
without losing track of freed pages.
_______________________________________________
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/3] USB: host: ohci-at91: tailor power consumption
From: Alan Stern @ 2019-09-11 15:09 UTC (permalink / raw)
To: Nicolas Ferre
Cc: Alexandre Belloni, Boris.Krasnovskiy, gregkh, linux-usb,
linux-kernel, Ludovic Desroches, linux-arm-kernel
In-Reply-To: <20190911064154.28633-1-nicolas.ferre@microchip.com>
On Wed, 11 Sep 2019, Nicolas Ferre wrote:
> Following a set of experiments we found areas of improvement for OHCI power
> consumption (and associated USB analog cells).
> This enhances the shutdown of residual power consumption in case of Linux
> suspend/resume and removal of the driver (when compiled as a module).
>
> Best regards,
> Nicolas
>
> Boris Krasnovskiy (2):
> USB: host: ohci-at91: completely shutdown the controller in
> at91_stop_hc()
> USB: host: ohci-at91: resume: balance the clock start call
>
> Nicolas Ferre (1):
> USB: host: ohci-at91: suspend: delay needed before to stop clocks
>
> drivers/usb/host/ohci-at91.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
For all three patches:
Acked-by: Alan Stern <stern@rowland.harvard.edu>
_______________________________________________
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 v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Andre Przywara @ 2019-09-11 15:03 UTC (permalink / raw)
To: Jassi Brar
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Peng Fan,
f.fainelli@gmail.com, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, dl-linux-imx, sudeep.holla@arm.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CABb+yY2rppSOgqMy+R294d94xwi5UPR55Eo-WB8KA6m11nG3iQ@mail.gmail.com>
On Tue, 10 Sep 2019 21:44:11 -0500
Jassi Brar <jassisinghbrar@gmail.com> wrote:
Hi,
> On Mon, Sep 9, 2019 at 10:42 AM Andre Przywara <andre.przywara@arm.com> wrote:
> >
> > On Wed, 28 Aug 2019 03:02:58 +0000
> > Peng Fan <peng.fan@nxp.com> wrote:
> >
[ ... ]
> >
> > > +
> > > + arm,func-ids:
> > > + description: |
> > > + An array of 32-bit values specifying the function IDs used by each
> > > + mailbox channel. Those function IDs follow the ARM SMC calling
> > > + convention standard [1].
> > > +
> > > + There is one identifier per channel and the number of supported
> > > + channels is determined by the length of this array.
> >
> > I think this makes it obvious that arm,num-chans is not needed.
> >
> > Also this somewhat contradicts the driver implementation, which allows the array to be shorter, marking this as UINT_MAX and later on using the first data item as a function identifier. This is somewhat surprising and not documented (unless I missed something).
> >
> > So I would suggest:
> > - We drop the transports property, and always put the client provided data in the registers, according to the SMCCC. Document this here.
> > A client not needing those could always puts zeros (or garbage) in there, the respective firmware would just ignore the registers.
> > - We drop "arm,num-chans", as this is just redundant with the length of the func-ids array.
> > - We don't impose an arbitrary limit on the number of channels. From the firmware point of view this is just different function IDs, from Linux' point of view just the size of the memory used. Both don't need to be limited artificially IMHO.
> >
> Sounds like we are in sync.
>
> > - We mark arm,func-ids as required, as this needs to be fixed, allocated number.
> >
> I still think func-id can be done without. A client can always pass
> the value as it knows what it expects.
I don't think it's the right abstraction. The mailbox *controller* uses a specific func-id, this has to match the one the firmware expects. So this is a property of the mailbox transport channel (the SMC call), and the *client* should *not* care about it. It just sees the logical channel ID (if we have one), which the controller translates into the func-ID.
So it should really look like this (assuming only single channel controllers):
mailbox: smc-mailbox {
#mbox-cells = <0>;
compatible = "arm,smc-mbox";
method = "smc";
arm,func-id = <0x820000fe>;
};
scmi {
compatible = "arm,scmi";
mboxes = <&smc_mbox>;
mbox-names = "tx"; /* rx is optional */
shmem = <&cpu_scp_hpri>;
};
If you allow the client to provide the function ID (and I am not saying this is a good idea): where would this func ID come from? It would need to be a property of the client DT node, then. So one way would be to use the func ID as the Linux mailbox channel ID:
mailbox: smc-mailbox {
#mbox-cells = <1>;
compatible = "arm,smc-mbox";
method = "smc";
};
scmi {
compatible = "arm,scmi";
mboxes = <&smc_mbox 0x820000fe>;
mbox-names = "tx"; /* rx is optional */
shmem = <&cpu_scp_hpri>;
};
But this doesn't look desirable.
And as I mentioned this before: allowing some mailbox clients to provide the function IDs sound scary, as they could use anything they want, triggering random firmware actions (think PSCI_CPU_OFF).
So I think we should have a required "arm,func-id" property, with exactly one 32-bit value (again assuming single channel controllers).
Cheers,
Andre.
_______________________________________________
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 v5 3/4] arm64: use both ZONE_DMA and ZONE_DMA32
From: Nicolas Saenz Julienne @ 2019-09-11 15:00 UTC (permalink / raw)
To: Catalin Marinas
Cc: f.fainelli, mbrugger, marc.zyngier, robin.murphy, linux-kernel,
linux-mm, robh+dt, wahrenst, m.szyprowski, linux-riscv, phill,
Will Deacon, hch, linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <20190911143527.GB43864@C02TF0J2HF1T.local>
[-- Attachment #1.1: Type: text/plain, Size: 2154 bytes --]
On Wed, 2019-09-11 at 15:35 +0100, Catalin Marinas wrote:
> On Wed, Sep 11, 2019 at 12:54:38PM +0200, Nicolas Saenz Julienne wrote:
> > On Mon, 2019-09-09 at 11:58 +0200, Nicolas Saenz Julienne wrote:
> > > /*
> > > - * Return the maximum physical address for ZONE_DMA32 (DMA_BIT_MASK(32)).
> > > It
> > > - * currently assumes that for memory starting above 4G, 32-bit devices
> > > will
> > > - * use a DMA offset.
> > > + * Return the maximum physical address for a zone with a given address
> > > size
> > > + * limit. It currently assumes that for memory starting above 4G, 32-bit
> > > + * devices will use a DMA offset.
> > > */
> > > -static phys_addr_t __init max_zone_dma32_phys(void)
> > > +static phys_addr_t __init max_zone_phys(unsigned int zone_bits)
> > > {
> > > phys_addr_t offset = memblock_start_of_DRAM() & GENMASK_ULL(63,
> > > 32);
> > > - return min(offset + (1ULL << 32), memblock_end_of_DRAM());
> > > + return min(offset + (1ULL << zone_bits), memblock_end_of_DRAM());
> > > }
> >
> > while testing other code on top of this series on odd arm64 machines I found
> > an
> > issue: when memblock_start_of_DRAM() != 0, max_zone_phys() isn't taking into
> > account the offset to the beginning of memory. This doesn't matter with
> > zone_bits == 32 but it does when zone_bits == 30.
>
> I thought about this but I confused myself and the only case I had in
> mind was an AMD Seattle system with RAM starting at 4GB.
I found the issue on a Cavium ThunderX2 server. Oddly enough the memory starts
at 0x802f0000.
> What we need from this function is that the lowest naturally aligned
> 2^30 RAM is covered by ZONE_DMA while the rest to 2^32 are ZONE_DMA32.
> This assumed that devices only capable of 30-bit (or 32-bit), have the
> top address bits hardwired to be able access the bottom of the memory
> (and this would be expressed in DT as the DMA offset).
Ok, I was testing a fix I wrote under these assumptions...
> I guess the fix here is to use GENMASK_ULL(63, zone_bits).
...but this is way cleaner than my solution. Thanks!
Regards,
Nicolas
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 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
* [PATCH 2/2] ARM: omap2plus_defconfig: Update for moved item
From: Adam Ford @ 2019-09-11 14:52 UTC (permalink / raw)
To: linux-omap
Cc: Tony Lindgren, adam.ford, Russell King, linux-kernel, Adam Ford,
linux-arm-kernel
In-Reply-To: <20190911145226.21088-1-aford173@gmail.com>
When running make savedefconfig ARCH=arm, CONFIG_DMA_CMA
changed location. To help facilitate future changes to
omap2plus_defconfig, this patch re-syncs the omap2plus file
with the updated location generated by make savedefconfig.
No items were removed or added during this patch.
Signed-off-by: Adam Ford <aford173@gmail.com>
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 166b36be2ca6..a0449d3b48a5 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -128,7 +128,6 @@ CONFIG_PCI_ENDPOINT_CONFIGFS=y
CONFIG_PCI_EPF_TEST=m
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
-CONFIG_DMA_CMA=y
CONFIG_OMAP_OCP2SCP=y
CONFIG_CONNECTOR=m
CONFIG_MTD=y
@@ -537,6 +536,7 @@ CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=y
CONFIG_CRC7=y
CONFIG_LIBCRC32C=y
+CONFIG_DMA_CMA=y
CONFIG_FONTS=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
--
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
* [PATCH 1/2] ARM: omap2plus_defconfig: Update for removed items
From: Adam Ford @ 2019-09-11 14:52 UTC (permalink / raw)
To: linux-omap
Cc: Tony Lindgren, adam.ford, Russell King, linux-kernel, Adam Ford,
linux-arm-kernel
The omap panel-dpi driver was removed in
Commit 8bf4b1621178 ("drm/omap: Remove panel-dpi driver")
The tFP410 and DVI connector was remove in
Commit be3143d8b27f ("drm/omap: Remove TFP410 and DVI connector drivers")
This patch removes these items from the omap2plus_defconfig.
Signed-off-by: Adam Ford <aford173@gmail.com>
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index c7bf9c493646..166b36be2ca6 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -349,12 +349,9 @@ CONFIG_OMAP5_DSS_HDMI=y
CONFIG_OMAP2_DSS_SDI=y
CONFIG_OMAP2_DSS_DSI=y
CONFIG_DRM_OMAP_ENCODER_OPA362=m
-CONFIG_DRM_OMAP_ENCODER_TFP410=m
CONFIG_DRM_OMAP_ENCODER_TPD12S015=m
-CONFIG_DRM_OMAP_CONNECTOR_DVI=m
CONFIG_DRM_OMAP_CONNECTOR_HDMI=m
CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV=m
-CONFIG_DRM_OMAP_PANEL_DPI=m
CONFIG_DRM_OMAP_PANEL_DSI_CM=m
CONFIG_DRM_OMAP_PANEL_SONY_ACX565AKM=m
CONFIG_DRM_OMAP_PANEL_LGPHILIPS_LB035Q02=m
--
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
* [PATCH 4/4] dmaengine: imx-sdma: drop redundant variable
From: Philipp Puschmann @ 2019-09-11 14:49 UTC (permalink / raw)
To: linux-kernel
Cc: linux-serial, shawnguo, s.hauer, jslaby, vkoul, linux-imx, kernel,
gregkh, dmaengine, dan.j.williams, festevam, Philipp Puschmann,
linux-arm-kernel
In-Reply-To: <20190911144943.21554-1-philipp.puschmann@emlix.com>
In sdma_prep_dma_cyclic buf is redundant. Drop it.
Signed-off-by: Philipp Puschmann <philipp.puschmann@emlix.com>
---
drivers/dma/imx-sdma.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 6a5a84504858..5b6beeee9f0e 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1544,7 +1544,7 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
struct sdma_engine *sdma = sdmac->sdma;
int num_periods = buf_len / period_len;
int channel = sdmac->channel;
- int i = 0, buf = 0;
+ int i;
struct sdma_desc *desc;
dev_dbg(sdma->dev, "%s channel: %d\n", __func__, channel);
@@ -1565,7 +1565,7 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
goto err_bd_out;
}
- while (buf < buf_len) {
+ for (i = 0; i < num_periods; i++) {
struct sdma_buffer_descriptor *bd = &desc->bd[i];
int param;
@@ -1592,9 +1592,6 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
bd->mode.status = param;
dma_addr += period_len;
- buf += period_len;
-
- i++;
}
return vchan_tx_prep(&sdmac->vc, &desc->vd, flags);
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/4] Fix UART DMA freezes for iMX6
From: Philipp Puschmann @ 2019-09-11 14:49 UTC (permalink / raw)
To: linux-kernel
Cc: linux-serial, shawnguo, s.hauer, jslaby, vkoul, linux-imx, kernel,
gregkh, dmaengine, dan.j.williams, festevam, Philipp Puschmann,
linux-arm-kernel
For some years and since many kernel versions there are reports that
RX UART DMA channel stops working at one point. So far the usual workaround was
to disable RX DMA. This patches try to fix the underlying problem.
When a running sdma script does not find any usable destination buffer to put
its data into it just leads to stopping the channel being scheduled again. As
solution we we manually retrigger the sdma script for this channel and by this
dissolve the freeze.
While this seems to work fine so far a further patch in this series increases
the number of RX DMA periods for UART to reduce use cases running into such
a situation.
This patch series was tested with the current kernel and backported to
kernel 4.15 with a special use case using a WL1837MOD via UART and provoking
the hanging of UART RX DMA within seconds after starting a test application.
It resulted in well known
"Bluetooth: hci0: command 0x0408 tx timeout"
errors and complete stop of UART data reception. Our Bluetooth traffic consists
of many independent small packets, mostly only a few bytes, causing high usage
of periods.
Philipp Puschmann (4):
dmaengine: imx-sdma: fix buffer ownership
dmaengine: imx-sdma: fix dma freezes
serial: imx: adapt rx buffer and dma periods
dmaengine: imx-sdma: drop redundant variable
drivers/dma/imx-sdma.c | 32 ++++++++++++++++++++++----------
drivers/tty/serial/imx.c | 5 ++---
2 files changed, 24 insertions(+), 13 deletions(-)
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/4] serial: imx: adapt rx buffer and dma periods
From: Philipp Puschmann @ 2019-09-11 14:49 UTC (permalink / raw)
To: linux-kernel
Cc: linux-serial, shawnguo, s.hauer, jslaby, vkoul, linux-imx, kernel,
gregkh, dmaengine, dan.j.williams, festevam, Philipp Puschmann,
linux-arm-kernel
In-Reply-To: <20190911144943.21554-1-philipp.puschmann@emlix.com>
Using only 4 DMA periods for UART RX is very few if we have a high
frequency of small transfers - like in our case using Bluetooth with many
small packets via UART - causing many dma transfers but in each only
filling a fraction of a single buffer. Such a case may lead to the
situation that DMA RX transfer is triggered but no buffer is available.
While we have addressed the dma handling already we still want to avoid
UART RX FIFO overrun. So we decrease the size of the buffers and increase
their number and the total buffer size.
Signed-off-by: Philipp Puschmann <philipp.puschmann@emlix.com>
---
drivers/tty/serial/imx.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 57d6e6ba556e..cdc51569237c 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1028,8 +1028,6 @@ static void imx_uart_timeout(struct timer_list *t)
}
}
-#define RX_BUF_SIZE (PAGE_SIZE)
-
/*
* There are two kinds of RX DMA interrupts(such as in the MX6Q):
* [1] the RX DMA buffer is full.
@@ -1112,7 +1110,8 @@ static void imx_uart_dma_rx_callback(void *data)
}
/* RX DMA buffer periods */
-#define RX_DMA_PERIODS 4
+#define RX_DMA_PERIODS 16
+#define RX_BUF_SIZE (PAGE_SIZE / 4)
static int imx_uart_start_rx_dma(struct imx_port *sport)
{
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/4] dmaengine: imx-sdma: fix dma freezes
From: Philipp Puschmann @ 2019-09-11 14:49 UTC (permalink / raw)
To: linux-kernel
Cc: linux-serial, shawnguo, s.hauer, jslaby, vkoul, linux-imx, kernel,
gregkh, dmaengine, dan.j.williams, festevam, Philipp Puschmann,
linux-arm-kernel
In-Reply-To: <20190911144943.21554-1-philipp.puschmann@emlix.com>
For some years and since many kernel versions there are reports that the
RX UART SDMA channel stops working at some point. The workaround was to
disable DMA for RX. This commit tries to fix the problem itself.
Due to its license i wasn't able to debug the sdma script itself but it
somehow leads to blocking the scheduling of the channel script when a
running sdma script does not find any usable destination buffer to put its
data into.
If we detect such a potential case we manually retrigger the sdma script
for this channel and by this reenable the scipt being run by scheduler.
As sdmac->desc is constant we can move desc out of the loop.
Signed-off-by: Philipp Puschmann <philipp.puschmann@emlix.com>
---
drivers/dma/imx-sdma.c | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 1abb14ff394d..6a5a84504858 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -775,21 +775,23 @@ static void sdma_start_desc(struct sdma_channel *sdmac)
static void sdma_update_channel_loop(struct sdma_channel *sdmac)
{
struct sdma_buffer_descriptor *bd;
- int error = 0;
- enum dma_status old_status = sdmac->status;
+ struct sdma_desc *desc = sdmac->desc;
+ int error = 0, cnt = 0;
+ enum dma_status old_status = sdmac->status;
/*
* loop mode. Iterate over descriptors, re-setup them and
* call callback function.
*/
- while (sdmac->desc) {
- struct sdma_desc *desc = sdmac->desc;
+ while (desc) {
bd = &desc->bd[desc->buf_tail];
if (bd->mode.status & BD_DONE)
break;
+ cnt++;
+
if (bd->mode.status & BD_RROR) {
bd->mode.status &= ~BD_RROR;
sdmac->status = DMA_ERROR;
@@ -821,6 +823,18 @@ static void sdma_update_channel_loop(struct sdma_channel *sdmac)
if (error)
sdmac->status = old_status;
}
+
+ /* In some situations it happens that the sdma stops serving
+ * dma interrupt requests. It happens when running dma script
+ * does not find any usable destination buffer to put its data into.
+ *
+ * While there is no specific error condition we can check for, a
+ * necessary condition is that all available buffers for the current
+ * channel have been written to by the sdma script. In such a case we
+ * will trigger the sdma script manually.
+ */
+ if (cnt >= desc->num_bd)
+ sdma_enable_channel(sdmac->sdma, sdmac->channel);
}
static void mxc_sdma_handle_channel_normal(struct sdma_channel *data)
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/4] dmaengine: imx-sdma: fix buffer ownership
From: Philipp Puschmann @ 2019-09-11 14:49 UTC (permalink / raw)
To: linux-kernel
Cc: linux-serial, shawnguo, s.hauer, jslaby, vkoul, linux-imx, kernel,
gregkh, dmaengine, dan.j.williams, festevam, Philipp Puschmann,
linux-arm-kernel
In-Reply-To: <20190911144943.21554-1-philipp.puschmann@emlix.com>
BD_DONE flag marks ownership of the buffer. When 1 SDMA owns the buffer,
when 0 ARM owns it. When processing the buffers in
sdma_update_channel_loop the ownership of the currently processed buffer
was set to SDMA again before running the callback function of the the
buffer and while the sdma script may be running in parallel. So there was
the possibility to get the buffer overwritten by SDMA before it has been
processed by kernel leading to kind of random errors in the upper layers,
e.g. bluetooth.
It may be further a good idea to make the status struct member volatile or
access it using writel or similar to rule out that the compiler sets the
BD_DONE flag before the callback routine has finished.
Signed-off-by: Philipp Puschmann <philipp.puschmann@emlix.com>
---
drivers/dma/imx-sdma.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index a01f4b5d793c..1abb14ff394d 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -802,7 +802,6 @@ static void sdma_update_channel_loop(struct sdma_channel *sdmac)
*/
desc->chn_real_count = bd->mode.count;
- bd->mode.status |= BD_DONE;
bd->mode.count = desc->period_len;
desc->buf_ptail = desc->buf_tail;
desc->buf_tail = (desc->buf_tail + 1) % desc->num_bd;
@@ -817,6 +816,8 @@ static void sdma_update_channel_loop(struct sdma_channel *sdmac)
dmaengine_desc_get_callback_invoke(&desc->vd.tx, NULL);
spin_lock(&sdmac->vc.lock);
+ bd->mode.status |= BD_DONE;
+
if (error)
sdmac->status = old_status;
}
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/3] iommu/io-pgtable-arm: Allow coherent walks for Mali
From: Robin Murphy @ 2019-09-11 14:42 UTC (permalink / raw)
To: will, joro
Cc: robh, tomeu.vizoso, narmstrong, steven.price, iommu,
linux-arm-kernel
In-Reply-To: <cover.1568211045.git.robin.murphy@arm.com>
Midgard GPUs have ACE-Lite master interfaces which allows systems to
integrate them in an I/O-coherent manner. It seems that from the GPU's
viewpoint, the rest of the system is its outer shareable domain, and it
will only emit snoop signals for outer shareable accesses. As such,
setting the TTBR_SHARE_OUTER bit does indeed get coherent pagetable
walks working nicely.
Making data accesses coherent seems to be more of a challenge...
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/io-pgtable-arm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 77f41c9dd9be..2794d4661339 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -1061,6 +1061,9 @@ arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie)
cfg->arm_mali_lpae_cfg.transtab = virt_to_phys(data->pgd) |
ARM_MALI_LPAE_TTBR_READ_INNER |
ARM_MALI_LPAE_TTBR_ADRMODE_TABLE;
+ if (cfg->coherent_walk)
+ cfg->arm_mali_lpae_cfg.transtab |= ARM_MALI_LPAE_TTBR_SHARE_OUTER;
+
return &data->iop;
out_free_data:
--
2.21.0.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/3] iommu/io-pgtable-arm: Support more Mali configurations
From: Robin Murphy @ 2019-09-11 14:42 UTC (permalink / raw)
To: will, joro
Cc: robh, tomeu.vizoso, narmstrong, steven.price, iommu,
linux-arm-kernel
In-Reply-To: <cover.1568211045.git.robin.murphy@arm.com>
In principle, Midgard GPUs supporting smaller VA sizes should only
require 3-level pagetables, since the address bits resolved at level 0
(47:40) will never change. However, the kbase driver does not appear to
have any notion of a variable start level, and empirically T720 and T820
rapidly blow up with translation faults unless given a full 4-level
table, despite only supporting a 33-bit VA size.
The 'real' IAS value is still valuable in terms of validating addresses
on map/unmap, so tweak the allocator to allow smaller values while still
forcing the resultant tables to the full 4 levels.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/io-pgtable-arm.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 9e35cd991f06..77f41c9dd9be 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -1022,7 +1022,7 @@ arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie)
if (cfg->quirks)
return NULL;
- if (cfg->ias != 48 || cfg->oas > 40)
+ if (cfg->ias > 48 || cfg->oas > 40)
return NULL;
cfg->pgsize_bitmap &= (SZ_4K | SZ_2M | SZ_1G);
@@ -1031,6 +1031,11 @@ arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie)
if (!data)
return NULL;
+ /* Mali seems to need a full 4-level table regardless of IAS */
+ if (data->levels < ARM_LPAE_MAX_LEVELS) {
+ data->levels = ARM_LPAE_MAX_LEVELS;
+ data->pgd_size = sizeof(arm_lpae_iopte);
+ }
/*
* MEMATTR: Mali has no actual notion of a non-cacheable type, so the
* best we can do is mimic the out-of-tree driver and hope that the
--
2.21.0.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/3] iommu/io-pgtable-arm: Correct Mali attributes
From: Robin Murphy @ 2019-09-11 14:42 UTC (permalink / raw)
To: will, joro
Cc: robh, tomeu.vizoso, narmstrong, steven.price, iommu,
linux-arm-kernel
In-Reply-To: <cover.1568211045.git.robin.murphy@arm.com>
Whilst Midgard's MEMATTR follows a similar principle to the VMSA MAIR,
the actual attribute values differ, so although it currently appears to
work to some degree, we probably shouldn't be using our standard stage 1
MAIR for that. Instead, generate a reasonable MEMATTR with attribute
values borrowed from the kbase driver; at this point we'll be overriding
or ignoring pretty much all of the LPAE config, so just implement these
Mali details in a dedicated allocator instead of pretending to subclass
the standard VMSA format.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/io-pgtable-arm.c | 53 +++++++++++++++++++++++++---------
1 file changed, 40 insertions(+), 13 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 161a7d56264d..9e35cd991f06 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -167,6 +167,9 @@
#define ARM_MALI_LPAE_TTBR_READ_INNER BIT(2)
#define ARM_MALI_LPAE_TTBR_SHARE_OUTER BIT(4)
+#define ARM_MALI_LPAE_MEMATTR_IMP_DEF 0x88ULL
+#define ARM_MALI_LPAE_MEMATTR_WRITE_ALLOC 0x8DULL
+
/* IOPTE accessors */
#define iopte_deref(pte,d) __va(iopte_to_paddr(pte, d))
@@ -1013,27 +1016,51 @@ arm_32_lpae_alloc_pgtable_s2(struct io_pgtable_cfg *cfg, void *cookie)
static struct io_pgtable *
arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie)
{
- struct io_pgtable *iop;
+ struct arm_lpae_io_pgtable *data;
+
+ /* No quirks for Mali (hopefully) */
+ if (cfg->quirks)
+ return NULL;
if (cfg->ias != 48 || cfg->oas > 40)
return NULL;
cfg->pgsize_bitmap &= (SZ_4K | SZ_2M | SZ_1G);
- iop = arm_64_lpae_alloc_pgtable_s1(cfg, cookie);
- if (iop) {
- u64 mair, ttbr;
- /* Copy values as union fields overlap */
- mair = cfg->arm_lpae_s1_cfg.mair[0];
- ttbr = cfg->arm_lpae_s1_cfg.ttbr[0];
+ data = arm_lpae_alloc_pgtable(cfg);
+ if (!data)
+ return NULL;
- cfg->arm_mali_lpae_cfg.memattr = mair;
- cfg->arm_mali_lpae_cfg.transtab = ttbr |
- ARM_MALI_LPAE_TTBR_READ_INNER |
- ARM_MALI_LPAE_TTBR_ADRMODE_TABLE;
- }
+ /*
+ * MEMATTR: Mali has no actual notion of a non-cacheable type, so the
+ * best we can do is mimic the out-of-tree driver and hope that the
+ * "implementation-defined caching policy" is good enough. Similarly,
+ * we'll use it for the sake of a valid attribute for our 'device'
+ * index, although callers should never request that in practice.
+ */
+ cfg->arm_mali_lpae_cfg.memattr =
+ (ARM_MALI_LPAE_MEMATTR_IMP_DEF
+ << ARM_LPAE_MAIR_ATTR_SHIFT(ARM_LPAE_MAIR_ATTR_IDX_NC)) |
+ (ARM_MALI_LPAE_MEMATTR_WRITE_ALLOC
+ << ARM_LPAE_MAIR_ATTR_SHIFT(ARM_LPAE_MAIR_ATTR_IDX_CACHE)) |
+ (ARM_MALI_LPAE_MEMATTR_IMP_DEF
+ << ARM_LPAE_MAIR_ATTR_SHIFT(ARM_LPAE_MAIR_ATTR_IDX_DEV));
- return iop;
+ data->pgd = __arm_lpae_alloc_pages(data->pgd_size, GFP_KERNEL, cfg);
+ if (!data->pgd)
+ goto out_free_data;
+
+ /* Ensure the empty pgd is visible before TRANSTAB can be written */
+ wmb();
+
+ cfg->arm_mali_lpae_cfg.transtab = virt_to_phys(data->pgd) |
+ ARM_MALI_LPAE_TTBR_READ_INNER |
+ ARM_MALI_LPAE_TTBR_ADRMODE_TABLE;
+ return &data->iop;
+
+out_free_data:
+ kfree(data);
+ return NULL;
}
struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s1_init_fns = {
--
2.21.0.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/3] iommu/io-pgtable-arm: Mali LPAE improvements
From: Robin Murphy @ 2019-09-11 14:42 UTC (permalink / raw)
To: will, joro
Cc: robh, tomeu.vizoso, narmstrong, steven.price, iommu,
linux-arm-kernel
Hi all,
Here's the eagerly-awaited fix to unblock T720/T820, plus a couple of
other bits that I've collected so far. I'm not considering this as
5.3 fixes material, but it would be nice if there's any chance still
to sneak it into 5.4.
Robin.
Robin Murphy (3):
iommu/io-pgtable-arm: Correct Mali attributes
iommu/io-pgtable-arm: Support more Mali configurations
iommu/io-pgtable-arm: Allow coherent walks for Mali
drivers/iommu/io-pgtable-arm.c | 61 ++++++++++++++++++++++++++--------
1 file changed, 48 insertions(+), 13 deletions(-)
--
2.21.0.dirty
_______________________________________________
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 v5 3/4] arm64: use both ZONE_DMA and ZONE_DMA32
From: Catalin Marinas @ 2019-09-11 14:35 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: f.fainelli, mbrugger, marc.zyngier, robin.murphy, linux-kernel,
linux-mm, robh+dt, wahrenst, m.szyprowski, linux-riscv, phill,
Will Deacon, hch, linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <b0b824bebb9ef13ce746f9914de83126b0386e23.camel@suse.de>
On Wed, Sep 11, 2019 at 12:54:38PM +0200, Nicolas Saenz Julienne wrote:
> On Mon, 2019-09-09 at 11:58 +0200, Nicolas Saenz Julienne wrote:
> > /*
> > - * Return the maximum physical address for ZONE_DMA32 (DMA_BIT_MASK(32)). It
> > - * currently assumes that for memory starting above 4G, 32-bit devices will
> > - * use a DMA offset.
> > + * Return the maximum physical address for a zone with a given address size
> > + * limit. It currently assumes that for memory starting above 4G, 32-bit
> > + * devices will use a DMA offset.
> > */
> > -static phys_addr_t __init max_zone_dma32_phys(void)
> > +static phys_addr_t __init max_zone_phys(unsigned int zone_bits)
> > {
> > phys_addr_t offset = memblock_start_of_DRAM() & GENMASK_ULL(63, 32);
> > - return min(offset + (1ULL << 32), memblock_end_of_DRAM());
> > + return min(offset + (1ULL << zone_bits), memblock_end_of_DRAM());
> > }
>
> while testing other code on top of this series on odd arm64 machines I found an
> issue: when memblock_start_of_DRAM() != 0, max_zone_phys() isn't taking into
> account the offset to the beginning of memory. This doesn't matter with
> zone_bits == 32 but it does when zone_bits == 30.
I thought about this but I confused myself and the only case I had in
mind was an AMD Seattle system with RAM starting at 4GB.
What we need from this function is that the lowest naturally aligned
2^30 RAM is covered by ZONE_DMA while the rest to 2^32 are ZONE_DMA32.
This assumed that devices only capable of 30-bit (or 32-bit), have the
top address bits hardwired to be able access the bottom of the memory
(and this would be expressed in DT as the DMA offset).
I guess the fix here is to use GENMASK_ULL(63, zone_bits).
--
Catalin
_______________________________________________
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] ARM: module: Drop 'rel->r_offset < 0' statement
From: Austin Kim @ 2019-09-11 14:15 UTC (permalink / raw)
To: linux, allison, info, matthias.schiffer
Cc: austindh.kim, linux-kernel, linux-arm-kernel
Since rel->r_offset is declared as Elf32_Addr,
this value is always non-negative.
typedef struct elf32_rel {
Elf32_Addr r_offset;
Elf32_Word r_info;
} Elf32_Rel;
typedef __u32 Elf32_Addr;
typedef unsigned int __u32;
Drop 'rel->r_offset < 0' statement which is always false.
Also change %u to %d in pr_err() for rel->r_offset.
Signed-off-by: Austin Kim <austindh.kim@gmail.com>
---
arch/arm/kernel/module.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index deef17f34..f805bcbda 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -92,8 +92,8 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex,
sym = ((Elf32_Sym *)symsec->sh_addr) + offset;
symname = strtab + sym->st_name;
- if (rel->r_offset < 0 || rel->r_offset > dstsec->sh_size - sizeof(u32)) {
- pr_err("%s: section %u reloc %u sym '%s': out of bounds relocation, offset %d size %u\n",
+ if (rel->r_offset > dstsec->sh_size - sizeof(u32)) {
+ pr_err("%s: section %u reloc %u sym '%s': out of bounds relocation, offset %u size %u\n",
module->name, relindex, i, symname,
rel->r_offset, dstsec->sh_size);
return -ENOEXEC;
--
2.11.0
_______________________________________________
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 v9 0/8] stg mail -e --version=v9 \
From: Nitesh Narayan Lal @ 2019-09-11 14:03 UTC (permalink / raw)
To: Michal Hocko, David Hildenbrand
Cc: Yang Zhang, Pankaj Gupta, kvm list, Michael S. Tsirkin,
Catalin Marinas, Alexander Duyck, lcapitulino, linux-mm,
Alexander Duyck, will, Andrea Arcangeli, virtio-dev, Rik van Riel,
Matthew Wilcox, Wang, Wei W, ying.huang, Konrad Rzeszutek Wilk,
Dan Williams, linux-arm-kernel, Oscar Salvador, Dave Hansen, LKML,
Paolo Bonzini, Andrew Morton, Fengguang Wu, Kirill A. Shutemov
In-Reply-To: <20190911132002.GA4023@dhcp22.suse.cz>
On 9/11/19 9:20 AM, Michal Hocko wrote:
> On Wed 11-09-19 15:03:39, David Hildenbrand wrote:
>> On 11.09.19 14:54, Michal Hocko wrote:
>>> On Wed 11-09-19 14:42:41, David Hildenbrand wrote:
>>>> On 11.09.19 14:25, Michal Hocko wrote:
>>>>> On Wed 11-09-19 14:19:41, Michal Hocko wrote:
>>>>>> On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
>>>>>>> On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
>>>>>>>> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
>>>>>>>> [...]
>>>>>>>>> We don't put any limitations on the allocator other then that it needs to
>>>>>>>>> clean up the metadata on allocation, and that it cannot allocate a page
>>>>>>>>> that is in the process of being reported since we pulled it from the
>>>>>>>>> free_list. If the page is a "Reported" page then it decrements the
>>>>>>>>> reported_pages count for the free_area and makes sure the page doesn't
>>>>>>>>> exist in the "Boundary" array pointer value, if it does it moves the
>>>>>>>>> "Boundary" since it is pulling the page.
>>>>>>>> This is still a non-trivial limitation on the page allocation from an
>>>>>>>> external code IMHO. I cannot give any explicit reason why an ordering on
>>>>>>>> the free list might matter (well except for page shuffling which uses it
>>>>>>>> to make physical memory pattern allocation more random) but the
>>>>>>>> architecture seems hacky and dubious to be honest. It shoulds like the
>>>>>>>> whole interface has been developed around a very particular and single
>>>>>>>> purpose optimization.
>>>>>>>>
>>>>>>>> I remember that there was an attempt to report free memory that provided
>>>>>>>> a callback mechanism [1], which was much less intrusive to the internals
>>>>>>>> of the allocator yet it should provide a similar functionality. Did you
>>>>>>>> see that approach? How does this compares to it? Or am I completely off
>>>>>>>> when comparing them?
>>>>>>>>
>>>>>>>> [1] mostly likely not the latest version of the patchset
>>>>>>>> http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com
>>>>>>> Linus nacked that one. He thinks invoking callbacks with lots of
>>>>>>> internal mm locks is too fragile.
>>>>>> I would be really curious how much he would be happy about injecting
>>>>>> other restrictions on the allocator like this patch proposes. This is
>>>>>> more intrusive as it has a higher maintenance cost longterm IMHO.
>>>>> Btw. I do agree that callbacks with internal mm locks are not great
>>>>> either. We do have a model for that in mmu_notifiers and it is something
>>>>> I do consider PITA, on the other hand it is mostly sleepable part of the
>>>>> interface which makes it the real pain. The above callback mechanism was
>>>>> explicitly documented with restrictions and that the context is
>>>>> essentially atomic with no access to particular struct pages and no
>>>>> expensive operations possible. So in the end I've considered it
>>>>> acceptably painful. Not that I want to override Linus' nack but if
>>>>> virtualization usecases really require some form of reporting and no
>>>>> other way to do that push people to invent even more interesting
>>>>> approaches then we should simply give them/you something reasonable
>>>>> and least intrusive to our internals.
>>>>>
>>>> The issue with "[PATCH v14 4/5] mm: support reporting free page blocks"
>>>> is that it cannot really handle the use case we have here if I am not
>>>> wrong. While a page is getting processed by the hypervisor (e.g.
>>>> MADV_DONTNEED), it must not get reused.
>>> What prevents to use the callback to get a list of pfn ranges to work on
>>> and then use something like start_isolate_page_range on the collected
>>> pfn ranges to make sure nobody steals pages from under your feet, do
>>> your thing and drop the isolated state afterwards.
>>>
>>> I am saying somethig like because you wouldn't really want a generic
>>> has_unmovable_pages but rather
>>> if (!page_ref_count(page)) {
>>> if (PageBuddy(page))
>>> iter += (1 << page_order(page)) - 1;
>>> continue;
>>> }
>>> subset of it.
>>>
>> Something slightly similar is being performed by Nitesh's patch set. On
>> every free of a certain granularity, he records it in the bitmap. These
>> bits are "hints of free pages".
>>
>> A thread then walks over the bitmap and tries to allocate the "hints".
>> If the pages were already reused, the bit is silently cleared.
>>
>> Instead of allocating/freeing, we could only try to isolate the
>> pageblock, then test if free. (One of the usual issues to work around is
>> MAX_ORDER-1 crossing pageblocks, that might need special care)
> OK, cool that I have reinvented the wheel ;). Allocation is indeed not
> necessary as long as pages are isolated because nobody will allocate
> them.
>
>> I think you should have a look at the rough idea of Nitesh's patch set
>> to see if something like that is going into a better direction. The
>> bitmap part is in place to do bulk reporting and avoid duplicate reports.
> Let's see how much time I can find for that in my endless inbox whack a mole.
>
>> I think main points we want (and what I am missing from callback idea
>> being discussed) are
>> 1. Do bulk reporting only when a certain threshold is reached
> Is a time based approach too coarse?
I haven't looked into it yet. One situation which I would definitely
want to avoid is to unnecessary invoke bitmap scans when there are not
sufficient free pages available in the zone.
I can take a look at it if required.
>
>> 2. Report only bigger granularities (especially, avoid THP splits in the
>> hypervisor - >= 2MB proofed to be effective)
> the callback has supported order based scan in some of its iteration.
>
>> 3. Avoid reporting what has just been reported.
> Is the overhead of checking a pfn range in a bitmask that much of an
> overhead to really care?
In most of the cases No. Similar to Alexander I was also running will-it-scale/
page_fault1 to analyze the performance impact of the patch series and haven't
noticed any significant degradation.
In some specific cases, we may see noticeable degradation due to the scanning
overhead.
>
>> 4. Continuously report, not the "one time report everything" approach.
> So you mean the allocator reporting this rather than an external code to
> poll right? I do not know, how much this is nice to have than must have?
Not sure if I understood the question completely.
But yes in my case any workload which is allocating and freeing pages will end
up initiating reporting requests based on the number of free pages in the zone.
--
Thanks
Nitesh
_______________________________________________
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 v9 0/8] stg mail -e --version=v9 \
From: Michal Hocko @ 2019-09-11 13:51 UTC (permalink / raw)
To: David Hildenbrand
Cc: Yang Zhang, Pankaj Gupta, kvm list, Michael S. Tsirkin,
Catalin Marinas, Alexander Duyck, lcapitulino, linux-mm,
Alexander Duyck, will, Andrea Arcangeli, virtio-dev, Rik van Riel,
Matthew Wilcox, Wang, Wei W, ying.huang, Konrad Rzeszutek Wilk,
Dan Williams, linux-arm-kernel, Oscar Salvador,
Nitesh Narayan Lal, Dave Hansen, LKML, Paolo Bonzini,
Andrew Morton, Fengguang Wu, Kirill A. Shutemov
In-Reply-To: <20190911132002.GA4023@dhcp22.suse.cz>
On Wed 11-09-19 15:20:02, Michal Hocko wrote:
[...]
> > 4. Continuously report, not the "one time report everything" approach.
>
> So you mean the allocator reporting this rather than an external code to
> poll right? I do not know, how much this is nice to have than must have?
Another idea that I haven't really thought through so it might turned
out to be completely bogus but let's try anyway. Your "report everything"
just made me look and realize that free_pages_prepare already performs
stuff that actually does something similar yet unrelated.
We do report to special page poisoning, zeroying or
CONFIG_DEBUG_PAGEALLOC to unmap the address from the kernel address
space. This sounds like something fitting your model no?
--
Michal Hocko
SUSE Labs
_______________________________________________
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 4/4] gpio: devres: Switch to EXPORT_SYMBOL_GPL()
From: Linus Walleij @ 2019-09-11 13:48 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:GPIO SUBSYSTEM, linux-kernel@vger.kernel.org,
Bartosz Golaszewski, Rob Herring, Frank Rowand, Linux ARM
In-Reply-To: <20190906084539.21838-5-geert+renesas@glider.be>
On Fri, Sep 6, 2019 at 9:45 AM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> Change all exported symbols for managed GPIO functions from
> EXPORT_SYMBOL() to EXPORT_SYMBOL_GPL(), like is used for their
> non-managed counterparts.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Patch applied.
Yours,
Linus Walleij
_______________________________________________
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 3/4] gpio: of: Switch to EXPORT_SYMBOL_GPL()
From: Linus Walleij @ 2019-09-11 13:47 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:GPIO SUBSYSTEM, linux-kernel@vger.kernel.org,
Bartosz Golaszewski, Rob Herring, Frank Rowand, Linux ARM
In-Reply-To: <20190906084539.21838-4-geert+renesas@glider.be>
On Fri, Sep 6, 2019 at 9:45 AM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> All exported functions provide genuine Linux-specific functionality.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Patch applied.
Yours,
Linus Walleij
_______________________________________________
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