On Mon, Jun 24, 2019 at 04:29:39PM +0200, Ard Biesheuvel wrote:
> On Mon, 24 Jun 2019 at 13:23, Ard Biesheuvel wrote:
> > On 6/24/19 1:16 PM, Will Deacon wrote:
> > > On Tue, May 28, 2019 at 11:04:20AM +0100, Will Deacon wrote:
> > >> On Thu, May 23, 2019 at 11:22:52AM +0100, Ard Biesheuvel
On Mon, Jun 24, 2019 at 03:23:46PM +0100, Russell King wrote:
> On Mon, Jun 24, 2019 at 04:18:28PM +0200, Thomas Gleixner wrote:
> > Vincenzo,
> >
> > On Mon, 24 Jun 2019, Thomas Gleixner wrote:
> >
> > > I did not merge the ARM and MIPS parts as they lack any form of
> > > acknowlegment from
y traps and emulates them by default). Also your Makefile
changes never define a __LINUX_ARM_ARCH__ lower than 7. Fix-up below:
--8<---
>From 5655a0313ce7bb731bfed6a19bcfe6b1100b542a Mon Sep 17 00:00:00 2001
From: Catalin Marinas
Date: Mon, 24 Jun 2019 12:16:06 +0100
LANK();
>DEFINE(TVAL_TV_SEC,offsetof(struct timeval, tv_sec));
>DEFINE(TSPEC_TV_SEC, offsetof(struct timespec, tv_sec));
Now that we are moving this to C, do we actually need the asm-offsets?
If not, here's a clean-up patch:
---8<
mers/vdso branch):
8<--
>From 2e09fa6fca341b3ec7ecaf0b67a313a167bb4ff2 Mon Sep 17 00:00:00 2001
From: Catalin Marinas
Date: Mon, 24 Jun 2019 12:19:23 +0100
Subject: [PATCH] vdso: Remove superfluous #ifdef __KERNEL__ in
vdso/datapage.h
With
On Thu, Jun 20, 2019 at 08:46:58AM +0100, Will Deacon wrote:
> On Wed, Jun 19, 2019 at 05:32:42PM -0700, Nick Desaulniers wrote:
> > Generated via:
> > $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make defconfig
> > $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make menuconfig
> >
> > $
On Fri, Jun 21, 2019 at 09:36:15PM +1000, Stephen Rothwell wrote:
> In commit
>
> 86fc32fee888 ("arm64: Fix incorrect irqflag restore for priority masking")
>
> Fixes tag
>
> Fixes: commit 4a503217ce37 ("arm64: irqflags: Use ICC_PMR_EL1 for interrupt
> masking")
>
> has these problem(s):
On Tue, Jun 11, 2019 at 10:38:05AM +0100, Julien Thierry wrote:
> Julien Thierry (7):
> arm64: Do not enable IRQs for ct_user_exit
> arm64: irqflags: Pass flags as readonly operand to restore instruction
> arm64: irqflags: Add condition flags to inline asm clobber list
> arm64: Fix
On Mon, Jun 17, 2019 at 07:00:34PM +0800, Zhangshaokun wrote:
> On 2019/6/17 18:45, Catalin Marinas wrote:
> > On Sat, Jun 15, 2019 at 10:44:33AM +0800, Zhangshaokun wrote:
> >> On 2019/6/14 21:11, Masayoshi Mizuma wrote:
> >>> diff --git a/arch/arm64/mm/dma-mapping.c
On Sat, Jun 15, 2019 at 10:44:33AM +0800, Zhangshaokun wrote:
> On 2019/6/14 21:11, Masayoshi Mizuma wrote:
> > diff --git a/arch/arm64/kernel/cacheinfo.c b/arch/arm64/kernel/cacheinfo.c
> > index 6eaf1c07aa4e..7fa6828bb488 100644
> > --- a/arch/arm64/kernel/cacheinfo.c
> > +++
On Thu, Jun 13, 2019 at 04:45:54PM +0100, Vincenzo Frascino wrote:
> On 13/06/2019 16:35, Catalin Marinas wrote:
> > On Thu, Jun 13, 2019 at 12:16:59PM +0100, Dave P Martin wrote:
> >> On Wed, Jun 12, 2019 at 01:43:20PM +0200, Andrey Konovalov wrote:
> >>> +
> >
On Tue, Jun 11, 2019 at 06:02:47PM -0400, Masayoshi Mizuma wrote:
> On Tue, Jun 11, 2019 at 07:00:07PM +0100, Catalin Marinas wrote:
> > On Tue, Jun 11, 2019 at 11:17:30AM -0400, Masayoshi Mizuma wrote:
> > > --- a/arch/arm64/mm/dma-mapping.c
> > > +++ b/arch/arm64/mm/dm
Hi Szabolcs,
On Wed, Jun 12, 2019 at 05:30:34PM +0100, Szabolcs Nagy wrote:
> On 12/06/2019 15:21, Vincenzo Frascino wrote:
> > +2. ARM64 Tagged Address ABI
> > +---
> > +
> > +From the kernel syscall interface prospective, we define, for the purposes
>
On Thu, Jun 13, 2019 at 02:23:43PM +0100, Dave P Martin wrote:
> On Thu, Jun 13, 2019 at 01:28:21PM +0100, Catalin Marinas wrote:
> > On Thu, Jun 13, 2019 at 12:37:32PM +0100, Dave P Martin wrote:
> > > On Thu, Jun 13, 2019 at 11:15:34AM +0100, Vincenzo Frascino wrote:
> >
On Thu, Jun 13, 2019 at 12:16:59PM +0100, Dave P Martin wrote:
> On Wed, Jun 12, 2019 at 01:43:20PM +0200, Andrey Konovalov wrote:
> > From: Catalin Marinas
> >
> > It is not desirable to relax the ABI to allow tagged user addresses into
> > the kernel indiscrimina
Hi Dave,
On Thu, Jun 13, 2019 at 12:02:35PM +0100, Dave P Martin wrote:
> On Wed, Jun 12, 2019 at 01:43:20PM +0200, Andrey Konovalov wrote:
> > +/*
> > + * Global sysctl to disable the tagged user addresses support. This control
> > + * only prevents the tagged address ABI enabling via prctl()
Change this error code to a more appropriate one.
>
> Signed-off-by: André Almeida
Acked-by: Catalin Marinas
on about how to use
> the kmemleak-test module to test the memory leak scanning.
>
> Signed-off-by: André Almeida
Acked-by: Catalin Marinas
On Tue, Jun 11, 2019 at 11:17:30AM -0400, Masayoshi Mizuma wrote:
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -91,10 +91,6 @@ static int __swiotlb_mmap_pfn(struct vm_area_struct *vma,
>
> static int __init arm64_dma_init(void)
> {
> -
On Tue, Jun 11, 2019 at 11:17:31AM -0400, Masayoshi Mizuma wrote:
> From: Masayoshi Mizuma
>
> Show the warning and taints as TAINT_CPU_OUT_OF_SPEC if the cache line
> size is greater than the maximum.
In general the "out of spec" part is a misnomer, we tend to apply it to
CPU features that are
On Mon, Jun 10, 2019 at 06:53:27PM +0100, Catalin Marinas wrote:
> On Mon, Jun 03, 2019 at 06:55:04PM +0200, Andrey Konovalov wrote:
> > diff --git a/arch/arm64/include/asm/uaccess.h
> > b/arch/arm64/include/asm/uaccess.h
> > index e5d5f31c6d36..9164ecb5feca 100644
> &g
On Tue, Apr 30, 2019 at 02:14:13PM +0100, Andrew Murray wrote:
> diff --git a/arch/arm/include/asm/arch_timer.h
> b/arch/arm/include/asm/arch_timer.h
> index 0a8d7bba2cb0..f21e038dc9f3 100644
> --- a/arch/arm/include/asm/arch_timer.h
> +++ b/arch/arm/include/asm/arch_timer.h
> @@ -4,6 +4,7 @@
>
some
> > cycles by replacing multiple user_mode() calls into a single one earlier
> > during the fault.
> >
> > Signed-off-by: Anshuman Khandual
> > Cc: Catalin Marinas
> > Cc: Will Deacon
> > Cc: Mark Rutland
> > Cc: James Morse
&g
On Fri, Jun 07, 2019 at 01:49:10AM +0200, Odin Ugedal wrote:
> The config value used in the if was changed in
> b433dce056d3814dc4b33e5a8a533d6401ffcfb0, but the comment on the
> corresponding end was not changed.
>
> Signed-off-by: Odin Ugedal
Queued for 5.3. Thanks.
--
Catalin
On Fri, May 24, 2019 at 03:53:06PM +0100, Dave P Martin wrote:
> On Fri, May 24, 2019 at 02:02:17PM +0100, Mark Rutland wrote:
> > On Fri, May 24, 2019 at 11:25:29AM +0100, Dave Martin wrote:
> > > #endif /* _UAPI__ASM_HWCAP_H */
> > > diff --git a/arch/arm64/include/uapi/asm/mman.h
> > >
On Thu, Jun 06, 2019 at 10:24:01AM +0530, Anshuman Khandual wrote:
> On 06/04/2019 08:26 PM, Catalin Marinas wrote:
> > On Mon, Jun 03, 2019 at 12:11:25PM +0530, Anshuman Khandual wrote:
> >> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> >> in
On Thu, Jun 06, 2019 at 10:38:11AM +0100, Mark Rutland wrote:
> On Tue, Jun 04, 2019 at 03:42:09PM +0100, Catalin Marinas wrote:
> > On Mon, Jun 03, 2019 at 12:11:24PM +0530, Anshuman Khandual wrote:
> > > diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> >
On Thu, May 23, 2019 at 10:06:14AM +0100, Sudeep Holla wrote:
> Sudeep Holla (4):
> ptrace: move clearing of TIF_SYSCALL_EMU flag to core
> x86: simplify _TIF_SYSCALL_EMU handling
> arm64: add PTRACE_SYSEMU{,SINGLESTEP} definations to uapi headers
> arm64: ptrace: add support for syscall
On Mon, May 27, 2019 at 05:34:10PM +0900, Masahiro Yamada wrote:
> Some in-kernel headers use _BITUL() instead of BIT().
>
> arch/arm64/include/asm/sysreg.h
> arch/s390/include/asm/*.h
>
> I think the reason is because BIT() is currently not available
> in assembly. It hard-codes 1UL, which is
On Mon, Jun 03, 2019 at 12:11:25PM +0530, Anshuman Khandual wrote:
> __do_page_fault() is over complicated with multiple goto statements. This
> cleans up the code flow and while there drops local variable vm_fault_t.
I'd change the subject as well here to something like refactor or
simplify
Anshuman Khandual
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Mark Rutland
> Cc: James Morse
> Cc: Andrey Konovalov
Queued for 5.3. Thanks.
--
Catalin
;& is_el1_permission_fault)
>
> Signed-off-by: Anshuman Khandual
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Mark Rutland
> Cc: James Morse
> Cc: Andrey Konovalov
Queued for 5.3. Thanks.
--
Catalin
On Mon, Jun 03, 2019 at 12:11:24PM +0530, Anshuman Khandual wrote:
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index da02678..4bb65f3 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -435,6 +435,14 @@ static bool is_el0_instruction_abort(unsigned int esr)
> Signed-off-by: Anshuman Khandual
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Mark Rutland
> Cc: Ard Biesheuvel
Queued for 5.3. Thanks.
--
Catalin
On Sat, Jun 01, 2019 at 10:08:08AM +0800, Liu Song wrote:
> From: Liu Song
>
> Should use aff3 instead of aff2 in comment.
>
> Signed-off-by: Liu Song
Queued for 5.3. Thanks.
--
Catalin
On Thu, May 30, 2019 at 12:30:58PM +0100, Julien Grall wrote:
> cpu_enable_ssbs() is called via stop_machine() as part of the cpu_enable
> callback. A spin lock is used to ensure the hook is registered before
> the rest of the callback is executed.
>
> On -RT spin_lock() may sleep. However, all
On Wed, May 29, 2019 at 12:08:20AM +0800, Miles Chen wrote:
> This change makes CONFIG_ZONE_DMA32 defuly y and allows users
> to overwrite it only when CONFIG_EXPERT=y.
>
> For the SoCs that do not need CONFIG_ZONE_DMA32, this is the
> first step to manage all available memory by a single
>
are same,
> we should use page table level specific macros to be consistent as per the
> MMU specifications. Create page table level specific wrappers for kernel
> huge mapping entries and just drop mk_sect_prot() which does not have any
> other user.
>
> Signed-off-by: Anshu
he_line_size() for arm64.
>
> Cc: Greg Kroah-Hartman
> Cc: "Rafael J. Wysocki"
> Cc: Sudeep Holla
> Cc: Catalin Marinas
> Cc: Jeremy Linton
> Cc: Will Deacon
> Signed-off-by: Shaokun Zhang
Both patches queued for 5.3. Thanks.
--
Catalin
This patch adds an
> > untagged_addr() macro, which is defined as noop for architectures that do
> > not support memory tagging. The oncoming patch series will define it at
> > least for sparc64 and arm64.
> >
> > Acked-by: Catalin Marinas
> > Reviewed-by: Khalid Aziz
>
to have elf
> randomization and no MMU: without MMU, the security added by randomization
> is worth nothing.
Not planning on this anytime soon ;).
Acked-by: Catalin Marinas
set by other architectures to benefit from those functions.
> Note that this new config depends on MMU being enabled, if selected
> without MMU support, a warning will be thrown.
>
> Suggested-by: Christoph Hellwig
> Signed-off-by: Alexandre Ghiti
> Reviewed-by: Christoph Hellwig
Acked-by: Catalin Marinas
s Cook
> Reviewed-by: Christoph Hellwig
Acked-by: Catalin Marinas
Ghiti
> Acked-by: Kees Cook
> Reviewed-by: Christoph Hellwig
Acked-by: Catalin Marinas
elt
> ---
> arch/Kconfig | 3 +++
> arch/arm64/Kconfig | 2 +-
> arch/x86/Kconfig | 4 +---
> 3 files changed, 5 insertions(+), 4 deletions(-)
For arm64:
Acked-by: Catalin Marinas
On Thu, May 23, 2019 at 10:06:16AM +0100, Sudeep Holla wrote:
> The usage of emulated/_TIF_SYSCALL_EMU flags in syscall_trace_enter
> seems to be bit overcomplicated than required. Let's simplify it.
>
> Cc: Andy Lutomirski
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
>
propriate
> header file.
>
> Signed-off-by: Anshuman Khandual
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Steve Capper
> Cc: Suzuki Poulose
> Cc: James Morse
Queued for 5.3. Thanks.
--
Catalin
nge makes it
> consistently use the same mnemonic.
>
> Signed-off-by: Anshuman Khandual
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Steve Capper
> Cc: Mark Rutland
Queued for 5.3. Thanks.
--
Catalin
Bjorn Andersson
> Cc: Andy Gross
> Cc: Will Deacon
> Cc: Catalin Marinas
> Cc: Dan Williams
> Signed-off-by: Stephen Boyd
Not sure what the plans are with this series but if you need an ack for
arm64:
Acked-by: Catalin Marinas
On Thu, May 30, 2019 at 03:15:27PM +0100, Vincenzo Frascino wrote:
> Add vDSO compat support to the arm64 building system.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Signed-off-by: Vincenzo Frascino
> ---
> arch/arm64/Kconfig | 1 +
> arch/ar
On Wed, May 29, 2019 at 01:42:25PM +0100, Dave P Martin wrote:
> On Tue, May 28, 2019 at 05:34:00PM +0100, Catalin Marinas wrote:
> > On Tue, May 28, 2019 at 04:56:45PM +0100, Dave P Martin wrote:
> > > On Tue, May 28, 2019 at 04:40:58PM +0100, Cat
Hi Christoph,
On Sat, 25 May 2019 at 14:33, Christoph Hellwig wrote:
> diff --git a/mm/gup.c b/mm/gup.c
> index f173fcbaf1b2..1c21ecfbf38b 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -2117,6 +2117,10 @@ static void gup_pgd_range(unsigned long addr, unsigned
> long end,
> } while
On Thu, May 23, 2019 at 11:42:57AM +0100, Dave P Martin wrote:
> On Wed, May 22, 2019 at 09:20:52PM -0300, Jason Gunthorpe wrote:
> > On Wed, May 22, 2019 at 02:49:28PM +0100, Dave Martin wrote:
> > > If multiple people will care about this, perhaps we should try to
> > > annotate types more
, "softirq", sizeof(object->comm));
> > > } else {
> >
> > What are the user-visible runtime effects of this change?
>
> If user does cat from /sys/kernel/debug/kmemleak previously they would
> see this, which is clearly wrong, this is system call context (see the
> comm):
Indeed, with your patch you get the correct output.
Acked-by: Catalin Marinas
Thanks.
--
Catalin
On Fri, May 17, 2019 at 12:59:56PM -0700, Mark Salyzyn wrote:
> Some (out of tree modular) drivers feel a need to ensure
> data is flushed to the DDR before continuing flow.
>
> Signed-off-by: Mark Salyzyn
> Cc: linux-kernel@vger.kernel.org
> Cc: kernel-t...@android.com
> ---
>
Hi,
On Wed, May 08, 2019 at 11:45:03AM -0700, Salman Qazi wrote:
> What is the intention behind icache_is_aliasing on big.LITTLE systems
> where some icaches are VIPT and others are PIPT? Is it meant to be
> conservative in some sense or should it be made per-CPU?
It needs to cover the worst
On Tue, Apr 30, 2019 at 03:25:09PM +0200, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> mlx4_get_umem_mr() uses provided user
On Tue, Apr 30, 2019 at 03:25:06PM +0200, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> userfaultfd_register() and
On Thu, May 02, 2019 at 03:22:08PM +0200, Christoph Hellwig wrote:
> can you quickly look over the arm64 parts? I'd really like to still
> get this series in for this merge window as it would conflict with
> a lot of dma-mapping work for next merge window, and we also have
> the amd and possibly
(trimmed down the cc list slightly as the message bounces)
On Mon, Apr 29, 2019 at 09:09:15PM +0300, Leon Romanovsky wrote:
> On Wed, Mar 20, 2019 at 03:51:30PM +0100, Andrey Konovalov wrote:
> > This patch is a part of a series that extends arm64 kernel ABI to allow to
> > pass tagged user
Hi Linus,
Please pull the arm64 fixes below. Thanks.
The following changes since commit 085b7755808aa11f78ab9377257e1dad2e6fa4bb:
Linux 5.1-rc6 (2019-04-21 10:45:57 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
On Tue, Apr 02, 2019 at 02:47:34PM +0200, Andrey Konovalov wrote:
> On Fri, Mar 29, 2019 at 11:30 AM Catalin Marinas
> wrote:
> > On Thu, Mar 28, 2019 at 02:19:34PM -0400, Steven Rostedt wrote:
> > > On Thu, 28 Mar 2019 19:10:07 +0100
> > > Andrey Konovalov wrote
() even if not all
> address ranges passed to this function are known to kmemleak.
>
> Signed-off-by: Qian Cai
Reviewed-by: Catalin Marinas
Hi Boris,
On Tue, Apr 23, 2019 at 03:25:18PM +0200, Borislav Petkov wrote:
> On Thu, Apr 18, 2019 at 10:50:15AM +0100, Catalin Marinas wrote:
> > Kmemleak is basically a tri-colour marking tracing garbage collector [1]
>
> Thanks for that - interesting read.
>
> > but w
Hi Linus,
Please pull the arm64 fix below. Thanks.
The following changes since commit dc4060a5dc2557e6b5aa813bf5b73677299d62d2:
Linux 5.1-rc5 (2019-04-14 15:17:41 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
for
On Thu, Apr 18, 2019 at 09:45:10AM +0200, Borislav Petkov wrote:
> On Tue, Apr 16, 2019 at 08:38:30PM -0400, Qian Cai wrote:
> > kmemleak_init() will register the data/bss sections (only register
> > .data..ro_after_init if not within .data) and then kmemleak_scan() will scan
> > those address and
On Wed, Apr 17, 2019 at 10:41:37AM +0100, Russell King wrote:
> On Sun, Apr 14, 2019 at 10:51:09PM -0700, Christoph Hellwig wrote:
> > On Sat, Apr 13, 2019 at 06:30:52PM +0200, Heinrich Schuchardt wrote:
> > > This patch avoids
> > > ERROR: "__sync_icache_dcache" [drivers/xen/xen-privcmd.ko]
On Wed, Apr 17, 2019 at 12:21:21AM -0700, Nathan Chancellor wrote:
> Commit 045afc24124d ("arm64: futex: Fix FUTEX_WAKE_OP atomic ops with
> non-zero result value") removed oldval's zero initialization in
> arch_futex_atomic_op_inuser because it is not necessary. Unfortunately,
> Android's arm64
gt; kthread+0x1d2/0x1f0
> ret_from_fork+0x35/0x40
>
> Signed-off-by: Qian Cai
It seems that commit 298a32b13208 ("kmemleak: powerpc: skip scanning
holes in the .bss section") has other uses as well.
Acked-by: Catalin Marinas
>
> Add a new #ifdef around it.
>
> Fixes: 298a32b13208 ("kmemleak: powerpc: skip scanning holes in the .bss
> section")
> Signed-off-by: Arnd Bergmann
Acked-by: Catalin Marinas
AP) || defined(CONFIG_DEBUG_VIRTUAL)
> #define virt_to_page(kaddr) pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
> #define _virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
> #else
IIUC, this shouldn't change the behaviour of virt_addr_valid(). The
patch looks fine to me.
Acked-by: Catalin Marinas
Hi Linus,
Please pull the arm64 fix below.
The following changes since commit 79a3aaa7b82e3106be97842dedfd8429248896e6:
Linux 5.1-rc3 (2019-03-31 14:39:29 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
for you to
On Mon, Apr 01, 2019 at 10:12:01PM +0200, Michal Hocko wrote:
> On Fri 29-03-19 16:16:38, Catalin Marinas wrote:
> > On Fri, Mar 29, 2019 at 01:02:37PM +0100, Michal Hocko wrote:
> > > On Thu 28-03-19 14:59:17, Catalin Marinas wrote:
> &g
nteed to be executable on these architectures.
> >
> > Signed-off-by: James Morse
> > Acked-by: Pavel Machek
> > Acked-by: Rafael J. Wysocki
> > Acked-by: Catalin Marinas
> > [will: make clean_pages_on_* static and remove initialisers]
> > Signed
So in a sense, the patch is
> meaningless.
>
> But I think since it is a problem, why not fix it (Even if max_mapnr
> is not be used)?
> What is your opinion?
I'm ok with fixing, only that it's not urgent. Will can pick it up for
the 5.2 merging window.
Reviewed-by: Catalin Marinas
On Sat, Mar 30, 2019 at 09:13:46PM +0800, Muchun Song wrote:
> When we not use flat memory, the mem_map will be NULL and
> pfn_to_page(max_pfn) is a pointer which is located in kernel space. So
> max_mapnr is assigned a very large number(e.g., 0x_) - fix
> it.
>
> Signed-off-by:
Hi Linus,
Please pull the arm64 fix below. Thanks.
The following changes since commit 8c2ffd9174779014c3fe1f96d9dc3641d9175f00:
Linux 5.1-rc2 (2019-03-24 14:02:26 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
for
On Fri, Mar 29, 2019 at 01:02:37PM +0100, Michal Hocko wrote:
> On Thu 28-03-19 14:59:17, Catalin Marinas wrote:
> [...]
> > >From 09eba8f0235eb16409931e6aad77a45a12bedc82 Mon Sep 17 00:00:00 2001
> > From: Catalin Marinas
> > Date: Thu, 28 Mar 2019 13:26:07 +0
(I trimmed down the cc list a bit since it's always bouncing)
On Thu, Mar 28, 2019 at 02:19:34PM -0400, Steven Rostedt wrote:
> On Thu, 28 Mar 2019 19:10:07 +0100
> Andrey Konovalov wrote:
>
> > > > Signed-off-by: Andrey Konovalov
> > > > ---
> > > > ipc/shm.c | 2 ++
> > > >
y I am not that brave soul, but I'm wondering what the
> > > complication here is? It shouldn't be too hard to teach calculate_sizes()
> > > in
> > > SLUB about a new SLAB_KMEMLEAK flag that reserves spaces for the metadata.
>
> On 28/03/2019 12.30, Catalin Marinas wr
On Wed, Mar 27, 2019 at 02:02:27PM -0400, Qian Cai wrote:
> On 3/27/19 1:29 PM, Catalin Marinas wrote:
> > From dc4194539f8191bb754901cea74c86e7960886f8 Mon Sep 17 00:00:00 2001
> > From: Catalin Marinas
> > Date: Wed, 27 Mar 2019 17:20:57 +
> > Subject: [PATCH] mm:
On Wed, Mar 27, 2019 at 11:21:58AM -0700, Matthew Wilcox wrote:
> On Wed, Mar 27, 2019 at 05:29:57PM +0000, Catalin Marinas wrote:
> > On Wed, Mar 27, 2019 at 09:44:32AM +0100, Michal Hocko wrote:
> > > As long as there is an implicit __GFP_NOFAIL then kmemleak is simply
>
On Thu, Mar 28, 2019 at 08:05:31AM +0200, Pekka Enberg wrote:
> On 27/03/2019 2.59, Qian Cai wrote:
> > Unless there is a brave soul to reimplement the kmemleak to embed it's
> > metadata into the tracked memory itself in a foreseeable future, this
> > provides a good balance between enabling
eat from?
Quick attempt below and it needs some more testing (pretty random pick
of the EMERGENCY_POOL_SIZE value). Also, with __GFP_NOFAIL removed, are
the other flags safe or we should trim them further?
---8<---
>From dc4194539f8191bb754901cea74c86e
On Tue, Mar 26, 2019 at 09:05:36AM -0700, Matthew Wilcox wrote:
> On Tue, Mar 26, 2019 at 11:43:38AM -0400, Qian Cai wrote:
> > Unless there is a brave soul to reimplement the kmemleak to embed it's
> > metadata into the tracked memory itself in a foreseeable future, this
> > provides a good
On Tue, Mar 26, 2019 at 11:43:38AM -0400, 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. This is especially problematic for
> running things
s.
The v6 logic looks fine to me. For the whole series:
Reviewed-by: Catalin Marinas
Hi Linus,
Please pull the arm64 changes below. It's mostly fixes apart from the
kprobe blacklist checking which was deferred because of conflicting with
a fix merged after I pinned the arm64 for-next/core branch (f2b3d8566d81
"arm64: kprobe: Always blacklist the KVM world-switch code").
Thanks.
On Wed, Mar 20, 2019 at 10:20:56AM -0700, Matthias Kaehlcke wrote:
> The arm64 config selects MULTI_IRQ_HANDLER, which was renamed to
> GENERIC_IRQ_MULTI_HANDLER by commit 4c301f9b6a94 ("ARM: Convert
> to GENERIC_IRQ_MULTI_HANDLER"). The 'new' option is already
> selected, so just remove the
On Thu, Mar 14, 2019 at 11:20:47AM +0800, pierre Kuo wrote:
> in the previous case, initrd_start and initrd_end can be successfully
> returned either (base < memblock_start_of_DRAM()) or (base + size >
> memblock_start_of_DRAM() + linear_region_size).
>
> That means even linear mapping range
Hi Stephen,
On Wed, Mar 20, 2019 at 01:43:12AM +1100, Stephen Rothwell wrote:
> Commit
>
> a4d17a19c493 ("arm64: apply workaround on A64FX v1r0")
>
> is missing a Signed-off-by from its author.
Thanks for this. The patch is indeed confusing, sent by Takayuki with a
signed-off-by from Zhang
On Fri, Mar 01, 2019 at 03:00:41PM -0500, William Cohen wrote:
> The ARM64 implements the save_stack_trace_regs function, but it is
> unusable for any diagnostic tooling compiled as a kernel module due
> the missing EXPORT_SYMBOL_GPL for the function. Export
> save_stack_trace_regs() to align
On Mon, Mar 18, 2019 at 12:06:06PM +, Mark Rutland wrote:
> From 6439e9c0b1525e9d4c7be65552e6f2b1f9d1dbe0 Mon Sep 17 00:00:00 2001
> From: "Okamoto, Takayuki"
> Date: Fri, 15 Mar 2019 12:22:36 +
> Subject: [PATCH] arm64: apply workaround on A64FX v1r0
>
> Fujitsu erratum 010001 applies
6c62a0f>] 0x
This patch removes the original refcount_inc(>ls_count) that was
paired with the memcpy() lock copying.
Fixes: 7b587e1a5a6c ("NFS: use locks_copy_lock() to copy locks.")
Cc: # 5.0.x-
Cc: NeilBrown
Signed-off-by: Catalin Marinas
---
fs/nfs/nfs4proc.c | 2 --
Hi Linus,
On Fri, Mar 08, 2019 at 04:42:23PM +, Catalin Marinas wrote:
> The following changes since commit 6e4933a006616343f66c4702dc4fc56bb25e7b02:
>
> irqdesc: Add domain handler for NMIs (2019-02-05 14:37:05 +)
>
> are available in the Git repository
in NEON recovery routine
Arnd Bergmann (1):
arm64: avoid clang warning about self-assignment
Catalin Marinas (3):
Merge branch 'irq/generic-nmi' of
git://git.kernel.org/.../maz/arm-platforms
Merge branch 'for-next/perf' of git://git.kernel.org/.../will/linux
Revert "
On Fri, Mar 01, 2019 at 10:53:50AM -0600, Jeremy Linton wrote:
> On 3/1/19 10:20 AM, Catalin Marinas wrote:
> > On Fri, Mar 01, 2019 at 10:12:09AM -0600, Jeremy Linton wrote:
> > > On 3/1/19 1:11 AM, Andre Przywara wrote:
> > > > On 2/26/19 7:05 PM, Jeremy Li
On Tue, Feb 26, 2019 at 03:39:08PM +0100, Andrey Konovalov wrote:
> On Sat, Feb 23, 2019 at 12:06 AM Dave Hansen wrote:
> >
> > On 2/22/19 4:53 AM, Andrey Konovalov wrote:
> > > userfaultfd_register() and userfaultfd_unregister() use provided user
> > > pointers for vma lookups, which can only by
On Fri, Mar 01, 2019 at 10:12:09AM -0600, Jeremy Linton wrote:
> On 3/1/19 1:11 AM, Andre Przywara wrote:
> > On 2/26/19 7:05 PM, Jeremy Linton wrote:
> > > Display the mitigation status if active, otherwise
> > > assume the cpu is safe unless it doesn't have CSV3
> > > and isn't in our whitelist.
On Fri, Mar 01, 2019 at 09:10:36AM +1100, Stephen Rothwell wrote:
> Today's linux-next merge of the arm-soc tree got a conflict in:
>
> arch/arm64/Kconfig.platforms
>
> between commit:
>
> a29c78234942 ("arm64: Kconfig.platforms: fix warning unmet direct
> dependencies")
>
> from the
801 - 900 of 5901 matches
Mail list logo
