On Wed, Sep 25, 2019 at 10:59:20AM +0800, Jia He wrote:
> We unconditionally set the HW_AFDBM capability and only enable it on
> CPUs which really have the feature. But sometimes we need to know
> whether this cpu has the capability of HW AF. So decouple AF from
> DBM by new helper
lect that.
>
> Signed-off-by: Jeremy Cline
I forgot about this. Thanks.
Acked-by: Catalin Marinas
: bfe801ebe84f ("arm64: vdso: Enable vDSO compat support")
Cc: Will Deacon
Cc: Vincenzo Frascino
Cc: Thomas Gleixner
Signed-off-by: Catalin Marinas
---
It looks like you can't really win with the current compat vDSO logic.
You either don't have a compat cross-compiler and you get a Makefi
On Tue, Sep 24, 2019 at 11:29:07PM +0800, Jia He wrote:
> On 2019/9/24 18:33, Catalin Marinas wrote:
> > On Tue, Sep 24, 2019 at 06:43:06AM +, Justin He (Arm Technology China)
> > wrote:
> > > Catalin Marinas wrote:
> > > > On Sat, Sep 21, 20
On Tue, Sep 24, 2019 at 06:43:06AM +, Justin He (Arm Technology China)
wrote:
> Catalin Marinas wrote:
> > On Sat, Sep 21, 2019 at 09:50:54PM +0800, Jia He wrote:
> > > @@ -2151,21 +2163,53 @@ static inline void cow_user_page(struct page
> > > *dst, st
On Sat, Sep 21, 2019 at 09:50:54PM +0800, Jia He wrote:
> @@ -2151,21 +2163,53 @@ static inline void cow_user_page(struct page *dst,
> struct page *src, unsigned lo
>* fails, we just zero-fill it. Live with it.
>*/
> if (unlikely(!src)) {
> - void *kaddr =
n case this
function will be used elsewhere in the future.
> +}
> +#define arch_faults_on_old_pte arch_faults_on_old_pte
Otherwise,
Reviewed-by: Catalin Marinas
ot;Check whether hardware update of the Access flag is supported".
> +static inline bool cpu_has_hw_af(void)
> +{
> + if (IS_ENABLED(CONFIG_ARM64_HW_AFDBM))
> + return read_cpuid(ID_AA64MMFR1_EL1) & 0xf;
> +
> + return false;
> +}
Other than the comment above,
Reviewed-by: Catalin Marinas
On Thu, Sep 19, 2019 at 05:03:21PM +0200, Thomas Gleixner wrote:
> The syscall handling code has an obscure check of pending work which does a
> shortcut before returning to user space. It calls into the exit work code
> when the flags at entry time required an entry into the slowpath. That does
>
On Thu, Sep 19, 2019 at 05:03:18PM +0200, Thomas Gleixner wrote:
> #ifdef CONFIG_ARM64_ERRATUM_1463225
> @@ -97,19 +97,16 @@ static void el0_svc_common(struct pt_reg
>
> regs->orig_x0 = regs->regs[0];
> regs->syscallno = scno;
> + /* Set default error number */
> +
On Fri, Sep 20, 2019 at 12:12:04AM +0800, Jia He wrote:
> @@ -2152,7 +2163,29 @@ static inline void cow_user_page(struct page *dst,
> struct page *src, unsigned lo
>*/
> if (unlikely(!src)) {
> void *kaddr = kmap_atomic(dst);
> - void __user *uaddr = (void
On Fri, Sep 20, 2019 at 12:12:02AM +0800, Jia He wrote:
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index b1fdc486aed8..fb0e9425d286 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -1141,6 +1141,16 @@ static bool
On Thu, Sep 19, 2019 at 06:00:07PM +0300, Kirill A. Shutemov wrote:
> On Wed, Sep 18, 2019 at 07:00:30PM +0100, Catalin Marinas wrote:
> > On Wed, Sep 18, 2019 at 05:00:27PM +0300, Kirill A. Shutemov wrote:
> > > On Wed, Sep 18, 2019 at 09:19:14PM +0800, Jia He wrote:
> >
On Wed, Sep 18, 2019 at 05:00:27PM +0300, Kirill A. Shutemov wrote:
> On Wed, Sep 18, 2019 at 09:19:14PM +0800, Jia He wrote:
> > @@ -2152,20 +2163,34 @@ static inline void cow_user_page(struct page *dst,
> > struct page *src, unsigned lo
> > */
> > if (unlikely(!src)) {
> >
On Wed, Sep 18, 2019 at 07:20:17AM -0700, Matthew Wilcox wrote:
> On Wed, Sep 18, 2019 at 09:19:12PM +0800, Jia He wrote:
> > +/* Decouple AF from AFDBM. */
> > +bool cpu_has_hw_af(void)
> > +{
> > + return (read_cpuid(ID_AA64MMFR1_EL1) & 0xf);
> > +}
> > +
>
> Do you really want to call
On Wed, Sep 18, 2019 at 03:20:41PM +0100, Suzuki K Poulose wrote:
> On 18/09/2019 14:19, Jia He wrote:
> > diff --git a/arch/arm64/include/asm/cpufeature.h
> > b/arch/arm64/include/asm/cpufeature.h
> > index c96ffa4722d3..206b6e3954cf 100644
> > --- a/arch/arm64/include/asm/cpufeature.h
> > +++
On Tue, Sep 17, 2019 at 10:06:11AM +0530, Anshuman Khandual wrote:
> On 09/13/2019 03:39 PM, Catalin Marinas wrote:
> > On Fri, Sep 13, 2019 at 11:28:01AM +0530, Anshuman Khandual wrote:
> >> The problem (race) is not because of the inability to deal with partially
> >>
On Fri, Sep 13, 2019 at 11:28:01AM +0530, Anshuman Khandual wrote:
> On 09/13/2019 01:45 AM, Catalin Marinas wrote:
> > On Tue, Sep 03, 2019 at 03:15:58PM +0530, Anshuman Khandual wrote:
> >> @@ -770,6 +1022,28 @@ int __meminit vmemmap_populate(unsigned long start,
> >
Hi Anshuman,
Thanks for the details on the need for removing the page tables and
vmemmap backing. Some comments on the code below.
On Tue, Sep 03, 2019 at 03:15:58PM +0530, Anshuman Khandual wrote:
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -60,6 +60,14 @@ static pud_t
On Wed, Sep 11, 2019 at 12:54:38PM +0200, Nicolas Saenz Julienne wrote:
> On Mon, 2019-09-09 at 11:58 +0200, Nicolas Saenz Julienne wrote:
> > /*
> > - * Return the maximum physical address for ZONE_DMA32 (DMA_BIT_MASK(32)).
> > It
> > - * currently assumes that for memory starting above 4G,
On Tue, Sep 03, 2019 at 03:15:58PM +0530, Anshuman Khandual wrote:
> @@ -770,6 +1022,28 @@ int __meminit vmemmap_populate(unsigned long start,
> unsigned long end, int node,
> void vmemmap_free(unsigned long start, unsigned long end,
> struct vmem_altmap *altmap)
> {
> +#ifdef
On Fri, Sep 06, 2019 at 07:57:42AM -0700, Matthew Wilcox wrote:
> On Fri, Sep 06, 2019 at 09:57:47PM +0800, Jia He wrote:
> > * This really shouldn't fail, because the page is there
> > * in the page tables. But it might just be unreadable,
> > * in which
On Mon, Sep 09, 2019 at 02:27:12PM -0700, Matthew Wilcox wrote:
> On Fri, Sep 06, 2019 at 09:57:47PM +0800, Jia He wrote:
> > + if (!pte_young(vmf->orig_pte)) {
> > + entry = pte_mkyoung(vmf->orig_pte);
> > + if (ptep_set_access_flags(vmf->vma,
initialise
swiotlb unnecessarily. I guess you need a similar check to the
dma_contiguous_reserve() above.
With that:
Reviewed-by: Catalin Marinas
Unless there are other objections, I can queue this series for 5.5 in a
few weeks time (too late for 5.4).
--
Catalin
> Signed-off-by: Nicolas Saenz Julienne
> Reviewed-by: Christoph Hellwig
Reviewed-by: Catalin Marinas
On Mon, Sep 02, 2019 at 04:10:41PM +0200, Nicolas Saenz Julienne wrote:
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 8956c22634dd..f02a4945aeac 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -50,6 +50,13 @@
> s64 memstart_addr __ro_after_init = -1;
>
On Mon, Sep 02, 2019 at 04:10:40PM +0200, Nicolas Saenz Julienne wrote:
> Let the name indicate that they are used to calculate ZONE_DMA32's size
> as opposed to ZONE_DMA.
>
> Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Catalin Marinas
> Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Catalin Marinas
On Wed, 4 Sep 2019 at 04:20, Anshuman Khandual
wrote:
> On 09/04/2019 06:28 AM, Jia He wrote:
> > @@ -2152,20 +2153,30 @@ static inline void cow_user_page(struct page *dst,
> > struct page *src, unsigned lo
> >*/
> > if (unlikely(!src)) {
> > void *kaddr =
On Wed, 4 Sep 2019 at 01:59, Jia He wrote:
> @@ -2152,20 +2153,30 @@ static inline void cow_user_page(struct page *dst,
> struct page *src, unsigned lo
> */
> if (unlikely(!src)) {
> void *kaddr = kmap_atomic(dst);
> - void __user *uaddr = (void
On Mon, Sep 02, 2019 at 11:44:43AM +1000, Michael Ellerman wrote:
> Stephen Rothwell writes:
> > Hi all,
> >
> > Today's linux-next merge of the powerpc tree got a conflict in:
> >
> > arch/Kconfig
> >
> > between commit:
> >
> > 5cf896fb6be3 ("arm64: Add support for relocating the kernel
ALLBACK from arm64 compat vdso.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Signed-off-by: Vincenzo Frascino
Acked-by: Catalin Marinas
e these symbols.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Signed-off-by: Vincenzo Frascino
Acked-by: Catalin Marinas
Hi Linus,
Please pull the arm64 fixes below. Thanks.
The following changes since commit 30e235389faadb9e3d918887b1f126155d7d761d:
arm64: mm: add missing PTE_SPECIAL in pte_mkdevmap on arm64 (2019-08-08
18:38:20 +0100)
are available in the Git repository at:
On Fri, Aug 16, 2019 at 10:16:03PM +1000, Stephen Rothwell wrote:
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> mm/kmemleak.c: In function 'kmemleak_disable':
> mm/kmemleak.c:1884:2: error: 'kmemleak_early_log' undeclared (first use
quot;memory pool size" as I see the size as
a constant set at config time. What about "memory pool available"?
(even this one is not entirely accurate since we have a
mem_pool_free_list but I expect such list not to have too many elements
at the late_initcall time)
If you change the printed string:
Acked-by: Catalin Marinas
for kmemleak or suffering from higher chance of a kmemleak
> metadata allocation failure. 524288 proves to be the good number for all
> architectures here. Increase the upper bound to 1M to leave some room
> for the future.
>
> Signed-off-by: Qian Cai
Acked-by: Catalin Marinas
d.
>
> For consistency, let's use is_kthread() here.
>
> Signed-off-by: Mark Rutland
> Cc: Catalin Marinas
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Will Deacon
Acked-by: Catalin Marinas
> For consistency, let's use is_kthread() here.
>
> Signed-off-by: Mark Rutland
> Cc: Catalin Marinas
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> ---
> mm/kmemleak.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Acked-by: Catalin Marinas
> in
On Tue, Aug 13, 2019 at 08:35:54AM -0400, Qian Cai wrote:
> On Mon, 2019-08-12 at 17:06 +0100, Catalin Marinas wrote:
> > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> > index 4d39540011e2..39df06ffd9f4 100644
> > --- a/lib/Kconfig.debug
> > +++ b/lib/Kconfig.d
On Mon, Aug 12, 2019 at 02:07:30PM -0700, Andrew Morton wrote:
> On Mon, 12 Aug 2019 17:06:39 +0100 Catalin Marinas
> wrote:
>
> > Following the discussions on v2 of this patch(set) [1], this series
> > takes slightly different approach:
> >
> > - it impl
On Mon, Aug 12, 2019 at 05:06:41PM +0100, Catalin Marinas wrote:
> Add a memory pool for struct kmemleak_object in case the normal
> kmem_cache_alloc() fails under the gfp constraints passed by the caller.
> The mem_pool[] array size is currently fixed at 16000.
Following Andrew's com
On Mon, Aug 12, 2019 at 05:06:42PM +0100, Catalin Marinas wrote:
> @@ -466,9 +419,13 @@ static struct kmemleak_object *mem_pool_alloc(gfp_t gfp)
> struct kmemleak_object *object;
>
> /* try the slab allocator first */
> - object = kmem_cache_alloc(object_cache, gf
Add a memory pool for struct kmemleak_object in case the normal
kmem_cache_alloc() fails under the gfp constraints passed by the caller.
The mem_pool[] array size is currently fixed at 16000.
Signed-off-by: Catalin Marinas
---
mm/kmemleak.c | 54
object_cache has been initialised as we wouldn't have any
concurrent list traversal before this.
In order to reduce the number of callbacks before kmemleak is fully
initialised, move the kmemleak_init() call to mm_init().
Signed-off-by: Catalin Marinas
---
init/main.c | 2 +-
lib
such allocations fail as scan areas are rather an
optimisation
[1] http://lkml.kernel.org/r/20190727132334.9184-1-catalin.mari...@arm.com
Catalin Marinas (3):
mm: kmemleak: Make the tool tolerant to struct scan_area allocation
failures
mm: kmemleak: Simple memory allocation pool for kmemleak objects
an OBJECT_FULL_SCAN flag and mark objects as such when
scan_area allocation fails.
Signed-off-by: Catalin Marinas
---
mm/kmemleak.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index f6e602918dac..5ba7fad00fda 100644
--- a/mm
Hi Linus,
Please pull the arm64 fix below. Thanks.
The following changes since commit e21a712a9685488f5ce80495b37b9fdbe96c230d:
Linux 5.3-rc3 (2019-08-04 18:40:12 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
for
On Wed, Aug 07, 2019 at 10:09:29AM +0100, Will Deacon wrote:
> On Wed, Aug 07, 2019 at 12:58:51PM +0800, Jia He wrote:
> > diff --git a/arch/arm64/include/asm/pgtable.h
> > b/arch/arm64/include/asm/pgtable.h
> > index 5fdcfe237338..e09760ece844 100644
> > --- a/arch/arm64/include/asm/pgtable.h
>
On Thu, Aug 01, 2019 at 08:41:53AM +0200, Michal Hocko wrote:
> On Wed 31-07-19 16:44:50, Catalin Marinas wrote:
> > On Tue, Jul 30, 2019 at 01:02:15PM -0700, Andrew Morton wrote:
> > > On Sat, 27 Jul 2019 14:23:33 +0100 Catalin Marinas
> > > wrote:
> > >
On Sat, Aug 03, 2019 at 09:42:12AM +0900, Masami Hiramatsu wrote:
> On Fri, 2 Aug 2019 07:48:13 +1000
> Stephen Rothwell wrote:
> > In commit
> >
> > 72de4a283cb1 ("arm64: kprobes: Recover pstate.D in single-step exception
> > handler")
> >
> > Fixes tag
> >
> > Fixes: commit 7419333fa15e
Hi Linus,
Please pull the arm64 fixes below. Thanks.
The following changes since commit 609488bc979f99f805f34e9a32c1e3b71179d10b:
Linux 5.3-rc2 (2019-07-28 12:47:02 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
On Thu, Aug 01, 2019 at 08:36:47AM -0700, Dave Hansen wrote:
> On 8/1/19 5:48 AM, Andrey Konovalov wrote:
> > On Thu, Aug 1, 2019 at 2:11 PM Kevin Brodsky wrote:
> >> On 31/07/2019 17:50, Dave Hansen wrote:
> >>> On 7/23/19 10:58 AM, Andrey Konovalov wrote:
> The mmap and mremap (only
On Tue, Jul 30, 2019 at 05:23:48PM -0400, Qian Cai wrote:
> GCC throws out this warning on arm64.
>
> drivers/firmware/efi/libstub/arm-stub.c: In function 'efi_entry':
> drivers/firmware/efi/libstub/arm-stub.c:132:22: warning: variable 'si'
> set but not used [-Wunused-but-set-variable]
>
> Fix
ariables and functions, expansions you would consider empty may
> actually contain whitespace characters and thus are not seen as
> empty. However, you can use the strip function to avoid interpreting
> whitespace as a non-empty value."
>
> Fix the issue adding strip to the CROSS_
On Wed, Jul 31, 2019 at 05:47:48PM +0200, Nicolas Saenz Julienne wrote:
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 1c4ffabbe1cb..f5279ef85756 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -50,6 +50,13 @@
> s64 memstart_addr __ro_after_init = -1;
>
On Tue, Jul 30, 2019 at 01:02:15PM -0700, Andrew Morton wrote:
> On Sat, 27 Jul 2019 14:23:33 +0100 Catalin Marinas
> wrote:
>
> > Add mempool allocations for struct kmemleak_object and
> > kmemleak_scan_area as slightly more resilient than kmem_cache_alloc()
>
that kmemleak_disable() also disables early logging.
Cc: Andrew Morton
Reported-by: Qian Cai
Signed-off-by: Catalin Marinas
---
mm/kmemleak.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 6e9e8cca663e..f6e602918dac 100644
--- a/mm/kmemleak.c
+++ b/mm
On Wed, Jul 31, 2019 at 08:02:30AM -0400, Qian Cai wrote:
> On Jul 31, 2019, at 5:53 AM, Catalin Marinas wrote:
> > On Tue, Jul 30, 2019 at 04:22:37PM -0400, Qian Cai wrote:
> >> On Tue, 2019-07-30 at 12:57 -0700, Andrew Morton wrote:
> >>> On Sat, 27 Jul 2019
On Tue, Jul 30, 2019 at 04:22:37PM -0400, Qian Cai wrote:
> On Tue, 2019-07-30 at 12:57 -0700, Andrew Morton wrote:
> > On Sat, 27 Jul 2019 14:23:33 +0100 Catalin Marinas
> > > --- a/Documentation/admin-guide/kernel-parameters.txt
> > > +++ b/Documentation/admin-
On Wed, Jul 31, 2019 at 11:06:53AM +0200, Michal Hocko wrote:
> On Tue 30-07-19 12:57:43, Andrew Morton wrote:
> > On Sat, 27 Jul 2019 14:23:33 +0100 Catalin Marinas
> > wrote:
> >
> > > Add mempool allocations for struct kmemleak_object and
> > > kmemle
, so let's pick that value.
>
> This consumes more RAM on boot (each entry is 160 bytes, so
> in total ~2.5MB of RAM), but the memory would later be freed
> (early_log is __initdata).
>
> Suggested-by: Dmitry Vyukov
> Signed-off-by: Nicolas Boichat
Acked-by: Catalin Marinas
Some nitpicking below:
On Mon, Jul 29, 2019 at 03:13:42PM +0100, Valentin Schneider wrote:
> specs.tla:
>
> MODULE specs
> EXTENDS Integers, Sequences, TLC
>
> CONSTANTS
> NR_WRITERS,
> NR_READERS,
> WRITER_TASK,
> READER_TASK
>
> WRITERS == {WRITER_TASK} \X
Hi Dmitry,
On Mon, Jul 29, 2019 at 01:08:16PM +0200, Dmitry Vyukov wrote:
> The remaining 10 were all diverged due to other unrelated memory leaks
> and other non-leak bugs. It seems the main 2 reasons for this:
> 1. Lots of leaks are old (kernel is under-tested with KMEMLEAK).
> 2. Lots of
) is added to allow a
different minimum pool size (defaulting to NR_CPUS * 4).
Cc: Michal Hocko
Cc: Matthew Wilcox
Cc: Qian Cai
Suggested-by: Michal Hocko
Signed-off-by: Catalin Marinas
---
v1 posted here:
http://lkml.kernel.org/r/20190328145917.gc10...@arrakis.emea.arm.com
Changes in v2
On Tue, Jul 16, 2019 at 02:23:30PM -0400, Qian Cai wrote:
> As mentioned in anther thread, the situation for kmemleak under memory
> pressure
> has already been unhealthy. I don't feel comfortable to make it even worse by
> reverting this commit alone. This could potentially make kmemleak kill
On Fri, Jul 26, 2019 at 06:05:32PM +0200, Dmitry Vyukov wrote:
> On Fri, Jul 26, 2019 at 5:57 PM Catalin Marinas
> wrote:
> >
> > On Fri, Jul 26, 2019 at 05:20:55PM +0200, Dmitry Vyukov wrote:
> > > On Fri, Jul 26, 2019 at 3:00 PM Catalin Marinas
> > > wrote
On Fri, Jul 26, 2019 at 05:20:55PM +0200, Dmitry Vyukov wrote:
> On Fri, Jul 26, 2019 at 3:00 PM Catalin Marinas
> wrote:
> > On Wed, Jul 24, 2019 at 12:18:07PM -0700, syzbot wrote:
> > > syzbot found the following crash on:
> > >
> > > HEAD commit:c6dd
On Wed, Jul 24, 2019 at 12:18:07PM -0700, syzbot wrote:
> syzbot found the following crash on:
>
> HEAD commit:c6dd78fc Merge branch 'x86-urgent-for-linus' of git://git...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15fffef460
> kernel config:
On Thu, Jul 25, 2019 at 12:25:23PM +0530, Anshuman Khandual wrote:
> +#if !defined(__PAGETABLE_PMD_FOLDED) && !defined(__ARCH_HAS_4LEVEL_HACK)
> +static void pud_clear_tests(void)
> +{
> + pud_t pud;
> +
> + pud_clear();
> + WARN_ON(!pud_none(pud));
> +}
For the clear tests, I think
On Wed, Jul 17, 2019 at 05:31:33PM +0200, Nicolas Saenz Julienne wrote:
> The dma physical limit has so far been calculated based on the memory
> size and the assumption that dma would be at least able to address the
> first 4 GB. This turned out no to be true with the Raspberry Pi 4
> which, on
On Mon, Jul 22, 2019 at 11:00:10AM -0400, Steven Rostedt wrote:
> On Mon, 22 Jul 2019 13:42:02 +0100
> Catalin Marinas wrote:
>
> > > I agree with Masami, that the selftest actually caught a bug here. I
> > > think the arch code may need to change as the purpos
Hi Steve,
On Tue, Jul 09, 2019 at 11:15:20AM -0400, Steven Rostedt wrote:
> On Wed, 3 Jul 2019 15:08:32 +0100
> Catalin Marinas wrote:
> > > diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> > > index 5471efbeb937..0ca6f53c8505 100644
> > > --- a/kernel/kprob
On Tue, Jul 09, 2019 at 09:30:49PM +0900, Masami Hiramatsu wrote:
> On Wed, 3 Jul 2019 10:02:05 -0400 Steven Rostedt
> wrote:
> > On Tue, 2 Jul 2019 17:50:09 +0100 Mark Rutland
> > wrote:
> > > On Sun, May 26, 2019 at 03:18:40PM -0400, Steven Rostedt wrote:
> > > > Signed-off-by: Masami
ion. Drop this
> helper which is redundant on arm64.
I had this on my list for 5.3 but the arm64 for-next/core was already
frozen. Will can queue this whenever he sees fit.
Acked-by: Catalin Marinas
On 15 Jul 2019, at 08:17, Michal Hocko wrote:
> On Sat 13-07-19 04:49:04, Yang Shi wrote:
>> When running ltp's oom test with kmemleak enabled, the below warning was
>> triggerred since kernel detects __GFP_NOFAIL & ~__GFP_DIRECT_RECLAIM is
>> passed in:
>
> kmemleak is broken and this is a long
not allocate executable memory
Bartlomiej Zolnierkiewicz (1):
arm64: remove redundant 'default n' from Kconfig
Catalin Marinas (2):
arm64: ARM64_MODULES_PLTS must depend on MODULES
Merge branch 'for-next/perf' of git://git.kernel.org/.../will/linux
Florian Fainelli (1
On Tue, Jul 02, 2019 at 09:07:28AM +0530, Anshuman Khandual wrote:
> On 06/28/2019 03:50 PM, Catalin Marinas wrote:
> > On Thu, Jun 27, 2019 at 06:18:15PM +0530, Anshuman Khandual wrote:
> >> pmd_present() and pmd_trans_huge() are expected to behave in the following
> >
s_initcall(init_kprobes);
>
> +static int __init run_init_test_probes(void)
> +{
> + if (run_kprobe_tests)
> + init_test_probes();
A return 0 here.
> +}
> +module_init(run_init_test_probes);
This does the trick. I prefer your fix as it leaves the arch code
unchanged. In case you need it:
Tested-by: Catalin Marinas
Thanks.
--
Catalin
xt/core assuming that the above commit id remains stable):
--8<
>From de4f4d30bab3d77d6643a6fa9ba1deff73dac7f2 Mon Sep 17 00:00:00 2001
From: Catalin Marinas
Date: Wed, 3 Jul 2019 14:44:23 +0100
Subject: [PATCH] arm64: Initialise the de
On Mon, Jun 24, 2019 at 10:55:41AM +0100, Raphael Gault wrote:
> Until now, the section .altinstr_replacement wasn't marked as containing
> executable instructions on arm64. This patch changes that so that it is
> coherent with what is done on x86.
>
> Signed-off-by: Raphael Gault
> ---
>
On Mon, Jun 24, 2019 at 10:55:42AM +0100, Raphael Gault wrote:
> --- a/arch/arm64/include/asm/assembler.h
> +++ b/arch/arm64/include/asm/assembler.h
> @@ -752,4 +752,17 @@ USER(\label, ic ivau, \tmp2)//
> invalidate I line PoU
> .Lyield_out_\@ :
> .endm
>
> + /*
Hi Anshuman,
On Thu, Jun 27, 2019 at 06:18:15PM +0530, Anshuman Khandual wrote:
> pmd_present() and pmd_trans_huge() are expected to behave in the following
> manner during various phases of a given PMD. It is derived from a previous
> detailed discussion on this topic [1] and present THP
On Thu, Jun 27, 2019 at 08:58:03AM -0700, Kees Cook wrote:
> On Thu, Jun 27, 2019 at 09:02:08AM +0100, Catalin Marinas wrote:
> > On Wed, Jun 26, 2019 at 01:51:15PM -0700, Kees Cook wrote:
> > > This moves arm64 jump_label_init() from smp_prepare_boot_cpu() to
> > > se
Hi Kees,
On Wed, Jun 26, 2019 at 01:51:15PM -0700, Kees Cook wrote:
> This moves arm64 jump_label_init() from smp_prepare_boot_cpu() to
> setup_arch(), as done already on x86, in preparation from early param
> usage in the init_on_alloc/free() series:
>
Hi Andrew,
Cc'ing Luc (sparse maintainer) who's been involved in the past
discussions around static checking of user pointers:
https://lore.kernel.org/linux-arm-kernel/20180905190316.a34yycthgbamx2t3@ltop.local/
So I think the difference here from the previous approach is that we
explicitly
On Wed, Jun 26, 2019 at 08:50:13PM +0900, jinho lim wrote:
> In traps.c, only __die calls dump_instr.
> However, this function has sub-function as __dump_instr.
>
> dump_kernel_instr can replace those functions.
> By using aarch64_insn_read, it does not have to change fs to KERNEL_DS.
>
>
Commit-ID: 6a5b78b32d10cd7901f639870eca304b270769f9
Gitweb: https://git.kernel.org/tip/6a5b78b32d10cd7901f639870eca304b270769f9
Author: Catalin Marinas
AuthorDate: Mon, 24 Jun 2019 15:00:19 +0100
Committer: Thomas Gleixner
CommitDate: Wed, 26 Jun 2019 07:28:10 +0200
arm64: compat
Commit-ID: 94fee4d43752b6022428d9de402632904968e15b
Gitweb: https://git.kernel.org/tip/94fee4d43752b6022428d9de402632904968e15b
Author: Catalin Marinas
AuthorDate: Mon, 24 Jun 2019 14:58:12 +0100
Committer: Thomas Gleixner
CommitDate: Wed, 26 Jun 2019 07:28:10 +0200
arm64: vdso
Commit-ID: ed75e8f60bb1d41d751ccad470e15bc2a57adee6
Gitweb: https://git.kernel.org/tip/ed75e8f60bb1d41d751ccad470e15bc2a57adee6
Author: Catalin Marinas
AuthorDate: Mon, 24 Jun 2019 14:56:24 +0100
Committer: Thomas Gleixner
CommitDate: Wed, 26 Jun 2019 07:28:09 +0200
vdso: Remove
; git log -p arch/arm64/ | grep PTE_TYPE_FAULT
> git log -p arch/arm64/ | grep PMD_TYPE_FAULT
>
> These probably meant to identify non present entries which can now be
> achieved with PMD_SECT_VALID or PTE_VALID bits. Hence just drop these
> unused symbols which are not re
On Tue, Jun 25, 2019 at 05:42:49PM +0200, Ard Biesheuvel wrote:
> On Tue, 25 Jun 2019 at 17:39, Catalin Marinas wrote:
> > On Mon, Jun 24, 2019 at 12:06:18PM +0200, Ard Biesheuvel wrote:
> > > On Mon, 24 Jun 2019 at 11:57, Will Deacon wrote:
> > > > Than
On Mon, Jun 24, 2019 at 12:06:18PM +0200, Ard Biesheuvel wrote:
> On Mon, 24 Jun 2019 at 11:57, Will Deacon wrote:
> > Thanks for having a look. It could be that we've fixed the issue Catalin was
> > running into in the past -- he was going to see if the problem persists with
> > mainline, since
On Mon, Jun 17, 2019 at 03:29:59PM -0700, Florian Fainelli wrote:
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 697ea0510729..9206feaeff07 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1418,8 +1418,26 @@ config ARM64_SVE
> KVM in the same kernel image.
On Mon, Jun 24, 2019 at 10:58:50AM -0700, Nick Desaulniers wrote:
> For testing coverage and improved defense in depth, enable KASLR by
> default.
>
> Acked-by: Ard Biesheuvel
> Acked-by: Will Deacon
> Reviewed-by: Kees Cook
> Suggested-by: Arnd Bergmann
> Suggested-by: Olof Johansson
>
Commit-ID: 53d87b37a2a4a4b6b0c7f8073c4be04022252e26
Gitweb: https://git.kernel.org/tip/53d87b37a2a4a4b6b0c7f8073c4be04022252e26
Author: Catalin Marinas
AuthorDate: Mon, 24 Jun 2019 15:00:19 +0100
Committer: Thomas Gleixner
CommitDate: Tue, 25 Jun 2019 09:43:38 +0200
arm64: compat
Commit-ID: b4b12aca00d509a233abd28990194628adcd71e6
Gitweb: https://git.kernel.org/tip/b4b12aca00d509a233abd28990194628adcd71e6
Author: Catalin Marinas
AuthorDate: Mon, 24 Jun 2019 14:58:12 +0100
Committer: Thomas Gleixner
CommitDate: Tue, 25 Jun 2019 09:43:38 +0200
arm64: vdso
Commit-ID: 4d33ebb02c45738296ffde4b8f2089edaf75be1c
Gitweb: https://git.kernel.org/tip/4d33ebb02c45738296ffde4b8f2089edaf75be1c
Author: Catalin Marinas
AuthorDate: Mon, 24 Jun 2019 14:56:24 +0100
Committer: Thomas Gleixner
CommitDate: Tue, 25 Jun 2019 09:43:38 +0200
vdso: Remove
d user pointers for vma lookups, which can
> only by done with untagged pointers.
>
> Untag user pointers in validate_range().
>
> Reviewed-by: Vincenzo Frascino
> Reviewed-by: Catalin Marinas
> Reviewed-by: Kees Cook
> Signed-off-by: Andrey Konovalov
> ---
> fs/u
On Tue, Jun 11, 2019 at 03:56:27PM +0100, Sudeep Holla wrote:
> The usage of emulated and _TIF_SYSCALL_EMU flags in syscall_trace_enter
> is more complicated than required.
>
> Cc: Andy Lutomirski
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Acked-by: Oleg Nesterov
> Reviewed-by: Thomas Gleixner
701 - 800 of 5901 matches
Mail list logo
