* Re: [PATCH v8 1/5] mm: untag user pointers in mmap/munmap/mremap/brk
From: Andrey Konovalov @ 2019-08-19 15:45 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-arch, open list:DOCUMENTATION, Dave Hansen, Szabolcs Nagy,
Kevin Brodsky, Will Deacon, Linux Memory Management List,
Andrew Morton, Vincenzo Frascino, Dave P Martin, Linux ARM
In-Reply-To: <20190815154403.16473-2-catalin.marinas@arm.com>
On Thu, Aug 15, 2019 at 5:44 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> There isn't a good reason to differentiate between the user address
> space layout modification syscalls and the other memory
> permission/attributes ones (e.g. mprotect, madvise) w.r.t. the tagged
> address ABI. Untag the user addresses on entry to these functions.
>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Andrey Konovalov <andreyknvl@google.com>
> ---
> mm/mmap.c | 5 +++++
> mm/mremap.c | 6 +-----
> 2 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 7e8c3e8ae75f..b766b633b7ae 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -201,6 +201,8 @@ SYSCALL_DEFINE1(brk, unsigned long, brk)
> bool downgraded = false;
> LIST_HEAD(uf);
>
> + brk = untagged_addr(brk);
> +
> if (down_write_killable(&mm->mmap_sem))
> return -EINTR;
>
> @@ -1573,6 +1575,8 @@ unsigned long ksys_mmap_pgoff(unsigned long addr, unsigned long len,
> struct file *file = NULL;
> unsigned long retval;
>
> + addr = untagged_addr(addr);
> +
> if (!(flags & MAP_ANONYMOUS)) {
> audit_mmap_fd(fd, flags);
> file = fget(fd);
> @@ -2874,6 +2878,7 @@ EXPORT_SYMBOL(vm_munmap);
>
> SYSCALL_DEFINE2(munmap, unsigned long, addr, size_t, len)
> {
> + addr = untagged_addr(addr);
> profile_munmap(addr);
> return __vm_munmap(addr, len, true);
> }
> diff --git a/mm/mremap.c b/mm/mremap.c
> index 64c9a3b8be0a..1fc8a29fbe3f 100644
> --- a/mm/mremap.c
> +++ b/mm/mremap.c
> @@ -606,12 +606,8 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len,
> LIST_HEAD(uf_unmap_early);
> LIST_HEAD(uf_unmap);
>
> - /*
> - * Architectures may interpret the tag passed to mmap as a background
> - * colour for the corresponding vma. For mremap we don't allow tagged
> - * new_addr to preserve similar behaviour to mmap.
> - */
> addr = untagged_addr(addr);
> + new_addr = untagged_addr(new_addr);
>
> if (flags & ~(MREMAP_FIXED | MREMAP_MAYMOVE))
> return ret;
_______________________________________________
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 v8 2/5] arm64: Tighten the PR_{SET,GET}_TAGGED_ADDR_CTRL prctl() unused arguments
From: Andrey Konovalov @ 2019-08-19 15:46 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-arch, open list:DOCUMENTATION, Dave Hansen, Szabolcs Nagy,
Kevin Brodsky, Will Deacon, Linux Memory Management List,
Andrew Morton, Vincenzo Frascino, Dave P Martin, Linux ARM
In-Reply-To: <20190815154403.16473-3-catalin.marinas@arm.com>
On Thu, Aug 15, 2019 at 5:44 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> Require that arg{3,4,5} of the PR_{SET,GET}_TAGGED_ADDR_CTRL prctl and
> arg2 of the PR_GET_TAGGED_ADDR_CTRL prctl() are zero rather than ignored
> for future extensions.
>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Andrey Konovalov <andreyknvl@google.com>
> ---
> kernel/sys.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/kernel/sys.c b/kernel/sys.c
> index c6c4d5358bd3..ec48396b4943 100644
> --- a/kernel/sys.c
> +++ b/kernel/sys.c
> @@ -2499,9 +2499,13 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
> error = PAC_RESET_KEYS(me, arg2);
> break;
> case PR_SET_TAGGED_ADDR_CTRL:
> + if (arg3 || arg4 || arg5)
> + return -EINVAL;
> error = SET_TAGGED_ADDR_CTRL(arg2);
> break;
> case PR_GET_TAGGED_ADDR_CTRL:
> + if (arg2 || arg3 || arg4 || arg5)
> + return -EINVAL;
> error = GET_TAGGED_ADDR_CTRL();
> break;
> default:
_______________________________________________
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 v8 3/5] arm64: Change the tagged_addr sysctl control semantics to only prevent the opt-in
From: Andrey Konovalov @ 2019-08-19 15:47 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-arch, open list:DOCUMENTATION, Dave Hansen, Szabolcs Nagy,
Kevin Brodsky, Will Deacon, Linux Memory Management List,
Andrew Morton, Vincenzo Frascino, Dave P Martin, Linux ARM
In-Reply-To: <20190815154403.16473-4-catalin.marinas@arm.com>
On Thu, Aug 15, 2019 at 5:44 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> First rename the sysctl control to abi.tagged_addr_disabled and make it
> default off (zero). When abi.tagged_addr_disabled == 1, only block the
> enabling of the TBI ABI via prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE).
> Getting the status of the ABI or disabling it is still allowed.
>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Andrey Konovalov <andreyknvl@google.com>
> ---
> arch/arm64/kernel/process.c | 17 ++++++++++-------
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index 76b7c55026aa..03689c0beb34 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -579,17 +579,22 @@ void arch_setup_new_exec(void)
> /*
> * Control the relaxed ABI allowing tagged user addresses into the kernel.
> */
> -static unsigned int tagged_addr_prctl_allowed = 1;
> +static unsigned int tagged_addr_disabled;
>
> long set_tagged_addr_ctrl(unsigned long arg)
> {
> - if (!tagged_addr_prctl_allowed)
> - return -EINVAL;
> if (is_compat_task())
> return -EINVAL;
> if (arg & ~PR_TAGGED_ADDR_ENABLE)
> return -EINVAL;
>
> + /*
> + * Do not allow the enabling of the tagged address ABI if globally
> + * disabled via sysctl abi.tagged_addr_disabled.
> + */
> + if (arg & PR_TAGGED_ADDR_ENABLE && tagged_addr_disabled)
> + return -EINVAL;
> +
> update_thread_flag(TIF_TAGGED_ADDR, arg & PR_TAGGED_ADDR_ENABLE);
>
> return 0;
> @@ -597,8 +602,6 @@ long set_tagged_addr_ctrl(unsigned long arg)
>
> long get_tagged_addr_ctrl(void)
> {
> - if (!tagged_addr_prctl_allowed)
> - return -EINVAL;
> if (is_compat_task())
> return -EINVAL;
>
> @@ -618,9 +621,9 @@ static int one = 1;
>
> static struct ctl_table tagged_addr_sysctl_table[] = {
> {
> - .procname = "tagged_addr",
> + .procname = "tagged_addr_disabled",
> .mode = 0644,
> - .data = &tagged_addr_prctl_allowed,
> + .data = &tagged_addr_disabled,
> .maxlen = sizeof(int),
> .proc_handler = proc_dointvec_minmax,
> .extra1 = &zero,
_______________________________________________
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 v8 5/5] arm64: Relax Documentation/arm64/tagged-pointers.rst
From: Andrey Konovalov @ 2019-08-19 15:48 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-arch, open list:DOCUMENTATION, Dave Hansen, Szabolcs Nagy,
Kevin Brodsky, Will Deacon, Linux Memory Management List,
Andrew Morton, Vincenzo Frascino, Dave P Martin, Linux ARM
In-Reply-To: <20190815154403.16473-6-catalin.marinas@arm.com>
On Thu, Aug 15, 2019 at 5:44 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> From: Vincenzo Frascino <vincenzo.frascino@arm.com>
>
> On AArch64 the TCR_EL1.TBI0 bit is set by default, allowing userspace
> (EL0) to perform memory accesses through 64-bit pointers with a non-zero
> top byte. However, such pointers were not allowed at the user-kernel
> syscall ABI boundary.
>
> With the Tagged Address ABI patchset, it is now possible to pass tagged
> pointers to the syscalls. Relax the requirements described in
> tagged-pointers.rst to be compliant with the behaviours guaranteed by
> the AArch64 Tagged Address ABI.
>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Andrey Konovalov <andreyknvl@google.com>
> Cc: Szabolcs Nagy <szabolcs.nagy@arm.com>
> Cc: Kevin Brodsky <kevin.brodsky@arm.com>
> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
> Co-developed-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Andrey Konovalov <andreyknvl@google.com>
> ---
> Documentation/arm64/tagged-pointers.rst | 23 ++++++++++++++++-------
> 1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/arm64/tagged-pointers.rst b/Documentation/arm64/tagged-pointers.rst
> index 2acdec3ebbeb..fd5306019e91 100644
> --- a/Documentation/arm64/tagged-pointers.rst
> +++ b/Documentation/arm64/tagged-pointers.rst
> @@ -20,7 +20,9 @@ Passing tagged addresses to the kernel
> --------------------------------------
>
> All interpretation of userspace memory addresses by the kernel assumes
> -an address tag of 0x00.
> +an address tag of 0x00, unless the application enables the AArch64
> +Tagged Address ABI explicitly
> +(Documentation/arm64/tagged-address-abi.rst).
>
> This includes, but is not limited to, addresses found in:
>
> @@ -33,13 +35,15 @@ This includes, but is not limited to, addresses found in:
> - the frame pointer (x29) and frame records, e.g. when interpreting
> them to generate a backtrace or call graph.
>
> -Using non-zero address tags in any of these locations may result in an
> -error code being returned, a (fatal) signal being raised, or other modes
> -of failure.
> +Using non-zero address tags in any of these locations when the
> +userspace application did not enable the AArch64 Tagged Address ABI may
> +result in an error code being returned, a (fatal) signal being raised,
> +or other modes of failure.
>
> -For these reasons, passing non-zero address tags to the kernel via
> -system calls is forbidden, and using a non-zero address tag for sp is
> -strongly discouraged.
> +For these reasons, when the AArch64 Tagged Address ABI is disabled,
> +passing non-zero address tags to the kernel via system calls is
> +forbidden, and using a non-zero address tag for sp is strongly
> +discouraged.
>
> Programs maintaining a frame pointer and frame records that use non-zero
> address tags may suffer impaired or inaccurate debug and profiling
> @@ -59,6 +63,11 @@ be preserved.
> The architecture prevents the use of a tagged PC, so the upper byte will
> be set to a sign-extension of bit 55 on exception return.
>
> +This behaviour is maintained when the AArch64 Tagged Address ABI is
> +enabled. In addition, with the exceptions above, the kernel will
> +preserve any non-zero tags passed by the user via syscalls and stored in
> +kernel data structures (e.g. set_robust_list(), sigaltstack()).
> +
>
> Other considerations
> --------------------
_______________________________________________
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 02/14] arm64, hibernate: create_safe_exec_page cleanup
From: Mark Rutland @ 2019-08-19 15:50 UTC (permalink / raw)
To: Pavel Tatashin
Cc: sashal, vladimir.murzin, corbet, marc.zyngier, catalin.marinas,
bhsharma, kexec, linux-kernel, jmorris, linux-mm, james.morse,
ebiederm, matthias.bgg, will, linux-arm-kernel
In-Reply-To: <20190817024629.26611-3-pasha.tatashin@soleen.com>
On Fri, Aug 16, 2019 at 10:46:17PM -0400, Pavel Tatashin wrote:
> create_safe_exec_page() is going to be split into two parts in preparation
> of moving page table handling code out of hibernate.c
>
> Remove allocator parameter, and rename dst to page. Also, remove the
> goto's, as we can return directly without cleanups.
It would be nice if you could do the goto/allocator/rename changes as
separate patches, since it's vastly easier to verify each change in
isolation that way.
What's the point of the rename? It's inconsistent with the phys_dst_addr
that you leave as-is, so I'm not sure that's worthwhile.
>
> Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
> ---
> arch/arm64/kernel/hibernate.c | 60 +++++++++++++++--------------------
> 1 file changed, 26 insertions(+), 34 deletions(-)
>
> diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
> index 9341fcc6e809..96b6f8da7e49 100644
> --- a/arch/arm64/kernel/hibernate.c
> +++ b/arch/arm64/kernel/hibernate.c
> @@ -196,57 +196,51 @@ EXPORT_SYMBOL(arch_hibernation_header_restore);
> */
> static int create_safe_exec_page(void *src_start, size_t length,
> unsigned long dst_addr,
> - phys_addr_t *phys_dst_addr,
> - void *(*allocator)(gfp_t mask),
> - gfp_t mask)
> + phys_addr_t *phys_dst_addr)
> {
> - int rc = 0;
> + void *page = (void *)get_safe_page(GFP_ATOMIC);
> + pgd_t *trans_table;
The addition of this trans_table variable wasn't mentioned in the commit
message...
> + trans_table = (void *)get_safe_page(GFP_ATOMIC);
> + if (!trans_table)
> + return -ENOMEM;
>
> - pgdp = pgd_offset_raw(allocator(mask), dst_addr);
> + pgdp = pgd_offset_raw(trans_table, dst_addr);
> - write_sysreg(phys_to_ttbr(virt_to_phys(pgdp)), ttbr0_el1);
> + write_sysreg(phys_to_ttbr(virt_to_phys(trans_table)), ttbr0_el1);
... and I guess you're trying to ensure that we program the TTBR with
the correct base address, without the offset of whatever pgd entry we
happen to have plumbed in?
I think that's a fix, and should come before any other cleanup or
rework.
If you can respin that specific change with s/trans_table/pgdir/, that
would make sense to me.
Thanks,
Mark.
_______________________________________________
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 v8 4/5] arm64: Define Documentation/arm64/tagged-address-abi.rst
From: Andrey Konovalov @ 2019-08-19 15:50 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-arch, open list:DOCUMENTATION, Dave Hansen, Szabolcs Nagy,
Kevin Brodsky, Will Deacon, Linux Memory Management List,
Andrew Morton, Vincenzo Frascino, Dave P Martin, Linux ARM
In-Reply-To: <20190815154403.16473-5-catalin.marinas@arm.com>
On Thu, Aug 15, 2019 at 5:44 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> From: Vincenzo Frascino <vincenzo.frascino@arm.com>
>
> On AArch64 the TCR_EL1.TBI0 bit is set by default, allowing userspace
> (EL0) to perform memory accesses through 64-bit pointers with a non-zero
> top byte. Introduce the document describing the relaxation of the
> syscall ABI that allows userspace to pass certain tagged pointers to
> kernel syscalls.
>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Andrey Konovalov <andreyknvl@google.com>
> Cc: Szabolcs Nagy <szabolcs.nagy@arm.com>
> Cc: Kevin Brodsky <kevin.brodsky@arm.com>
> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
> Co-developed-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Andrey Konovalov <andreyknvl@google.com>
> ---
> Documentation/arm64/tagged-address-abi.rst | 155 +++++++++++++++++++++
> 1 file changed, 155 insertions(+)
> create mode 100644 Documentation/arm64/tagged-address-abi.rst
>
> diff --git a/Documentation/arm64/tagged-address-abi.rst b/Documentation/arm64/tagged-address-abi.rst
> new file mode 100644
> index 000000000000..8808337775d6
> --- /dev/null
> +++ b/Documentation/arm64/tagged-address-abi.rst
> @@ -0,0 +1,155 @@
> +==========================
> +AArch64 TAGGED ADDRESS ABI
> +==========================
> +
> +Authors: Vincenzo Frascino <vincenzo.frascino@arm.com>
> + Catalin Marinas <catalin.marinas@arm.com>
> +
> +Date: 15 August 2019
> +
> +This document describes the usage and semantics of the Tagged Address
> +ABI on AArch64 Linux.
> +
> +1. Introduction
> +---------------
> +
> +On AArch64 the TCR_EL1.TBI0 bit is set by default, allowing userspace
> +(EL0) to perform memory accesses through 64-bit pointers with a non-zero
> +top byte. This document describes the relaxation of the syscall ABI that
> +allows userspace to pass certain tagged pointers to kernel syscalls.
> +
> +2. AArch64 Tagged Address ABI
> +-----------------------------
> +
> +From the kernel syscall interface perspective and for the purposes of
> +this document, a "valid tagged pointer" is a pointer with a potentially
> +non-zero top-byte that references an address in the user process address
> +space obtained in one of the following ways:
> +
> +- mmap() done by the process itself (or its parent), where either:
> +
> + - flags have the **MAP_ANONYMOUS** bit set
> + - the file descriptor refers to a regular file (including those
> + returned by memfd_create()) or **/dev/zero**
> +
> +- brk() system call done by the process itself (i.e. the heap area
> + between the initial location of the program break at process creation
> + and its current location).
> +
> +- any memory mapped by the kernel in the address space of the process
> + during creation and with the same restrictions as for mmap() above
> + (e.g. data, bss, stack).
> +
> +The AArch64 Tagged Address ABI has two stages of relaxation depending
> +how the user addresses are used by the kernel:
> +
> +1. User addresses not accessed by the kernel but used for address space
> + management (e.g. mmap(), mprotect(), madvise()). The use of valid
> + tagged pointers in this context is always allowed.
> +
> +2. User addresses accessed by the kernel (e.g. write()). This ABI
> + relaxation is disabled by default and the application thread needs to
> + explicitly enable it via **prctl()** as follows:
> +
> + - **PR_SET_TAGGED_ADDR_CTRL**: enable or disable the AArch64 Tagged
> + Address ABI for the calling thread.
> +
> + The (unsigned int) arg2 argument is a bit mask describing the
> + control mode used:
> +
> + - **PR_TAGGED_ADDR_ENABLE**: enable AArch64 Tagged Address ABI.
> + Default status is disabled.
> +
> + Arguments arg3, arg4, and arg5 must be 0.
> +
> + - **PR_GET_TAGGED_ADDR_CTRL**: get the status of the AArch64 Tagged
> + Address ABI for the calling thread.
> +
> + Arguments arg2, arg3, arg4, and arg5 must be 0.
> +
> + The ABI properties described above are thread-scoped, inherited on
> + clone() and fork() and cleared on exec().
> +
> + Calling prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0)
> + returns -EINVAL if the AArch64 Tagged Address ABI is globally disabled
> + by sysctl abi.tagged_addr_disabled=1. The default sysctl
> + abi.tagged_addr_disabled configuration is 0.
> +
> +When the AArch64 Tagged Address ABI is enabled for a thread, the
> +following behaviours are guaranteed:
> +
> +- All syscalls except the cases mentioned in section 3 can accept any
> + valid tagged pointer.
> +
> +- The syscall behaviour is undefined for invalid tagged pointers: it may
> + result in an error code being returned, a (fatal) signal being raised,
> + or other modes of failure.
> +
> +- A valid tagged pointer has the same semantics as the corresponding
> + untagged pointer.
> +
> +A definition of the meaning of tagged pointers on AArch64 can be found
> +in Documentation/arm64/tagged-pointers.rst.
> +
> +3. AArch64 Tagged Address ABI Exceptions
> +-----------------------------------------
> +
> +The following system call parameters must be untagged regardless of the
> +ABI relaxation:
> +
> +- prctl() other than arguments pointing to user structures to be
> + accessed by the kernel.
> +
> +- ioctl() other than arguments pointing to user structures to be
> + accessed by the kernel.
> +
> +- shmat() and shmdt().
> +
> +Any attempt to use non-zero tagged pointers may result in an error code
> +being returned, a (fatal) signal being raised, or other modes of
> +failure.
> +
> +4. Example of correct usage
> +---------------------------
> +.. code-block:: c
> +
> + #include <stdlib.h>
> + #include <string.h>
> + #include <unistd.h>
> + #include <sys/mman.h>
> + #include <sys/prctl.h>
> +
> + #define PR_SET_TAGGED_ADDR_CTRL 55
> + #define PR_TAGGED_ADDR_ENABLE (1UL << 0)
> +
> + #define TAG_SHIFT 56
> +
> + int main(void)
> + {
> + int tbi_enabled = 0;
> + unsigned long tag = 0;
> + char *ptr;
> +
> + /* check/enable the tagged address ABI */
> + if (!prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0))
> + tbi_enabled = 1;
> +
> + /* memory allocation */
> + ptr = mmap(NULL, sysconf(_SC_PAGE_SIZE), PROT_READ | PROT_WRITE,
> + MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
> + if (ptr == MAP_FAILED)
> + return 1;
> +
> + /* set a non-zero tag if the ABI is available */
> + if (tbi_enabled)
> + tag = rand() & 0xff;
> + ptr = (char *)((unsigned long)ptr | (tag << TAG_SHIFT));
> +
> + /* memory access to a tagged address */
> + strcpy(ptr, "tagged pointer\n");
> +
> + /* syscall with a tagged pointer */
> + write(1, ptr, strlen(ptr));
> +
> + return 0;
> + }
_______________________________________________
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 00/17] Arm SMMU refactoring
From: Will Deacon @ 2019-08-19 15:56 UTC (permalink / raw)
To: Robin Murphy
Cc: robdclark, joro, bjorn.andersson, iommu, vivek.gautam, jcrouse,
gregory.clement, linux-arm-kernel
In-Reply-To: <cover.1565892337.git.robin.murphy@arm.com>
On Thu, Aug 15, 2019 at 07:37:20PM +0100, Robin Murphy wrote:
> v1 for context: https://patchwork.kernel.org/cover/11087347/
>
> Here's a quick v2 attempting to address all the minor comments; I've
> tweaked a whole bunch of names, added some verbosity in macros and
> comments for clarity, and rejigged arm_smmu_impl_init() for a bit more
> structure. The (new) patches #1 and #2 are up front as conceptual fixes,
> although they're not actually critical - it turns out to be more of an
> embarrassment than a real problem in practice.
Thanks, I'll pick this up and send to Joerg later this week.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: s3c64xx: squash samsung_usb_phy.h into setup-usb-phy.c
From: Masahiro Yamada @ 2019-08-19 15:56 UTC (permalink / raw)
To: Kukjin Kim, Krzysztof Kozlowski, linux-arm-kernel,
linux-samsung-soc
Cc: Masahiro Yamada, linux-usb, Russell King, linux-kernel,
Greg Kroah-Hartman
This is only used by arch/arm/mach-s3c64xx/setup-usb-phy.c
$ git grep samsung_usb_phy_type
include/linux/usb/samsung_usb_phy.h:enum samsung_usb_phy_type {
$ git grep USB_PHY_TYPE_DEVICE
arch/arm/mach-s3c64xx/setup-usb-phy.c: if (type == USB_PHY_TYPE_DEVICE)
arch/arm/mach-s3c64xx/setup-usb-phy.c: if (type == USB_PHY_TYPE_DEVICE)
include/linux/usb/samsung_usb_phy.h: USB_PHY_TYPE_DEVICE,
$ git grep USB_PHY_TYPE_HOST
include/linux/usb/samsung_usb_phy.h: USB_PHY_TYPE_HOST,
Actually, 'enum samsung_usb_phy_type' is unused; the 'type' parameter
has 'int' type. Anyway, there is no need to declare this enum in the
globally visible header. Squash the header.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
arch/arm/mach-s3c64xx/setup-usb-phy.c | 5 +++++
arch/arm/plat-samsung/include/plat/usb-phy.h | 2 --
include/linux/usb/samsung_usb_phy.h | 17 -----------------
3 files changed, 5 insertions(+), 19 deletions(-)
delete mode 100644 include/linux/usb/samsung_usb_phy.h
diff --git a/arch/arm/mach-s3c64xx/setup-usb-phy.c b/arch/arm/mach-s3c64xx/setup-usb-phy.c
index 46a9e955607f..6aaaa1d8e8b9 100644
--- a/arch/arm/mach-s3c64xx/setup-usb-phy.c
+++ b/arch/arm/mach-s3c64xx/setup-usb-phy.c
@@ -15,6 +15,11 @@
#include "regs-sys.h"
#include "regs-usb-hsotg-phy.h"
+enum samsung_usb_phy_type {
+ USB_PHY_TYPE_DEVICE,
+ USB_PHY_TYPE_HOST,
+};
+
static int s3c_usb_otgphy_init(struct platform_device *pdev)
{
struct clk *xusbxti;
diff --git a/arch/arm/plat-samsung/include/plat/usb-phy.h b/arch/arm/plat-samsung/include/plat/usb-phy.h
index 6d0c788beb9d..94da89ecbd3b 100644
--- a/arch/arm/plat-samsung/include/plat/usb-phy.h
+++ b/arch/arm/plat-samsung/include/plat/usb-phy.h
@@ -7,8 +7,6 @@
#ifndef __PLAT_SAMSUNG_USB_PHY_H
#define __PLAT_SAMSUNG_USB_PHY_H __FILE__
-#include <linux/usb/samsung_usb_phy.h>
-
extern int s5p_usb_phy_init(struct platform_device *pdev, int type);
extern int s5p_usb_phy_exit(struct platform_device *pdev, int type);
diff --git a/include/linux/usb/samsung_usb_phy.h b/include/linux/usb/samsung_usb_phy.h
deleted file mode 100644
index dc0071741695..000000000000
--- a/include/linux/usb/samsung_usb_phy.h
+++ /dev/null
@@ -1,17 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2012 Samsung Electronics Co.Ltd
- * http://www.samsung.com/
- *
- * Defines phy types for samsung usb phy controllers - HOST or DEIVCE.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- */
-
-enum samsung_usb_phy_type {
- USB_PHY_TYPE_DEVICE,
- USB_PHY_TYPE_HOST,
-};
--
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 v2 03/14] arm64, hibernate: add trans_table public functions
From: Mark Rutland @ 2019-08-19 15:58 UTC (permalink / raw)
To: Pavel Tatashin
Cc: sashal, vladimir.murzin, corbet, marc.zyngier, catalin.marinas,
bhsharma, kexec, linux-kernel, jmorris, linux-mm, james.morse,
ebiederm, matthias.bgg, will, linux-arm-kernel
In-Reply-To: <20190817024629.26611-4-pasha.tatashin@soleen.com>
On Fri, Aug 16, 2019 at 10:46:18PM -0400, Pavel Tatashin wrote:
> trans_table_create_copy() and trans_table_map_page() are going to be
> the basis for public interface of new subsystem that handles page
> tables for cases which are between kernels: kexec, and hibernate.
While the architecture uses the term 'translation table', in the kernel
we generally use 'pgdir' or 'pgd' to refer to the tables, so please keep
to that naming scheme.
For example, in arch/arm64/mm/mmu.c we have a somewhat analagous
function called create_pgd_mapping() -- could we use that here, to crate
the mapping?
Thanks,
Mark.
>
> Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
> ---
> arch/arm64/kernel/hibernate.c | 96 ++++++++++++++++++++++-------------
> 1 file changed, 61 insertions(+), 35 deletions(-)
>
> diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
> index 96b6f8da7e49..449d69b5651c 100644
> --- a/arch/arm64/kernel/hibernate.c
> +++ b/arch/arm64/kernel/hibernate.c
> @@ -182,39 +182,15 @@ int arch_hibernation_header_restore(void *addr)
> }
> EXPORT_SYMBOL(arch_hibernation_header_restore);
>
> -/*
> - * Copies length bytes, starting at src_start into an new page,
> - * perform cache maintentance, then maps it at the specified address low
> - * address as executable.
> - *
> - * This is used by hibernate to copy the code it needs to execute when
> - * overwriting the kernel text. This function generates a new set of page
> - * tables, which it loads into ttbr0.
> - *
> - * Length is provided as we probably only want 4K of data, even on a 64K
> - * page system.
> - */
> -static int create_safe_exec_page(void *src_start, size_t length,
> - unsigned long dst_addr,
> - phys_addr_t *phys_dst_addr)
> +int trans_table_map_page(pgd_t *trans_table, void *page,
> + unsigned long dst_addr,
> + pgprot_t pgprot)
> {
> - void *page = (void *)get_safe_page(GFP_ATOMIC);
> - pgd_t *trans_table;
> pgd_t *pgdp;
> pud_t *pudp;
> pmd_t *pmdp;
> pte_t *ptep;
>
> - if (!page)
> - return -ENOMEM;
> -
> - memcpy((void *)page, src_start, length);
> - __flush_icache_range((unsigned long)page, (unsigned long)page + length);
> -
> - trans_table = (void *)get_safe_page(GFP_ATOMIC);
> - if (!trans_table)
> - return -ENOMEM;
> -
> pgdp = pgd_offset_raw(trans_table, dst_addr);
> if (pgd_none(READ_ONCE(*pgdp))) {
> pudp = (void *)get_safe_page(GFP_ATOMIC);
> @@ -242,6 +218,44 @@ static int create_safe_exec_page(void *src_start, size_t length,
> ptep = pte_offset_kernel(pmdp, dst_addr);
> set_pte(ptep, pfn_pte(virt_to_pfn(page), PAGE_KERNEL_EXEC));
>
> + return 0;
> +}
> +
> +/*
> + * Copies length bytes, starting at src_start into an new page,
> + * perform cache maintentance, then maps it at the specified address low
> + * address as executable.
> + *
> + * This is used by hibernate to copy the code it needs to execute when
> + * overwriting the kernel text. This function generates a new set of page
> + * tables, which it loads into ttbr0.
> + *
> + * Length is provided as we probably only want 4K of data, even on a 64K
> + * page system.
> + */
> +static int create_safe_exec_page(void *src_start, size_t length,
> + unsigned long dst_addr,
> + phys_addr_t *phys_dst_addr)
> +{
> + void *page = (void *)get_safe_page(GFP_ATOMIC);
> + pgd_t *trans_table;
> + int rc;
> +
> + if (!page)
> + return -ENOMEM;
> +
> + memcpy(page, src_start, length);
> + __flush_icache_range((unsigned long)page, (unsigned long)page + length);
> +
> + trans_table = (void *)get_safe_page(GFP_ATOMIC);
> + if (!trans_table)
> + return -ENOMEM;
> +
> + rc = trans_table_map_page(trans_table, page, dst_addr,
> + PAGE_KERNEL_EXEC);
> + if (rc)
> + return rc;
> +
> /*
> * Load our new page tables. A strict BBM approach requires that we
> * ensure that TLBs are free of any entries that may overlap with the
> @@ -259,7 +273,7 @@ static int create_safe_exec_page(void *src_start, size_t length,
> write_sysreg(phys_to_ttbr(virt_to_phys(trans_table)), ttbr0_el1);
> isb();
>
> - *phys_dst_addr = virt_to_phys((void *)page);
> + *phys_dst_addr = virt_to_phys(page);
>
> return 0;
> }
> @@ -462,6 +476,24 @@ static int copy_page_tables(pgd_t *dst_pgdp, unsigned long start,
> return 0;
> }
>
> +int trans_table_create_copy(pgd_t **dst_pgdp, unsigned long start,
> + unsigned long end)
> +{
> + int rc;
> + pgd_t *trans_table = (pgd_t *)get_safe_page(GFP_ATOMIC);
> +
> + if (!trans_table) {
> + pr_err("Failed to allocate memory for temporary page tables.\n");
> + return -ENOMEM;
> + }
> +
> + rc = copy_page_tables(trans_table, start, end);
> + if (!rc)
> + *dst_pgdp = trans_table;
> +
> + return rc;
> +}
> +
> /*
> * Setup then Resume from the hibernate image using swsusp_arch_suspend_exit().
> *
> @@ -483,13 +515,7 @@ int swsusp_arch_resume(void)
> * Create a second copy of just the linear map, and use this when
> * restoring.
> */
> - tmp_pg_dir = (pgd_t *)get_safe_page(GFP_ATOMIC);
> - if (!tmp_pg_dir) {
> - pr_err("Failed to allocate memory for temporary page tables.\n");
> - rc = -ENOMEM;
> - goto out;
> - }
> - rc = copy_page_tables(tmp_pg_dir, PAGE_OFFSET, 0);
> + rc = trans_table_create_copy(&tmp_pg_dir, PAGE_OFFSET, 0);
> if (rc)
> goto out;
>
> --
> 2.22.1
>
_______________________________________________
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: kasan: fix phys_to_virt() false positive on tag-based kasan
From: Mark Rutland @ 2019-08-19 16:03 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Walter Wu, wsd_upstream, Catalin Marinas, Will Deacon, LKML,
kasan-dev, linux-mediatek, Alexander Potapenko, Linux ARM,
Matthias Brugger, Andrey Ryabinin, Andrew Morton, Will Deacon,
Dmitry Vyukov
In-Reply-To: <CAAeHK+wBNnnKY4wg=34aD8Of6Vea4nzWF-FEnnSpHN0pFyTR3Q@mail.gmail.com>
On Mon, Aug 19, 2019 at 05:37:36PM +0200, Andrey Konovalov wrote:
> On Mon, Aug 19, 2019 at 5:03 PM Mark Rutland <mark.rutland@arm.com> wrote:
> >
> > On Mon, Aug 19, 2019 at 04:05:22PM +0200, Andrey Konovalov wrote:
> > > On Mon, Aug 19, 2019 at 3:34 PM Will Deacon <will@kernel.org> wrote:
> > > >
> > > > On Mon, Aug 19, 2019 at 02:23:48PM +0100, Mark Rutland wrote:
> > > > > On Mon, Aug 19, 2019 at 01:56:26PM +0100, Will Deacon wrote:
> > > > > > On Mon, Aug 19, 2019 at 07:44:20PM +0800, Walter Wu wrote:
> > > > > > > __arm_v7s_unmap() call iopte_deref() to translate pyh_to_virt address,
> > > > > > > but it will modify pointer tag into 0xff, so there is a false positive.
> > > > > > >
> > > > > > > When enable tag-based kasan, phys_to_virt() function need to rewrite
> > > > > > > its original pointer tag in order to avoid kasan report an incorrect
> > > > > > > memory corruption.
> > > > > >
> > > > > > Hmm. Which tree did you see this on? We've recently queued a load of fixes
> > > > > > in this area, but I /thought/ they were only needed after the support for
> > > > > > 52-bit virtual addressing in the kernel.
> > > > >
> > > > > I'm seeing similar issues in the virtio blk code (splat below), atop of
> > > > > the arm64 for-next/core branch. I think this is a latent issue, and
> > > > > people are only just starting to test with KASAN_SW_TAGS.
> > > > >
> > > > > It looks like the virtio blk code will round-trip a SLUB-allocated pointer from
> > > > > virt->page->virt, losing the per-object tag in the process.
> > > > >
> > > > > Our page_to_virt() seems to get a per-page tag, but this only makes
> > > > > sense if you're dealing with the page allocator, rather than something
> > > > > like SLUB which carves a page into smaller objects giving each object a
> > > > > distinct tag.
> > > > >
> > > > > Any round-trip of a pointer from SLUB is going to lose the per-object
> > > > > tag.
> > > >
> > > > Urgh, I wonder how this is supposed to work?
> > > >
> > > > If we end up having to check the KASAN shadow for *_to_virt(), then why
> > > > do we need to store anything in the page flags at all? Andrey?
> > >
> > > As per 2813b9c0 ("kasan, mm, arm64: tag non slab memory allocated via
> > > pagealloc") we should only save a non-0xff tag in page flags for non
> > > slab pages.
> > >
> > > Could you share your .config so I can reproduce this?
> >
> > I wrote a test (below) to do so. :)
> >
> > It fires with arm64 defconfig, + CONFIG_TEST_KASAN=m.
> >
> > With Andrey Ryabinin's patch it works as expected with no KASAN splats
> > for the two new test cases.
>
> OK, Andrey's patch makes sense and fixes both Mark's test patch and
> reports from CONFIG_IOMMU_IO_PGTABLE_ARMV7S_SELFTEST.
>
> Tested-by: Andrey Konovalov <andreyknvl@google.com>
> Reviewed-by: Andrey Konovalov <andreyknvl@google.com>
>
> on both patches.
>
> >
> > Thanks,
> > Mark.
> >
> > ---->8----
> > From 7e8569b558fca21ad4e80fddae659591bc84ce1f Mon Sep 17 00:00:00 2001
> > From: Mark Rutland <mark.rutland@arm.com>
> > Date: Mon, 19 Aug 2019 15:39:32 +0100
> > Subject: [PATCH] lib/test_kasan: add roundtrip tests
> >
> > In several places we needs to be able to operate on pointers which have
>
> "needs" => "need"
Thanks!
I'll spin a standalone v2 of this with that fixed and your tags folded
in.
Mark.
>
> > gone via a roundtrip:
> >
> > virt -> {phys,page} -> virt
> >
> > With KASAN_SW_TAGS, we can't preserve the tag for SLUB objects, and the
> > {phys,page} -> virt conversion will use KASAN_TAG_KERNEL.
> >
> > This patch adds tests to ensure that this works as expected, without
> > false positives.
> >
> > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> > Cc: Andrey Konovalov <andreyknvl@google.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > ---
> > lib/test_kasan.c | 40 ++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 40 insertions(+)
> >
> > diff --git a/lib/test_kasan.c b/lib/test_kasan.c
> > index b63b367a94e8..cf7b93f0d90c 100644
> > --- a/lib/test_kasan.c
> > +++ b/lib/test_kasan.c
> > @@ -19,6 +19,8 @@
> > #include <linux/string.h>
> > #include <linux/uaccess.h>
> >
> > +#include <asm/page.h>
> > +
> > /*
> > * Note: test functions are marked noinline so that their names appear in
> > * reports.
> > @@ -337,6 +339,42 @@ static noinline void __init kmalloc_uaf2(void)
> > kfree(ptr2);
> > }
> >
> > +static noinline void __init kfree_via_page(void)
> > +{
> > + char *ptr;
> > + size_t size = 8;
> > + struct page *page;
> > + unsigned long offset;
> > +
> > + pr_info("invalid-free false positive (via page)\n");
> > + ptr = kmalloc(size, GFP_KERNEL);
> > + if (!ptr) {
> > + pr_err("Allocation failed\n");
> > + return;
> > + }
> > +
> > + page = virt_to_page(ptr);
> > + offset = offset_in_page(ptr);
> > + kfree(page_address(page) + offset);
> > +}
> > +
> > +static noinline void __init kfree_via_phys(void)
> > +{
> > + char *ptr;
> > + size_t size = 8;
> > + phys_addr_t phys;
> > +
> > + pr_info("invalid-free false positive (via phys)\n");
> > + ptr = kmalloc(size, GFP_KERNEL);
> > + if (!ptr) {
> > + pr_err("Allocation failed\n");
> > + return;
> > + }
> > +
> > + phys = virt_to_phys(ptr);
> > + kfree(phys_to_virt(phys));
> > +}
> > +
> > static noinline void __init kmem_cache_oob(void)
> > {
> > char *p;
> > @@ -737,6 +775,8 @@ static int __init kmalloc_tests_init(void)
> > kmalloc_uaf();
> > kmalloc_uaf_memset();
> > kmalloc_uaf2();
> > + kfree_via_page();
> > + kfree_via_phys();
> > kmem_cache_oob();
> > memcg_accounted_kmem_cache();
> > kasan_stack_oob();
> > --
> > 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
* Re: [PATCH v2 02/14] arm64, hibernate: create_safe_exec_page cleanup
From: Pavel Tatashin @ 2019-08-19 16:25 UTC (permalink / raw)
To: Mark Rutland
Cc: Sasha Levin, Vladimir Murzin, Jonathan Corbet, Marc Zyngier,
Catalin Marinas, Bhupesh Sharma, kexec mailing list, LKML,
James Morris, linux-mm, James Morse, Eric W. Biederman,
Matthias Brugger, will, Linux ARM
In-Reply-To: <20190819155014.GD9927@lakrids.cambridge.arm.com>
Hi Mark,
Thank you for your review comments. My replies below:
On Mon, Aug 19, 2019 at 11:50 AM Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Fri, Aug 16, 2019 at 10:46:17PM -0400, Pavel Tatashin wrote:
> > create_safe_exec_page() is going to be split into two parts in preparation
> > of moving page table handling code out of hibernate.c
> >
> > Remove allocator parameter, and rename dst to page. Also, remove the
> > goto's, as we can return directly without cleanups.
>
> It would be nice if you could do the goto/allocator/rename changes as
> separate patches, since it's vastly easier to verify each change in
> isolation that way.
Sure, I will split these changes into separate patches in the next
version of this patch series.
>
> What's the point of the rename? It's inconsistent with the phys_dst_addr
> that you leave as-is, so I'm not sure that's worthwhile.
dst_addr, phys_dst_addr VA/PA destination addresses. But, page is a
buffer in the current VA space (hence changed to void *), dst looked
confusing as it seemed as it was part of the
destination addresses.
>
> >
> > Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
> > ---
> > arch/arm64/kernel/hibernate.c | 60 +++++++++++++++--------------------
> > 1 file changed, 26 insertions(+), 34 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
> > index 9341fcc6e809..96b6f8da7e49 100644
> > --- a/arch/arm64/kernel/hibernate.c
> > +++ b/arch/arm64/kernel/hibernate.c
> > @@ -196,57 +196,51 @@ EXPORT_SYMBOL(arch_hibernation_header_restore);
> > */
> > static int create_safe_exec_page(void *src_start, size_t length,
> > unsigned long dst_addr,
> > - phys_addr_t *phys_dst_addr,
> > - void *(*allocator)(gfp_t mask),
> > - gfp_t mask)
> > + phys_addr_t *phys_dst_addr)
> > {
> > - int rc = 0;
> > + void *page = (void *)get_safe_page(GFP_ATOMIC);
> > + pgd_t *trans_table;
>
> The addition of this trans_table variable wasn't mentioned in the commit
> message...
>
> > + trans_table = (void *)get_safe_page(GFP_ATOMIC);
> > + if (!trans_table)
> > + return -ENOMEM;
> >
> > - pgdp = pgd_offset_raw(allocator(mask), dst_addr);
> > + pgdp = pgd_offset_raw(trans_table, dst_addr);
>
> > - write_sysreg(phys_to_ttbr(virt_to_phys(pgdp)), ttbr0_el1);
> > + write_sysreg(phys_to_ttbr(virt_to_phys(trans_table)), ttbr0_el1);
>
>
> ... and I guess you're trying to ensure that we program the TTBR with
> the correct base address, without the offset of whatever pgd entry we
> happen to have plumbed in?
>
> I think that's a fix, and should come before any other cleanup or
> rework.
Yes.
>
> If you can respin that specific change with s/trans_table/pgdir/, that
> would make sense to me.
I will split this patch into several changes. I will describe
trans_table rational in different e-mail. There we will decide what
namespace to use.
Thank you,
Pasha
_______________________________________________
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 v8 4/5] arm64: Define Documentation/arm64/tagged-address-abi.rst
From: Will Deacon @ 2019-08-19 16:25 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-arch, linux-doc, Szabolcs Nagy, Andrey Konovalov,
Kevin Brodsky, Will Deacon, Dave P Martin, linux-mm,
Andrew Morton, Vincenzo Frascino, Dave Hansen, linux-arm-kernel
In-Reply-To: <20190815154403.16473-5-catalin.marinas@arm.com>
On Thu, Aug 15, 2019 at 04:44:02PM +0100, Catalin Marinas wrote:
> From: Vincenzo Frascino <vincenzo.frascino@arm.com>
>
> On AArch64 the TCR_EL1.TBI0 bit is set by default, allowing userspace
> (EL0) to perform memory accesses through 64-bit pointers with a non-zero
> top byte. Introduce the document describing the relaxation of the
> syscall ABI that allows userspace to pass certain tagged pointers to
> kernel syscalls.
>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Andrey Konovalov <andreyknvl@google.com>
> Cc: Szabolcs Nagy <szabolcs.nagy@arm.com>
> Cc: Kevin Brodsky <kevin.brodsky@arm.com>
> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
> Co-developed-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
> Documentation/arm64/tagged-address-abi.rst | 155 +++++++++++++++++++++
> 1 file changed, 155 insertions(+)
> create mode 100644 Documentation/arm64/tagged-address-abi.rst
>
> diff --git a/Documentation/arm64/tagged-address-abi.rst b/Documentation/arm64/tagged-address-abi.rst
> new file mode 100644
> index 000000000000..8808337775d6
> --- /dev/null
> +++ b/Documentation/arm64/tagged-address-abi.rst
> @@ -0,0 +1,155 @@
> +==========================
> +AArch64 TAGGED ADDRESS ABI
> +==========================
> +
> +Authors: Vincenzo Frascino <vincenzo.frascino@arm.com>
> + Catalin Marinas <catalin.marinas@arm.com>
> +
> +Date: 15 August 2019
> +
> +This document describes the usage and semantics of the Tagged Address
> +ABI on AArch64 Linux.
> +
> +1. Introduction
> +---------------
> +
> +On AArch64 the TCR_EL1.TBI0 bit is set by default, allowing userspace
> +(EL0) to perform memory accesses through 64-bit pointers with a non-zero
> +top byte. This document describes the relaxation of the syscall ABI that
> +allows userspace to pass certain tagged pointers to kernel syscalls.
> +
> +2. AArch64 Tagged Address ABI
> +-----------------------------
> +
> +From the kernel syscall interface perspective and for the purposes of
> +this document, a "valid tagged pointer" is a pointer with a potentially
> +non-zero top-byte that references an address in the user process address
> +space obtained in one of the following ways:
> +
> +- mmap() done by the process itself (or its parent), where either:
> +
> + - flags have the **MAP_ANONYMOUS** bit set
> + - the file descriptor refers to a regular file (including those
> + returned by memfd_create()) or **/dev/zero**
nit: but the markup is pretty inconsistent throughout. Why is /dev/zero
bold, but not memfd_create()? I think they would both be better off in
typewriter font, if that's a thing in rst.
> +- brk() system call done by the process itself (i.e. the heap area
> + between the initial location of the program break at process creation
> + and its current location).
> +
> +- any memory mapped by the kernel in the address space of the process
> + during creation and with the same restrictions as for mmap() above
> + (e.g. data, bss, stack).
> +
> +The AArch64 Tagged Address ABI has two stages of relaxation depending
> +how the user addresses are used by the kernel:
> +
> +1. User addresses not accessed by the kernel but used for address space
> + management (e.g. mmap(), mprotect(), madvise()). The use of valid
> + tagged pointers in this context is always allowed.
> +
> +2. User addresses accessed by the kernel (e.g. write()). This ABI
> + relaxation is disabled by default and the application thread needs to
> + explicitly enable it via **prctl()** as follows:
> +
> + - **PR_SET_TAGGED_ADDR_CTRL**: enable or disable the AArch64 Tagged
> + Address ABI for the calling thread.
> +
> + The (unsigned int) arg2 argument is a bit mask describing the
> + control mode used:
> +
> + - **PR_TAGGED_ADDR_ENABLE**: enable AArch64 Tagged Address ABI.
> + Default status is disabled.
> +
> + Arguments arg3, arg4, and arg5 must be 0.
> +
> + - **PR_GET_TAGGED_ADDR_CTRL**: get the status of the AArch64 Tagged
> + Address ABI for the calling thread.
> +
> + Arguments arg2, arg3, arg4, and arg5 must be 0.
> +
> + The ABI properties described above are thread-scoped, inherited on
> + clone() and fork() and cleared on exec().
> +
> + Calling prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0)
> + returns -EINVAL if the AArch64 Tagged Address ABI is globally disabled
> + by sysctl abi.tagged_addr_disabled=1. The default sysctl
> + abi.tagged_addr_disabled configuration is 0.
> +
> +When the AArch64 Tagged Address ABI is enabled for a thread, the
> +following behaviours are guaranteed:
> +
> +- All syscalls except the cases mentioned in section 3 can accept any
> + valid tagged pointer.
> +
> +- The syscall behaviour is undefined for invalid tagged pointers: it may
> + result in an error code being returned, a (fatal) signal being raised,
> + or other modes of failure.
> +
> +- A valid tagged pointer has the same semantics as the corresponding
> + untagged pointer.
nit, but I'd reword this last bullet slightly to say:
- The syscall behaviour for a valid tagged pointer is the same as for
the corresponding untagged pointer.
Since that flows better wrt the previous bullet and is explicit about
syscall behaviour, rather than overall semantics.
> +
> +A definition of the meaning of tagged pointers on AArch64 can be found
> +in Documentation/arm64/tagged-pointers.rst.
> +
> +3. AArch64 Tagged Address ABI Exceptions
> +-----------------------------------------
> +
> +The following system call parameters must be untagged regardless of the
> +ABI relaxation:
> +
> +- prctl() other than arguments pointing to user structures to be
> + accessed by the kernel.
> +
> +- ioctl() other than arguments pointing to user structures to be
> + accessed by the kernel.
I agree with Kevin that we should tighten this up. How about:
- ... other than pointers to user data either passed directly or
indirectly as arguments to be accessed by the kernel.
?
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 v8 1/5] mm: untag user pointers in mmap/munmap/mremap/brk
From: Will Deacon @ 2019-08-19 16:28 UTC (permalink / raw)
To: Catalin Marinas, akpm
Cc: linux-arch, linux-doc, Szabolcs Nagy, Andrey Konovalov,
Kevin Brodsky, Will Deacon, Dave P Martin, linux-mm,
Vincenzo Frascino, Dave Hansen, linux-arm-kernel
In-Reply-To: <20190815154403.16473-2-catalin.marinas@arm.com>
On Thu, Aug 15, 2019 at 04:43:59PM +0100, Catalin Marinas wrote:
> There isn't a good reason to differentiate between the user address
> space layout modification syscalls and the other memory
> permission/attributes ones (e.g. mprotect, madvise) w.r.t. the tagged
> address ABI. Untag the user addresses on entry to these functions.
>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
> mm/mmap.c | 5 +++++
> mm/mremap.c | 6 +-----
> 2 files changed, 6 insertions(+), 5 deletions(-)
Acked-by: Will Deacon <will@kernel.org>
Andrew -- please can you pick this patch up? I'll take the rest of the
series via arm64 once we've finished discussing the wording details.
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 03/14] arm64, hibernate: add trans_table public functions
From: Pavel Tatashin @ 2019-08-19 16:33 UTC (permalink / raw)
To: Mark Rutland
Cc: Sasha Levin, Vladimir Murzin, Jonathan Corbet, Marc Zyngier,
Catalin Marinas, Bhupesh Sharma, kexec mailing list, LKML,
James Morris, linux-mm, James Morse, Eric W. Biederman,
Matthias Brugger, will, Linux ARM
In-Reply-To: <20190819155824.GE9927@lakrids.cambridge.arm.com>
On Mon, Aug 19, 2019 at 11:58 AM Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Fri, Aug 16, 2019 at 10:46:18PM -0400, Pavel Tatashin wrote:
> > trans_table_create_copy() and trans_table_map_page() are going to be
> > the basis for public interface of new subsystem that handles page
> > tables for cases which are between kernels: kexec, and hibernate.
>
> While the architecture uses the term 'translation table', in the kernel
> we generally use 'pgdir' or 'pgd' to refer to the tables, so please keep
> to that naming scheme.
The idea is to have a unique name space for new subsystem of page
tables that are used between kernels:
between stage 1 and stage 2 kexec kernel, and similarly between
kernels during hibernate boot process.
I picked: "trans_table" that stands for transitional page table:
meaning they are used only during transition between worlds.
All public functions in this subsystem will have trans_table_* prefix,
and page directory will be named: "trans_table". If this is confusing,
I can either use a different prefix, or describe what "trans_table"
stand for in trans_table.h/.c
Thank you,
Pasha
_______________________________________________
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 4/9] KVM: arm64: Support stolen time reporting via shared structure
From: Marc Zyngier @ 2019-08-19 16:40 UTC (permalink / raw)
To: Steven Price, Will Deacon, linux-arm-kernel, kvmarm
Cc: Mark Rutland, kvm, Radim Krčmář, Catalin Marinas,
Suzuki K Pouloze, linux-doc, Russell King, linux-kernel,
James Morse, Paolo Bonzini, Julien Thierry
In-Reply-To: <20190819140436.12207-5-steven.price@arm.com>
Hi Steven,
On 19/08/2019 15:04, Steven Price wrote:
> Implement the service call for configuring a shared structure between a
> VCPU and the hypervisor in which the hypervisor can write the time
> stolen from the VCPU's execution time by other tasks on the host.
>
> The hypervisor allocates memory which is placed at an IPA chosen by user
> space. The hypervisor then uses WRITE_ONCE() to update the shared
> structure ensuring single copy atomicity of the 64-bit unsigned value
> that reports stolen time in nanoseconds.
>
> Whenever stolen time is enabled by the guest, the stolen time counter is
> reset.
>
> The stolen time itself is retrieved from the sched_info structure
> maintained by the Linux scheduler code. We enable SCHEDSTATS when
> selecting KVM Kconfig to ensure this value is meaningful.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> arch/arm/include/asm/kvm_host.h | 15 +++++++
> arch/arm64/include/asm/kvm_host.h | 16 ++++++-
> arch/arm64/kvm/Kconfig | 1 +
> include/linux/kvm_types.h | 2 +
> virt/kvm/arm/arm.c | 19 +++++++++
> virt/kvm/arm/hypercalls.c | 3 ++
> virt/kvm/arm/pvtime.c | 71 +++++++++++++++++++++++++++++++
> 7 files changed, 126 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index 369b5d2d54bf..14d61a84c270 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -39,6 +39,7 @@
> KVM_ARCH_REQ_FLAGS(0, KVM_REQUEST_WAIT | KVM_REQUEST_NO_WAKEUP)
> #define KVM_REQ_IRQ_PENDING KVM_ARCH_REQ(1)
> #define KVM_REQ_VCPU_RESET KVM_ARCH_REQ(2)
> +#define KVM_REQ_RECORD_STEAL KVM_ARCH_REQ(3)
>
> DECLARE_STATIC_KEY_FALSE(userspace_irqchip_in_use);
>
> @@ -77,6 +78,12 @@ struct kvm_arch {
>
> /* Mandated version of PSCI */
> u32 psci_version;
> +
> + struct kvm_arch_pvtime {
> + struct gfn_to_hva_cache st_ghc;
> + gpa_t st_base;
> + u64 st_size;
> + } pvtime;
It'd be good if we could avoid having this in the 32bit vcpu structure,
given that it serves no real purpose (other than being able to compile
things).
> };
>
> #define KVM_NR_MEM_OBJS 40
> @@ -328,6 +335,14 @@ static inline int kvm_hypercall_pv_features(struct kvm_vcpu *vcpu)
> {
> return SMCCC_RET_NOT_SUPPORTED;
> }
> +static inline int kvm_hypercall_stolen_time(struct kvm_vcpu *vcpu)
> +{
> + return SMCCC_RET_NOT_SUPPORTED;
> +}
> +static inline int kvm_update_stolen_time(struct kvm_vcpu *vcpu, bool init)
> +{
> + return -ENOTSUPP;
> +}
>
> void kvm_mmu_wp_memory_region(struct kvm *kvm, int slot);
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 583b3639062a..627ecbdd0c59 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -44,6 +44,7 @@
> KVM_ARCH_REQ_FLAGS(0, KVM_REQUEST_WAIT | KVM_REQUEST_NO_WAKEUP)
> #define KVM_REQ_IRQ_PENDING KVM_ARCH_REQ(1)
> #define KVM_REQ_VCPU_RESET KVM_ARCH_REQ(2)
> +#define KVM_REQ_RECORD_STEAL KVM_ARCH_REQ(3)
>
> DECLARE_STATIC_KEY_FALSE(userspace_irqchip_in_use);
>
> @@ -83,6 +84,12 @@ struct kvm_arch {
>
> /* Mandated version of PSCI */
> u32 psci_version;
> +
> + struct kvm_arch_pvtime {
> + struct gfn_to_hva_cache st_ghc;
> + gpa_t st_base;
> + u64 st_size;
> + } pvtime;
> };
>
> #define KVM_NR_MEM_OBJS 40
> @@ -338,8 +345,13 @@ struct kvm_vcpu_arch {
> /* True when deferrable sysregs are loaded on the physical CPU,
> * see kvm_vcpu_load_sysregs and kvm_vcpu_put_sysregs. */
> bool sysregs_loaded_on_cpu;
> -};
>
> + /* Guest PV state */
> + struct {
> + u64 steal;
> + u64 last_steal;
> + } steal;
> +};
> /* Pointer to the vcpu's SVE FFR for sve_{save,load}_state() */
> #define vcpu_sve_pffr(vcpu) ((void *)((char *)((vcpu)->arch.sve_state) + \
> sve_ffr_offset((vcpu)->arch.sve_max_vl)))
> @@ -479,6 +491,8 @@ int kvm_perf_init(void);
> int kvm_perf_teardown(void);
>
> int kvm_hypercall_pv_features(struct kvm_vcpu *vcpu);
> +int kvm_hypercall_stolen_time(struct kvm_vcpu *vcpu);
> +int kvm_update_stolen_time(struct kvm_vcpu *vcpu, bool init);
>
> void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome);
>
> diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
> index a67121d419a2..d8b88e40d223 100644
> --- a/arch/arm64/kvm/Kconfig
> +++ b/arch/arm64/kvm/Kconfig
> @@ -39,6 +39,7 @@ config KVM
> select IRQ_BYPASS_MANAGER
> select HAVE_KVM_IRQ_BYPASS
> select HAVE_KVM_VCPU_RUN_PID_CHANGE
> + select SCHEDSTATS
> ---help---
> Support hosting virtualized guest machines.
> We don't support KVM with 16K page tables yet, due to the multiple
> diff --git a/include/linux/kvm_types.h b/include/linux/kvm_types.h
> index bde5374ae021..1c88e69db3d9 100644
> --- a/include/linux/kvm_types.h
> +++ b/include/linux/kvm_types.h
> @@ -35,6 +35,8 @@ typedef unsigned long gva_t;
> typedef u64 gpa_t;
> typedef u64 gfn_t;
>
> +#define GPA_INVALID (~(gpa_t)0)
> +
> typedef unsigned long hva_t;
> typedef u64 hpa_t;
> typedef u64 hfn_t;
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index 35a069815baf..53cc80e98d8b 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -40,6 +40,10 @@
> #include <asm/kvm_coproc.h>
> #include <asm/sections.h>
>
> +#include <kvm/arm_hypercalls.h>
> +#include <kvm/arm_pmu.h>
> +#include <kvm/arm_psci.h>
> +
> #ifdef REQUIRES_VIRT
> __asm__(".arch_extension virt");
> #endif
> @@ -135,6 +139,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> kvm->arch.max_vcpus = vgic_present ?
> kvm_vgic_get_max_vcpus() : KVM_MAX_VCPUS;
>
> + kvm->arch.pvtime.st_base = GPA_INVALID;
> return ret;
> out_free_stage2_pgd:
> kvm_free_stage2_pgd(kvm);
> @@ -379,6 +384,8 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> kvm_vcpu_load_sysregs(vcpu);
> kvm_arch_vcpu_load_fp(vcpu);
> kvm_vcpu_pmu_restore_guest(vcpu);
> + if (vcpu->kvm->arch.pvtime.st_base != GPA_INVALID)
> + kvm_make_request(KVM_REQ_RECORD_STEAL, vcpu);
>
> if (single_task_running())
> vcpu_clear_wfe_traps(vcpu);
> @@ -625,6 +632,15 @@ static void vcpu_req_sleep(struct kvm_vcpu *vcpu)
> smp_rmb();
> }
>
> +static void vcpu_req_record_steal(struct kvm_vcpu *vcpu)
> +{
> + int idx;
> +
> + idx = srcu_read_lock(&vcpu->kvm->srcu);
> + kvm_update_stolen_time(vcpu, false);
> + srcu_read_unlock(&vcpu->kvm->srcu, idx);
> +}
> +
> static int kvm_vcpu_initialized(struct kvm_vcpu *vcpu)
> {
> return vcpu->arch.target >= 0;
> @@ -644,6 +660,9 @@ static void check_vcpu_requests(struct kvm_vcpu *vcpu)
> * that a VCPU sees new virtual interrupts.
> */
> kvm_check_request(KVM_REQ_IRQ_PENDING, vcpu);
> +
> + if (kvm_check_request(KVM_REQ_RECORD_STEAL, vcpu))
> + vcpu_req_record_steal(vcpu);
> }
> }
>
> diff --git a/virt/kvm/arm/hypercalls.c b/virt/kvm/arm/hypercalls.c
> index 63ae629c466a..ac678eabf15f 100644
> --- a/virt/kvm/arm/hypercalls.c
> +++ b/virt/kvm/arm/hypercalls.c
> @@ -56,6 +56,9 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> case ARM_SMCCC_HV_PV_FEATURES:
> val = kvm_hypercall_pv_features(vcpu);
> break;
> + case ARM_SMCCC_HV_PV_TIME_ST:
> + val = kvm_hypercall_stolen_time(vcpu);
> + break;
> default:
> return kvm_psci_call(vcpu);
> }
> diff --git a/virt/kvm/arm/pvtime.c b/virt/kvm/arm/pvtime.c
> index 6201d71cb1f8..f169184e4076 100644
> --- a/virt/kvm/arm/pvtime.c
> +++ b/virt/kvm/arm/pvtime.c
> @@ -3,8 +3,55 @@
>
> #include <linux/arm-smccc.h>
>
> +#include <asm/pvclock-abi.h>
> +
> #include <kvm/arm_hypercalls.h>
>
> +int kvm_update_stolen_time(struct kvm_vcpu *vcpu, bool init)
> +{
> + struct kvm *kvm = vcpu->kvm;
> + struct kvm_arch_pvtime *pvtime = &kvm->arch.pvtime;
> + u64 steal;
> + u64 steal_le;
> + u64 offset;
> + int idx;
> + const int stride = sizeof(struct pvclock_vcpu_stolen_time);
> +
> + if (pvtime->st_base == GPA_INVALID)
> + return -ENOTSUPP;
> +
> + /* Let's do the local bookkeeping */
> + steal = vcpu->arch.steal.steal;
> + steal += current->sched_info.run_delay - vcpu->arch.steal.last_steal;
> + vcpu->arch.steal.last_steal = current->sched_info.run_delay;
> + vcpu->arch.steal.steal = steal;
> +
> + offset = stride * kvm_vcpu_get_idx(vcpu);
> +
> + if (unlikely(offset + stride > pvtime->st_size))
> + return -EINVAL;
> +
> + steal_le = cpu_to_le64(steal);
> + pagefault_disable();
What's the reason for doing a pagefault_disable()? What I'd expect is
for the userspace page to be faulted in and written to, and doing a
pagefault_disable() seems to be going against this idea.
> + idx = srcu_read_lock(&kvm->srcu);
> + if (init) {
> + struct pvclock_vcpu_stolen_time init_values = {
> + .revision = 0,
> + .attributes = 0
> + };
> + kvm_write_guest_offset_cached(kvm,
> + &pvtime->st_ghc,
> + &init_values, offset, sizeof(init_values));
> + }
> + offset += offsetof(struct pvclock_vcpu_stolen_time, stolen_time);
> + kvm_write_guest_offset_cached(kvm, &pvtime->st_ghc,
> + &steal_le, offset, sizeof(steal_le));
> + srcu_read_unlock(&kvm->srcu, idx);
> + pagefault_enable();
> +
> + return 0;
> +}
> +
> int kvm_hypercall_pv_features(struct kvm_vcpu *vcpu)
> {
> u32 feature = smccc_get_arg1(vcpu);
> @@ -12,6 +59,7 @@ int kvm_hypercall_pv_features(struct kvm_vcpu *vcpu)
>
> switch (feature) {
> case ARM_SMCCC_HV_PV_FEATURES:
> + case ARM_SMCCC_HV_PV_TIME_ST:
> val = SMCCC_RET_SUCCESS;
> break;
> }
> @@ -19,3 +67,26 @@ int kvm_hypercall_pv_features(struct kvm_vcpu *vcpu)
> return val;
> }
>
> +int kvm_hypercall_stolen_time(struct kvm_vcpu *vcpu)
> +{
> + u64 ret;
> + int err;
> +
> + /*
> + * Start counting stolen time from the time the guest requests
> + * the feature enabled.
> + */
> + vcpu->arch.steal.steal = 0;
> + vcpu->arch.steal.last_steal = current->sched_info.run_delay;
> +
> + err = kvm_update_stolen_time(vcpu, true);
> +
> + if (err)
> + ret = SMCCC_RET_NOT_SUPPORTED;
> + else
> + ret = vcpu->kvm->arch.pvtime.st_base +
> + (sizeof(struct pvclock_vcpu_stolen_time) *
> + kvm_vcpu_get_idx(vcpu));
> +
> + return ret;
> +}
>
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 1/4] kprobes: adjust kprobe addr for KPROBES_ON_FTRACE
From: Naveen N. Rao @ 2019-08-19 16:43 UTC (permalink / raw)
To: Anil S Keshavamurthy, Borislav Petkov, Catalin Marinas,
David S. Miller, H. Peter Anvin, Jisheng Zhang, Masami,
Hiramatsu, Ingo Molnar, Steven Rostedt, Thomas Gleixner,
Will Deacon
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190819192505.483c0bf0@xhacker.debian>
Jisheng Zhang wrote:
> For KPROBES_ON_FTRACE case, we need to adjust the kprobe's addr
> correspondingly.
>
> Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> ---
> kernel/kprobes.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index 9873fc627d61..f8400753a8a9 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -1560,6 +1560,9 @@ int register_kprobe(struct kprobe *p)
> addr = kprobe_addr(p);
> if (IS_ERR(addr))
> return PTR_ERR(addr);
> +#ifdef CONFIG_KPROBES_ON_FTRACE
> + addr = (kprobe_opcode_t *)ftrace_call_adjust((unsigned long)addr);
> +#endif
> p->addr = addr;
I'm not sure what this is achieving, but looks wrong to me.
If you intend to have kprobes default to using ftrace entry for probing
functions, consider over-riding kprobe_lookup_name() -- see powerpc
variant for example.
- Naveen
_______________________________________________
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 3/4] perf: Use CAP_SYSLOG with kptr_restrict checks
From: Mathieu Poirier @ 2019-08-19 16:51 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Suzuki K Poulose, Peter Zijlstra, Alexey Budankov, Lubashev, Igor,
Linux Kernel Mailing List, James Morris, Alexander Shishkin,
Ingo Molnar, Leo Yan, Namhyung Kim, Jiri Olsa, linux-arm-kernel
In-Reply-To: <20190815214236.GA3929@kernel.org>
On Thu, 15 Aug 2019 at 15:42, Arnaldo Carvalho de Melo
<arnaldo.melo@gmail.com> wrote:
>
> Em Thu, Aug 15, 2019 at 02:16:48PM -0600, Mathieu Poirier escreveu:
> > On Wed, 14 Aug 2019 at 14:02, Lubashev, Igor <ilubashe@akamai.com> wrote:
> > >
> > > > On Wed, August 14, 2019 at 2:52 PM Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com> wrote:
> > > > Em Wed, Aug 14, 2019 at 03:48:14PM -0300, Arnaldo Carvalho de Melo
> > > > escreveu:
> > > > > Em Wed, Aug 14, 2019 at 12:04:33PM -0600, Mathieu Poirier escreveu:
> > > > > > # echo 0 > /proc/sys/kernel/kptr_restrict # ./tools/perf/perf record
> > > > > > -e instructions:k uname
> > > > > > perf: Segmentation fault
> > > > > > Obtained 10 stack frames.
> > > > > > ./tools/perf/perf(sighandler_dump_stack+0x44) [0x55af9e5da5d4]
> > > > > > /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7fd31efb6f20]
> > > > > > ./tools/perf/perf(perf_event__synthesize_kernel_mmap+0xa7)
> > > > > > [0x55af9e590337]
> > > > > > ./tools/perf/perf(+0x1cf5be) [0x55af9e50c5be]
> > > > > > ./tools/perf/perf(cmd_record+0x1022) [0x55af9e50dff2]
> > > > > > ./tools/perf/perf(+0x23f98d) [0x55af9e57c98d]
> > > > > > ./tools/perf/perf(+0x23fc9e) [0x55af9e57cc9e]
> > > > > > ./tools/perf/perf(main+0x369) [0x55af9e4f6bc9]
> > > > > > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)
> > > > > > [0x7fd31ef99b97]
> > > > > > ./tools/perf/perf(_start+0x2a) [0x55af9e4f704a] Segmentation fault
> > > > > >
> > > > > > I can reproduce this on both x86 and ARM64.
> > > > >
> > > > > I don't see this with these two csets removed:
> > > > >
> > > > > 7ff5b5911144 perf symbols: Use CAP_SYSLOG with kptr_restrict checks
> > > > > d7604b66102e perf tools: Use CAP_SYS_ADMIN with perf_event_paranoid
> > > > > checks
> > > > >
> > > > > Which were the ones I guessed were related to the problem you
> > > > > reported, so they are out of my ongoing perf/core pull request to
> > > > > Ingo/Thomas, now trying with these applied and your instructions...
> > > >
> > > > Can't repro:
> > > >
> > > > [root@quaco ~]# cat /proc/sys/kernel/kptr_restrict
> > > > 0
> > > > [root@quaco ~]# perf record -e instructions:k uname Linux [ perf record:
> > > > Woken up 1 times to write data ] [ perf record: Captured and wrote 0.024 MB
> > > > perf.data (1 samples) ] [root@quaco ~]# echo 1 >
> > > > /proc/sys/kernel/kptr_restrict [root@quaco ~]# perf record -e instructions:k
> > > > uname Linux [ perf record: Woken up 1 times to write data ] [ perf record:
> > > > Captured and wrote 0.024 MB perf.data (1 samples) ] [root@quaco ~]# echo
> > > > 0 > /proc/sys/kernel/kptr_restrict [root@quaco ~]# perf record -e
> > > > instructions:k uname Linux [ perf record: Woken up 1 times to write data ] [
> > > > perf record: Captured and wrote 0.024 MB perf.data (1 samples) ]
> > > > [root@quaco ~]#
> > > >
> > > > [acme@quaco perf]$ git log --oneline --author Lubashev tools/
> > > > 7ff5b5911144 (HEAD -> perf/cap, acme.korg/tmp.perf/cap,
> > > > acme.korg/perf/cap) perf symbols: Use CAP_SYSLOG with kptr_restrict
> > > > checks d7604b66102e perf tools: Use CAP_SYS_ADMIN with
> > > > perf_event_paranoid checks c766f3df635d perf ftrace: Use CAP_SYS_ADMIN
> > > > instead of euid==0 c22e150e3afa perf tools: Add helpers to use capabilities if
> > > > present
> > > > 74d5f3d06f70 tools build: Add capability-related feature detection perf
> > > > version 5.3.rc4.g7ff5b5911144 [acme@quaco perf]$
> > >
> > > I got an ARM64 cloud VM, but I cannot reproduce.
> > > # cat /proc/sys/kernel/kptr_restrict
> > > 0
> > >
> > > Perf trace works fine (does not die):
> > > # ./perf trace -a
> > >
> > > Here is my setup:
> > > Repo: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
> > > Branch: tmp.perf/cap
> > > Commit: 7ff5b5911 "perf symbols: Use CAP_SYSLOG with kptr_restrict checks"
> > > gcc --version: gcc (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1) 7.4.0
> > > uname -a: Linux arm-4-par-1 4.9.93-mainline-rev1 #1 SMP Tue Apr 10 09:54:46 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
> > > lsb_release -a: Ubuntu 18.04.3 LTS
> > >
> > > Auto-detecting system features:
> > > ... dwarf: [ on ]
> > > ... dwarf_getlocations: [ on ]
> > > ... glibc: [ on ]
> > > ... gtk2: [ on ]
> > > ... libaudit: [ on ]
> > > ... libbfd: [ on ]
> > > ... libcap: [ on ]
> > > ... libelf: [ on ]
> > > ... libnuma: [ on ]
> > > ... numa_num_possible_cpus: [ on ]
> > > ... libperl: [ on ]
> > > ... libpython: [ on ]
> > > ... libcrypto: [ on ]
> > > ... libunwind: [ on ]
> > > ... libdw-dwarf-unwind: [ on ]
> > > ... zlib: [ on ]
> > > ... lzma: [ on ]
> > > ... get_cpuid: [ OFF ]
> > > ... bpf: [ on ]
> > > ... libaio: [ on ]
> > > ... libzstd: [ on ]
> > > ... disassembler-four-args: [ on ]
> > >
> > > I also could not reproduce on x86:
> > > lsb_release -a: Ubuntu 18.04.1 LTS
> > > gcc --version: gcc (Ubuntu 7.4.0-1ubuntu1~18.04aka10.0.0) 7.4.0
> > > uname -r: 4.4.0-154-generic
> >
> > I isolated the problem to libcap-dev - if it is not installed a
> > segmentation fault will occur. Since this set is about using
> > capabilities it is obvious that not having it on a system should fail
> > a trace session, but it should not crash it.
>
> It shouldn't crash on x86_64:
>
> root@quaco ~]# sysctl kernel.kptr_restrict
> kernel.kptr_restrict = 0
> [root@quaco ~]# perf record -e instructions:k uname
> Linux
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.023 MB perf.data (5 samples) ]
> [root@quaco ~]# ldd ~/bin/perf | grep libcap
> [root@quaco ~]# perf -v
> perf version 5.3.rc4.g329ca330bf8b
> [root@quaco ~]#
> [acme@quaco perf]$ git log --oneline -4
> 329ca330bf8b (HEAD -> perf/cap) perf symbols: Use CAP_SYSLOG with kptr_restrict checks
> f7b9999387af perf tools: Use CAP_SYS_ADMIN with perf_event_paranoid checks
> 4d0489cf1c47 (acme.korg/tmp.perf/script-switch-on-off, perf/core) perf report: Add --switch-on/--switch-off events
> 2f53ae347f59 perf top: Add --switch-on/--switch-off events
> [acme@quaco perf]$
>
> > If libcap-dev is not installed function symbol__restricted_filename()
> > will return true, which in turn will prevent symbol_name to be set in
> > machine__get_running_kernel_start(). That prevents function
> > map__set_kallsyms_ref_reloc_sym() from being called in
> > machine__create_kernel_maps(), resulting in kmap->ref_reloc_sym being
> > NULL in _perf_event__synthesize_kernel_mmap() and a segmentation
> > fault.
>
> Can you please try with my perf/cap branch? Perhaps you're using Igor's
> original set of patches? I made changes to the fallback, he was making
> it return false while I made it fallback to geteuid() == 0, as was
> before his patches.
Things are working properly on your perf/cap branch. I tested with on
both x86 and ARM.
Mathieu
>
> - Arnaldo
>
> > I am not sure how this can be fixed. I counted a total of 19
> > instances where kmap->ref_reloc_sym->XYZ is called, only 2 of wich
> > care to check if kmap->ref_reloc_sym is valid before proceeding. As
> > such I must hope that in the 17 other cases, kmap->ref_reloc_sym is
> > guaranteed to be valid. If I am correct then all we need is to check
> > for a valid pointer in _perf_event__synthesize_kernel_mmap().
> > Otherwise it will be a little harder.
> >
> > Mathieu
>
> --
>
> - Arnaldo
_______________________________________________
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] arm64: implement KPROBES_ON_FTRACE
From: Naveen N. Rao @ 2019-08-19 16:52 UTC (permalink / raw)
To: Anil S Keshavamurthy, Borislav Petkov, Catalin Marinas,
David S. Miller, H. Peter Anvin, Jisheng Zhang, Masami,
Hiramatsu, Ingo Molnar, Steven Rostedt, Thomas Gleixner,
Will Deacon
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190819192706.46ce2c1d@xhacker.debian>
Jisheng Zhang wrote:
> This patch implements KPROBES_ON_FTRACE for arm64.
>
> ~ # mount -t debugfs debugfs /sys/kernel/debug/
> ~ # cd /sys/kernel/debug/
> /sys/kernel/debug # echo 'p _do_fork' > tracing/kprobe_events
>
> before the patch:
>
> /sys/kernel/debug # cat kprobes/list
> ffffff801009ff7c k _do_fork+0x4 [DISABLED]
This looks wrong -- we should not be allowing kprobe to be registered on
ftrace address without KPROBES_ON_FTRACE. Is _do_fork+0x4 the location
of ftrace entry on arm64?
- Naveen
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Enabling UBSAN breaks KCOV in clang (8.0.*) on arm64
From: Mark Rutland @ 2019-08-19 16:59 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, clang-built-linux
Cc: Nathan Chancellor, Nick Desaulniers
Hi,
I found that when I enable both KCOV and UBSAN on arm64, clang fails to
emit any __sanitizer_cov_trace_*() calls in the resulting binary,
rendering KCOV useless.
For example, when building v5.3-rc3's arch/arm64/kernel/setup.o:
* With defconfig + CONFIG KCOV:
clang -Wp,-MD,arch/arm64/kernel/.setup.o.d -nostdinc -isystem
/mnt/data/opt/toolchain/llvm/8.0.0/clang+llvm-8.0.0-x86_64-linux-sles11.3/lib/clang/8.0.0/include
-I./arch/arm64/include -I./arch/arm64/include/generated -I./include
-I./arch/arm64/include/uapi -I./arch/arm64/include/generated/uapi
-I./include/uapi -I./include/generated/uapi -include
./include/linux/kconfig.h -include ./include/linux/compiler_types.h
-D__KERNEL__ -mlittle-endian -DKASAN_SHADOW_SCALE_SHIFT=3
-Qunused-arguments -Wall -Wundef -Werror=strict-prototypes
-Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE
-Werror=implicit-function-declaration -Werror=implicit-int
-Wno-format-security -std=gnu89 --target=aarch64-linux
--prefix=/mnt/data/opt/toolchain/kernel-org-crosstool/gcc-8.1.0-nolibc/aarch64-linux/bin/
--gcc-toolchain=/mnt/data/opt/toolchain/kernel-org-crosstool/gcc-8.1.0-nolibc/aarch64-linux
-no-integrated-as -Werror=unknown-warning-option -mgeneral-regs-only
-DCONFIG_AS_LSE=1 -fno-asynchronous-unwind-tables
-DKASAN_SHADOW_SCALE_SHIFT=3 -fno-delete-null-pointer-checks
-Wno-address-of-packed-member -O2 -Wframe-larger-than=2048
-fstack-protector-strong -Wno-format-invalid-specifier -Wno-gnu
-Wno-tautological-compare -mno-global-merge -Wno-unused-const-variable
-fno-omit-frame-pointer -fno-optimize-sibling-calls -g
-Wdeclaration-after-statement -Wvla -Wno-pointer-sign
-fno-strict-overflow -fno-merge-all-constants -fno-stack-check
-Werror=date-time -Werror=incompatible-pointer-types
-Wno-initializer-overrides -Wno-format -Wno-sign-compare
-Wno-format-zero-length -fsanitize-coverage=trace-pc
-DKBUILD_BASENAME='"setup"' -DKBUILD_MODNAME='"setup"' -c -o
arch/arm64/kernel/setup.o arch/arm64/kernel/setup.c
... and there are 44 calls to __sanitizer_cov_trace_pc in the
resulting setup.o
* with defconfig + CONFIG_KCOV + CONFIG_UBSAN:
clang -Wp,-MD,arch/arm64/kernel/.setup.o.d -nostdinc -isystem
/mnt/data/opt/toolchain/llvm/8.0.0/clang+llvm-8.0.0-x86_64-linux-sles11.3/lib/clang/8.0.0/include
-I./arch/arm64/include -I./arch/arm64/include/generated -I./include
-I./arch/arm64/include/uapi -I./arch/arm64/include/generated/uapi
-I./include/uapi -I./include/generated/uapi -include
./include/linux/kconfig.h -include ./include/linux/compiler_types.h
-D__KERNEL__ -mlittle-endian -DKASAN_SHADOW_SCALE_SHIFT=3
-Qunused-arguments -Wall -Wundef -Werror=strict-prototypes
-Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE
-Werror=implicit-function-declaration -Werror=implicit-int
-Wno-format-security -std=gnu89 --target=aarch64-linux
--prefix=/mnt/data/opt/toolchain/kernel-org-crosstool/gcc-8.1.0-nolibc/aarch64-linux/bin/
--gcc-toolchain=/mnt/data/opt/toolchain/kernel-org-crosstool/gcc-8.1.0-nolibc/aarch64-linux
-no-integrated-as -Werror=unknown-warning-option -mgeneral-regs-only
-DCONFIG_AS_LSE=1 -fno-asynchronous-unwind-tables
-DKASAN_SHADOW_SCALE_SHIFT=3 -fno-delete-null-pointer-checks
-Wno-address-of-packed-member -O2 -Wframe-larger-than=2048
-fstack-protector-strong -Wno-format-invalid-specifier -Wno-gnu
-Wno-tautological-compare -mno-global-merge -Wno-unused-const-variable
-fno-omit-frame-pointer -fno-optimize-sibling-calls -g
-Wdeclaration-after-statement -Wvla -Wno-pointer-sign
-fno-strict-overflow -fno-merge-all-constants -fno-stack-check
-Werror=date-time -Werror=incompatible-pointer-types
-Wno-initializer-overrides -Wno-format -Wno-sign-compare
-Wno-format-zero-length -fsanitize=shift
-fsanitize=integer-divide-by-zero -fsanitize=unreachable
-fsanitize=signed-integer-overflow -fsanitize=bounds
-fsanitize=object-size -fsanitize=bool -fsanitize=enum
-fsanitize-coverage=trace-pc -DKBUILD_BASENAME='"setup"'
-DKBUILD_MODNAME='"setup"' -c -o arch/arm64/kernel/setup.o
arch/arm64/kernel/setup.c
... and there are 0 calls to __sanitizer_cov_trace_pc in the resulting
setup.o, even though -fsanitize-coverage=trace-pc was passed to clang.
If I remove -fsanitize=bounds, there are 121 calls to
__sanitizer_cov_trace_pc in setup.o. Removing the other options enabled
by UBSAN didn't have any effect on setup.o.
I'm using the llvm.org 8.0.{0,1} binaries [1,2], along with the
kernel.org crosstool 8.1.0 binaries [3].
Any ideas as to what's going on?
Thanks,
Mark.
[1] http://releases.llvm.org/download.html#8.0.0
[2] http://releases.llvm.org/download.html#8.0.1
[3] https://mirrors.edge.kernel.org/pub/tools/crosstool/
_______________________________________________
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 v12 09/12] soc: mediatek: cmdq: define the instruction struct
From: houlong wei @ 2019-08-19 17:00 UTC (permalink / raw)
To: Bibby Hsieh
Cc: devicetree@vger.kernel.org, Nicolas Boichat, Philipp Zabel,
srv_heupstream, Daoyuan Huang (黃道原),
Sascha Hauer, Jassi Brar, linux-kernel@vger.kernel.org,
Daniel Kurtz, houlong.wei, YT Shen (沈岳霆),
CK Hu (胡俊光), Rob Herring,
linux-mediatek@lists.infradead.org,
Ginny Chen (陳治傑), Sascha Hauer,
Matthias Brugger, Jiaguang Zhang (张加广),
linux-arm-kernel@lists.infradead.org,
Dennis-YC Hsieh (謝宇哲)
In-Reply-To: <20190819025359.11381-10-bibby.hsieh@mediatek.com>
On Mon, 2019-08-19 at 10:53 +0800, Bibby Hsieh wrote:
> Define an instruction structure for gce driver to append command.
> This structure can make the client's code more readability.
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> Reviewed-by: CK Hu <ck.hu@mediatek.com>
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 105 +++++++++++++++--------
> include/linux/mailbox/mtk-cmdq-mailbox.h | 2 +
> 2 files changed, 73 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 7aa0517ff2f3..e1e41914ed7a 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -9,12 +9,24 @@
> #include <linux/mailbox_controller.h>
> #include <linux/soc/mediatek/mtk-cmdq.h>
>
> -#define CMDQ_ARG_A_WRITE_MASK 0xffff
> #define CMDQ_WRITE_ENABLE_MASK BIT(0)
> #define CMDQ_EOC_IRQ_EN BIT(0)
> #define CMDQ_EOC_CMD ((u64)((CMDQ_CODE_EOC << CMDQ_OP_CODE_SHIFT)) \
> << 32 | CMDQ_EOC_IRQ_EN)
>
> +struct cmdq_instruction {
> + union {
> + u32 value;
> + u32 mask;
> + };
> + union {
> + u16 offset;
> + u16 event;
> + };
> + u8 subsys;
> + u8 op;
> +};
> +
> static void cmdq_client_timeout(struct timer_list *t)
> {
> struct cmdq_client *client = from_timer(client, t, timer);
> @@ -110,10 +122,8 @@ void cmdq_pkt_destroy(struct cmdq_pkt *pkt)
> }
> EXPORT_SYMBOL(cmdq_pkt_destroy);
>
> -static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
> - u32 arg_a, u32 arg_b)
> +static struct cmdq_instruction *cmdq_pkt_append_command(struct cmdq_pkt *pkt)
> {
> - u64 *cmd_ptr;
>
> if (unlikely(pkt->cmd_buf_size + CMDQ_INST_SIZE > pkt->buf_size)) {
> /*
> @@ -127,81 +137,108 @@ static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
> pkt->cmd_buf_size += CMDQ_INST_SIZE;
> WARN_ONCE(1, "%s: buffer size %u is too small !\n",
> __func__, (u32)pkt->buf_size);
> - return -ENOMEM;
> + return NULL;
> }
> - cmd_ptr = pkt->va_base + pkt->cmd_buf_size;
> - (*cmd_ptr) = (u64)((code << CMDQ_OP_CODE_SHIFT) | arg_a) << 32 | arg_b;
> +
> pkt->cmd_buf_size += CMDQ_INST_SIZE;
>
> - return 0;
> + return pkt->va_base + pkt->cmd_buf_size - CMDQ_INST_SIZE;
> }
>
> int cmdq_pkt_write(struct cmdq_pkt *pkt, u8 subsys, u16 offset, u32 value)
> {
> - u32 arg_a = (offset & CMDQ_ARG_A_WRITE_MASK) |
> - (subsys << CMDQ_SUBSYS_SHIFT);
> + struct cmdq_instruction *inst;
> +
> + inst = cmdq_pkt_append_command(pkt);
> + if (!inst)
> + return -ENOMEM;
> +
> + inst->op = CMDQ_CODE_WRITE;
> + inst->value = value;
> + inst->offset = offset;
> + inst->subsys = subsys;
>
> - return cmdq_pkt_append_command(pkt, CMDQ_CODE_WRITE, arg_a, value);
> + return 0;
> }
> EXPORT_SYMBOL(cmdq_pkt_write);
>
> int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
> u16 offset, u32 value, u32 mask)
> {
> - u32 offset_mask = offset;
> - int err = 0;
> + struct cmdq_instruction *inst;
> + u16 offset_mask = offset;
>
> if (mask != 0xffffffff) {
> - err = cmdq_pkt_append_command(pkt, CMDQ_CODE_MASK, 0, ~mask);
> + inst = cmdq_pkt_append_command(pkt);
> + if (!inst)
> + return -ENOMEM;
> +
> + inst->op = CMDQ_CODE_MASK;
> + inst->mask = ~mask;
> offset_mask |= CMDQ_WRITE_ENABLE_MASK;
I think we should consider the reusing command packet case, I commented
via link below and there were discussion before.
http://lists.infradead.org/pipermail/linux-mediatek/2019-August/022052.html
Before this patch, each 64-bit of an instruction is set. But now some
bits may be ignored and keep the original values. That may make us
confused when we analyze the instruction for debugging.
> }
> - err |= cmdq_pkt_write(pkt, value, subsys, offset_mask);
>
> - return err;
> + return cmdq_pkt_write(pkt, subsys, offset_mask, value);
> }
> EXPORT_SYMBOL(cmdq_pkt_write_mask);
>
> int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
> {
> - u32 arg_b;
> + struct cmdq_instruction *inst;
>
> if (event >= CMDQ_MAX_EVENT)
> return -EINVAL;
>
> - /*
> - * WFE arg_b
> - * bit 0-11: wait value
> - * bit 15: 1 - wait, 0 - no wait
> - * bit 16-27: update value
> - * bit 31: 1 - update, 0 - no update
> - */
> - arg_b = CMDQ_WFE_UPDATE | CMDQ_WFE_WAIT | CMDQ_WFE_WAIT_VALUE;
> + inst = cmdq_pkt_append_command(pkt);
> + if (!inst)
> + return -ENOMEM;
> +
> + inst->op = CMDQ_CODE_WFE;
> + inst->value = CMDQ_WFE_OPTION;
> + inst->event = event;
>
> - return cmdq_pkt_append_command(pkt, CMDQ_CODE_WFE, event, arg_b);
> + return 0;
> }
> EXPORT_SYMBOL(cmdq_pkt_wfe);
>
> int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
> {
> + struct cmdq_instruction *inst;
> +
> if (event >= CMDQ_MAX_EVENT)
> return -EINVAL;
>
> - return cmdq_pkt_append_command(pkt, CMDQ_CODE_WFE, event,
> - CMDQ_WFE_UPDATE);
> + inst = cmdq_pkt_append_command(pkt);
> + if (!inst)
> + return -ENOMEM;
> +
> + inst->op = CMDQ_CODE_WFE;
> + inst->value = CMDQ_WFE_UPDATE;
> + inst->event = event;
> +
> + return 0;
> }
> EXPORT_SYMBOL(cmdq_pkt_clear_event);
>
> static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> {
> - int err;
> + struct cmdq_instruction *inst;
> +
> + inst = cmdq_pkt_append_command(pkt);
> + if (!inst)
> + return -ENOMEM;
>
> - /* insert EOC and generate IRQ for each command iteration */
> - err = cmdq_pkt_append_command(pkt, CMDQ_CODE_EOC, 0, CMDQ_EOC_IRQ_EN);
> + inst->op = CMDQ_CODE_EOC;
> + inst->value = CMDQ_EOC_IRQ_EN;
>
> - /* JUMP to end */
> - err |= cmdq_pkt_append_command(pkt, CMDQ_CODE_JUMP, 0, CMDQ_JUMP_PASS);
> + inst = cmdq_pkt_append_command(pkt);
> + if (!inst)
> + return -ENOMEM;
> +
> + inst->op = CMDQ_CODE_JUMP;
> + inst->value = CMDQ_JUMP_PASS;
>
> - return err;
> + return 0;
> }
>
> static void cmdq_pkt_flush_async_cb(struct cmdq_cb_data data)
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index 911475da7a53..c8adedefaf42 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -19,6 +19,8 @@
> #define CMDQ_WFE_UPDATE BIT(31)
> #define CMDQ_WFE_WAIT BIT(15)
> #define CMDQ_WFE_WAIT_VALUE 0x1
> +#define CMDQ_WFE_OPTION (CMDQ_WFE_UPDATE | CMDQ_WFE_WAIT | \
> + CMDQ_WFE_WAIT_VALUE)
> /** cmdq event maximum */
> #define CMDQ_MAX_EVENT 0x3ff
>
_______________________________________________
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][next] soc: samsung: exynos-chipid: fix memory leak
From: Krzysztof Kozlowski @ 2019-08-19 17:09 UTC (permalink / raw)
To: Colin King
Cc: linux-samsung-soc, Pankaj Dubey, kernel-janitors, linux-kernel,
Kukjin Kim, linux-arm-kernel
In-Reply-To: <20190816222151.11098-1-colin.king@canonical.com>
On Fri, Aug 16, 2019 at 11:21:51PM +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Currently when the call to product_id_to_soc_id fails there
> is a memory leak of soc_dev_attr->revision and soc_dev_attr
> on the error return path. Fix this by adding a common error
> return path that frees there obects and use this for two
> error return paths.
>
> Addresses-Coverity: ("Resource leak")
> Fixes: 3253b7b7cd44 ("soc: samsung: Add exynos chipid driver support")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/soc/samsung/exynos-chipid.c | 14 ++++++++++----
Thanks, applied.
Best regards,
Krzysztof
_______________________________________________
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 v12 11/12] soc: mediatek: cmdq: add cmdq_dev_get_client_reg function
From: houlong wei @ 2019-08-19 17:24 UTC (permalink / raw)
To: Bibby Hsieh
Cc: devicetree@vger.kernel.org, Nicolas Boichat, Philipp Zabel,
srv_heupstream, Daoyuan Huang (黃道原),
Sascha Hauer, Jassi Brar, linux-kernel@vger.kernel.org,
Daniel Kurtz, YT Shen (沈岳霆),
CK Hu (胡俊光), Rob Herring,
linux-mediatek@lists.infradead.org,
Ginny Chen (陳治傑), Sascha Hauer, houlon.wei,
Matthias Brugger, Jiaguang Zhang (张加广),
linux-arm-kernel@lists.infradead.org,
Dennis-YC Hsieh (謝宇哲)
In-Reply-To: <20190819025359.11381-12-bibby.hsieh@mediatek.com>
On Mon, 2019-08-19 at 10:53 +0800, Bibby Hsieh wrote:
> GCE cannot know the register base address, this function
> can help cmdq client to get the cmdq_client_reg structure.
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 29 ++++++++++++++++++++++++++
> include/linux/soc/mediatek/mtk-cmdq.h | 21 +++++++++++++++++++
> 2 files changed, 50 insertions(+)
>
[...]
>
> +/**
> + * cmdq_dev_get_client_reg() - parse cmdq client reg from the device
> + * node of CMDQ client
> + * @dev: device of CMDQ mailbox clienti
'clienti' looks like a typo, 'client'?
> + * @client_reg: CMDQ client reg pointer
> + * @idx: the index of desired reg
> + *
> + * Return: 0 for success; else the error code is returned
> + *
> + * Help CMDQ client pasing the cmdq client reg
'pasing' looks like a typo, 'parsing'?
> + * from the device node of CMDQ client.
> + */
> +int cmdq_dev_get_client_reg(struct device *dev,
> + struct cmdq_client_reg *client_reg, int idx);
> +
> /**
> * cmdq_mbox_create() - create CMDQ mailbox client and channel
> * @dev: device of CMDQ mailbox client
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 0/2] add imx8mq nitrogen support - changes since v3
From: Dafna Hirschfeld @ 2019-08-19 17:26 UTC (permalink / raw)
To: dafna.hirschfeld
Cc: mark.rutland, devicetree, ezequiel, s.hauer, linux-kernel,
robh+dt, kernel, kernel, shawnguo, linux-arm-kernel
change log:
patch 1: no changes
patch 2:
- gpio-key,wakeup -> source-wakeup
- newline between property list and child nodes.
- settting pinctrl nodes names to: "pinctrl_xxx: xxxgrp {"
Gary Bisson (2):
dt-bindings: arm: imx: add imx8mq nitrogen support
arm64: dts: imx: Add i.mx8mq nitrogen8m basic dts support
.../devicetree/bindings/arm/fsl.yaml | 1 +
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../boot/dts/freescale/imx8mq-nitrogen.dts | 405 ++++++++++++++++++
3 files changed, 407 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mq-nitrogen.dts
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 1/2] dt-bindings: arm: imx: add imx8mq nitrogen support
From: Dafna Hirschfeld @ 2019-08-19 17:26 UTC (permalink / raw)
To: dafna.hirschfeld
Cc: mark.rutland, devicetree, ezequiel, s.hauer, linux-kernel,
Troy Kisky, Gary Bisson, robh+dt, kernel, kernel, shawnguo,
linux-arm-kernel
In-Reply-To: <20190819172606.6410-1-dafna.hirschfeld@collabora.com>
From: Gary Bisson <gary.bisson@boundarydevices.com>
The Nitrogen8M is an ARM based single board computer (SBC)
designed to leverage the full capabilities of NXP’s i.MX8M
Quad processor.
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
[Dafna: porting vendor's code to mainline]
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 362bf827cad1..16db1c699ba7 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -224,6 +224,7 @@ properties:
- description: i.MX8MQ based Boards
items:
- enum:
+ - boundary,imx8mq-nitrogen8m # i.MX8MQ NITROGEN Board
- fsl,imx8mq-evk # i.MX8MQ EVK Board
- purism,librem5-devkit # Purism Librem5 devkit
- technexion,pico-pi-imx8m # TechNexion PICO-PI-8M evk
--
2.20.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 v4 2/2] arm64: dts: imx: Add i.mx8mq nitrogen8m basic dts support
From: Dafna Hirschfeld @ 2019-08-19 17:26 UTC (permalink / raw)
To: dafna.hirschfeld
Cc: mark.rutland, devicetree, ezequiel, s.hauer, linux-kernel,
Troy Kisky, Gary Bisson, robh+dt, kernel, kernel, shawnguo,
linux-arm-kernel
In-Reply-To: <20190819172606.6410-1-dafna.hirschfeld@collabora.com>
From: Gary Bisson <gary.bisson@boundarydevices.com>
Add basic dts support for i.MX8MQ NITROGEN8M.
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
[Dafna: porting vendor's code to mainline]
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../boot/dts/freescale/imx8mq-nitrogen.dts | 405 ++++++++++++++++++
2 files changed, 406 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mq-nitrogen.dts
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 8c0c4343e586..e2c6c93f47b6 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -25,6 +25,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5-devkit.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mq-nitrogen.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-pico-pi.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-rmb3.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-zest.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-nitrogen.dts b/arch/arm64/boot/dts/freescale/imx8mq-nitrogen.dts
new file mode 100644
index 000000000000..c832bf0fcc60
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mq-nitrogen.dts
@@ -0,0 +1,405 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2018 Boundary Devices
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/input/input.h>
+#include "imx8mq.dtsi"
+
+/ {
+ model = "Boundary Devices i.MX8MQ Nitrogen8M";
+ compatible = "boundary,imx8mq-nitrogen8m", "fsl,imx8mq";
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@40000000 {
+ device_type = "memory";
+ reg = <0x00000000 0x40000000 0 0x80000000>;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_keys>;
+
+ power {
+ label = "Power Button";
+ gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_POWER>;
+ wakeup-source;
+ };
+ };
+
+ reg_vref_0v9: regulator-vref-0v9 {
+ compatible = "regulator-fixed";
+ regulator-name = "vref-0v9";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+ };
+
+ reg_vref_1v8: regulator-vref-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "vref-1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ reg_vref_2v5: regulator-vref-2v5 {
+ compatible = "regulator-fixed";
+ regulator-name = "vref-2v5";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ };
+
+ reg_vref_3v3: regulator-vref-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vref-3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ reg_vref_5v: regulator-vref-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "vref-5v";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+};
+
+
+&fec1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec1>;
+ phy-mode = "rgmii-id";
+ phy-handle = <ðphy0>;
+ fsl,magic-packet;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@4 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <4>;
+ interrupts-extended = <&gpio1 11 IRQ_TYPE_LEVEL_LOW>;
+ };
+ };
+};
+
+&i2c1 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+
+ i2cmux@70 {
+ compatible = "nxp,pca9546";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1_pca9546>;
+ reg = <0x70>;
+ reset-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c1a: i2c1@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg_arm_dram: regulator@60 {
+ compatible = "fcs,fan53555";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_arm_dram>;
+ reg = <0x60>;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-always-on;
+ vsel-gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ i2c1b: i2c1@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg_dram_1p1v: regulator@60 {
+ compatible = "fcs,fan53555";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_dram_1p1v>;
+ reg = <0x60>;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-always-on;
+ vsel-gpios = <&gpio2 11 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ i2c1c: i2c1@2 {
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg_soc_gpu_vpu: regulator@60 {
+ compatible = "fcs,fan53555";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_soc_gpu_vpu>;
+ reg = <0x60>;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-always-on;
+ vsel-gpios = <&gpio2 20 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ i2c1d: i2c1@3 {
+ reg = <3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rtc@68 {
+ compatible = "microcrystal,rv4162";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1d_rv4162>;
+ reg = <0x68>;
+ interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_LOW>;
+ wakeup-source;
+ };
+ };
+ };
+};
+
+&uart1 { /* console */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ assigned-clocks = <&clk IMX8MQ_CLK_UART1>;
+ assigned-clock-parents = <&clk IMX8MQ_CLK_25M>;
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ assigned-clocks = <&clk IMX8MQ_CLK_UART2>;
+ assigned-clock-parents = <&clk IMX8MQ_CLK_25M>;
+ status = "okay";
+};
+
+&usdhc1 {
+ bus-width = <8>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ non-removable;
+ vmmc-supply = <®_vref_1v8>;
+ status = "okay";
+};
+
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ fsl,ext-reset-output;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hog>;
+
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ /* J17 connector, odd */
+ MX8MQ_IOMUXC_SAI1_RXFS_GPIO4_IO0 0x19 /* Pin 19 */
+ MX8MQ_IOMUXC_SAI1_RXC_GPIO4_IO1 0x19 /* Pin 21 */
+ MX8MQ_IOMUXC_SAI1_RXD1_GPIO4_IO3 0x19 /* Pin 23 */
+ MX8MQ_IOMUXC_SAI1_RXD2_GPIO4_IO4 0x19 /* Pin 25 */
+ MX8MQ_IOMUXC_SAI1_RXD3_GPIO4_IO5 0x19 /* Pin 27 */
+ MX8MQ_IOMUXC_SAI1_RXD4_GPIO4_IO6 0x19 /* Pin 29 */
+ MX8MQ_IOMUXC_SAI1_RXD5_GPIO4_IO7 0x19 /* Pin 31 */
+ MX8MQ_IOMUXC_SAI1_RXD6_GPIO4_IO8 0x19 /* Pin 33 */
+ MX8MQ_IOMUXC_SAI1_RXD7_GPIO4_IO9 0x19 /* Pin 35 */
+ MX8MQ_IOMUXC_SAI1_TXD1_GPIO4_IO13 0x19 /* Pin 39 */
+ MX8MQ_IOMUXC_SAI1_TXD2_GPIO4_IO14 0x19 /* Pin 41 */
+ MX8MQ_IOMUXC_SAI1_TXD3_GPIO4_IO15 0x19 /* Pin 43 */
+ MX8MQ_IOMUXC_SAI1_TXD4_GPIO4_IO16 0x19 /* Pin 45 */
+ MX8MQ_IOMUXC_SAI1_TXD5_GPIO4_IO17 0x19 /* Pin 47 */
+ MX8MQ_IOMUXC_SAI1_TXD6_GPIO4_IO18 0x19 /* Pin 49 */
+ MX8MQ_IOMUXC_SAI1_TXD7_GPIO4_IO19 0x19 /* Pin 51 */
+
+ /* J17 connector, even */
+ MX8MQ_IOMUXC_SAI3_RXFS_GPIO4_IO28 0x19 /* Pin 44 */
+ MX8MQ_IOMUXC_SAI3_RXC_GPIO4_IO29 0x19 /* Pin 48 */
+ MX8MQ_IOMUXC_GPIO1_IO10_GPIO1_IO10 0x19 /* Pin 50 */
+ MX8MQ_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x19 /* Pin 54 */
+ MX8MQ_IOMUXC_GPIO1_IO05_GPIO1_IO5 0x19 /* Pin 56 */
+
+ /* J18 connector, odd */
+ MX8MQ_IOMUXC_NAND_CE3_B_GPIO3_IO4 0x19 /* Pin 41 */
+ MX8MQ_IOMUXC_NAND_CLE_GPIO3_IO5 0x19 /* Pin 43 */
+ MX8MQ_IOMUXC_NAND_READY_B_GPIO3_IO16 0x19 /* Pin 45 */
+ MX8MQ_IOMUXC_NAND_DATA05_GPIO3_IO11 0x19 /* Pin 47 */
+ MX8MQ_IOMUXC_NAND_WP_B_GPIO3_IO18 0x19 /* Pin 49 */
+ MX8MQ_IOMUXC_NAND_DQS_GPIO3_IO14 0x19 /* Pin 53 */
+
+ /* J18 connector, even */
+ MX8MQ_IOMUXC_NAND_ALE_GPIO3_IO0 0x19 /* Pin 32 */
+ MX8MQ_IOMUXC_NAND_CE0_B_GPIO3_IO1 0x19 /* Pin 36 */
+ MX8MQ_IOMUXC_NAND_DATA00_GPIO3_IO6 0x19 /* Pin 38 */
+ MX8MQ_IOMUXC_NAND_DATA01_GPIO3_IO7 0x19 /* Pin 40 */
+ MX8MQ_IOMUXC_NAND_DATA02_GPIO3_IO8 0x19 /* Pin 42 */
+ MX8MQ_IOMUXC_NAND_DATA03_GPIO3_IO9 0x19 /* Pin 44 */
+ MX8MQ_IOMUXC_NAND_DATA04_GPIO3_IO10 0x19 /* Pin 46 */
+
+ /* J13 Pin 2, WL_WAKE */
+ MX8MQ_IOMUXC_SAI5_RXD2_GPIO3_IO23 0xd6
+ /* J13 Pin 4, WL_IRQ, not needed for Silex */
+ MX8MQ_IOMUXC_SAI5_RXD0_GPIO3_IO21 0xd6
+ /* J13 pin 9, unused */
+ MX8MQ_IOMUXC_SD2_CD_B_GPIO2_IO12 0x19
+ /* J13 Pin 41, BT_CLK_REQ */
+ MX8MQ_IOMUXC_SAI5_RXD1_GPIO3_IO22 0xd6
+ /* J13 Pin 42, BT_HOST_WAKE */
+ MX8MQ_IOMUXC_SAI5_MCLK_GPIO3_IO25 0xd6
+
+ /* Clock for both CSI1 and CSI2 */
+ MX8MQ_IOMUXC_GPIO1_IO15_CCMSRCGPCMIX_CLKO2 0x07
+ /* test points */
+ MX8MQ_IOMUXC_GPIO1_IO04_GPIO1_IO4 0xc1 /* TP87 */
+ >;
+ };
+
+ pinctrl_fec1: fec1grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_ENET_MDC_ENET1_MDC 0x3
+ MX8MQ_IOMUXC_ENET_MDIO_ENET1_MDIO 0x23
+ MX8MQ_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL 0x1f
+ MX8MQ_IOMUXC_ENET_TXC_ENET1_RGMII_TXC 0x1f
+ MX8MQ_IOMUXC_ENET_TD0_ENET1_RGMII_TD0 0x1f
+ MX8MQ_IOMUXC_ENET_TD1_ENET1_RGMII_TD1 0x1f
+ MX8MQ_IOMUXC_ENET_TD2_ENET1_RGMII_TD2 0x1f
+ MX8MQ_IOMUXC_ENET_TD3_ENET1_RGMII_TD3 0x1f
+ MX8MQ_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL 0x91
+ MX8MQ_IOMUXC_ENET_RXC_ENET1_RGMII_RXC 0x91
+ MX8MQ_IOMUXC_ENET_RD0_ENET1_RGMII_RD0 0x91
+ MX8MQ_IOMUXC_ENET_RD1_ENET1_RGMII_RD1 0x91
+ MX8MQ_IOMUXC_ENET_RD2_ENET1_RGMII_RD2 0x91
+ MX8MQ_IOMUXC_ENET_RD3_ENET1_RGMII_RD3 0x91
+ MX8MQ_IOMUXC_GPIO1_IO09_GPIO1_IO9 0x19
+ MX8MQ_IOMUXC_GPIO1_IO11_GPIO1_IO11 0x59
+ >;
+ };
+
+ pinctrl_gpio_keys: gpio-keysgrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_GPIO1_IO07_GPIO1_IO7 0x19
+ >;
+ };
+
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_I2C1_SCL_I2C1_SCL 0x4000007f
+ MX8MQ_IOMUXC_I2C1_SDA_I2C1_SDA 0x4000007f
+ >;
+ };
+
+ pinctrl_i2c1_pca9546: i2c1-pca9546grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_GPIO1_IO08_GPIO1_IO8 0x49
+ >;
+ };
+
+ pinctrl_i2c1d_rv4162: i2c1d-rv4162grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_GPIO1_IO06_GPIO1_IO6 0x49
+ >;
+ };
+
+ pinctrl_reg_arm_dram: reg-arm-dramgrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SAI5_RXD3_GPIO3_IO24 0x16
+ >;
+ };
+
+ pinctrl_reg_dram_1p1v: reg-dram-1p1vgrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD1_STROBE_GPIO2_IO11 0x16
+ >;
+ };
+
+ pinctrl_reg_soc_gpu_vpu: reg-soc-gpu-vpugrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD2_WP_GPIO2_IO20 0x16
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_UART1_RXD_UART1_DCE_RX 0x45
+ MX8MQ_IOMUXC_UART1_TXD_UART1_DCE_TX 0x45
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_UART2_RXD_UART2_DCE_RX 0x45
+ MX8MQ_IOMUXC_UART2_TXD_UART2_DCE_TX 0x45
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x83
+ MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xc3
+ MX8MQ_IOMUXC_SD1_DATA0_USDHC1_DATA0 0xc3
+ MX8MQ_IOMUXC_SD1_DATA1_USDHC1_DATA1 0xc3
+ MX8MQ_IOMUXC_SD1_DATA2_USDHC1_DATA2 0xc3
+ MX8MQ_IOMUXC_SD1_DATA3_USDHC1_DATA3 0xc3
+ MX8MQ_IOMUXC_SD1_DATA4_USDHC1_DATA4 0xc3
+ MX8MQ_IOMUXC_SD1_DATA5_USDHC1_DATA5 0xc3
+ MX8MQ_IOMUXC_SD1_DATA6_USDHC1_DATA6 0xc3
+ MX8MQ_IOMUXC_SD1_DATA7_USDHC1_DATA7 0xc3
+ MX8MQ_IOMUXC_SD1_RESET_B_GPIO2_IO10 0x41
+ >;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x8d
+ MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xcd
+ MX8MQ_IOMUXC_SD1_DATA0_USDHC1_DATA0 0xcd
+ MX8MQ_IOMUXC_SD1_DATA1_USDHC1_DATA1 0xcd
+ MX8MQ_IOMUXC_SD1_DATA2_USDHC1_DATA2 0xcd
+ MX8MQ_IOMUXC_SD1_DATA3_USDHC1_DATA3 0xcd
+ MX8MQ_IOMUXC_SD1_DATA4_USDHC1_DATA4 0xcd
+ MX8MQ_IOMUXC_SD1_DATA5_USDHC1_DATA5 0xcd
+ MX8MQ_IOMUXC_SD1_DATA6_USDHC1_DATA6 0xcd
+ MX8MQ_IOMUXC_SD1_DATA7_USDHC1_DATA7 0xcd
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x9f
+ MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xdf
+ MX8MQ_IOMUXC_SD1_DATA0_USDHC1_DATA0 0xdf
+ MX8MQ_IOMUXC_SD1_DATA1_USDHC1_DATA1 0xdf
+ MX8MQ_IOMUXC_SD1_DATA2_USDHC1_DATA2 0xdf
+ MX8MQ_IOMUXC_SD1_DATA3_USDHC1_DATA3 0xdf
+ MX8MQ_IOMUXC_SD1_DATA4_USDHC1_DATA4 0xdf
+ MX8MQ_IOMUXC_SD1_DATA5_USDHC1_DATA5 0xdf
+ MX8MQ_IOMUXC_SD1_DATA6_USDHC1_DATA6 0xdf
+ MX8MQ_IOMUXC_SD1_DATA7_USDHC1_DATA7 0xdf
+ >;
+ };
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B 0xc6
+ >;
+ };
+};
--
2.20.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
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