[GIT PULL] arm64 fixes for 4.17-rc2

Hi Linus, Please pull the arm64 fixes below. Thanks. The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes

Re: [RFC] mm: kmemleak: replace __GFP_NOFAIL to GFP_NOWAIT in gfp_kmemleak_mask

On Sat, Apr 21, 2018 at 12:58:33AM +0800, Chunyu Hu wrote: > __GFP_NORETRY and __GFP_NOFAIL are combined in gfp_kmemleak_mask now. > But it's a wrong combination. As __GFP_NOFAIL is blockable, but > __GFP_NORETY is not blockable, make it self-contradiction. > > __GFP_NOFAIL means 'The VM

Re: [RFC] mm: kmemleak: replace __GFP_NOFAIL to GFP_NOWAIT in gfp_kmemleak_mask

On Sat, Apr 21, 2018 at 12:58:33AM +0800, Chunyu Hu wrote: > __GFP_NORETRY and __GFP_NOFAIL are combined in gfp_kmemleak_mask now. > But it's a wrong combination. As __GFP_NOFAIL is blockable, but > __GFP_NORETY is not blockable, make it self-contradiction. > > __GFP_NOFAIL means 'The VM

Re: [PATCH] treewide: use PHYS_ADDR_MAX to avoid type casting ULLONG_MAX

_t)ULLONG_MAX > +PHYS_ADDR_MAX > // > > Signed-off-by: Stefan Agner <ste...@agner.ch> > --- > arch/arm64/mm/init.c | 6 +++--- For arm64: Acked-by: Catalin Marinas <catalin.mari...@arm.com>

Re: [PATCH] treewide: use PHYS_ADDR_MAX to avoid type casting ULLONG_MAX

_t)ULLONG_MAX > +PHYS_ADDR_MAX > // > > Signed-off-by: Stefan Agner > --- > arch/arm64/mm/init.c | 6 +++--- For arm64: Acked-by: Catalin Marinas

Re: [PATCH v2 00/13] kernel/locking: qspinlock improvements

On Wed, Apr 11, 2018 at 07:01:07PM +0100, Will Deacon wrote: > * Spin for a bounded duration while lock is observed in the > pending->locked transition FWIW, I updated my model [1] to include the bounded handover loop and, as expected, it passes the liveness check (well, assuming fairness

Re: [PATCH v2 00/13] kernel/locking: qspinlock improvements

On Wed, Apr 11, 2018 at 07:01:07PM +0100, Will Deacon wrote: > * Spin for a bounded duration while lock is observed in the > pending->locked transition FWIW, I updated my model [1] to include the bounded handover loop and, as expected, it passes the liveness check (well, assuming fairness

Re: [PATCH 2/2] locking/qspinlock: Limit # of spins in _Q_PENDING_VAL wait loop

Hi Waiman, On Mon, Apr 09, 2018 at 02:08:52PM -0400, Waiman Long wrote: > @@ -311,13 +320,19 @@ void queued_spin_lock_slowpath(struct qspinlock *lock, > u32 val) > return; > > /* > - * wait for in-progress pending->locked hand-overs > + * wait for in-progress

Re: [PATCH 2/2] locking/qspinlock: Limit # of spins in _Q_PENDING_VAL wait loop

Hi Waiman, On Mon, Apr 09, 2018 at 02:08:52PM -0400, Waiman Long wrote: > @@ -311,13 +320,19 @@ void queued_spin_lock_slowpath(struct qspinlock *lock, > u32 val) > return; > > /* > - * wait for in-progress pending->locked hand-overs > + * wait for in-progress

Re: [PATCH 00/10] kernel/locking: qspinlock improvements

On Fri, Apr 06, 2018 at 03:22:49PM +0200, Andrea Parri wrote: > On Thu, Apr 05, 2018 at 05:58:57PM +0100, Will Deacon wrote: > > I've been kicking the tyres further on qspinlock and with this set of > > patches > > I'm happy with the performance and fairness properties. In particular, the > >

Re: [PATCH 00/10] kernel/locking: qspinlock improvements

On Fri, Apr 06, 2018 at 03:22:49PM +0200, Andrea Parri wrote: > On Thu, Apr 05, 2018 at 05:58:57PM +0100, Will Deacon wrote: > > I've been kicking the tyres further on qspinlock and with this set of > > patches > > I'm happy with the performance and fairness properties. In particular, the > >

Re: arm/arm64: smp_spin_table.c for arm32?

On Wed, Mar 28, 2018 at 08:12:50AM +, Michel Pollet wrote: > I'm currently adapting a port from a machine-file based approach to driver > based, and I > would have a need for arch/arm64/kernel/smp_spin_table.c -- it's *exactly* my > use > case, but for arm32. > So what would be my options

Re: arm/arm64: smp_spin_table.c for arm32?

On Wed, Mar 28, 2018 at 08:12:50AM +, Michel Pollet wrote: > I'm currently adapting a port from a machine-file based approach to driver > based, and I > would have a need for arch/arm64/kernel/smp_spin_table.c -- it's *exactly* my > use > case, but for arm32. > So what would be my options

Re: [PATCH 12/14] dma-direct: handle the memory encryption bit in common code

On Mon, Mar 19, 2018 at 08:49:30PM +0100, Christoph Hellwig wrote: > On Mon, Mar 19, 2018 at 06:01:41PM +0000, Catalin Marinas wrote: > > I don't particularly like maintaining an arm64-specific dma-direct.h > > either but arm64 seems to be the only architecture that needs to > &

Re: [PATCH 12/14] dma-direct: handle the memory encryption bit in common code

On Mon, Mar 19, 2018 at 08:49:30PM +0100, Christoph Hellwig wrote: > On Mon, Mar 19, 2018 at 06:01:41PM +0000, Catalin Marinas wrote: > > I don't particularly like maintaining an arm64-specific dma-direct.h > > either but arm64 seems to be the only architecture that needs to > &

Re: [PATCH 12/14] dma-direct: handle the memory encryption bit in common code

On Mon, Mar 19, 2018 at 05:03:43PM +0100, Christoph Hellwig wrote: > On Mon, Mar 19, 2018 at 03:48:33PM +, Will Deacon wrote: > > Why can't we just resolve the conflict by adding the underscores? > > We can solve the conflict easily that way. But that's not the point. > > The point is that

Re: [PATCH 12/14] dma-direct: handle the memory encryption bit in common code

On Mon, Mar 19, 2018 at 05:03:43PM +0100, Christoph Hellwig wrote: > On Mon, Mar 19, 2018 at 03:48:33PM +, Will Deacon wrote: > > Why can't we just resolve the conflict by adding the underscores? > > We can solve the conflict easily that way. But that's not the point. > > The point is that

Re: [RFC PATCH 3/6] mm, arm64: untag user addresses in memory syscalls

On Wed, Mar 14, 2018 at 04:45:20PM +0100, Andrey Konovalov wrote: > On Fri, Mar 9, 2018 at 6:42 PM, Evgenii Stepanov <euge...@google.com> wrote: > > On Fri, Mar 9, 2018 at 9:31 AM, Andrey Konovalov <andreyk...@google.com> > > wrote: > >> On Fri, Mar

Re: [RFC PATCH 3/6] mm, arm64: untag user addresses in memory syscalls

On Wed, Mar 14, 2018 at 04:45:20PM +0100, Andrey Konovalov wrote: > On Fri, Mar 9, 2018 at 6:42 PM, Evgenii Stepanov wrote: > > On Fri, Mar 9, 2018 at 9:31 AM, Andrey Konovalov > > wrote: > >> On Fri, Mar 9, 2018 at 4:53 PM, Catalin Marinas > >> w

[GIT PULL] arm64 fixes for 4.16-rc5

Hi Linus, Please pull the arm64 fixes below. Thanks. The following changes since commit 4a3928c6f8a53fa1aed28ccba227742486e8ddcb: Linux 4.16-rc3 (2018-02-25 18:50:41 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes

[GIT PULL] arm64 fixes for 4.16-rc5

Hi Linus, Please pull the arm64 fixes below. Thanks. The following changes since commit 4a3928c6f8a53fa1aed28ccba227742486e8ddcb: Linux 4.16-rc3 (2018-02-25 18:50:41 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes

Re: [RFC PATCH 2/6] arm64: untag user addresses in copy_from_user and others

uot;: -8<-- >From 6df503651f73c923d91eb695e56f977ddcc52d43 Mon Sep 17 00:00:00 2001 From: Catalin Marinas <catalin.mari...@arm.com> Date: Tue, 6 Feb 2018 17:54:05 + Subject: [PATCH] arm64: Allow user pointer tags to be passed into the kernel The c

Re: [RFC PATCH 2/6] arm64: untag user addresses in copy_from_user and others

uot;: -8<-- >From 6df503651f73c923d91eb695e56f977ddcc52d43 Mon Sep 17 00:00:00 2001 From: Catalin Marinas Date: Tue, 6 Feb 2018 17:54:05 + Subject: [PATCH] arm64: Allow user pointer tags to be passed into the kernel The current tagged pointer ABI disallows t

Re: [RFC PATCH 3/6] mm, arm64: untag user addresses in memory syscalls

On Fri, Mar 09, 2018 at 03:02:01PM +0100, Andrey Konovalov wrote: > Memory subsystem syscalls accept user addresses as arguments, but don't use > copy_from_user and other similar functions, so we need to handle this case > separately. > > Untag user pointers passed to madvise, mbind,

Re: [RFC PATCH 3/6] mm, arm64: untag user addresses in memory syscalls

On Fri, Mar 09, 2018 at 03:02:01PM +0100, Andrey Konovalov wrote: > Memory subsystem syscalls accept user addresses as arguments, but don't use > copy_from_user and other similar functions, so we need to handle this case > separately. > > Untag user pointers passed to madvise, mbind,

Re: [PATCH] arm64/efi: Make strrchr() available to the EFI namespace

On Thu, Mar 01, 2018 at 10:28:03AM -0600, Rob Herring wrote: > libfdt gained a new dependency on strrchr, so make it available to the > EFI namespace before we update libfdt. > > Thanks to Ard for providing this fix. > > Cc: Catalin Marinas <catalin.mari...@arm.com> >

Re: [PATCH] arm64/efi: Make strrchr() available to the EFI namespace

On Thu, Mar 01, 2018 at 10:28:03AM -0600, Rob Herring wrote: > libfdt gained a new dependency on strrchr, so make it available to the > EFI namespace before we update libfdt. > > Thanks to Ard for providing this fix. > > Cc: Catalin Marinas > Cc: Will Deacon >

[GIT PULL] arm64 fixes for 4.16-rc3

Hi Linus, Please pull the arm64 and perf fixes below (the latter pushed by Will to the arm64 fixes/core branch). Thanks. The following changes since commit 91ab883eb21325ad80f3473633f794c78ac87f51: Linux 4.16-rc2 (2018-02-18 17:29:42 -0800) are available in the git repository at:

[GIT PULL] arm64 fixes for 4.16-rc3

Hi Linus, Please pull the arm64 and perf fixes below (the latter pushed by Will to the arm64 fixes/core branch). Thanks. The following changes since commit 91ab883eb21325ad80f3473633f794c78ac87f51: Linux 4.16-rc2 (2018-02-18 17:29:42 -0800) are available in the git repository at:

Re: [PATCH v2] arm64: Add support for new control bits CTR_EL0.DIC and CTR_EL0.IDC

On Mon, Feb 19, 2018 at 08:59:06PM -0600, Shanker Donthineni wrote: > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index f55fe5b..4061210 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -1095,6 +1095,27 @@ config ARM64_RAS_EXTN > and access the new registers if

Re: [PATCH v2] arm64: Add support for new control bits CTR_EL0.DIC and CTR_EL0.IDC

On Mon, Feb 19, 2018 at 08:59:06PM -0600, Shanker Donthineni wrote: > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index f55fe5b..4061210 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -1095,6 +1095,27 @@ config ARM64_RAS_EXTN > and access the new registers if

Re: [PATCH] arm64: Add support for new control bits CTR_EL0.IDC and CTR_EL0.IDC

On Mon, Feb 19, 2018 at 10:35:30AM -0600, Shanker Donthineni wrote: > On 02/19/2018 08:38 AM, Catalin Marinas wrote: > > On the patch, I'd rather have an alternative framework entry for no VAU > > cache maint required and some ret instruction at the beginning of the > > cache

Re: [PATCH] arm64: Add support for new control bits CTR_EL0.IDC and CTR_EL0.IDC

On Mon, Feb 19, 2018 at 10:35:30AM -0600, Shanker Donthineni wrote: > On 02/19/2018 08:38 AM, Catalin Marinas wrote: > > On the patch, I'd rather have an alternative framework entry for no VAU > > cache maint required and some ret instruction at the beginning of the > > cache

Re: [PATCH] arm64: Add support for new control bits CTR_EL0.IDC and CTR_EL0.IDC

On Fri, Feb 16, 2018 at 06:57:46PM -0600, Shanker Donthineni wrote: > Two point of unification cache maintenance operations 'DC CVAU' and > 'IC IVAU' are optional for implementors as per ARMv8 specification. > This patch parses the updated CTR_EL0 register definition and adds > the required

Re: [PATCH] arm64: Add support for new control bits CTR_EL0.IDC and CTR_EL0.IDC

On Fri, Feb 16, 2018 at 06:57:46PM -0600, Shanker Donthineni wrote: > Two point of unification cache maintenance operations 'DC CVAU' and > 'IC IVAU' are optional for implementors as per ARMv8 specification. > This patch parses the updated CTR_EL0 register definition and adds > the required

Re: [PATCH] arm64: Fix compilation error while accessing MPIDR_HWID_BITMASK from .S files

On Mon, Feb 19, 2018 at 11:19:07AM +, Will Deacon wrote: > > >>On 19/02/2018 06:39, Bhupesh Sharma wrote: > > >>>Since commit e1a50de37860b3a93a9d643b09638db5aff47650 (arm64: cputype: > > >>>Silence Sparse warnings), compilation of arm64 architecture is broken > > >>>with the following error

Re: [PATCH] arm64: Fix compilation error while accessing MPIDR_HWID_BITMASK from .S files

On Mon, Feb 19, 2018 at 11:19:07AM +, Will Deacon wrote: > > >>On 19/02/2018 06:39, Bhupesh Sharma wrote: > > >>>Since commit e1a50de37860b3a93a9d643b09638db5aff47650 (arm64: cputype: > > >>>Silence Sparse warnings), compilation of arm64 architecture is broken > > >>>with the following error

Re: arm64/v4.16-rc1: KASAN: use-after-free Read in finish_task_switch

On Thu, Feb 15, 2018 at 02:22:39PM +, Will Deacon wrote: > Instead, we've come up with a more plausible sequence that can in theory > happen on a single CPU: > > > > do_exit > exit_mm > mmgrab(mm); // foo's mm has count +1 > BUG_ON(mm !=

Re: arm64/v4.16-rc1: KASAN: use-after-free Read in finish_task_switch

On Thu, Feb 15, 2018 at 02:22:39PM +, Will Deacon wrote: > Instead, we've come up with a more plausible sequence that can in theory > happen on a single CPU: > > > > do_exit > exit_mm > mmgrab(mm); // foo's mm has count +1 > BUG_ON(mm !=

[GIT PULL] arm64 fixes for 4.16-rc2

Hi Linus, Please pull the arm64 fixes below. The bulk of this pull request is the pte accessors annotation to READ/WRITE_ONCE (we tried to avoid pushing this during the merging window to avoid conflicts). Thanks. The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2:

[GIT PULL] arm64 fixes for 4.16-rc2

Hi Linus, Please pull the arm64 fixes below. The bulk of this pull request is the pte accessors annotation to READ/WRITE_ONCE (we tried to avoid pushing this during the merging window to avoid conflicts). Thanks. The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2:

Re: Patch "[Variant 2/Spectre-v2] arm64: Implement branch predictor hardening for Falkor" has been added to the 4.14-stable tree

On Wed, Feb 14, 2018 at 07:23:46PM +0100, Greg Kroah-Hartman wrote: > On Wed, Feb 14, 2018 at 10:16:51AM -0600, Timur Tabi wrote: > > On Wed, Feb 14, 2018 at 7:53 AM, wrote: > > > > > > This is a note to let you know that I've just added the patch titled > > > > > >

Re: Patch "[Variant 2/Spectre-v2] arm64: Implement branch predictor hardening for Falkor" has been added to the 4.14-stable tree

On Wed, Feb 14, 2018 at 07:23:46PM +0100, Greg Kroah-Hartman wrote: > On Wed, Feb 14, 2018 at 10:16:51AM -0600, Timur Tabi wrote: > > On Wed, Feb 14, 2018 at 7:53 AM, wrote: > > > > > > This is a note to let you know that I've just added the patch titled > > > > > > [Variant 2/Spectre-v2]

Re: [PATCH] arm64: Make L1_CACHE_SHIFT configurable

On Mon, Feb 12, 2018 at 03:45:23PM -0800, Florian Fainelli wrote: > On many platforms, including, but not limited to Brahma-B53 platforms, > the L1 cache line size is 64bytes. Increasing the value to 128bytes > appears to be creating performance problems for workloads involving > network drivers

Re: [PATCH] arm64: Make L1_CACHE_SHIFT configurable

On Mon, Feb 12, 2018 at 03:45:23PM -0800, Florian Fainelli wrote: > On many platforms, including, but not limited to Brahma-B53 platforms, > the L1 cache line size is 64bytes. Increasing the value to 128bytes > appears to be creating performance problems for workloads involving > network drivers

Re: [PATCH] arm64: Add missing Falkor part number for branch predictor hardening

On Mon, Feb 12, 2018 at 08:57:36AM +, Marc Zyngier wrote: > On Mon, 12 Feb 2018 01:16:15 +, > Shanker Donthineni wrote: > > > > References to CPU part number MIDR_QCOM_FALKOR were dropped from the > > mailing list patch due to mainline/arm64 branch dependency. So this > > patch adds the

Re: [PATCH] arm64: Add missing Falkor part number for branch predictor hardening

On Mon, Feb 12, 2018 at 08:57:36AM +, Marc Zyngier wrote: > On Mon, 12 Feb 2018 01:16:15 +, > Shanker Donthineni wrote: > > > > References to CPU part number MIDR_QCOM_FALKOR were dropped from the > > mailing list patch due to mainline/arm64 branch dependency. So this > > patch adds the

[GIT PULL] arm64 updates for 4.16-rc1

Hi Linus, As I mentioned in the last pull request, there's a second batch of security updates for arm64 with mitigations for Spectre/v1 and an improved one for Spectre/v2 (via a newly defined firmware interface API). The patch "arm64: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls" is

[GIT PULL] arm64 updates for 4.16-rc1

Hi Linus, As I mentioned in the last pull request, there's a second batch of security updates for arm64 with mitigations for Spectre/v1 and an improved one for Spectre/v2 (via a newly defined firmware interface API). The patch "arm64: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls" is

Re: [PATCH v4 00/17] arm64: Add SMCCC v1.1 support and CVE-2017-5715 (Spectre variant 2) mitigation

On Tue, Feb 06, 2018 at 05:56:04PM +, Marc Zyngier wrote: > ARM has recently published a SMC Calling Convention (SMCCC) > specification update[1] that provides an optimised calling convention > and optional, discoverable support for mitigating CVE-2017-5715. ARM > Trusted Firmware (ATF) has

Re: [PATCH v4 00/17] arm64: Add SMCCC v1.1 support and CVE-2017-5715 (Spectre variant 2) mitigation

On Tue, Feb 06, 2018 at 05:56:04PM +, Marc Zyngier wrote: > ARM has recently published a SMC Calling Convention (SMCCC) > specification update[1] that provides an optimised calling convention > and optional, discoverable support for mitigating CVE-2017-5715. ARM > Trusted Firmware (ATF) has

Re: [GIT PULL] arm64 updates for 4.16

On Tue, Jan 30, 2018 at 02:02:45PM -0800, Linus Torvalds wrote: > On Tue, Jan 30, 2018 at 11:26 AM, Catalin Marinas > <catalin.mari...@arm.com> wrote: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux > > tags/arm64-upstream > > I got some f

Re: [GIT PULL] arm64 updates for 4.16

On Tue, Jan 30, 2018 at 02:02:45PM -0800, Linus Torvalds wrote: > On Tue, Jan 30, 2018 at 11:26 AM, Catalin Marinas > wrote: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux > > tags/arm64-upstream > > I got some fairly trivial conflicts o

[GIT PULL] arm64 updates for 4.16

Catalin Marinas (5): Merge branch 'kpti' of git://git.kernel.org/.../arm64/linux Merge branch 'for-next/52-bit-pa' into for-next/core arm64: asid: Do not replace active_asids if already 0 Merge branch 'for-next/perf' of git

[GIT PULL] arm64 updates for 4.16

Catalin Marinas (5): Merge branch 'kpti' of git://git.kernel.org/.../arm64/linux Merge branch 'for-next/52-bit-pa' into for-next/core arm64: asid: Do not replace active_asids if already 0 Merge branch 'for-next/perf' of git

Re: [RFC 2/2] arm64: compat: cacheflush syscall: process only pages that are in the memory

On Fri, Jan 26, 2018 at 05:41:45PM +, Catalin Marinas wrote: > On Fri, Jan 26, 2018 at 12:14:41PM +0100, Marek Szyprowski wrote: > > @@ -32,23 +33,36 @@ > > static long > > __do_compat_cache_op(unsigned long start, unsigned long end) > [...] > > +

Re: [RFC 2/2] arm64: compat: cacheflush syscall: process only pages that are in the memory

On Fri, Jan 26, 2018 at 05:41:45PM +, Catalin Marinas wrote: > On Fri, Jan 26, 2018 at 12:14:41PM +0100, Marek Szyprowski wrote: > > @@ -32,23 +33,36 @@ > > static long > > __do_compat_cache_op(unsigned long start, unsigned long end) > [...] > > +

Re: [RFC 2/2] arm64: compat: cacheflush syscall: process only pages that are in the memory

On Fri, Jan 26, 2018 at 12:14:41PM +0100, Marek Szyprowski wrote: > @@ -32,23 +33,36 @@ > static long > __do_compat_cache_op(unsigned long start, unsigned long end) [...] > + if (follow_page(vma, start, 0)) { > + ret = __flush_cache_user_range(start, start +

Re: [RFC 2/2] arm64: compat: cacheflush syscall: process only pages that are in the memory

On Fri, Jan 26, 2018 at 12:14:41PM +0100, Marek Szyprowski wrote: > @@ -32,23 +33,36 @@ > static long > __do_compat_cache_op(unsigned long start, unsigned long end) [...] > + if (follow_page(vma, start, 0)) { > + ret = __flush_cache_user_range(start, start +

Re: [PATCH v3] arm64: fix unwind_frame() for filtered out fn for function graph tracing

On Fri, Jan 12, 2018 at 11:48:32AM +0100, Jerome Marchand wrote: > diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c > index 76809ccd309c..5a528c58ef68 100644 > --- a/arch/arm64/kernel/stacktrace.c > +++ b/arch/arm64/kernel/stacktrace.c > @@ -59,6 +59,10 @@ int notrace

Re: [PATCH v3] arm64: fix unwind_frame() for filtered out fn for function graph tracing

On Fri, Jan 12, 2018 at 11:48:32AM +0100, Jerome Marchand wrote: > diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c > index 76809ccd309c..5a528c58ef68 100644 > --- a/arch/arm64/kernel/stacktrace.c > +++ b/arch/arm64/kernel/stacktrace.c > @@ -59,6 +59,10 @@ int notrace

Re: [RFC 1/4] arm64: Correct type for PUD macros

n the future. > > Fix this by using pudval_t to define the PUD_* macros. > > Fixes: 084bd29810a56 ("ARM64: mm: HugeTLB support.") > Fixes: 206a2a73a62d3 ("arm64: mm: Create gigabyte kernel logical mappings > where possible") > Signed-off-by: Punit

Re: [RFC 1/4] arm64: Correct type for PUD macros

n the future. > > Fix this by using pudval_t to define the PUD_* macros. > > Fixes: 084bd29810a56 ("ARM64: mm: HugeTLB support.") > Fixes: 206a2a73a62d3 ("arm64: mm: Create gigabyte kernel logical mappings > where possible") > Signed-off-by: Punit Agrawal

Re: [PATCH] arm64: Inform user if software PAN is in use

On Wed, Nov 29, 2017 at 03:39:49PM -0800, Stephen Boyd wrote: > It isn't entirely obvious if we're using software PAN because we > don't say anything about it in the boot log. But if we're using > hardware PAN we'll print a nice CPU feature message indicating > it. Add a print for software PAN too

Re: [PATCH] arm64: Inform user if software PAN is in use

On Wed, Nov 29, 2017 at 03:39:49PM -0800, Stephen Boyd wrote: > It isn't entirely obvious if we're using software PAN because we > don't say anything about it in the boot log. But if we're using > hardware PAN we'll print a nice CPU feature message indicating > it. Add a print for software PAN too

Re: [PATCH v3 02/10] include: Move compat_timespec/ timeval to compat_time.h

safe syscalls. For arm64: Acked-by: Catalin Marinas <catalin.mari...@arm.com>

Re: [PATCH v3 02/10] include: Move compat_timespec/ timeval to compat_time.h

safe syscalls. For arm64: Acked-by: Catalin Marinas

Re: [PATCH] arm64: Stop printing the virtual memory layout

On Tue, Jan 09, 2018 at 03:02:12PM -0800, Kees Cook wrote: > On Tue, Dec 19, 2017 at 1:04 PM, Kees Cook wrote: > > On Tue, Dec 19, 2017 at 11:28 AM, Laura Abbott wrote: > >> Printing kernel addresses should be done in limited circumstances, mostly > >>

Re: [PATCH] arm64: Stop printing the virtual memory layout

On Tue, Jan 09, 2018 at 03:02:12PM -0800, Kees Cook wrote: > On Tue, Dec 19, 2017 at 1:04 PM, Kees Cook wrote: > > On Tue, Dec 19, 2017 at 11:28 AM, Laura Abbott wrote: > >> Printing kernel addresses should be done in limited circumstances, mostly > >> for debugging purposes. Printing out the

Re: [PATCH -next] firmware: arm_sdei: Fix return value check in sdei_present_dt()

On Mon, Jan 15, 2018 at 10:41:53AM +, Wei Yongjun wrote: > In case of error, the function of_platform_device_create() returns > NULL pointer not ERR_PTR(). The IS_ERR() test in the return value > check should be replaced with NULL test. > > Fixes: 677a60bd2003 ("firmware: arm_sdei: Discover

Re: [PATCH -next] firmware: arm_sdei: Fix return value check in sdei_present_dt()

On Mon, Jan 15, 2018 at 10:41:53AM +, Wei Yongjun wrote: > In case of error, the function of_platform_device_create() returns > NULL pointer not ERR_PTR(). The IS_ERR() test in the return value > check should be replaced with NULL test. > > Fixes: 677a60bd2003 ("firmware: arm_sdei: Discover

Re: [PATCH v3 11/13] arm64: Implement branch predictor hardening for affected Cortex-A CPUs

On Tue, Jan 09, 2018 at 04:12:18PM +, Suzuki K. Poulose wrote: > arm64: capabilities: Handle duplicate entries for a capability > > Sometimes a single capability could be listed multiple times with > differing matches(), e.g, CPU errata for different MIDR versions. > This breaks

Re: [PATCH v3 11/13] arm64: Implement branch predictor hardening for affected Cortex-A CPUs

On Tue, Jan 09, 2018 at 04:12:18PM +, Suzuki K. Poulose wrote: > arm64: capabilities: Handle duplicate entries for a capability > > Sometimes a single capability could be listed multiple times with > differing matches(), e.g, CPU errata for different MIDR versions. > This breaks

Re: linux-next: manual merge of the arm64 tree with Linus' tree

On Mon, Jan 15, 2018 at 08:32:14AM +1100, Stephen Rothwell wrote: > diff --cc arch/arm64/include/asm/cputype.h > index cbf08d7cbf30,2f8d39ed9c2e.. > --- a/arch/arm64/include/asm/cputype.h > +++ b/arch/arm64/include/asm/cputype.h > @@@ -91,7 -94,7 +94,8 @@@ > #define

Re: linux-next: manual merge of the arm64 tree with Linus' tree

On Mon, Jan 15, 2018 at 08:32:14AM +1100, Stephen Rothwell wrote: > diff --cc arch/arm64/include/asm/cputype.h > index cbf08d7cbf30,2f8d39ed9c2e.. > --- a/arch/arm64/include/asm/cputype.h > +++ b/arch/arm64/include/asm/cputype.h > @@@ -91,7 -94,7 +94,8 @@@ > #define

Re: [PATCH v3] arm64: cpu_errata: Add Kryo to Falkor 1003 errata

On Tue, Jan 09, 2018 at 01:22:12PM -0800, Stephen Boyd wrote: > On 12/14, Will Deacon wrote: > > On Wed, Dec 13, 2017 at 02:19:37PM -0800, Stephen Boyd wrote: > > > The Kryo CPUs are also affected by the Falkor 1003 errata, so > > > we need to do the same workaround on Kryo CPUs. The MIDR is > > >

Re: [PATCH v3] arm64: cpu_errata: Add Kryo to Falkor 1003 errata

On Tue, Jan 09, 2018 at 01:22:12PM -0800, Stephen Boyd wrote: > On 12/14, Will Deacon wrote: > > On Wed, Dec 13, 2017 at 02:19:37PM -0800, Stephen Boyd wrote: > > > The Kryo CPUs are also affected by the Falkor 1003 errata, so > > > we need to do the same workaround on Kryo CPUs. The MIDR is > > >

Re: [PATCH v3 00/13] arm64 kpti hardening and variant 2 workarounds

On Tue, Jan 09, 2018 at 03:07:28PM +0100, Matthias Brugger wrote: > On 01/08/2018 07:53 PM, Catalin Marinas wrote: > > On Mon, Jan 08, 2018 at 05:32:25PM +, Will Deacon wrote: > >> Jayachandran C (1): > >> arm64: cputype: Add MIDR values for Cavium ThunderX2 CPU

Re: [PATCH v3 00/13] arm64 kpti hardening and variant 2 workarounds

On Tue, Jan 09, 2018 at 03:07:28PM +0100, Matthias Brugger wrote: > On 01/08/2018 07:53 PM, Catalin Marinas wrote: > > On Mon, Jan 08, 2018 at 05:32:25PM +, Will Deacon wrote: > >> Jayachandran C (1): > >> arm64: cputype: Add MIDR values for Cavium ThunderX2 CPU

Re: linux-next: manual merge of the arm64 tree with Linus' tree

On Fri, Jan 12, 2018 at 08:23:59AM +1100, Stephen Rothwell wrote: > diff --cc arch/arm64/kernel/cpufeature.c > index a73a5928f09b,da6722db50b0.. > --- a/arch/arm64/kernel/cpufeature.c > +++ b/arch/arm64/kernel/cpufeature.c > @@@ -145,8 -146,9 +146,10 @@@ static const struct

Re: linux-next: manual merge of the arm64 tree with Linus' tree

On Fri, Jan 12, 2018 at 08:23:59AM +1100, Stephen Rothwell wrote: > diff --cc arch/arm64/kernel/cpufeature.c > index a73a5928f09b,da6722db50b0.. > --- a/arch/arm64/kernel/cpufeature.c > +++ b/arch/arm64/kernel/cpufeature.c > @@@ -145,8 -146,9 +146,10 @@@ static const struct

Re: [PATCH] arm64: Implement branch predictor hardening for Falkor

On Tue, Jan 09, 2018 at 09:41:46AM +, Will Deacon wrote: > You'll need to send a fixup patch. for-next/core is non-rebasing. I haven't pushed it out yet (will do this morning) but note that for-next/core is based on 4.15-rc3. -- Catalin

Re: [PATCH] arm64: Implement branch predictor hardening for Falkor

On Tue, Jan 09, 2018 at 09:41:46AM +, Will Deacon wrote: > You'll need to send a fixup patch. for-next/core is non-rebasing. I haven't pushed it out yet (will do this morning) but note that for-next/core is based on 4.15-rc3. -- Catalin

Re: [PATCH v3 00/13] arm64 kpti hardening and variant 2 workarounds

On Mon, Jan 08, 2018 at 05:32:25PM +, Will Deacon wrote: > Jayachandran C (1): > arm64: cputype: Add MIDR values for Cavium ThunderX2 CPUs > > Marc Zyngier (3): > arm64: Move post_ttbr_update_workaround to C code > arm64: KVM: Use per-CPU vector when BP hardening is enabled > arm64:

Re: [PATCH v3 00/13] arm64 kpti hardening and variant 2 workarounds

On Mon, Jan 08, 2018 at 05:32:25PM +, Will Deacon wrote: > Jayachandran C (1): > arm64: cputype: Add MIDR values for Cavium ThunderX2 CPUs > > Marc Zyngier (3): > arm64: Move post_ttbr_update_workaround to C code > arm64: KVM: Use per-CPU vector when BP hardening is enabled > arm64:

Re: [PATCH v7 07/10] kernel/jump_label: abstract jump_entry member accessors

On Fri, Jan 05, 2018 at 06:01:33PM +, Ard Biesheuvel wrote: > On 5 January 2018 at 17:58, Catalin Marinas <catalin.mari...@arm.com> wrote: > > On Tue, Jan 02, 2018 at 08:05:46PM +, Ard Biesheuvel wrote: > >> diff --git a/arch/arm/include/asm/jump_label.h >

Re: [PATCH v7 07/10] kernel/jump_label: abstract jump_entry member accessors

On Fri, Jan 05, 2018 at 06:01:33PM +, Ard Biesheuvel wrote: > On 5 January 2018 at 17:58, Catalin Marinas wrote: > > On Tue, Jan 02, 2018 at 08:05:46PM +, Ard Biesheuvel wrote: > >> diff --git a/arch/arm/include/asm/jump_label.h > >> b/arch/arm/include/

Re: [PATCH v7 07/10] kernel/jump_label: abstract jump_entry member accessors

On Tue, Jan 02, 2018 at 08:05:46PM +, Ard Biesheuvel wrote: > diff --git a/arch/arm/include/asm/jump_label.h > b/arch/arm/include/asm/jump_label.h > index e12d7d096fc0..7b05b404063a 100644 > --- a/arch/arm/include/asm/jump_label.h > +++ b/arch/arm/include/asm/jump_label.h > @@ -45,5 +45,32 @@

Re: [PATCH v7 07/10] kernel/jump_label: abstract jump_entry member accessors

On Tue, Jan 02, 2018 at 08:05:46PM +, Ard Biesheuvel wrote: > diff --git a/arch/arm/include/asm/jump_label.h > b/arch/arm/include/asm/jump_label.h > index e12d7d096fc0..7b05b404063a 100644 > --- a/arch/arm/include/asm/jump_label.h > +++ b/arch/arm/include/asm/jump_label.h > @@ -45,5 +45,32 @@

Re: [PATCH v7 05/10] PCI: Add support for relative addressing in quirk tables

On Tue, Jan 02, 2018 at 08:05:44PM +, Ard Biesheuvel wrote: > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > index 10684b17d0bd..b6d51b4d5ce1 100644 > --- a/drivers/pci/quirks.c > +++ b/drivers/pci/quirks.c > @@ -3556,9 +3556,16 @@ static void pci_do_fixups(struct pci_dev *dev,

Re: [PATCH v7 05/10] PCI: Add support for relative addressing in quirk tables

On Tue, Jan 02, 2018 at 08:05:44PM +, Ard Biesheuvel wrote: > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > index 10684b17d0bd..b6d51b4d5ce1 100644 > --- a/drivers/pci/quirks.c > +++ b/drivers/pci/quirks.c > @@ -3556,9 +3556,16 @@ static void pci_do_fixups(struct pci_dev *dev,

Re: [PATCH v3] arm64: v8.4: Support for new floating point multiplication instructions

On Fri, Jan 05, 2018 at 04:22:24PM +0800, gengdongjiu wrote: > On 2018/1/5 15:57, Greg KH wrote: > > On Fri, Jan 05, 2018 at 09:22:54AM +0800, gengdongjiu wrote: > >> Hi will/catalin > >> > >> On 2017/12/13 18:09, Suzuki K Poulose wrote: > >>> On 13/12/17 10:13, Dongjiu Geng wrote: > ARM v8.4

Re: [PATCH v3] arm64: v8.4: Support for new floating point multiplication instructions

On Fri, Jan 05, 2018 at 04:22:24PM +0800, gengdongjiu wrote: > On 2018/1/5 15:57, Greg KH wrote: > > On Fri, Jan 05, 2018 at 09:22:54AM +0800, gengdongjiu wrote: > >> Hi will/catalin > >> > >> On 2017/12/13 18:09, Suzuki K Poulose wrote: > >>> On 13/12/17 10:13, Dongjiu Geng wrote: > ARM v8.4

Re: [PATCH] arm64: defconfig: Select schedutil as default cpufreq governor

On Thu, Nov 16, 2017 at 11:51:36AM +0530, Viresh Kumar wrote: > Currently performance governor is getting selected by default, which is > surely not a very good choice as its pretty much power hungry. > > Select schedutil instead. And why do we care about this in defconfig? People deploying

Re: [PATCH] arm64: defconfig: Select schedutil as default cpufreq governor

On Thu, Nov 16, 2017 at 11:51:36AM +0530, Viresh Kumar wrote: > Currently performance governor is getting selected by default, which is > surely not a very good choice as its pretty much power hungry. > > Select schedutil instead. And why do we care about this in defconfig? People deploying

Re: [PATCH v3 00/20] arm64: Unmap the kernel whilst running in userspace (KPTI)

On Wed, Dec 06, 2017 at 12:35:19PM +, Will Deacon wrote: > Patches are also pushed here: > > git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git kpti > > Feedback and testing welcome. At this point, I'd like to start thinking > about getting this merged for 4.16. For the record,

Re: [PATCH v3 00/20] arm64: Unmap the kernel whilst running in userspace (KPTI)

On Wed, Dec 06, 2017 at 12:35:19PM +, Will Deacon wrote: > Patches are also pushed here: > > git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git kpti > > Feedback and testing welcome. At this point, I'd like to start thinking > about getting this merged for 4.16. For the record,

Re: [PATCH v8 00/20] ILP32 for ARM64

Hi Yury, On Thu, Nov 16, 2017 at 02:11:30PM +0300, Yury Norov wrote: > This is ILP32 patches on top of 4.14 kernel: > https://github.com/norov/linux/commits/ilp32-4.14 > > I tested the series with LTP lite built by Linaro toolchain, and no > regressions found. Thanks. I gave it a try as well

Re: [PATCH v8 00/20] ILP32 for ARM64

Hi Yury, On Thu, Nov 16, 2017 at 02:11:30PM +0300, Yury Norov wrote: > This is ILP32 patches on top of 4.14 kernel: > https://github.com/norov/linux/commits/ilp32-4.14 > > I tested the series with LTP lite built by Linaro toolchain, and no > regressions found. Thanks. I gave it a try as well

Re: a racy access flag clearing warning when calling mmap system call

On Fri, Dec 08, 2017 at 11:19:52AM +0800, chenjiankang wrote: > 在 2017/12/7 21:23, Will Deacon 写道: > > diff --git a/arch/arm64/include/asm/pgtable.h > > b/arch/arm64/include/asm/pgtable.h > > index 149d05fb9421..8fe103b1e101 100644 > > --- a/arch/arm64/include/asm/pgtable.h > > +++

<    8   9   10   11   12   13   14   15   16   17   >