Hi Stephen,
On Mon, Nov 13, 2017 at 05:09:53PM +1100, Stephen Rothwell wrote:
> On Wed, 1 Nov 2017 07:57:23 +1100 Stephen Rothwell
> wrote:
> > Today's linux-next merge of the arm64 tree got a conflict in:
> >
> > drivers/acpi/arm64/iort.c
> >
> > between commit:
> >
> > 37f6b42e9c29 ("AC
On Mon, Nov 13, 2017 at 07:05:12PM +, Ben Hutchings wrote:
> On Mon, 2017-11-06 at 10:44 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Mark Rutland
> >
> > commit 7a7003b1da010d2b0d1d
On Mon, Nov 06, 2017 at 10:31:51AM +0100, Jason A. Donenfeld wrote:
> Versions of gcc prior to gcc 5 emitted a __multi3 function call when
> dealing with TI types, resulting in failures when trying to link to
> libgcc, and more generally, bad performance. However, since gcc 5,
> the compiler suppor
On Mon, Nov 06, 2017 at 03:59:18PM +, Catalin Marinas wrote:
> On Mon, Nov 06, 2017 at 10:31:51AM +0100, Jason A. Donenfeld wrote:
> > Versions of gcc prior to gcc 5 emitted a __multi3 function call when
> > dealing with TI types, resulting in failures when trying to link to
On Sat, Oct 03, 2015 at 02:18:57AM +, Kapoor, Prasun wrote:
> On 10/2/15, 2:37 AM, "Catalin Marinas" wrote:
> >So, at the time, following x32 discussions, we thought of using the
> >native ABI as much as possible. However, two important things happened
> >
On Tue, Oct 06, 2015 at 09:49:29AM +0200, Arnd Bergmann wrote:
> On Tuesday 06 October 2015 11:05:43 Manjeet Pawar wrote:
> > MINSIGSTKSZ and SIGSTKSZ for ARM64 are not correctly set in latest kernel.
> > This patch fixes this issue.
> >
> > This issue is reported in LTP (testcase: sigaltstack02.c
On Wed, Sep 23, 2015 at 11:55:37AM -0700, Feng Kan wrote:
> This coverts all copy in/from/to user file to use the copy template file.
> The copy template file is based on the memcpy.S. The first patch converts
> the memcpy to use the copy template as well. Overnight trinity test and
> 10G iperf was
On Thu, Sep 17, 2015 at 12:38:06PM +0300, Andrey Ryabinin wrote:
> As usual patches available in git
> git://github.com/aryabinin/linux.git kasan/arm64v6
>
> Changes since v5:
> - Rebase on top of 4.3-rc1
> - Fixed EFI boot.
> - Updated Doc/features/KASAN.
I tried to merge these patches
On Mon, Oct 05, 2015 at 06:01:55PM +0100, Suzuki K. Poulose wrote:
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -22,11 +22,11 @@
>
> #include
>
> -#define SCTLR_EL1_CP15BEN(0x1 << 5)
> -#define SCTLR_EL1_SED(0x1 << 8)
> -
> /*
> - *
On Mon, Oct 05, 2015 at 06:01:56PM +0100, Suzuki K. Poulose wrote:
> diff --git a/arch/arm64/include/asm/cpufeature.h
> b/arch/arm64/include/asm/cpufeature.h
> index b5f313d..7ed92f2 100644
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -35,6 +35,38 @@
On Mon, Oct 05, 2015 at 12:53:52PM +0100, Ian Campbell wrote:
> Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2 on
> LogicTile Express 20MG" added a new dts file to arch/arm64 which
> included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
> .dtsi supplied by arch/arm.
On Mon, Oct 12, 2015 at 06:52:56PM +0300, Andrey Ryabinin wrote:
> Andrey Ryabinin (3):
> arm64: move PGD_SIZE definition to pgalloc.h
> arm64: add KASAN support
> Documentation/features/KASAN: arm64 supports KASAN now
>
> Linus Walleij (1):
> ARM64: kasan: print memory assignment
Patches
On Mon, Oct 12, 2015 at 06:21:04PM +0100, Mark Rutland wrote:
> On Mon, Oct 12, 2015 at 06:01:25PM +0100, Suzuki K. Poulose wrote:
> > On 08/10/15 16:03, Catalin Marinas wrote:
> > >On Thu, Oct 08, 2015 at 10:55:11AM +0100, Suzuki K. Poulose wrote:
> >
> > ...
> &
On Mon, Oct 12, 2015 at 10:28:18AM +0800, yalin wang wrote:
> Add ioremap_cache macro, because some code will test if this macro
> is defined or not, and will generate a generric version if not defined,
> for example, memremap.c do like this.
>
> Signed-off-by: yalin wang
> ---
> arch/arm64/incl
On Mon, Oct 12, 2015 at 02:52:59PM +0800, yalin wang wrote:
> This patch add kc_offset_to_vaddr() and kc_vaddr_to_offset(),
> the default version doesn't work on arm64, because arm64 kernel address
> is below the PAGE_OFFSET, like module address and vmemmap address are
> all below PAGE_OFFSET addre
On Tue, Oct 13, 2015 at 03:23:27PM +0100, Will Deacon wrote:
> On Tue, Oct 13, 2015 at 03:10:55PM +0100, Catalin Marinas wrote:
> > On Mon, Oct 12, 2015 at 10:28:18AM +0800, yalin wang wrote:
> > > Add ioremap_cache macro, because some code will test if this macro
> > >
On Fri, Sep 04, 2015 at 09:36:06AM -0700, David Daney wrote:
> On 09/04/2015 09:04 AM, Yury Norov wrote:
> >This patch is on top of https://lkml.org/lkml/2015/9/2/413
> >
> >In master, there's only a single function -
> > update_mixed_endian_el0_support
> >And similar function is on review ment
On Fri, Aug 21, 2015 at 03:01:41PM -0700, Feng Kan wrote:
> This converts the memcpy.S to use the copy template file. The copy
> template file was based originally on the memcpy.S. Minor changes
> was made to it to accommodate the copy to/from/in user files.
I think it will be easier to follow if
On Fri, Aug 21, 2015 at 03:01:33PM -0700, Feng Kan wrote:
> diff --git a/arch/arm64/lib/copy_from_user.S b/arch/arm64/lib/copy_from_user.S
> index 1be9ef2..cb085cf 100644
> --- a/arch/arm64/lib/copy_from_user.S
> +++ b/arch/arm64/lib/copy_from_user.S
> @@ -18,6 +18,7 @@
>
> #include
> #include
On Mon, Sep 07, 2015 at 05:54:06PM +0100, Suzuki K. Poulose wrote:
> On 14/08/15 19:28, Robert Richter wrote:
> >diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> >index c52f7ba205b4..4211c39b8744 100644
> >--- a/drivers/irqchip/irq-gic-v3.c
> >+++ b/drivers/irqchip/irq-gic
On Mon, Sep 07, 2015 at 06:41:50PM +0100, Suzuki K. Poulose wrote:
> On 07/09/15 18:15, Catalin Marinas wrote:
> >On Mon, Sep 07, 2015 at 05:54:06PM +0100, Suzuki K. Poulose wrote:
> >>On 14/08/15 19:28, Robert Richter wrote:
> >>>+static void gicv3_enable_q
On Tue, Sep 08, 2015 at 10:09:30AM +0100, Suzuki K. Poulose wrote:
> On 08/09/15 10:00, Catalin Marinas wrote:
> >On Mon, Sep 07, 2015 at 06:41:50PM +0100, Suzuki K. Poulose wrote:
> >>On 07/09/15 18:15, Catalin Marinas wrote:
> >>>On Mon, Sep 07, 2015 at 05:54:06PM
Hi Suzuki,
Some minor comments below.
On Tue, Oct 13, 2015 at 06:22:17PM +0100, Suzuki K. Poulose wrote:
> This patch adds an infrastructure to keep track of the CPU feature
> registers on the system. For each register, the infrastructure keeps
> track of the system wide safe value of the feature
On Tue, Oct 13, 2015 at 06:22:21PM +0100, Suzuki K. Poulose wrote:
> This patch delays populating the cpuinfo for a new (hotplugged)
> CPU until the notifiers have executed. This will enable us to verify
> if the new (hotplugged) CPU has all the capabilities which the system
> already has. If it do
On Fri, Oct 16, 2015 at 08:52:24AM +0100, Vladimir Murzin wrote:
> > On 15/10/15 14:02, Will Deacon wrote:
> >> diff --git a/arch/arm64/kernel/armv8_deprecated.c
> >> b/arch/arm64/kernel/armv8_deprecated.c
> >> index bcee7abac68e..6039d1eb5912 100644
> >> --- a/arch/arm64/kernel/armv8_deprecated.c
On Tue, Oct 13, 2015 at 02:30:51PM -0700, Mark Salyzyn wrote:
> armv7 does not have a PC alignment exception. armv8 Aarch32
> user space however can produce a PC alignment exception. Add
> handler so the we do not dump an unexpected stack trace in
> the logs.
>
> Signed-off-by: Mark Salyzyn
Queu
On Fri, Oct 16, 2015 at 10:01:20PM +0900, Jungseok Lee wrote:
> On Oct 16, 2015, at 12:59 AM, James Morse wrote:
> > My concern is there could be push-back from the maintainer of
> > kernel/fork.c, saying "define CONFIG_ARCH_THREAD_INFO_ALLOCATOR if the
> > generic code isn't what you need", and pu
I'll try to reply in Will's absence, though I gave up trying to
understand these threads long time ago ;).
On 16 October 2015 at 17:16, Peter Zijlstra wrote:
> On Fri, Oct 16, 2015 at 09:04:22AM -0700, Paul E. McKenney wrote:
>> On Fri, Oct 16, 2015 at 05:18:30PM +0200, Peter Zijlstra wrote:
>> >
On 16 October 2015 at 17:04, Paul E. McKenney
wrote:
> On Fri, Oct 16, 2015 at 05:18:30PM +0200, Peter Zijlstra wrote:
>> If so, however, I suspect AARGH64 is borken and would need (just like
>> PPC):
>>
>> #define smp_mb__before_spinlock() smp_mb()
>>
>> The problem is that schedule() (when a
On Wed, Oct 21, 2015 at 09:44:38AM +0100, Dave P Martin wrote:
> On Mon, Oct 19, 2015 at 02:24:39PM +0100, Suzuki K. Poulose wrote:
> > Delay the ELF HWCAP initialisation untill all the (enabled) CPUs are
>
> nit: untill
>
> No need to fix this unless you respin the series for some other
> reason
On Wed, Oct 21, 2015 at 10:00:51AM +0100, Dave P Martin wrote:
> From ab00f84e4d45e95b4d816961a0160f1d448aa886 Mon Sep 17 00:00:00 2001
> From: Dave Martin
> Date: Thu, 30 Jul 2015 16:36:25 +0100
> Subject: [PATCH 1/2] arm64: Constify hwcap name string arrays
>
> The hwcap string arrays used for
On Mon, Oct 19, 2015 at 02:24:37PM +0100, Suzuki K. Poulose wrote:
> At the end( Patches 19-24 ) , we add a new ABI to expose the CPU feature
> registers to the user space via emulation of MRS. The system exposes only a
> limited set of feature values (See the documentation patch) from the above
>
On Thu, Oct 22, 2015 at 01:06:03PM +0100, Suzuki K. Poulose wrote:
> On Thu, Oct 22, 2015 at 01:26:52PM +1100, Stephen Rothwell wrote:
> > Today's linux-next merge of the tip tree got a conflict in:
> >
> > arch/arm64/kernel/cpufeature.c
> >
> > between commit:
> >
> > da8d02d19ffd ("arm64/c
On Thu, Oct 22, 2015 at 02:43:34PM +0200, Thomas Gleixner wrote:
> On Thu, 22 Oct 2015, Russell King - ARM Linux wrote:
> > The solutions are:
> > * A patch to restore the pr_debug() which Thomas applies, and Catalin
> > and myself then pull Thomas' tree again, which potentially creates
> > a m
entries, I would rather have a
HWCAP_ASYMMETRIC bit for big.LITTLE systems and let user space decide
whether to read all entries or not.
> > I wonder if we still can try to make "sched_getcpu()" use vDSO
> > instead of the syscall to make it faster? Now that there exists a
> > vDS
On Wed, Sep 02, 2015 at 05:21:24PM +, Pinski, Andrew wrote:
> On Sep 3, 2015, at 1:12 AM, Catalin Marinas wrote:
> > On Wed, Sep 02, 2015 at 10:52:05PM +0800, Andrew Pinski wrote:
> >> That is not a bad idea. Put this array in the data section of the
> >> VDSO too.
On Fri, Sep 04, 2015 at 12:11:51AM +0600, Alexander Kuleshov wrote:
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -28,7 +28,50 @@
>
> #define ARM64_NCAPS 4
>
> +/*
> + * ID_AA64ISAR0_EL1 AES, bits [7:4]
> + */
> +#define I
On Fri, Sep 04, 2015 at 12:12:52AM +0600, Alexander Kuleshov wrote:
> The 26d75e67c commit (arm64/cpufeature.h: Add macros for a cpu features
Please drop the commit number here, that's specific to your tree and not
something in mainline.
--
Catalin
--
To unsubscribe from this list: send the line
On Wed, Sep 02, 2015 at 12:19:07PM +0200, Ard Biesheuvel wrote:
> On 2 September 2015 at 11:48, Ard Biesheuvel
> wrote:
> > Couldn't we allocate some flag bits in the Image header to communicate
> > the page size to the bootloader?
>
> Something like this perhaps?
>
> 8<
On Thu, Aug 27, 2015 at 04:21:00PM +0800, yalin wang wrote:
> This patch change ioremap_*() first parameter type to resource_size_t to
> be the same as other platforms, and add ioremap_cache macro,
> because some code will test if this macro is defined or not, and
> will generate a generric version
On Wed, Sep 02, 2015 at 11:24:54AM +0100, Will Deacon wrote:
> On Sun, Aug 30, 2015 at 07:19:59AM +0100, yalin wang wrote:
> > This patch add kc_offset_to_vaddr() and kc_vaddr_to_offset(),
> > the default version doesn't work on arm64, because arm64 kernel address
> > is below the PAGE_OFFSET, like
On Fri, Oct 16, 2015 at 10:28:11AM -0700, Paul E. McKenney wrote:
> So RCU needs the following sort of guarantee:
>
> void task1(unsigned long flags)
> {
> WRITE_ONCE(x, 1);
> WRITE_ONCE(z, 1);
> raw_spin_unlock_irqrestore(&rnp->lock, flags);
>
On Mon, Oct 19, 2015 at 09:06:05AM +0200, Ingo Molnar wrote:
> * Peter Zijlstra wrote:
>
> > In any case, its all moot now, since Paul no longer requires schedule() to
> > imply
> > a full barrier.
> >
> > [...]
>
> Nevertheless from a least-surprise POV it might be worth guaranteeing it,
> b
On Mon, Oct 19, 2015 at 03:39:36PM +0200, Christoffer Dall wrote:
> On Mon, Oct 19, 2015 at 02:24:55PM +0100, Suzuki K. Poulose wrote:
> > Use the system wide safe value from the new API for safer
> > decisions
> >
> > Cc: Marc Zyngier
> > Cc: Christoffer Dall
> > Cc: kvm...@lists.cs.columbia.ed
On Sat, Oct 17, 2015 at 10:38:16PM +0900, Jungseok Lee wrote:
> On Oct 17, 2015, at 1:06 AM, Catalin Marinas wrote:
> > BTW, a static allocation (DEFINE_PER_CPU for the whole irq stack) would
> > save us from another stack address reading on the IRQ entry path. I'm
> >
On Mon, Oct 19, 2015 at 02:19:26PM +0100, Suzuki K. Poulose wrote:
> Ard Biesheuvel (1):
> arm64: Add page size to the kernel image header
>
> Mark Rutland (1):
> arm64: Simplify NR_FIX_BTMAPS calculation
>
> Suzuki K. Poulose (10):
> arm64: Move swapper pagetable definitions
> arm64: Han
On Wed, Sep 16, 2015 at 10:23:21PM +0800, Jisheng Zhang wrote:
> Currently, if cpuidle is disabled or not supported, powertop reports
> zero wakeups and zero events. This is due to the cpu_idle tracepoints
> are missing.
>
> This patch is to make cpu_idle tracepoints always available even if
> cpu
On Sat, Oct 17, 2015 at 02:28:11PM +, Jungseok Lee wrote:
> Note that this patch does not cover a case where MMU is disabled. The
> last stack frame of swapper, for example, has PC in a form of physical
> address. Unfortunately, a simple conversion using phys_to_virt() cannot
> cover all scenar
On Thu, Oct 15, 2015 at 10:18:12AM -0400, Steven Rostedt wrote:
> On Thu, 15 Oct 2015 13:51:33 +0100
> Will Deacon wrote:
>
> > Is this the same old problem caused by e306dfd06fcb ("ARM64: unwind: Fix
> > PC calculation")? I've said previously that I'm happy to revert that if
> > we're the only a
On Wed, Sep 30, 2015 at 05:41:03PM +0100, Mark Brown wrote:
> On Wed, Sep 30, 2015 at 11:19:19AM +0100, Catalin Marinas wrote:
> > On Wed, Sep 30, 2015 at 01:13:57AM +0300, Yury Norov wrote:
>
> > > - What for ILP32 on ARM64?
> > > See https://lkml.org/lkml/
On Thu, Oct 01, 2015 at 01:02:46PM +0530, Pankaj Jangra wrote:
> In android system, after system is running for long time say 10 hour,
> some time i am hitting below
> traces:
>
> init[1]: undefined instruction: pc=00401624
> Code: 1a9f00c2 aa1703e0 2a1603e1 9400e1bf (6b1f001f)
> Kernel p
On Thu, Oct 01, 2015 at 04:24:24PM +0200, Thomas Gleixner wrote:
> On Thu, 1 Oct 2015, tip-bot for Yang Yingliang wrote:
>
> > Commit-ID: f1e0bb0ad473a32d1b7e6d285ae9f7e47710bb5e
> > Gitweb:
> > http://git.kernel.org/tip/f1e0bb0ad473a32d1b7e6d285ae9f7e47710bb5e
> > Author: Yang Yingliang
On Wed, Sep 30, 2015 at 03:59:04PM -0700, Yang Shi wrote:
> diff --git a/arch/arm64/kernel/debug-monitors.c
> b/arch/arm64/kernel/debug-monitors.c
> index cebf786..eb520d0 100644
> --- a/arch/arm64/kernel/debug-monitors.c
> +++ b/arch/arm64/kernel/debug-monitors.c
> @@ -292,11 +292,11 @@ static in
On Thu, Oct 01, 2015 at 03:11:29PM +0900, AKASHI Takahiro wrote:
> On 09/30/2015 11:49 AM, Li Bin wrote:
> >When function graph tracer is enabled, the following operation
> >will trigger panic:
> >
> >mount -t debugfs nodev /sys/kernel
> >echo next_tgid > /sys/kernel/tracing/set_ftrace_filter
> >ec
On Thu, Oct 01, 2015 at 09:49:46PM +, Pinski, Andrew wrote:
> Ok, we will rewrite these patches using 32bit time_t and 32bit off_t
> and redo the toolchain support for them. Note this is going back to
> the abi I had originally done when I submitted my original version
> when it was asked to c
On Fri, Oct 02, 2015 at 04:56:48PM +0900, AKASHI Takahiro wrote:
> >>On 09/30/2015 11:49 AM, Li Bin wrote:
> >>>This is because when using function graph tracer, if the traced
> >>>function return value is in multi regs ([0x-07]), return_to_handler
>
> typo: 0x-07 => x0-x7
I fixed this up.
> and
On Tue, Sep 15, 2015 at 04:41:18PM +0100, Suzuki K. Poulose wrote:
> From: Ard Biesheuvel
>
> This patch adds the page size to the arm64 kernel image header
> so that one can infer the PAGESIZE used by the kernel. This will
> be helpful to diagnose failures to boot the kernel with page size
> not
On Fri, Oct 02, 2015 at 04:49:01PM +0100, Catalin Marinas wrote:
> On Tue, Sep 15, 2015 at 04:41:18PM +0100, Suzuki K. Poulose wrote:
> > From: Ard Biesheuvel
> >
> > This patch adds the page size to the arm64 kernel image header
> > so that one can infer the PAGESI
Hi Linus,
Please pull the arm64 fixes below. Thanks.
The following changes since commit 9ffecb10283508260936b96022d4ee43a7798b4c:
Linux 4.3-rc3 (2015-09-27 07:50:08 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
fo
On Mon, Aug 06, 2018 at 05:47:36PM +0200, Ard Biesheuvel wrote:
> On 6 August 2018 at 14:42, Robin Murphy wrote:
> > On 06/08/18 11:25, Mikulas Patocka wrote:
> > [...]
> >>>
> >>> None of this explains why some transactions fail to make it across
> >>> entirely. The overlapping writes in question
Hi Linus,
Please pull the arm64 fixes below. Thanks.
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
f
On Tue, Aug 28, 2018 at 12:14:12PM +0200, Vincent Whitchurch wrote:
> On Mon, Aug 27, 2018 at 03:16:41PM -0700, Andrew Morton wrote:
> > On Mon, 27 Aug 2018 10:38:21 +0200 Vincent Whitchurch
> > wrote:
> > > --- a/lib/Kconfig.debug
> > > +++ b/lib/Kconfig.debug
> > > @@ -593,6 +593,15 @@ config D
On Thu, Aug 23, 2018 at 08:20:36PM +0530, Kedareswararao Appana wrote:
> On arm64 platform I have booted Linux only with > 32-bit
> Address i.e from 0x8 (reg = <0x8 0x 0x0 0x8000>)
So you have 2GB of RAM starting at 0x8__.
> In my driver, I am using dma_
On Fri, Aug 03, 2018 at 01:09:02PM -0400, Mikulas Patocka wrote:
> while (1) {
> start = (unsigned)random() % (LEN + 1);
> end = (unsigned)random() % (LEN + 1);
> if (start > end)
> continue;
> for (i = start; i < e
Hi Matt,
On Fri, Aug 03, 2018 at 03:44:44PM -0500, Matt Sealey wrote:
> On 3 August 2018 at 13:25, Mikulas Patocka wrote:
> > On Fri, 3 Aug 2018, Ard Biesheuvel wrote:
> >> Are we still talking about overlapping unaligned accesses here? Or do
> >> you see other failures as well?
> >
> > Yes - it
leaner to
> > map this to SIGILL rather than be permissive and regret it later.
>
> I couldn't find any user, and I'm happy to just send userspace to hell
> in that case. But it could also been said that since it was never
> prevented, it is a de-facto ABI.
I wouldn't really go as far as SIGILL on WFI. I think the patch is fine
as it is. In case Will plans to merge it:
Acked-by: Catalin Marinas
On Wed, Aug 08, 2018 at 10:12:27AM -0400, Mikulas Patocka wrote:
> On Wed, 8 Aug 2018, Catalin Marinas wrote:
> > On Fri, Aug 03, 2018 at 01:09:02PM -0400, Mikulas Patocka wrote:
> > > while (1) {
> > > start = (unsigned)random() % (LEN + 1);
> > &
On Wed, Aug 08, 2018 at 02:26:11PM +, David Laight wrote:
> From: Mikulas Patocka
> > Sent: 08 August 2018 14:47
> ...
> > The problem on ARM is that I see data corruption when the overlapping
> > unaligned writes are done just by a single core.
>
> Is this a sequence of unaligned writes (that
On Wed, Aug 08, 2018 at 04:01:12PM +0100, Richard Earnshaw wrote:
> On 08/08/18 15:12, Mikulas Patocka wrote:
> > On Wed, 8 Aug 2018, Catalin Marinas wrote:
> >> On Fri, Aug 03, 2018 at 01:09:02PM -0400, Mikulas Patocka wrote:
> >>> while (1) {
> >>>
On Thu, Aug 23, 2018 at 06:47:09PM +1000, Nicholas Piggin wrote:
> The generic tlb_end_vma does not call invalidate_range mmu notifier,
> and it resets resets the mmu_gather range, which means the notifier
> won't be called on part of the range in case of an unmap that spans
> multiple vmas.
>
> A
On Fri, Aug 24, 2018 at 02:40:11PM +0200, Vincent Whitchurch wrote:
> diff --git a/mm/kmemleak.c b/mm/kmemleak.c
> index 9a085d525bbc..61ba47a357fc 100644
> --- a/mm/kmemleak.c
> +++ b/mm/kmemleak.c
> @@ -311,6 +311,9 @@ static void hex_dump_object(struct seq_file *seq,
> const u8 *ptr = (con
is available but is disabled
> by default and can be activated via the kernel command line.
>
> Signed-off-by: Vincent Whitchurch
I think that's also consistent with a late disabling of kmemleak when
the debugfs entry sticks around.
Acked-by: Catalin Marinas
point?
> Signed-off-by: Dave Kleikamp
> Cc: AKASHI Takahiro
> Cc: Catalin Marinas
> Cc: Will Deacon
> ---
> arch/arm64/kernel/machine_kexec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/machine_kexec.c
> b/arch/arm64
On Mon, Jul 30, 2018 at 05:22:35PM +0100, Will Deacon wrote:
> On Mon, Jul 30, 2018 at 05:16:42PM +0100, Catalin Marinas wrote:
> > On Mon, Jul 30, 2018 at 10:29:21AM -0500, Dave Kleikamp wrote:
> > > machine_kexec flushes the reboot_code_buffer from the icache
> > > af
On Wed, May 10, 2017 at 12:55:12PM +0100, Will Deacon wrote:
> On Wed, May 10, 2017 at 09:38:03AM +0100, Catalin Marinas wrote:
> > On Mon, May 08, 2017 at 11:07:24AM +0100, Will Deacon wrote:
> > > On Fri, May 05, 2017 at 02:07:28PM -0700, Florian Fainelli wrote:
> > &g
Hi Linus,
Please pull the arm64 updates below. The mm/vmalloc.c change was acked
by Michal Hocko and the arch/arm one by Russell King. Thanks.
The following changes since commit 92f66f84d9695d07adf9bc987bbcce4bf9b8e87c:
arm64: Fix the DMA mmap and get_sgtable API with DMA_ATTR_FORCE_CONTIGUOUS
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 arm64_ftr_bi
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
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 enabled
--------
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
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 on t
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
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, stru
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 @@
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/
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 + chunk)
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)
> [...]
> > +
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 un
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: KV
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
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 BRCM_CPU_PART_VULC
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 verify_local_c
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 SD
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 vir
safe syscalls.
For arm64:
Acked-by: Catalin Marinas
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
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
>
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
> > lock
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 pendi
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 of
601 - 700 of 3477 matches
Mail list logo
