On Fri, Jul 26, 2019 at 04:18:25PM +0100, Lorenzo Pieralisi wrote:
> On Fri, Jul 26, 2019 at 01:29:56PM +0100, Mark Rutland wrote:
> > On Fri, Jul 26, 2019 at 01:27:37PM +0200, Anders Roxell wrote:
> > > When fall-through warnings was enabled by default the following warning
Hi Daniel,
On Tue, Jul 30, 2019 at 12:21:06AM +1000, Daniel Axtens wrote:
> Hook into vmalloc and vmap, and dynamically allocate real shadow
> memory to back the mappings.
>
> Most mappings in vmalloc space are small, requiring less than a full
> page of shadow space. Allocating a full shadow
On Sun, Jul 28, 2019 at 05:14:31PM +0530, Anshuman Khandual wrote:
> On 07/23/2019 03:11 PM, Mark Rutland wrote:
> > It might also be worth pointing out the reasons for this naming, e.g.
> > p?d_large() aren't currently generic, and this name minimizes potential
> > confusi
On Fri, Jul 26, 2019 at 01:27:37PM +0200, Anders Roxell wrote:
> When fall-through warnings was enabled by default the following warning
> was starting to show up:
>
> ../drivers/perf/arm_pmu.c: In function ‘cpu_pm_pmu_notify’:
> ../drivers/perf/arm_pmu.c:726:3: warning: this statement may fall
>
On Fri, Jul 26, 2019 at 01:10:57PM +0100, Mark Rutland wrote:
> On Fri, Jul 26, 2019 at 01:27:16PM +0200, Anders Roxell wrote:
> > When fall-through warnings was enabled by default, commit d93512ef0f0e
> > ("Makefile: Globally enable fall-through warning"), the following
On Fri, Jul 26, 2019 at 01:27:16PM +0200, Anders Roxell wrote:
> When fall-through warnings was enabled by default, commit d93512ef0f0e
> ("Makefile: Globally enable fall-through warning"), the following
> warnings was starting to show up:
>
> ../arch/arm64/kernel/hw_breakpoint.c: In function
On Fri, Jul 26, 2019 at 01:14:26AM +1000, Daniel Axtens wrote:
> Mark Rutland writes:
> > On Thu, Jul 25, 2019 at 09:53:08AM +0200, Dmitry Vyukov wrote:
> >> FTR, Daniel just mailed:
> >>
> >> [PATCH 0/3] kasan: support backing vmalloc space with real shadow m
On Wed, Jul 24, 2019 at 12:28:50PM +0530, Anshuman Khandual wrote:
> On 07/23/2019 04:26 PM, Mark Rutland wrote:
> > On Mon, Jul 15, 2019 at 11:47:47AM +0530, Anshuman Khandual wrote:
> >> This series enables memory hot remove on arm64 after fixing a memblock
> >&g
On Thu, Jul 25, 2019 at 09:53:08AM +0200, Dmitry Vyukov wrote:
> On Wed, Jul 24, 2019 at 1:21 PM Mark Rutland wrote:
> >
> > On Wed, Jul 24, 2019 at 11:11:49AM +0200, Dmitry Vyukov wrote:
> > > On Tue, Jul 23, 2019 at 6:41 PM Mark Rutland wrote:
> > > >
> &
Hi Ruslan,
On Wed, Jul 10, 2019 at 03:27:58PM +0300, Ruslan Bilovol wrote:
> On Tue, Apr 9, 2019 at 8:52 PM Will Deacon wrote:
> >
> > On Mon, Apr 08, 2019 at 04:36:28PM +0100, Mark Rutland wrote:
> > > On Mon, Mar 11, 2019 at 12:49:46PM +0100, Torsten Duwe wrote:
>
t, cpu);
> + perf_install_in_context(ctx, event, event->cpu);
> perf_unpin_context(ctx);
> mutex_unlock(>mutex);
>
> return event;
This matches what we in a regular perf_event_open() syscall, and I
believe this is sane. I think we should also update t
On Wed, Jul 24, 2019 at 02:53:04PM +0100, Steven Price wrote:
> On 23/07/2019 11:14, Mark Rutland wrote:
> > On Mon, Jul 22, 2019 at 04:42:00PM +0100, Steven Price wrote:
> >> pgd_entry() and pud_entry() were removed by commit 0b1fbfe50006c410
> >> ("mm/pagewalk:
On Wed, Jul 24, 2019 at 03:57:33PM +0200, Thomas Gleixner wrote:
> On Wed, 24 Jul 2019, Steven Price wrote:
> > On 23/07/2019 11:16, Mark Rutland wrote:
> > > Are there any visible changes to the arm64 output?
> >
> > arm64 output shouldn't change. I've c
On Tue, Jul 23, 2019 at 06:49:03PM +0200, Marco Elver wrote:
> On Tue, 23 Jul 2019 at 18:24, Mark Rutland wrote:
> >
> > On Fri, Jul 19, 2019 at 03:28:18PM +0200, Marco Elver wrote:
> > > Adds a simple stack overflow test, to check the error being reported on
&g
On Wed, Jul 24, 2019 at 11:11:49AM +0200, Dmitry Vyukov wrote:
> On Tue, Jul 23, 2019 at 6:41 PM Mark Rutland wrote:
> >
> > On Fri, Jul 19, 2019 at 03:28:17PM +0200, Marco Elver wrote:
> > > Enabling STACK_GUARD_PAGE helps catching kernel stack overflows
> > &
On Sat, Jul 20, 2019 at 04:54:58PM +0900, Masami Hiramatsu wrote:
> Hi Mark,
>
> On Fri, 19 Jul 2019 10:59:59 +0100
> Mark Rutland wrote:
>
> > On Thu, Jul 18, 2019 at 11:31:33PM +0900, Masami Hiramatsu wrote:
> > > On Thu, 18 Jul 2019 10:20:23 +
ar
> Cc: Borislav Petkov
> Cc: "H. Peter Anvin"
> Cc: Andrey Ryabinin
> Cc: Alexander Potapenko
> Cc: Dmitry Vyukov
> Cc: Andrey Konovalov
> Cc: Mark Rutland
> Cc: Peter Zijlstra
> Cc: x...@kernel.org
> Cc: linux-kernel@vger.kernel.org
>
KASAN tests.
Thanks,
Mark.
>
> Signed-off-by: Marco Elver
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: "H. Peter Anvin"
> Cc: Andrey Ryabinin
> Cc: Alexander Potapenko
> Cc: Dmitry Vyukov
> Cc: Andrey Konovalov
> Cc: Mark Ru
Hi Anshuman,
On Mon, Jul 15, 2019 at 11:47:47AM +0530, Anshuman Khandual wrote:
> This series enables memory hot remove on arm64 after fixing a memblock
> removal ordering problem in generic try_remove_memory() and a possible
> arm64 platform specific kernel page table race condition. This series
On Mon, Jul 22, 2019 at 04:41:49PM +0100, Steven Price wrote:
> This is a slight reworking and extension of my previous patch set
> (Convert x86 & arm64 to use generic page walk), but I've continued the
> version numbering as most of the changes are the same. In particular
> this series ends with
On Mon, Jul 22, 2019 at 04:42:00PM +0100, Steven Price wrote:
> pgd_entry() and pud_entry() were removed by commit 0b1fbfe50006c410
> ("mm/pagewalk: remove pgd_entry() and pud_entry()") because there were
> no users. We're about to add users so reintroduce them, along with
> p4d_entry() as we now
On Mon, Jul 22, 2019 at 04:42:08PM +0100, Steven Price wrote:
> Add a generic version of page table dumping that architectures can
> opt-in to
>
> Signed-off-by: Steven Price
[...]
> +#ifdef CONFIG_KASAN
> +/*
> + * This is an optimization for KASAN=y case. Since all kasan page tables
> + *
This differs from p?d_huge() by the fact that they are always available
> (if
> + * the architecture supports large pages at the appropriate level) even
> + * if CONFIG_HUGETLB_PAGE is not defined.
> + */
I assume it's only safe to call these on valid entries? I think it would
be wo
/pgtable_pte_page_dtor/}' $FILE;
done
... with the documentation re-flowed to remain under 80 columns, and
whitespace fixed up in macros to keep backslashes aligned.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland
Cc: Andrew Morton
Cc: Anshuman Khandual
Cc: Matthew
On Thu, Jul 18, 2019 at 11:31:33PM +0900, Masami Hiramatsu wrote:
> On Thu, 18 Jul 2019 10:20:23 +0100
> Mark Rutland wrote:
>
> > On Wed, Jul 17, 2019 at 11:22:15PM -0700, Paul E. McKenney wrote:
> > > On Thu, Jul 18, 2019 at 02:43:58PM +0900, Masami Hiramat
On Wed, Jul 17, 2019 at 11:22:15PM -0700, Paul E. McKenney wrote:
> On Thu, Jul 18, 2019 at 02:43:58PM +0900, Masami Hiramatsu wrote:
> > Remove rcu_read_lock()/rcu_read_unlock() from debug exception
> > handlers since the software breakpoint can be hit on idle task.
Why precisely do we need to
90625191545.245259...@goodmis.org/
> > >
> > > Both patches resolved the issue.
> > > I've tested both.
> >
> > In that case, the later one (move postcore to subsys) seems good to me.
> >
> > Delaying the test is just avoiding the issue that t
Hi Marc,
On Tue, Jul 09, 2019 at 02:08:28PM +0100, Marc Zyngier wrote:
> From 7d4314d1ef3122d8bf56a7ef239c8c68e0c81277 Mon Sep 17 00:00:00 2001
> From: Marc Zyngier
> Date: Tue, 4 Jun 2019 17:35:18 +0100
> Subject: [PATCH] arm64: Force SSBS on context switch
>
> On a CPU that doesn't support
On Tue, Jul 02, 2019 at 04:41:35PM -0700, Nathan Huckleberry wrote:
> When analyzed with the clang static analyzer the
> following warning occurs
>
> line 251, column 2
> Value stored to 'old_pte' is never read
>
> This warning is repeated every time pgtable.h is
> included by another file and
On Sun, May 26, 2019 at 03:18:40PM -0400, Steven Rostedt wrote:
> From: Masami Hiramatsu
>
> Initialize kprobes at postcore_initcall level instead of module_init
> since kprobes is not a module, and it depends on only subsystems
> initialized in core_initcall.
> This will allow ftrace kprobe
On Tue, Jul 02, 2019 at 05:53:35PM +0200, Thomas Gleixner wrote:
> !current->mm is not a reliable indicator for kernel threads as they might
> temporarily use a user mm. Check for PF_KTHREAD instead.
>
> Signed-off-by: Thomas Gleixner
FWIW:
Acked-by: Mark Rutland
As a head
On Mon, Jul 01, 2019 at 09:09:33PM +0530, Mukesh Ojha wrote:
>
> On 6/28/2019 10:29 PM, Mark Rutland wrote:
> > On Fri, Jun 28, 2019 at 10:23:10PM +0530, Mukesh Ojha wrote:
> > > Hi All,
> > Hi Mukesh,
> >
> > > Is it looks considerable to add cluster b
On Fri, Jun 28, 2019 at 10:46:08PM +0200, Peter Zijlstra wrote:
> On Fri, Jun 28, 2019 at 05:50:03PM +0100, Mark Rutland wrote:
> > > + /*
> > > + * Wake any perf_event_free_task() waiting for this event to be
> > > + * freed.
> > &g
On Fri, Jun 28, 2019 at 10:23:10PM +0530, Mukesh Ojha wrote:
> Hi All,
Hi Mukesh,
> Is it looks considerable to add cluster based event support to add in
> current perf event framework and later in userspace perf to support
> such events ?
Could you elaborate on what you mean by "cluster based
erf,trace,cpuhp")
>
> seems to have overlooked this 'fun' parade.
>
> Solve it by using the fact that detached events still have a reference
> count on their (previous) context. With this perf_event_free_task()
> can detect when events have escaped and wait fo
On Wed, Jun 12, 2019 at 12:33:02PM +0800, Hsin-Yi Wang wrote:
> Adding "rng-seed" to dtb. It's fine to add this property if original
> fdt doesn't contain it. Since original seed will be wiped after
> read, so use a default size 128 bytes here.
Why is 128 bytes the default value?
I didn't see an
On Wed, Jun 12, 2019 at 12:33:00PM +0800, Hsin-Yi Wang wrote:
> Introducing a chosen node, rng-seed, which is an entropy that can be
> passed to kernel called very early to increase initial device
> randomness. Bootloader should provide this entropy and the value is
> read from /chosen/rng-seed in
On Mon, Jun 17, 2019 at 06:06:57AM -0700, Paul E. McKenney wrote:
> On Mon, Jun 17, 2019 at 12:58:19PM +0100, Mark Rutland wrote:
> > On Tue, Jun 11, 2019 at 12:24:10PM -0700, Paul E. McKenney wrote:
> > > This commit removes the open-coded CPU-offline notification with new
_KASAN_INTERNAL definition.
>
> Signed-off-by: Marco Elver
> Cc: Andrey Ryabinin
> Cc: Dmitry Vyukov
> Cc: Alexander Potapenko
> Cc: Andrey Konovalov
> Cc: Christoph Lameter
> Cc: Pekka Enberg
> Cc: David Rientjes
> Cc: Joonsoo Kim
> Cc: Andrew Morton
> Cc:
On Wed, Jun 26, 2019 at 02:20:16PM +0200, Marco Elver wrote:
> This introduces __kasan_check_{read,write} which return a bool if the
> access was valid or not. __kasan_check functions may be used from
> anywhere, even compilation units that disable instrumentation
> selectively. For consistency,
On Wed, Jun 26, 2019 at 12:35:33AM -0700, Christoph Hellwig wrote:
> Robin, Andrew:
As a heads-up, Robin is currently on holiday, so this is all down to
Andrew's preference.
> I have a series for the hmm tree, which touches the section size
> bits, and remove device public memory support.
>
>
On Mon, May 20, 2019 at 03:27:17PM +, Gerald BAEZA wrote:
> The DDRPERFM is the DDR Performance Monitor embedded in STM32MP1 SOC.
>
> This perf drivers supports the read, write, activate, idle and total
> time counters, described in the reference manual RM0436.
Is this document publicly
On Tue, Jun 25, 2019 at 10:57:07AM +0530, Anshuman Khandual wrote:
> On 06/24/2019 10:22 PM, Mark Rutland wrote:
> > On Fri, Jun 21, 2019 at 03:35:53PM +0100, Steve Capper wrote:
> >> On Wed, Jun 19, 2019 at 09:47:40AM +0530, Anshuman Khandual wrote:
> >>> +stati
On Fri, Jun 21, 2019 at 03:35:53PM +0100, Steve Capper wrote:
> Hi Anshuman,
>
> On Wed, Jun 19, 2019 at 09:47:40AM +0530, Anshuman Khandual wrote:
> > The arch code for hot-remove must tear down portions of the linear map and
> > vmemmap corresponding to memory being removed. In both cases the
I'm very confused by this patch. The title says arm64, yet the code is
under arch/csky/, and the code in question refers to HARTs, which IIUC
is RISC-V terminology.
On Mon, Jun 24, 2019 at 12:04:29AM +0800, guo...@kernel.org wrote:
> From: Guo Ren
>
> The hardware threads of one core could
On Fri, Jun 07, 2019 at 03:22:22PM -0700, Palmer Dabbelt wrote:
> The comment describes why in detail. This was found because QEMU never
> gives up load reservations, the issue is unlikely to manifest on real
> hardware.
>
> Thanks to Carlos Eduardo for finding the bug!
> @@ -330,6 +330,17 @@
infradead.org
> Cc: Russell King
> Cc: Mark Rutland
> Tested-by: Dietmar Eggemann
FWIW:
Acked-by: Mark Rutland
On the assumption that Russell is ok with this, I think this should be
dropped into the ARM patch system [1].
Paul, are you familiar with that, or would you prefer that som
nd by syzkaller.
>
> Reported-by: Mark Rutland
> Reported-by: syzbot+99de05d099a170867...@syzkaller.appspotmail.com
> Reported-by: syzbot+7008b8b8ba7df475f...@syzkaller.appspotmail.com
> Fixes: 93766fbd2696 ("vfs: syscall: Add fsmount() to create a mount for a
> supe
On Tue, Jun 11, 2019 at 11:23:56AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Jun 11, 2019 at 03:09:07PM +0100, Mark Rutland escreveu:
> > On Tue, Jun 11, 2019 at 01:53:09PM +0100, Raphael Gault wrote:
> > > In order to subsequently add more tests for the arm64 architectur
Hi Arnaldo,
On Tue, Jun 11, 2019 at 11:33:46AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Jun 11, 2019 at 01:53:11PM +0100, Raphael Gault escreveu:
> > Add an extra test to check userspace access to pmu hardware counters.
> > This test doesn't rely on the seqlock as a synchronisation
dwarf-unwind.o depending on CONFIG_DWARF_UNWIND.
There should be no functional change as a result of this patch.
>
> Signed-off-by: Raphael Gault
Either way, the patch looks good to me:
Acked-by: Mark Rutland
Mark.
> ---
> tools/perf/arch/arm64/Build | 2 +-
> tools/perf/a
On Tue, Jun 11, 2019 at 03:41:19PM +0300, Mike Rapoport wrote:
> On Tue, Jun 11, 2019 at 11:03:49AM +0100, Mark Rutland wrote:
> > On Mon, Jun 10, 2019 at 01:26:15PM -0400, Qian Cai wrote:
> > > On Mon, 2019-06-10 at 12:43 +0100, Will Deacon wrote:
> > > > On Tue, Ju
masking")
> Suggested-by: Marc Zyngier
> Signed-off-by: Julien Thierry
> Cc: Catalin Marinas
> Cc: Will Deacon
Acked-by: Mark Rutland
Mark.
> ---
> arch/arm64/include/asm/irqflags.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a
> Cc: Will Deacon
Acked-by: Mark Rutland
Mark.
> ---
> arch/arm64/include/asm/irqflags.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/irqflags.h
> b/arch/arm64/include/asm/irqflags.h
> index 62996318..9c93152 100644
Signed-off-by: Julien Thierry
> Reviewed-by: James Morse
> Cc:Catalin Marinas
> Cc: Will Deacon
> Cc: Mark Rutland
> Cc: Marc Zyngier
Acked-by: Mark Rutland
Mark.
> ---
> arch/arm64/kernel/entry.S | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> di
On Mon, Jun 10, 2019 at 01:26:15PM -0400, Qian Cai wrote:
> On Mon, 2019-06-10 at 12:43 +0100, Will Deacon wrote:
> > On Tue, Jun 04, 2019 at 03:23:38PM +0100, Mark Rutland wrote:
> > > On Tue, Jun 04, 2019 at 10:00:36AM -0400, Qian Cai wrote:
> > > > The commit &qu
On Mon, Jun 10, 2019 at 01:05:11PM -0700, Andrew Morton wrote:
> On Mon, 10 Jun 2019 17:33:54 +0100 Mark Rutland wrote:
>
> > The naming of pgtable_page_{ctor,dtor}() seems to have confused a few
> > people, and until recently arm64 used these erroneously/pointlessly fo
+ pgtable_pte_page_ctor
@ depends on patch @
@@
- pgtable_page_dtor
+ pgtable_pte_page_dtor
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland
Cc: Andrew Morton
Cc: Anshuman Khandual
Cc: Matthew Wilcox
Cc: Michal Hocko
Cc: Yu Zhao
Cc: linux
On Sun, Jun 09, 2019 at 12:42:06AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:79c3ba32 Merge tag 'drm-fixes-2019-06-07-1' of git://anong..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=16eacf36a0
>
On Mon, Jun 10, 2019 at 03:13:44PM +0300, Abel Vesa wrote:
> This is another alternative for the RFC:
> https://lkml.org/lkml/2019/3/27/545
>
> This new workaround proposal is a little bit more hacky but more contained
> since everything is done within the irq-imx-gpcv2 driver.
>
> Basically, it
e earlier
> during the fault.
>
> Signed-off-by: Anshuman Khandual
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Mark Rutland
> Cc: James Morse
> Cc: Andrey Konovalov
> ---
> arch/arm64/mm/fault.c | 26 +++---
> 1 file changed, 19 ins
t; Cc: Will Deacon
> Cc: Mark Rutland
> Cc: James Morse
> Cc: Andrey Konovalov
> Cc: Christoph Hellwig
This keeps the existing behaviour, and is certainly cleaner, so:
Reviewed-by: Mark Rutland
Mark.
> ---
> arch/arm64/mm/fault.c | 30 +++---
>
On Thu, Jun 06, 2019 at 12:27:40PM +0100, Catalin Marinas wrote:
> 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
On Thu, Jun 06, 2019 at 11:53:05AM +0200, Marc Gonzalez wrote:
> Hello everyone,
>
> There's something about interrupts I have never quite understood,
> which I'd like to clear up once and for all. What I'm about to write
> will probably sound trivial to anyone's who's already figured it out,
>
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
> > index da02678..4bb65f3 100644
> > --- a/arch/arm64/mm/fault.c
> > +++ b/arch/arm64/mm/fault.c
> >
On Thu, May 23, 2019 at 11:35:16AM -0700, Atish Patra wrote:
> Currently, last stage boot loaders such as U-Boot can accept only
> uImage which is an unnecessary additional step in automating boot flows.
>
> Add a PE/COFF compliant image header that boot loaders can parse and
> directly load
Hi All,
While fuzzing arm64 v5.2-rc3, Syzkaller started hitting splats of the
form:
BUG: Dentry (ptrval){i=1,n=/} still in use (2) [unmount of bpf bpf]
... which I can reliably reproduce with the following C program
(partially minimized from what Syzkaller auto-generated).
It
On Tue, Jun 04, 2019 at 03:23:38PM +0100, Mark Rutland wrote:
> On Tue, Jun 04, 2019 at 10:00:36AM -0400, Qian Cai wrote:
> > The commit "arm64: switch to generic version of pte allocation"
> > introduced endless failures during boot like,
> >
> > kobject_
On Tue, Jun 04, 2019 at 10:00:36AM -0400, Qian Cai wrote:
> The commit "arm64: switch to generic version of pte allocation"
> introduced endless failures during boot like,
>
> kobject_add_internal failed for pgd_cache(285:chronyd.service) (error:
> -2 parent: cgroup)
>
> It turns out
Commit-ID: 6a6a9d5fb9f26d2c2127497f3a42adbeb5ccc2a4
Gitweb: https://git.kernel.org/tip/6a6a9d5fb9f26d2c2127497f3a42adbeb5ccc2a4
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:50 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:57 +0200
locking/atomic, s390/pci
Commit-ID: 2af7a0f91c3a645ec9f1cd68e41472021746db35
Gitweb: https://git.kernel.org/tip/2af7a0f91c3a645ec9f1cd68e41472021746db35
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:49 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:57 +0200
locking/atomic, crypto/nx
Commit-ID: 3724921396dd1a07c93e3516b8d7c9ff570d17a9
Gitweb: https://git.kernel.org/tip/3724921396dd1a07c93e3516b8d7c9ff570d17a9
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:48 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:57 +0200
locking/atomic: Use s64
Commit-ID: 79c53a83d7a31a5b5c7bafce4f0723bebf26836a
Gitweb: https://git.kernel.org/tip/79c53a83d7a31a5b5c7bafce4f0723bebf26836a
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:47 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:57 +0200
locking/atomic, x86: Use
Commit-ID: 04e8851af767153c0878cc79ce30c0d8806eec43
Gitweb: https://git.kernel.org/tip/04e8851af767153c0878cc79ce30c0d8806eec43
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:46 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic, sparc: Use
Commit-ID: 0ca94800762e8a2f7037c9b02ba74aff8016dd82
Gitweb: https://git.kernel.org/tip/0ca94800762e8a2f7037c9b02ba74aff8016dd82
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:45 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic, s390: Use
Commit-ID: 0754211847d7a228f1c34a49fd122979dfd19a1a
Gitweb: https://git.kernel.org/tip/0754211847d7a228f1c34a49fd122979dfd19a1a
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:44 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic, riscv: Use
Commit-ID: 33e42ef571979fe6601ac838d338eb599d842a6d
Gitweb: https://git.kernel.org/tip/33e42ef571979fe6601ac838d338eb599d842a6d
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:43 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic, riscv: Fix
Commit-ID: 8cd8de59748ba71b476d1b7101f9ecaccd5cb8c2
Gitweb: https://git.kernel.org/tip/8cd8de59748ba71b476d1b7101f9ecaccd5cb8c2
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:42 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic, powerpc
Commit-ID: d184cf1a449ca4cb0d86f3dd82c3337c645ea6c0
Gitweb: https://git.kernel.org/tip/d184cf1a449ca4cb0d86f3dd82c3337c645ea6c0
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:41 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic, mips: Use
Commit-ID: d84e28d250150adc6526dcce4ca089e2b57430f3
Gitweb: https://git.kernel.org/tip/d84e28d250150adc6526dcce4ca089e2b57430f3
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:40 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic, ia64: Use
Commit-ID: 16f18688af7ea6c65f6daa3efb4661415e2e6041
Gitweb: https://git.kernel.org/tip/16f18688af7ea6c65f6daa3efb4661415e2e6041
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:39 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic, arm64: Use
Commit-ID: ef4cdc09260e2b0576423ca708e245e7549aa8e0
Gitweb: https://git.kernel.org/tip/ef4cdc09260e2b0576423ca708e245e7549aa8e0
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:38 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic, arm: Use
Commit-ID: 16fbad086976574b99ea7019c0504d0194e95dc3
Gitweb: https://git.kernel.org/tip/16fbad086976574b99ea7019c0504d0194e95dc3
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:37 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic, arc: Use
Commit-ID: 0203fdc160a8c8d8651a3b79aa453ec36cfbd867
Gitweb: https://git.kernel.org/tip/0203fdc160a8c8d8651a3b79aa453ec36cfbd867
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:36 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic, alpha: Use
Commit-ID: 982164d62a4b2097c0db28ae7c31fc905af26bb8
Gitweb: https://git.kernel.org/tip/982164d62a4b2097c0db28ae7c31fc905af26bb8
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:34 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic, s390/pci
Commit-ID: 9255813d5841e158f033e0d83d455bffdae009a4
Gitweb: https://git.kernel.org/tip/9255813d5841e158f033e0d83d455bffdae009a4
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:35 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic: Use s64
Commit-ID: 90fde663aed0a1c27e50dd1bf3f121141b2fe9f2
Gitweb: https://git.kernel.org/tip/90fde663aed0a1c27e50dd1bf3f121141b2fe9f2
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:33 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic, crypto/nx
On Mon, Jun 03, 2019 at 10:38:48AM +0200, Peter Zijlstra wrote:
> On Sat, Jun 01, 2019 at 06:12:53PM -0700, Paul E. McKenney wrote:
> > Scheduling-clock interrupts can arrive late in the CPU-offline process,
> > after idle entry and the subsequent call to cpuhp_report_idle_dead().
> > Once
Hi Anshuman,
>From reviwing the below, I can see some major issues that need to be
addressed, which I've commented on below.
Andrew, please do not pick up this patch.
On Wed, May 29, 2019 at 02:46:27PM +0530, Anshuman Khandual wrote:
> The arch code for hot-remove must tear down portions of the
t; +++ b/arch/arm64/mm/ptdump_debugfs.c
> @@ -7,7 +7,10 @@
> static int ptdump_show(struct seq_file *m, void *v)
> {
> struct ptdump_info *info = m->private;
> +
> + get_online_mems();
> ptdump_walk_pgd(m, info);
> + put_online_mems();
We need to explici
t; we wouldn't allow to remove it. So reordering is indeed safe.
>
> Acked-by: Michal Hocko
> Reviewed-by: David Hildenbrand
> Reviewed-by: Oscar Salvador
> Signed-off-by: Anshuman Khandual
Acked-by: Mark Rutland
Mark.
> ---
> mm/memory_hotplug.c | 2 +-
> 1 fil
On Wed, May 29, 2019 at 07:03:13PM +0200, Peter Zijlstra wrote:
> On Wed, May 29, 2019 at 05:38:54PM +0100, Mark Rutland wrote:
> > Generally speaking though, if we ever task task_pt_regs() of an idle
> > task we'll get junk, and user_mode() could be true.
>
> Agreed
On Wed, May 29, 2019 at 05:24:36PM +0100, Mark Rutland wrote:
> On Wed, May 29, 2019 at 06:19:55PM +0200, Peter Zijlstra wrote:
> > On Wed, May 29, 2019 at 03:35:10PM +0100, Will Deacon wrote:
> > > On Wed, May 29, 2019 at 03:25:15PM +0200, Peter Zijlstra wrote:
> > > &
On Wed, May 29, 2019 at 06:19:55PM +0200, Peter Zijlstra wrote:
> On Wed, May 29, 2019 at 03:35:10PM +0100, Will Deacon wrote:
> > On Wed, May 29, 2019 at 03:25:15PM +0200, Peter Zijlstra wrote:
> > > On Wed, May 29, 2019 at 02:05:21PM +0100, Will Deacon wrote:
> > > > On Wed, May 29, 2019 at
On Wed, May 29, 2019 at 04:14:59PM +0200, Marco Elver wrote:
> This adds bitops tests to the test_kasan module. In a follow-up patch,
> support for bitops instrumentation will be added.
>
> Signed-off-by: Marco Elver
> ---
> Changes in v2:
> * Use BITS_PER_LONG.
> * Use heap allocated memory for
Will Deacon
> Cc: Mark Rutland
> Cc: James Morse
> Cc: Andrey Konovalov
> ---
> arch/arm64/mm/fault.c | 38 --
> 1 file changed, 16 insertions(+), 22 deletions(-)
>
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> ind
e earlier
> during the fault.
To be honest, I doubt this has any measureable impact, but I agree that
using variables _may_ make the flow control easier to understand.
>
> Signed-off-by: Anshuman Khandual
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Mark Rutland
> Cc: James
On Tue, May 28, 2019 at 07:32:28PM +0200, Peter Zijlstra wrote:
> On Tue, May 28, 2019 at 04:32:24PM +0100, Will Deacon wrote:
> > On Tue, May 28, 2019 at 04:01:03PM +0200, Peter Zijlstra wrote:
> > > On Tue, May 28, 2019 at 08:31:29PM +0800, Young Xiao wrote:
> > > > When a kthread calls
On Tue, May 28, 2019 at 12:19:38PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, May 28, 2019 at 04:03:14PM +0100, Raphael Gault escreveu:
> > In order to subsequently add more tests for the arm64 architecture
> > we compile the tests target for arm64 systematically.
>
> Humm, the subject
On Tue, May 28, 2019 at 04:32:24PM +0100, Will Deacon wrote:
> On Tue, May 28, 2019 at 04:01:03PM +0200, Peter Zijlstra wrote:
> > On Tue, May 28, 2019 at 08:31:29PM +0800, Young Xiao wrote:
> > > When a kthread calls call_usermodehelper() the steps are:
> > > 1. allocate current->mm
> > > 2.
501 - 600 of 8690 matches
Mail list logo
