On Thu, Feb 28, 2019 at 06:14:34PM +, Suzuki K Poulose wrote:
> On 27/02/2019 01:05, Jeremy Linton wrote:
> > There are various reasons, including bencmarking, to disable spectrev2
> > mitigation on a machine. Provide a command-line to do so.
> >
> > Signed-off-by: Jeremy Linton
> > Cc:
On Mon, Feb 25, 2019 at 08:03:42PM -0800, ndesaulni...@google.com wrote:
> Clang warns: vector initializers are not compatible with NEON intrinsics
> in big endian mode [-Wnonportable-vector-initialization]
>
> While this is usually the case, it's not an issue for this case since
> we're
On Fri, Feb 22, 2019 at 06:04:51PM +, Will Deacon wrote:
> Will Deacon (3):
> asm-generic/io: Pass result of I/O accessor to __io_[p]ar()
> riscv: io: Update __io_[p]ar() macros to take an argument
> arm64: io: Hook up __io_par() for inX() ordering
Since we have the acks in place, I
On Tue, Feb 26, 2019 at 06:43:41PM +, James Morse wrote:
> From: Zhang Lei
>
> On the Fujitsu-A64FX cores ver(1.0, 1.1), memory access may cause
> an undefined fault (Data abort, DFSC=0b11). This fault occurs under
> a specific hardware condition when a load/store instruction performs an
Hi Jeremy,
On Tue, Feb 26, 2019 at 07:05:34PM -0600, Jeremy Linton wrote:
> Jeremy Linton (6):
> arm64: Provide a command line to disable spectre_v2 mitigation
> arm64: add sysfs vulnerability show for meltdown
> arm64: Always enable spectrev2 vulnerability detection
> arm64: add sysfs
() GS:8881f768() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 888453d0 CR3: 0001c4244003 CR4: 001606a0
> Kernel panic - not syncing: Fatal exception
> Shutting down cpus with NMI
> Kernel Offset: 0x24c0 from 0x8100 (relocation range:
> 0x8000-0xbfff)
> ---[ end Kernel panic - not syncing: Fatal exception ]---
>
> Signed-off-by: Qian Cai
Reviewed-by: Catalin Marinas
BUG_ON(PageReserved(page));
> free_pages_exact(addr, table_size);
> + kmemleak_free(addr);
Same comment as for v1, call kmemleak_free() before free_pages_exact().
With that:
Reviewed-by: Catalin Marinas
On Wed, Feb 27, 2019 at 12:15:56PM -0500, Qian Cai wrote:
> After offlined a memory block, kmemleak scan will trigger a crash, as it
> encounters a page ext address that has already been freed during memory
> offlining. At the beginning in alloc_page_ext(), it calls
> kmemleak_alloc(), but it does
On Fri, Feb 08, 2019 at 05:04:25PM +, Julien Grall wrote:
> TIF_USEDFPU is not defined as thread flags for Arm64. So drop it from
> the documentation.
>
> Signed-off-by: Julien Grall
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: linux-arm-ker...@lists.infradead.org
Q
gt; As for the fixed==true path, memblock_reserve() does not register the area
> with kmemleak, so there would be no object to free in memblock_free().
> AFAIU, kmemleak simply ignores this.
Kmemleak is supposed to work with the memblock_{alloc,free} pair and it
ignores the memblock_reserve() as a memblock_alloc() implementation
detail. It is, however, tolerant to memblock_free() being called on a
sub-range or just a different range from a previous memblock_alloc(). So
the original patch looks fine to me. FWIW:
Reviewed-by: Catalin Marinas
Hi Szabolcs,
Thanks for looking into this. Comments below.
On Tue, Feb 19, 2019 at 06:38:31PM +, Szabolcs Nagy wrote:
> i think these rules work for the cases i care about, a more
> tricky question is when/how to check for the new syscall abi
> and when/how the TCR_EL1.TBI0 setting may be
On Sat, Feb 23, 2019 at 02:47:27PM +0800, Xuefeng Wang wrote:
> The protection attributes are only kept in last level tlb, so
> protection changing only need invalidate last level tlb, exclude
> the PWC entries.
>
> Signed-off-by: Xuefeng Wang
> ---
> mm/mprotect.c | 2 +-
> 1 file changed, 1
On Wed, Jan 30, 2019 at 06:04:15PM +, Andre Przywara wrote:
> On Fri, 25 Jan 2019 12:07:02 -0600
> Jeremy Linton wrote:
> > Buried behind EXPERT is the ability to build a kernel without
> > SSBD, this needlessly clutters up the code as well as creates
> > the opportunity for bugs. It also
Hi Masami,
On Wed, Feb 13, 2019 at 12:42:53AM +0900, Masami Hiramatsu wrote:
> In v3, I rebased on the latest arm64 kernel which includes
> James' KVM/HYP fixes for kprobes, and fix a reported bugs
> in [4/4].
I will queue this patches at 5.1-rc1 since the arm64 for-next/core
branch is currently
gt; With tagged pointers this range will get bigger than it needs to be.
> This patch makes kmemleak untag pointers before saving them to min_addr
> and max_addr and when performing a lookup.
>
> Signed-off-by: Andrey Konovalov
I reviewed the old series. This patch also looks fine:
Acked-by: Catalin Marinas
gt; With tagged pointers this range will get bigger than it needs to be.
> This patch makes kmemleak untag pointers before saving them to min_addr
> and max_addr and when performing a lookup.
>
> Signed-off-by: Andrey Konovalov
Acked-by: Catalin Marinas
initramfs.c | 9 +
> 8 files changed, 28 insertions(+), 47 deletions(-)
For arm64:
Acked-by: Catalin Marinas
On Mon, Feb 11, 2019 at 12:32:55PM -0800, Evgenii Stepanov wrote:
> On Mon, Feb 11, 2019 at 9:28 AM Kevin Brodsky wrote:
> > On 19/12/2018 12:52, Dave Martin wrote:
> > > Really, the kernel should do the expected thing with all "non-weird"
> > > memory.
> > >
> > > In lieu of a proper definition
On Mon, Feb 11, 2019 at 02:21:56PM +0100, Christoph Hellwig wrote:
> Any chance to get a quick review on this small series?
For arm64:
Acked-by: Catalin Marinas
On Sun, Feb 10, 2019 at 09:28:43AM +, Peng Fan wrote:
> arm64_memory_present is doing same thing as memblocks_present, so
> let's use common code memblocks_present instead of platform
> specific arm64_memory_present.
>
> Signed-off-by: Peng Fan
I already merged a similar one (see commit
Hi Dave,
On Wed, Dec 12, 2018 at 05:01:12PM +, Dave P Martin wrote:
> On Mon, Dec 10, 2018 at 01:50:57PM +0100, Andrey Konovalov wrote:
> > arm64 has a feature called Top Byte Ignore, which allows to embed pointer
> > tags into the top byte of each pointer. Userspace programs (such as
> >
On Fri, Feb 08, 2019 at 09:36:48AM +, Julien Thierry wrote:
> From e839dec632bbf440efe8314751138ba46324078c Mon Sep 17 00:00:00 2001
> From: Julien Thierry
> Date: Fri, 8 Feb 2019 09:21:58 +
> Subject: [PATCH] arm64: irqflags: Fix clang build warnings
>
> Clang complains when passing asm
Hi Julien,
On Thu, Jan 31, 2019 at 02:58:38PM +, Julien Thierry wrote:
> This series is a continuation of the work started by Daniel [1]. The goal
> is to use GICv3 interrupt priorities to simulate an NMI.
>
> The patches depend on the core API for NMIs patches [2]. Both series can
> be
On Mon, Feb 04, 2019 at 04:01:01PM -0500, Qian Cai wrote:
> The commit e2a2e56e4082 ("arm64: dump: no need to check return value of
> debugfs_create functions") converted ptdump_debugfs_register() from
> void, but forgot to fix the efi version of ptdump_init().
>
>
acon
> Signed-off-by: Valentin Schneider
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Mark Rutland
> Cc: Marc Zyngier
> Cc: Julien Grall
> Cc: Julien Thierry
> Cc: Thomas Gleixner
> Cc: linux-arm-ker...@lists.infradead.org
Queued for 5.1. Thanks
--
Catalin
Hi,
Could you please copy the whole description from the cover letter to the
actual patch and only send one email (full description as in here
together with the patch)? If we commit this to the kernel, it would be
useful to have the information in the log for reference later on.
More comments
On Tue, Jan 22, 2019 at 03:41:11PM +0100, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Catali
On Tue, Jan 22, 2019 at 08:54:33AM +, Zhang, Lei wrote:
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index efb7b2c..37e4f18 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -666,6 +666,28 @@ static int do_sea(unsigned long addr, unsigned int esr,
>
On Mon, Jan 21, 2019 at 10:03:53AM +0200, Mike Rapoport wrote:
> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
> index ae34e3a..2c61ea4 100644
> --- a/arch/arm64/mm/numa.c
> +++ b/arch/arm64/mm/numa.c
> @@ -237,6 +237,10 @@ static void __init setup_node_data(int nid, u64
> start_pfn,
y marking pages as PG_reserved is not necessary, they are
> already in the desired state (otherwise they would have been handed over
> to the buddy as free pages and bad things would happen).
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: James Morse
> Cc: Bhupesh Sharma
> Cc
On Mon, Jan 14, 2019 at 01:59:00PM +0100, David Hildenbrand wrote:
> This will be done by free_reserved_page().
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Bhupesh Sharma
> Cc: James Morse
> Cc: Marc Zyngier
> Cc: Dave Kleikamp
> Cc: Mark Rutland
> Cc: And
pass only counts elapsed time, not time since the epoch. They
> will be dealt with later.
>
> Signed-off-by: Arnd Bergmann
Acked-by: Catalin Marinas
(as long as compat follows the arm32 syscall numbers)
ectures twice.
>
> Signed-off-by: Arnd Bergmann
For arm64:
Acked-by: Catalin Marinas
NR_migrate_pages 400
> __SYSCALL(__NR_migrate_pages, compat_sys_migrate_pages)
> +#define __NR_kexec_file_load 401
> +__SYSCALL(__NR_kexec_file_load, sys_kexec_file_load)
For arm64:
Acked-by: Catalin Marinas
e on 64-bit kernels, so that argument is no
> longer very strong.
>
> Assigning the number lets us use the system call on 64-bit kernels as well
> as providing a more consistent set of syscalls across architectures.
>
> Signed-off-by: Arnd Bergmann
For the arm64 part:
Acked-by: Catalin Marinas
On Tue, Jan 15, 2019 at 08:18:39PM +0100, Anders Roxell wrote:
> When ARCH_MXC get enabled, ARM64_ERRATUM_845719 will be selected and
> this warning will happen when COMPAT isn't set.
>
> WARNING: unmet direct dependencies detected for ARM64_ERRATUM_845719
> Depends on [n]: COMPAT [=n]
>
Hi Julien,
On Tue, Jan 15, 2019 at 01:58:25PM +, Julien Thierry wrote:
> Julien Thierry (4):
> arm64: uaccess: Cleanup get/put_user()
> arm64: uaccess: Implement unsafe accessors
> uaccess: Check no rescheduling function is called in unsafe region
> arm64: uaccess: Implement
Hi Shijith,
On Thu, Jan 24, 2019 at 07:00:42AM +, Shijith Thotton wrote:
> On 01/23/2019 11:45 PM, Catalin Marinas wrote:
> > diff --git a/arch/arm64/mm/flush.c b/arch/arm64/mm/flush.c
> > index 30695a868107..5c9073bace83 100644
> > --- a/arch/arm64/mm/flush.c
> >
On Tue, Jan 22, 2019 at 05:44:02AM +, Will Deacon wrote:
> On Mon, Jan 21, 2019 at 02:21:28PM +0000, Catalin Marinas wrote:
> > arm64: Do not issue IPIs for user executable ptes
> >
> > From: Catalin Marinas
> >
> > Commit 3b8c9f1cdfc5 ("arm64: IPI e
WFI.
>
> Since the logic of cpu_do_idle is becoming a bit more complex than just
> two instructions, lets turn it from ASM to C.
>
> Signed-off-by: Julien Thierry
> Suggested-by: Daniel Thompson
> Cc: Catalin Marinas
> Cc: Will Deacon
Reviewed-by: Catalin Marinas
> + asm volatile(ALTERNATIVE(
> + "mov%0, %1\n"
> + "nop\n"
> + "nop",
> + "mrs_s %0, " __stringify(SYS_ICC_PMR_EL1) "\n"
> + "ands %1, %1, " __stringify(PSR_I_BIT) "\n"
> + "csel %0, %0, %2, eq",
> + ARM64_HAS_IRQ_PRIO_MASKING)
> + : "=" (flags), "+r" (daif_bits)
> + : "r" (GIC_PRIO_IRQOFF)
> : "memory");
> +
> + return flags;
> +}
BTW, how's the code generated from the C version? It will have a branch
but may not be too bad. Either way is fine by me.
Reviewed-by: Catalin Marinas
gt; similar to other arches.
> >>
> >> memblocks_present() is a direct replacement of arm64_memory_present()
> >>
> >> Signed-off-by: Logan Gunthorpe
> >> Acked-by: Catalin Marinas
> >> Cc: Will Deacon
> >> ---
> >> arch/arm64/mm/init.c | 20 +-
On Mon, Jan 21, 2019 at 07:35:11AM -0600, Rob Herring wrote:
> On Mon, Jan 21, 2019 at 6:19 AM Robin Murphy wrote:
> >
> > On 21/01/2019 11:57, Marc Gonzalez wrote:
> > [...]
> > > # echo dump=0xffc021e0 > /sys/kernel/debug/kmemleak
> > > kmemleak: Object 0xffc021e0 (size
onsibility of the user to ensure cache maintenance
(I can add more text to the patch below but need to get to the bottom of
this first)
-8<-
arm64: Do not issue IPIs for user executable ptes
From: Catalin Marinas
Commit 3b8c9f1cdfc5 ("arm64: IPI each CPU after invalidatin
On Fri, Jan 18, 2019 at 04:36:59PM +0100, Marc Gonzalez wrote:
> mount -t debugfs nodev /sys/kernel/debug/
> echo scan > /sys/kernel/debug/kmemleak
>
> Unable to handle kernel paging request at virtual address ffc021e0
[...]
> Call trace:
> scan_block+0x70/0x190
>
On Fri, Jan 18, 2019 at 05:30:02PM +, Catalin Marinas wrote:
> On Fri, Jan 18, 2019 at 04:57:32PM +, Julien Thierry wrote:
> > On 18/01/2019 16:09, Catalin Marinas wrote:
> > > On Tue, Jan 08, 2019 at 02:07:30PM +, Julien Thierry wrote:
> > >> +
On Fri, Jan 18, 2019 at 04:57:32PM +, Julien Thierry wrote:
> On 18/01/2019 16:09, Catalin Marinas wrote:
> > On Tue, Jan 08, 2019 at 02:07:30PM +, Julien Thierry wrote:
> >> + asm volatile(ALTERNATIVE(
> >> + "nop",
> >>
interrupt enabling/disabling
> goes through ICC_PMR_EL1.
>
> Signed-off-by: Julien Thierry
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: James Morse
Reviewed-by: Catalin Marinas
on return from a runtime service.
> This allows to check for flags that are not necesarly related to
> irqflags.
>
> Signed-off-by: Julien Thierry
Acked-by: Catalin Marinas
e enter a guest.
>
> Signed-off-by: Julien Thierry
> Cc: Christoffer Dall
> Cc: Marc Zyngier
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: kvm...@lists.cs.columbia.edu
Acked-by: Catalin Marinas
On Tue, Jan 08, 2019 at 02:07:27PM +, Julien Thierry wrote:
> CPU does not received signals for interrupts with a priority masked by
> ICC_PMR_EL1. This means the CPU might not come back from a WFI
> instruction.
>
> Make sure ICC_PMR_EL1 does not mask interrupts when doing a WFI.
>
> Since
stores PSR.I bit in spsr_el1 for exceptions and ERET.
>
> Add PMR to the registers to save in the pt_regs struct upon kernel entry,
> and restore it before ERET. Also, initialize it to a sane value when
> creating new tasks.
>
> Signed-off-by: Julien Thierry
> Cc: Catalin Marin
Hi Julien,
On Tue, Jan 08, 2019 at 02:07:30PM +, Julien Thierry wrote:
> + * Having two ways to control interrupt status is a bit complicated. Some
> + * locations like exception entries will have PSR.I bit set by the
> architecture
> + * while PMR is unmasked.
> + * We need the irqflags to
mask interrupts.
>
> Signed-off-by: Julien Thierry
> Suggested-by: Daniel Thompson
> Cc: Oleg Nesterov
> Cc: Catalin Marinas
> Cc: Will Deacon
Acked-by: Catalin Marinas
On Tue, Jan 08, 2019 at 02:07:19PM +, Julien Thierry wrote:
> When using VHE, the host needs to clear HCR_EL2.TGE bit in order
> to interract with guest TLBs, switching from EL2&0 translation regime
> to EL1&0.
>
> However, some non-maskable asynchronous event could happen while TGE is
>
On Fri, Jan 11, 2019 at 07:26:09AM +0300, Konstantin Khlebnikov wrote:
> On Thu, Jan 10, 2019 at 11:45 PM Cong Wang wrote:
> > On Tue, Jan 8, 2019 at 1:30 AM Konstantin Khlebnikov
> > wrote:
> > > @@ -443,12 +444,14 @@ static struct neigh_hash_table
> > > *neigh_hash_alloc(unsigned int shift)
>
Hi Prateek,
On Wed, Jan 09, 2019 at 02:09:22PM +0530, Prateek Patel wrote:
> From: Sri Krishna chowdary
>
> kmemleak detects allocated objects as leaks if not accessed for
> default scan time. The memory allocated using avc_alloc_node
> is freed using rcu mechanism when nodes are reclaimed or
On Thu, Jan 03, 2019 at 06:07:35PM +0100, Michal Hocko wrote:
> > > On Wed 02-01-19 13:06:19, Qian Cai wrote:
> > > [...]
> > >> diff --git a/mm/kmemleak.c b/mm/kmemleak.c
> > >> index f9d9dc250428..9e1aa3b7df75 100644
> > >> --- a/mm/kmemleak.c
> > >> +++ b/mm/kmemleak.c
> > >> @@ -576,6 +576,16
On Mon, Jan 07, 2019 at 03:31:18PM +0800, He Zhe wrote:
> On 1/5/19 2:37 AM, Catalin Marinas wrote:
> > On Fri, Jan 04, 2019 at 10:29:13PM +0800, zhe...@windriver.com wrote:
> >> It's not necessary to keep consistency between readers and writers of
> >> kmemle
Hi Nathan,
On Tue, Jan 01, 2019 at 01:17:06PM -0600, Nathan Royce wrote:
> I had a leak somewhere and I was directed to look into SUnreclaim
> which was 5.5 GB after an uptime of a little over 1 month on an 8 GB
> system. kmalloc-2048 was a problem.
> I just had enough and needed to find out the
On Fri, Jan 04, 2019 at 10:29:13PM +0800, zhe...@windriver.com wrote:
> It's not necessary to keep consistency between readers and writers of
> kmemleak_lock. RCU is more proper for this case. And in order to gain better
> performance, we turn the reader locks to RCU read locks and writer locks to
Hi Qian,
On Wed, Jan 02, 2019 at 11:08:49AM -0500, Qian Cai wrote:
> Kmemleak could quickly fail to allocate an object structure and then
> disable itself in a low-memory situation. For example, running a mmap()
> workload triggering swapping and OOM [1].
>
> First, it unnecessarily attempt to
On Tue, Dec 18, 2018 at 04:03:38PM +0100, Andrey Konovalov wrote:
> On Wed, Dec 12, 2018 at 4:02 PM Catalin Marinas
> wrote:
> > The summary of our internal discussions (mostly between kernel
> > developers) is that we can't properly describe a user ABI that covers
> > fu
gt; ksys_ioctl+0x67/0x90
> __x64_sys_ioctl+0x1a/0x20
> do_syscall_64+0x4d/0xf0
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> kmemleak is an error detecting feature. We would not expect as good
> performance
> as without it. As there is no raw rwlock defining helpers, we turn
> kmemleak_lock
> to a raw spinlock.
>
> Signed-off-by: He Zhe
> Cc: catalin.mari...@arm.com
> Cc: bige...@linutronix.de
> Cc: t...@linutronix.de
> Cc: rost...@goodmis.org
As I replied already, I don't think this patch would increase the
kmemleak latency (or performance), although I haven't actually tested
it. FWIW:
Acked-by: Catalin Marinas
On Tue, Dec 18, 2018 at 06:51:41PM +0800, He Zhe wrote:
> On 2018/12/6 03:14, Sebastian Andrzej Siewior wrote:
> > With raw locks you wouldn't have multiple readers at the same time.
> > Maybe you wouldn't have recursion but since you can't have multiple
> > readers you would add lock contention
> + select PCI_ECAM if (ACPI && PCI)
> > select POWER_RESET
> > select POWER_SUPPLY
> > select REFCOUNT_FULL
> >
>
> I need a maintainer ACK here.
Acked-by: Catalin Marinas
Hi Linus,
Please pull the arm64 fix below. Thanks.
The following changes since commit 40e020c129cfc991e8ab4736d2665351ffd1468d:
Linux 4.20-rc6 (2018-12-09 15:31:00 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
On Wed, Dec 12, 2018 at 10:03:30AM -0800, Andy Lutomirski wrote:
> On Wed, Dec 12, 2018 at 8:52 AM Rich Felker wrote:
> > On Wed, Dec 12, 2018 at 08:39:53AM -0800, Andy Lutomirski wrote:
> > > I'm proposing another alternative. Given that x32 already proves that
> > > the user bitness model
Hi Andrey,
On Wed, Dec 12, 2018 at 03:23:25PM +0100, Andrey Konovalov wrote:
> On Mon, Dec 10, 2018 at 3:31 PM Vincenzo Frascino
> wrote:
> > On arm64 the TCR_EL1.TBI0 bit has been set since Linux 3.x hence
> > the userspace (EL0) is allowed to set a non-zero value in the top
> > byte but the
On Wed, Dec 12, 2018 at 12:14:29PM +0530, Prateek Patel wrote:
> On 10/29/2018 4:13 PM, Catalin Marinas wrote:
> > On Mon, Oct 22, 2018 at 11:38:43PM +0530, Prateek Patel wrote:
> > > From: Sri Krishna chowdary
> > >
> > > Kmemleak scan can be cpu intensi
On Tue, Dec 11, 2018 at 12:37:42PM +0100, Florian Weimer wrote:
> * Catalin Marinas:
> > On Tue, Dec 11, 2018 at 10:02:45AM +0100, Arnd Bergmann wrote:
> >> On Tue, Dec 11, 2018 at 6:35 AM Andy Lutomirski wrote:
> >> > I tried to understand what's going o
On Tue, Dec 11, 2018 at 10:02:45AM +0100, Arnd Bergmann wrote:
> On Tue, Dec 11, 2018 at 6:35 AM Andy Lutomirski wrote:
> > I tried to understand what's going on. As far as I can tell, most of
> > the magic is the fact that __kernel_long_t and __kernel_ulong_t are
> > 64-bit as seen by x32 user
On Tue, Dec 11, 2018 at 08:52:57AM +1100, Stephen Rothwell wrote:
> Today's linux-next merge of the arm64 tree got conflicts in:
>
> Documentation/arm64/silicon-errata.txt
> arch/arm64/Kconfig
>
> between commit:
>
> ce8c80c536da ("arm64: Add workaround for Cortex-A76 erratum 1286807")
>
On Mon, Dec 10, 2018 at 02:29:45PM +, Will Deacon wrote:
> On Mon, Dec 10, 2018 at 08:22:06AM -0600, Richard Henderson wrote:
> > On 12/10/18 6:03 AM, Catalin Marinas wrote:
> > >> However, it won't be too long before someone implements support for
> > >> ARM
On Fri, Dec 07, 2018 at 08:38:11AM +, Julien Thierry wrote:
>
>
> On 12/06/2018 06:25 PM, Catalin Marinas wrote:
> > On Mon, Dec 03, 2018 at 01:55:18PM +, Julien Thierry wrote:
> > > diff --git a/arch/arm64/include/asm/uaccess.h
> > > b/arch/arm64/
On Thu, Dec 06, 2018 at 09:50:18AM +, Julien Thierry wrote:
> On 05/12/18 18:26, Catalin Marinas wrote:
> > On Wed, Dec 05, 2018 at 04:55:54PM +, Julien Thierry wrote:
> >> On 04/12/18 17:36, Catalin Marinas wrote:
> >>> On Mon, Nov 12, 2018 at 11:57:01
Hi Doug,
On Fri, Dec 07, 2018 at 10:40:24AM -0800, Doug Anderson wrote:
> On Fri, Dec 7, 2018 at 9:42 AM Catalin Marinas
> wrote:
> > On Tue, Dec 04, 2018 at 07:38:24PM -0800, Douglas Anderson wrote:
> > > Douglas Anderson (4):
> > > kgdb: Remove irq flags
On Sun, Dec 09, 2018 at 09:41:31AM -0600, Richard Henderson wrote:
> On 12/7/18 12:39 PM, Kristina Martsenko wrote:
> > When pointer authentication is in use, data/instruction pointers have a
> > number of PAC bits inserted into them. The number and position of these
> > bits depends on the
Hi Linus,
Please pull the arm64 fix below. Thanks.
The following changes since commit 2595646791c319cadfdbf271563aac97d0843dc7:
Linux 4.20-rc5 (2018-12-02 15:07:55 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
Hi Linus,
Please pull the arm64 fix below. Thanks.
The following changes since commit 2595646791c319cadfdbf271563aac97d0843dc7:
Linux 4.20-rc5 (2018-12-02 15:07:55 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
On Tue, Dec 04, 2018 at 07:38:24PM -0800, Douglas Anderson wrote:
> Douglas Anderson (4):
> kgdb: Remove irq flags from roundup
> kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function()
> kgdb: Don't round up a CPU that failed rounding up before
> kdb: Don't back trace on a
memleak_scan:
>
> # echo "scan" > /sys/kernel/debug/kmemleak
>
> before the patch:
>
> kmemleak: time spend: 41596 us
>
> after the patch:
>
> kmemleak: time spend: 34899 us
>
> Signed-off-by: Oscar Salvador
Acked-by: Catalin Marinas
memleak_scan:
>
> # echo "scan" > /sys/kernel/debug/kmemleak
>
> before the patch:
>
> kmemleak: time spend: 41596 us
>
> after the patch:
>
> kmemleak: time spend: 34899 us
>
> Signed-off-by: Oscar Salvador
Acked-by: Catalin Marinas
On Mon, Dec 03, 2018 at 01:55:18PM +, Julien Thierry wrote:
> diff --git a/arch/arm64/include/asm/uaccess.h
> b/arch/arm64/include/asm/uaccess.h
> index 07c3408..cabfcae 100644
> --- a/arch/arm64/include/asm/uaccess.h
> +++ b/arch/arm64/include/asm/uaccess.h
> @@ -233,6 +233,23 @@ static
On Mon, Dec 03, 2018 at 01:55:18PM +, Julien Thierry wrote:
> diff --git a/arch/arm64/include/asm/uaccess.h
> b/arch/arm64/include/asm/uaccess.h
> index 07c3408..cabfcae 100644
> --- a/arch/arm64/include/asm/uaccess.h
> +++ b/arch/arm64/include/asm/uaccess.h
> @@ -233,6 +233,23 @@ static
this leak has been existed for more than 8-year now and it does not
> reference other part of the memory, let kmemleak ignore it, so users don't
> need to waste time reporting this in the future.
>
> Signed-off-by: Qian Cai
Acked-by: Catalin Marinas
this leak has been existed for more than 8-year now and it does not
> reference other part of the memory, let kmemleak ignore it, so users don't
> need to waste time reporting this in the future.
>
> Signed-off-by: Qian Cai
Acked-by: Catalin Marinas
= kmalloc(sizeof(*rsv), GFP_ATOMIC);
>
> Kmemleak has a known limitation that can only track pointers in the kernel
> virtual space. Hence, it will report false positives due to "rsv" will only
> reference to other physical addresses,
>
> rsv->next = efi_memreserve_root->next;
> efi_memreserve_root->next = __pa(rsv);
>
> Signed-off-by: Qian Cai
Acked-by: Catalin Marinas
It seems that we somehow missed this patch. Cc'ing a few more people
that touched hugetlbpage.c.
Catalin
On Tue, Oct 23, 2018 at 06:36:57AM +0530, Allen Pais wrote:
> Add hstate for each supported hugepage size using arch initcall.
>
> * no hugepage parameters
>
> Without hugepage
It seems that we somehow missed this patch. Cc'ing a few more people
that touched hugetlbpage.c.
Catalin
On Tue, Oct 23, 2018 at 06:36:57AM +0530, Allen Pais wrote:
> Add hstate for each supported hugepage size using arch initcall.
>
> * no hugepage parameters
>
> Without hugepage
On Thu, Dec 06, 2018 at 01:44:24PM +0100, Andrey Konovalov wrote:
> On Thu, Nov 29, 2018 at 7:16 PM Catalin Marinas
> wrote:
> > On Thu, Nov 08, 2018 at 03:48:10PM +0100, Andrey Konovalov wrote:
> > > On Thu, Nov 8, 2018 at 3:36 PM, Andrey Konovalov
> > >
On Wed, Dec 05, 2018 at 04:55:54PM +, Julien Thierry wrote:
> On 04/12/18 17:36, Catalin Marinas wrote:
> > On Mon, Nov 12, 2018 at 11:57:01AM +, Julien Thierry wrote:
> >> diff --git a/arch/arm64/include/asm/irqflags.h
> >> b/arch/arm64/include/asm/irqflags.h
On Wed, Dec 05, 2018 at 04:55:54PM +, Julien Thierry wrote:
> On 04/12/18 17:36, Catalin Marinas wrote:
> > On Mon, Nov 12, 2018 at 11:57:01AM +, Julien Thierry wrote:
> >> diff --git a/arch/arm64/include/asm/irqflags.h
> >> b/arch/arm64/include/asm/irqflags.h
On Mon, Nov 12, 2018 at 11:57:12AM +, Julien Thierry wrote:
> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index 5f4d9ac..66344cd 100644
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -897,13 +897,17 @@ bool arm64_is_fatal_ras_serror(struct
On Mon, Nov 12, 2018 at 11:57:12AM +, Julien Thierry wrote:
> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index 5f4d9ac..66344cd 100644
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -897,13 +897,17 @@ bool arm64_is_fatal_ras_serror(struct
On Mon, Nov 12, 2018 at 11:57:06AM +, Julien Thierry wrote:
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 8dc9dde..e495360 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -35,6 +35,7 @@
> #include
> #include
> #include
> +#include
>
On Mon, Nov 12, 2018 at 11:57:06AM +, Julien Thierry wrote:
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 8dc9dde..e495360 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -35,6 +35,7 @@
> #include
> #include
> #include
> +#include
>
On Mon, Nov 12, 2018 at 11:57:01AM +, Julien Thierry wrote:
> diff --git a/arch/arm64/include/asm/irqflags.h
> b/arch/arm64/include/asm/irqflags.h
> index 24692ed..e0a32e4 100644
> --- a/arch/arm64/include/asm/irqflags.h
> +++ b/arch/arm64/include/asm/irqflags.h
> @@ -18,7 +18,27 @@
>
>
On Mon, Nov 12, 2018 at 11:57:01AM +, Julien Thierry wrote:
> diff --git a/arch/arm64/include/asm/irqflags.h
> b/arch/arm64/include/asm/irqflags.h
> index 24692ed..e0a32e4 100644
> --- a/arch/arm64/include/asm/irqflags.h
> +++ b/arch/arm64/include/asm/irqflags.h
> @@ -18,7 +18,27 @@
>
>
On Mon, Nov 12, 2018 at 11:56:58AM +, Julien Thierry wrote:
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index 039144e..eb8120e 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -249,6 +249,12 @@ alternative_else_nop_endif
> msr
901 - 1000 of 5901 matches
Mail list logo
