On Tue, Jun 23, 2020 at 07:05:07PM +0100, Peter Maydell wrote:
> On Wed, 17 Jun 2020 at 13:39, Steven Price wrote:
> > These patches add support to KVM to enable MTE within a guest. It is
> > based on Catalin's v4 MTE user space series[1].
> >
> > [1]
Hi Steven,
On Wed, Jun 17, 2020 at 01:38:42PM +0100, Steven Price wrote:
> These patches add support to KVM to enable MTE within a guest. It is
> based on Catalin's v4 MTE user space series[1].
>
> [1] http://lkml.kernel.org/r/20200515171612.1020-1-catalin.marinas%40arm.com
>
> Posting as an
On Wed, Jun 17, 2020 at 01:38:44PM +0100, Steven Price wrote:
> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> index e3b9ee268823..040a7fffaa93 100644
> --- a/virt/kvm/arm/mmu.c
> +++ b/virt/kvm/arm/mmu.c
> @@ -1783,6 +1783,17 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
>
On Wed, Jun 17, 2020 at 01:38:43PM +0100, Steven Price wrote:
> diff --git a/arch/arm64/kvm/hyp/sysreg-sr.c b/arch/arm64/kvm/hyp/sysreg-sr.c
> index 75b1925763f1..6ecee1528566 100644
> --- a/arch/arm64/kvm/hyp/sysreg-sr.c
> +++ b/arch/arm64/kvm/hyp/sysreg-sr.c
> @@ -26,6 +26,12 @@
> static void
On Thu, Jun 11, 2020 at 06:42:12PM +0900, Wooyeon Kim wrote:
> I am in charge of camera driver development in Samsung S.LSI division.
>
> In order to guarantee real time processing such as Camera 3A algorithm in
> current or ongoing projects, prebuilt binary is loaded and used in kernel
> space,
On Wed, Jun 10, 2020 at 04:39:44PM +0530, Shyam Thombre wrote:
> KASAN sw tagging sets a random tag of 8 bits in the top byte of the pointer
> returned by the memory allocating functions. So for the functions unaware
> of this change, the top 8 bits of the address must be reset which is done
> by
On Wed, Jun 10, 2020 at 03:51:56PM +0800, kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: b751c52bb587ae66f773b15204ef7a147467f4c7 ("kmemleak: increase
> DEBUG_KMEMLEAK_EARLY_LOG_SIZE default to 16K")
>
On Wed, Jun 10, 2020 at 09:47:55AM +0100, Will Deacon wrote:
> On Tue, Jun 09, 2020 at 04:55:13PM -0700, Nick Desaulniers wrote:
> > On Tue, Jun 9, 2020 at 1:35 PM Catalin Marinas
> > wrote:
> > > On Mon, Jun 08, 2020 at 01:57:08PM -0700, Nick Desaulniers wrote:
> &g
On Mon, Jun 08, 2020 at 01:57:08PM -0700, Nick Desaulniers wrote:
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 7f9d38444d6d..fe9e6b231cac 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1299,6 +1299,14 @@ config COMPAT_VDSO
> You must have a 32-bit
On Mon, Jun 08, 2020 at 10:49:25AM +0800, Wang ShaoBo wrote:
> Currently arm64 personality syscall uses wrapper __arm64_sys_personality
> to redirect to __arm64_sys_arm64_personality, it's easily confused,
> Whereas using an normal hook arch_check_personality() can reject
> additional settings
On Fri, Jun 05, 2020 at 06:01:16PM -0700, Andrew Morton wrote:
> On Fri, 5 Jun 2020 12:46:55 +0100 Catalin Marinas
> wrote:
> > On Fri, Jun 05, 2020 at 11:08:13AM +0100, Catalin Marinas wrote:
> > > This patch causes a kernel panic on arm64 (and possibly powerpc, I
> &
On Fri, Jun 05, 2020 at 11:08:13AM +0100, Catalin Marinas wrote:
> This patch causes a kernel panic on arm64 (and possibly powerpc, I
> haven't tried). arm64 still uses the 5level-fixup.h and pud_alloc()
> checks for the empty p4d with pgd_none() instead of p4d_none().
Ah, should hav
);
> +}
This patch causes a kernel panic on arm64 (and possibly powerpc, I
haven't tried). arm64 still uses the 5level-fixup.h and pud_alloc()
checks for the empty p4d with pgd_none() instead of p4d_none().
The patch below fixes it:
---8<---
Hi Zhenyu,
On Sat, May 30, 2020 at 06:24:21PM +0800, Zhenyu Ye wrote:
> On 2020/5/26 22:52, Catalin Marinas wrote:
> > On Mon, May 25, 2020 at 03:19:42PM +0800, Zhenyu Ye wrote:
> >> tlb_flush_##_pxx##_range() is used to set tlb->cleared_*,
> >> flush_##_pxx##_t
Hi Linus,
Please pull the arm64 fix below. Thanks.
The following changes since commit 8cfb347ad0cffdbfc69c82506fb3be9429563211:
arm64: Add get_user() type annotation on the !access_ok() path (2020-05-22
16:59:49 +0100)
are available in the Git repository at:
On Thu, May 28, 2020 at 09:05:08AM +0100, Peter Smith wrote:
> I suggest using Arm if you need a frame pointer, and disable the
> frame pointer if you want/need to use Thumb. My understanding is that
> runtime unwinding using the frame pointer in Thumb is already difficult
> due to Arm and Thumb
e:
/*
* Requesting a non-existent register search is an error. Warn
* and let the caller handle it.
*/
Otherwise it looks fine:
Reviewed-by: Catalin Marinas
On Tue, May 26, 2020 at 07:09:13PM +0530, Anshuman Khandual wrote:
> @@ -632,8 +654,6 @@ static void __init init_cpu_ftr_reg(u32 sys_reg, u64 new)
> const struct arm64_ftr_bits *ftrp;
> struct arm64_ftr_reg *reg = get_arm64_ftr_reg(sys_reg);
>
> - BUG_ON(!reg);
> -
> for
On Thu, Apr 23, 2020 at 09:56:56PM +0800, Zhenyu Ye wrote:
> This patch uses the cleared_* in struct mmu_gather to set the
> TTL field in flush_tlb_range().
>
> Signed-off-by: Zhenyu Ye
Reviewed-by: Catalin Marinas
On Mon, May 25, 2020 at 03:19:42PM +0800, Zhenyu Ye wrote:
> On 2020/5/22 23:42, Catalin Marinas wrote:
> > On Thu, Apr 23, 2020 at 09:56:55PM +0800, Zhenyu Ye wrote:
> >> diff --git a/mm/pgtable-generic.c b/mm/pgtable-generic.c
> >> index 3d7c01e76efc..3eff199d3507 1
On Mon, May 25, 2020 at 05:22:23AM +0530, Anshuman Khandual wrote:
> On 05/21/2020 10:29 PM, Catalin Marinas wrote:
> > On Thu, May 21, 2020 at 05:22:15PM +0100, Will Deacon wrote:
> >> On Thu, May 21, 2020 at 08:45:38AM +0530, Anshuman Khandual wrote:
> >>> The exist
On Mon, May 25, 2020 at 07:24:01PM +0800, Keqian Zhu wrote:
> diff --git a/arch/arm64/include/asm/pgtable-prot.h
> b/arch/arm64/include/asm/pgtable-prot.h
> index 1305e28225fc..f9910ba2afd8 100644
> --- a/arch/arm64/include/asm/pgtable-prot.h
> +++ b/arch/arm64/include/asm/pgtable-prot.h
> @@
slots) {
> + /* It will be freed separately in free_handle(). */
> + kmemleak_not_leak(slots);
> memset(slots->slot, 0, sizeof(slots->slot));
> slots->pool = (unsigned long)pool;
> rwlock_init(>lock);
Acked-
Hi Linus,
Please pull the arm64 fixes below. Thanks.
The following changes since commit d51c214541c5154dda3037289ee895ea3ded5ebd:
arm64: fix the flush_icache_range arguments in machine_kexec (2020-05-11
12:02:14 +0100)
are available in the Git repository at:
On Fri, May 15, 2020 at 04:36:26PM +0200, Christoph Hellwig wrote:
> ARM64 needs almost no cache flushing routines of its own. Rely on
> asm-generic/cacheflush.h for the defaults.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Catalin Marinas
On Thu, Apr 23, 2020 at 09:56:54PM +0800, Zhenyu Ye wrote:
> From: "Peter Zijlstra (Intel)"
>
> tlb_flush_{pte|pmd|pud|p4d}_range() adjust the tlb->start and
> tlb->end, then set corresponding cleared_*.
>
> Signed-off-by: Peter Zijlstra (Intel)
> Signed-
LL(47, 44)
> +
> +#define __tlbi_level(op, addr, level)
> \
> + do {\
Nitpick: move "do {" on the same line as __tlbi_level() to reduce the
indentation levels of the whole block.
Reviewed-by: Catalin Marinas
el of page table walk
> holding the leaf entry for the address being invalidated.
>
> Let's detect the feature for now. Further patches will implement
> its actual usage.
>
> Signed-off-by: Marc Zyngier
> Signed-off-by: Zhenyu Ye
Reviewed-by: Catalin Marinas
On Thu, Apr 23, 2020 at 09:56:53PM +0800, Zhenyu Ye wrote:
> @@ -190,8 +196,8 @@ static inline void flush_tlb_page_nosync(struct
> vm_area_struct *vma,
> unsigned long addr = __TLBI_VADDR(uaddr, ASID(vma->vm_mm));
>
> dsb(ishst);
> - __tlbi(vale1is, addr);
> -
On Thu, Apr 23, 2020 at 09:56:55PM +0800, Zhenyu Ye wrote:
> diff --git a/mm/pgtable-generic.c b/mm/pgtable-generic.c
> index 3d7c01e76efc..3eff199d3507 100644
> --- a/mm/pgtable-generic.c
> +++ b/mm/pgtable-generic.c
> @@ -101,6 +101,28 @@ pte_t ptep_clear_flush(struct vm_area_struct *vma,
>
On Thu, May 21, 2020 at 05:22:15PM +0100, Will Deacon wrote:
> On Thu, May 21, 2020 at 08:45:38AM +0530, Anshuman Khandual wrote:
> > On 05/20/2020 11:09 PM, Will Deacon wrote:
> > > On Wed, May 20, 2020 at 04:47:11PM +0100, Catalin Marinas wrote:
> > >> On Wed, Ma
On Mon, May 18, 2020 at 08:21:02PM +0800, Zhenyu Ye wrote:
> On 2020/5/14 23:28, Catalin Marinas wrote:
> > On Tue, Apr 14, 2020 at 07:28:35PM +0800, Zhenyu Ye wrote:
> >> + }
> >> + scale++;
> >> + range_size >>= TLB_RANGE_MA
> an argument 'failsafe' that provides required switch between callers based
> > on whether they could proceed or not.
> >
> > Cc: Catalin Marinas
> > Cc: Will Deacon
> > Cc: Suzuki K Poulose
> > Cc: Mark Brown
> > Cc: linux-arm-ker...@lists
uld proceed or not.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Suzuki K Poulose
> Cc: Mark Brown
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
>
> Signed-off-by: Anshuman Khandual
BTW, there should be no empty line between the Cc
On Wed, May 20, 2020 at 11:03:30AM +0100, Sudeep Holla wrote:
> On Tue, May 19, 2020 at 01:07:27PM +0100, Catalin Marinas wrote:
> > On Mon, May 18, 2020 at 12:41:20PM +0100, Will Deacon wrote:
> > > On Fri, May 15, 2020 at 06:22:53PM -0400, Keno Fischer wrote:
> >
On Mon, May 18, 2020 at 12:41:20PM +0100, Will Deacon wrote:
> On Fri, May 15, 2020 at 06:22:53PM -0400, Keno Fischer wrote:
> > Quoth the man page:
> > ```
> >If the tracee was restarted by PTRACE_SYSCALL or PTRACE_SYSEMU, the
> >tracee enters syscall-enter-stop just prior to
Hi Linus,
Please pull the arm64 fix below. Thanks.
The following changes since commit 027d0c7101f50cf03aeea9eebf484afd4920c8d3:
arm64: hugetlb: avoid potential NULL dereference (2020-05-07 09:24:15 +0100)
are available in the Git repository at:
Hi Zhenyu,
On Tue, Apr 14, 2020 at 07:28:35PM +0800, Zhenyu Ye wrote:
> diff --git a/arch/arm64/include/asm/tlb.h b/arch/arm64/include/asm/tlb.h
> index b76df828e6b7..3a1816770bd1 100644
> --- a/arch/arm64/include/asm/tlb.h
> +++ b/arch/arm64/include/asm/tlb.h
> @@ -38,7 +38,12 @@ static inline
On Tue, May 12, 2020 at 02:09:30PM -0400, Qian Cai wrote:
>
>
> > On May 12, 2020, at 10:15 AM, Catalin Marinas
> > wrote:
> >
> > In this case it uses kref_get() to increment the refcount. We could add
> > a kmemleak_add_trace() which allocates a new
On Mon, May 11, 2020 at 07:43:30AM -0400, Qian Cai wrote:
> On May 11, 2020, at 7:15 AM, Michael Ellerman wrote:
> > There is kmemleak_alloc_phys(), which according to the docs can be used
> > for tracking a phys address.
> >
> > Did you try that?
>
> Catalin, feel free to give your thoughts
On Sun, May 10, 2020 at 05:27:41PM -0400, Qian Cai wrote:
> On May 9, 2020, at 5:44 AM, Catalin Marinas wrote:
> > On Thu, May 07, 2020 at 01:29:04PM -0400, Qian Cai wrote:
> >> On May 7, 2020, at 1:16 PM, Catalin Marinas
> >> wrote:
> >>> I don
On Mon, May 11, 2020 at 09:15:55PM +1000, Michael Ellerman wrote:
> Qian Cai writes:
> > kvmppc_pmd_alloc() and kvmppc_pte_alloc() allocate some memory but then
> > pud_populate() and pmd_populate() will use __pa() to reference the newly
> > allocated memory. The same is in
On Mon, May 11, 2020 at 08:51:15AM +0100, Will Deacon wrote:
> On Sun, May 10, 2020 at 09:54:41AM +0200, Christoph Hellwig wrote:
> > The second argument is the end "pointer", not the length.
> >
> > Signed-off-by: Christoph Hellwig
> > ---
> > arch/arm64/kernel/machine_kexec.c | 1 +
> > 1
On Thu, May 07, 2020 at 01:29:04PM -0400, Qian Cai wrote:
> On May 7, 2020, at 1:16 PM, Catalin Marinas wrote:
> > I don't mind adding additional tracking info if it helps with debugging.
> > But if it's for improving false positives, I'd prefer to look deeper
> > into figur
On Wed, May 06, 2020 at 12:22:37PM -0400, Qian Cai wrote:
> What do you think about adding some aux call traces for kmemleak in
> general? For example, if the tracking object is a task struct, it
> would save call traces for the first and last call of both
> get_task_struct() and
On Wed, May 06, 2020 at 10:40:19AM -0700, Paul E. McKenney wrote:
> On Wed, May 06, 2020 at 12:22:37PM -0400, Qian Cai wrote:
> > == call_rcu() leaks ==
> > Another issue that might be relevant is that it seems sometimes,
> > kmemleak will give a lot of false positives (hundreds) because the
> >
Hi Linus,
Please pull the arm64 fix below. Thanks.
The following changes since commit 1578e5d03112e3e9d37e1c4d95b6dfb734c73955:
arm64: vdso: Add -fasynchronous-unwind-tables to cflags (2020-04-30 18:35:32
+0100)
are available in the Git repository at:
Hi Linus,
Please pull the arm64 fix below. Thanks.
The following changes since commit 6a8b55ed4056ea5559ebe4f6a4b247f627870d4c:
Linux 5.7-rc3 (2020-04-26 13:51:02 -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, Apr 29, 2020 at 08:52:25PM +0800, Chen, Rong A wrote:
> On 4/29/2020 11:28 AM, Anshuman Khandual wrote:
> > On 04/28/2020 02:51 PM, Catalin Marinas wrote:
> > > On Tue, Apr 28, 2020 at 04:41:11AM -0400, Qian Cai wrote:
> > > > On Apr 28, 2020, at 1:54 AM, Ans
On Tue, Apr 28, 2020 at 04:41:11AM -0400, Qian Cai wrote:
> On Apr 28, 2020, at 1:54 AM, Anshuman Khandual
> wrote:
> > That is true. There is a slight change in the rules, making it explicit yes
> > only when both ARCH_HAS_DEBUG_VM_PGTABLE and DEBUG_VM are enabled.
> >
> > +config
On Fri, Oct 11, 2019 at 08:26:32AM +0530, Anshuman Khandual wrote:
> On 10/10/2019 05:04 PM, Catalin Marinas wrote:
> > Mark Rutland mentioned at some point that, as a preparatory patch to
> > this series, we'd need to make sure we don't hot-remove memory already
> > given
On Thu, Oct 17, 2019 at 04:39:23PM -0500, Jeremy Linton wrote:
> On 10/11/19 8:54 AM, Mark Rutland wrote:
> > On Fri, Oct 11, 2019 at 02:33:43PM +0100, Marc Zyngier wrote:
> > > On Fri, 11 Oct 2019 11:50:11 +0100
> > > Mark Rutland wrote:
> > > > On Fri, Oct 11, 2019 at 11:19:00AM +0530, Sai
On Wed, Oct 16, 2019 at 07:47:14AM -0700, Nathan Chancellor wrote:
> When building arm64 allnoconfig, CONFIG_ZONE_DMA and CONFIG_ZONE_DMA32
> get disabled so there is a warning about max_dma being unused.
>
> ../arch/arm64/mm/init.c:215:16: warning: unused variable 'max_dma'
> [-Wunused-variable]
On Tue, Oct 15, 2019 at 08:11:08PM -0700, Nathan Chancellor wrote:
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 44f07fdf7a59..359c3b08b968 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -212,7 +212,9 @@ static void __init zone_sizes_init(unsigned long
On Tue, Oct 15, 2019 at 01:18:34AM +0100, Will Deacon wrote:
> On Fri, Oct 11, 2019 at 10:09:35PM +0800, Jia He wrote:
> > When we tested pmdk unit test vmmalloc_fork TEST1 in arm64 guest, there
> > will be a double page fault in __copy_from_user_inatomic of cow_user_page.
> >
> > As told by
fallback
> for free_initmem() and some other platforms overriding it.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Mark Rutland
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Anshuman Khandual
Queued for 5.5. Thanks.
--
Catalin
On Sat, Sep 28, 2019 at 11:02:26AM +0300, Mike Rapoport wrote:
> From: Mike Rapoport
>
> arm64 calls memblock_free() for the initrd area in its implementation of
> free_initrd_mem(), but this call has no actual effect that late in the boot
> process. By the time initrd is freed, all the reserved
On Wed, Oct 02, 2019 at 10:06:11AM +0100, Marc Zyngier wrote:
> This is a very late update on [1], fixing the 32bit compilation issue that
> was present in v2, and adding an extra message in the kernel log to find out
> what is going on.
>
> [1]
On Mon, Oct 14, 2019 at 08:57:41AM -0700, Linus Torvalds wrote:
> On Mon, Oct 14, 2019 at 12:03 AM Catalin Marinas
> wrote:
> > Linus, could you please merge the patch above? I can send it again if
> > it's easier.
>
> I took it.
Thanks.
> Generally I prefer hav
On Mon, Oct 14, 2019 at 07:50:21AM -0400, Theodore Y. Ts'o wrote:
> On Mon, Oct 14, 2019 at 08:03:14AM +0100, Catalin Marinas wrote:
> > Thanks for the report. I have a fix already:
> >
> > http://lkml.kernel.org/r/20191004134624.46216-1-catalin.mari...@arm.com
> >
Hi Ted,
On Sun, Oct 13, 2019 at 10:26:33PM -0400, Theodore Y. Ts'o wrote:
> Commit c566586818 ("mm: kmemleak: use the memory pool for early
> allocations") causes my test kernels to fail to boot on using both kvm
> and using Google Compute Engine. A git bisect localized it to
> c566586818, and I
On Fri, Oct 11, 2019 at 01:16:36AM +, Justin He (Arm Technology China)
wrote:
> From: Catalin Marinas
> > On Wed, Oct 09, 2019 at 04:42:43PM +0800, Jia He wrote:
> > > + u64 mmfr1 = read_cpuid(ID_AA64MMFR1_EL1);
> > > +
> > > + return !!
kyoung. Also, the parameter is
> changed because vmf should be passed to cow_user_page()
>
> Add a WARN_ON_ONCE when __copy_from_user_inatomic() returns error
> in case there can be some obscure use-case (by Kirill).
>
> [1] https://github.com/pmem/pmdk/tree/master/src/test/vm
pu_has_hw_af().
>
> Signed-off-by: Jia He
> Suggested-by: Suzuki Poulose
> Reviewed-by: Catalin Marinas
I don't think I reviewed this version of the patch.
> diff --git a/arch/arm64/include/asm/cpufeature.h
> b/arch/arm64/include/asm/cpufeature.h
> index 9cde5d2e768f.
for (i = 0; i < PTRS_PER_PTE; i++) {
> + if (!pte_none(READ_ONCE(ptep[i])))
> + return;
> + }
We could do with a comment for this loop along the lines of:
Check whether we can free the pte page if the rest of the
entries are empty.
Hi Murphy,
On Sun, Sep 29, 2019 at 05:56:59PM +0800, Murphy Zhou wrote:
> Now if DEFAULT_OFF set to y, kmemleak_init will start the cleanup_work
> workqueue. Then late_init call will set kmemleak_initialized to 1, the
> cleaup workqueue will try to do cleanup, triggering:
>
> [24.738773]
On Tue, Oct 08, 2019 at 10:06:26AM +0530, Anshuman Khandual wrote:
> On 10/07/2019 07:47 PM, Catalin Marinas wrote:
> > On Mon, Sep 23, 2019 at 11:13:45AM +0530, Anshuman Khandual wrote:
> >> The arch code for hot-remove must tear down portions of the linear map and
> >
On Mon, Sep 23, 2019 at 11:13:45AM +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 page
> tables mapping these regions must be freed, and when sparse vmemmap is in
> use
On Sat, Oct 05, 2019 at 01:08:43PM +1000, Alexey Kardashevskiy wrote:
> On 03/10/2019 18:41, Catalin Marinas wrote:
> > On Thu, Oct 03, 2019 at 04:13:07PM +1000, Alexey Kardashevskiy wrote:
> >> On 13/08/2019 02:06, Catalin Marinas wrote:
> >>> Object scan a
On Fri, Oct 04, 2019 at 11:37:22AM +0100, Will Deacon wrote:
> On Thu, Oct 03, 2019 at 12:12:07PM +0100, Julien Grall wrote:
> > This patch fix an issue related to exposing the FRINT capability to
> > userspace (see patch #1). The rest is documentation update.
> >
> For patches 2-4:
>
> Acked-by:
stream::out, and the
> generic radix tree uses raw pages which aren't tracked by kmemleak.
>
> Fix this by adding the kmemleak hooks to the generic radix tree code.
>
> Reported-by: syzbot+7f3b6b106be8dcdcd...@syzkaller.appspotmail.com
> Signed-off-by: Eric Biggers
Reviewed-by: Catalin Marinas
it already has the
struct kmemleak_object pointer.
Fixes: c5665868183f ("mm: kmemleak: use the memory pool for early allocations")
Reported-by: Alexey Kardashevskiy
Reported-by: Marc Dionne
Cc: Andrew Morton
Signed-off-by: Catalin Marinas
---
mm/kmemleak.c | 30 +---
On Wed, Oct 02, 2019 at 03:41:51PM +0100, Vincenzo Frascino wrote:
> Cc: Will Deacon
> Cc: Catalin Marinas
> Reported-by: Will Deacon
> Signed-off-by: Vincenzo Frascino
> Reviewed-by: Catalin Marinas
> Tested-by: Catalin Marinas
If you changed the patch, please drop
On Thu, Oct 03, 2019 at 05:00:41PM +0100, Catalin Marinas wrote:
> On Wed, Oct 02, 2019 at 03:41:51PM +0100, Vincenzo Frascino wrote:
> > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> > index 84a3d502c5a5..dfa6a5cb99e4 100644
> > --- a/arch/arm64/Makefile
> >
On Wed, Oct 02, 2019 at 07:26:51PM -0300, Marc Dionne wrote:
> 5.4-rc1 hangs early on boot for me; the stack trace that I could
> manage to see on screen suggested something kmemleak related, and it
> was fairly quick to bisect it down to commit c5665868183f ("mm:
> kmemleak: use the memory pool
On Wed, Oct 02, 2019 at 02:22:48PM -0700, Mark Salyzyn wrote:
> Some drivers can not be turned into a module without cma_alloc and
> cma_release exported. Examples include ion, and we also found some
> out of tree infiniband and camera drivers.
>
> Signed-off-by: Mark Salyzyn
> Cc:
On Thu, Oct 03, 2019 at 04:13:07PM +1000, Alexey Kardashevskiy wrote:
> On 13/08/2019 02:06, Catalin Marinas wrote:
> > Object scan areas are an optimisation aimed to decrease the false
> > positives and slightly improve the scanning time of large objects known
> > to onl
On Wed, Sep 11, 2019 at 08:25:42PM +0200, Nicolas Saenz Julienne wrote:
> Nicolas Saenz Julienne (4):
> arm64: mm: use arm64_dma_phys_limit instead of calling
> max_zone_dma_phys()
> arm64: rename variables used to calculate ZONE_DMA32's size
> arm64: use both ZONE_DMA and ZONE_DMA32
>
On Tue, Oct 01, 2019 at 03:43:54PM +0100, Will Deacon wrote:
> > On Thu, Sep 26, 2019 at 10:43:38PM +0100, Vincenzo Frascino wrote:
> > > +config COMPATCC_IS_ARM_GCC
> > > + def_bool $(success,$(COMPATCC) --version | head -n 1 | grep -q
> > > "arm-.*-gcc")
[...]
> My point
On Tue, Oct 01, 2019 at 02:14:23PM +0100, Will Deacon wrote:
> On Thu, Sep 26, 2019 at 10:43:38PM +0100, Vincenzo Frascino wrote:
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 37c610963eee..0e5beb928af5 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@
64: vdso32: Remove jump label config option in Makefile
You can add this as well:
Tested-by: Catalin Marinas
On Thu, Sep 26, 2019 at 10:43:42PM +0100, Vincenzo Frascino wrote:
> The jump labels are not used in vdso32 since it is not possible to run
> runtime patching on them.
>
> Remove the configuration option from the Makefile.
>
> Cc: Will Deacon
> Cc: Catalin Marinas
>
his patch.
With this note, I'm fine with the patch.
Reviewed-by: Catalin Marinas
cts if binutils supports those
> instructions and configure the kernel accordingly.
>
> Cc: Will Deacon
> Cc: Catalin Marinas
> Signed-off-by: Vincenzo Frascino
Reviewed-by: Catalin Marinas
nux-gnueabihf
Another nitpick, add a '-' at the end of 'gnueabihf'.
Otherwise:
Reviewed-by: Catalin Marinas
On Thu, Sep 26, 2019 at 02:38:03PM +0100, Vincenzo Frascino wrote:
> arch/arm64/kernel/vdso32/Makefile| 9 +
Could you please also remove the unnecessary gcc-goto.sh check in this
file? We don't use jump labels in the vdso (can't run-time patch them).
I found it while forcing
On Thu, Sep 26, 2019 at 08:47:18AM +0100, Catalin Marinas wrote:
> On Thu, Sep 26, 2019 at 01:06:50AM +0100, Vincenzo Frascino wrote:
> > On 9/25/19 6:08 PM, Catalin Marinas wrote:
> > > On Wed, Sep 25, 2019 at 09:53:16AM -0700, Nick Desaulniers wrote:
> > >> O
On Thu, Sep 26, 2019 at 02:38:01PM +0100, Vincenzo Frascino wrote:
> this patch series is meant to address the various compilation issues you
> reported about arm64 vdso32. (This time for real I hope ;))
>
> Please let me know if there is still something missing.
Apart from the diff I posted and
On Thu, Sep 26, 2019 at 12:02:38PM +0100, Vincenzo Frascino wrote:
> On 9/26/19 11:56 AM, Vincenzo Frascino wrote:
> > On 9/26/19 9:06 AM, Catalin Marinas wrote:
> >> Has CONFIG_CROSS_COMPILE_COMPAT_VDSO actually been removed from
> >> lib/vdso/Kconfig? (I haven't che
On Thu, Sep 26, 2019 at 02:38:04PM +0100, Vincenzo Frascino wrote:
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index b61b50bf68b1..cfa9cd87af14 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -228,11 +228,16 @@
On Thu, Sep 26, 2019 at 01:22:01PM +0100, Vincenzo Frascino wrote:
> On 9/26/19 11:56 AM, Vincenzo Frascino wrote:
> > On 9/26/19 9:06 AM, Catalin Marinas wrote:
> >> Now, could we not generate a COMPATCC in the Makefile and use
> >> $(COMPATCC) here instead of
On Thu, Sep 26, 2019 at 02:38:02PM +0100, Vincenzo Frascino wrote:
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 37c610963eee..13e2d2e16af7 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -110,7 +110,7 @@ config ARM64
> select GENERIC_STRNLEN_USER
>
On Thu, Sep 26, 2019 at 02:38:03PM +0100, Vincenzo Frascino wrote:
> diff --git a/arch/arm64/Kbuild b/arch/arm64/Kbuild
> index d6465823b281..75cf8c796d0e 100644
> --- a/arch/arm64/Kbuild
> +++ b/arch/arm64/Kbuild
> @@ -4,3 +4,9 @@ obj-$(CONFIG_NET) += net/
> obj-$(CONFIG_KVM)+= kvm/
>
o a side effect of
> rebase.
>
> Remove the file again.
>
> Cc: Will Deacon
> Cc: Catalin Marinas
>
> Signed-off-by: Vincenzo Frascino
Nitpick: don't leave a space between the Cc and the Sob lines, it all
comes as a single block.
Acked-by: Catalin Marinas
On Thu, Sep 26, 2019 at 07:03:52AM +0100, Vincenzo Frascino wrote:
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index b61b50bf68b1..b1c8c43234c5 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -228,11 +228,16 @@
On Thu, Sep 26, 2019 at 07:03:51AM +0100, Vincenzo Frascino wrote:
> diff --git a/arch/arm64/include/asm/vdso/compat_barrier.h
> b/arch/arm64/include/asm/vdso/compat_barrier.h
> index fb60a88b5ed4..3fd8fd6d8fc2 100644
> --- a/arch/arm64/include/asm/vdso/compat_barrier.h
> +++
On Thu, Sep 26, 2019 at 07:03:50AM +0100, Vincenzo Frascino wrote:
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 37c610963eee..afe8c948b493 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -110,7 +110,7 @@ config ARM64
> select GENERIC_STRNLEN_USER
>
On Thu, Sep 26, 2019 at 01:06:50AM +0100, Vincenzo Frascino wrote:
> On 9/25/19 6:08 PM, Catalin Marinas wrote:
> > On Wed, Sep 25, 2019 at 09:53:16AM -0700, Nick Desaulniers wrote:
> >> On Wed, Sep 25, 2019 at 6:09 AM Catalin Marinas
> >> wrote:
> >>&
On Wed, Sep 25, 2019 at 09:53:16AM -0700, Nick Desaulniers wrote:
> On Wed, Sep 25, 2019 at 6:09 AM Catalin Marinas
> wrote:
> >
> > The compat vDSO building requires a cross-compiler than produces AArch32
> > binaries, defined via CONFIG_CROSS_COMPILE_COMPAT_VDSO or the
s error
> in case there can be some obscure use-case.(by Kirill)
>
> [1] https://github.com/pmem/pmdk/tree/master/src/test/vmmalloc_fork
>
> Signed-off-by: Jia He
> Reported-by: Yibo Cai
Reviewed-by: Catalin Marinas
> mm/memory.c | 99
601 - 700 of 5901 matches
Mail list logo
