On 18/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Catalin Marinas <[EMAIL PROTECTED]> wrote:
> I could also use a simple allocator based on alloc_pages [...]
> [...] It could be so simple that it would never need to free any
> pages, just grow the size as required and re
On 17/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
it would be nice to record 1) the jiffies value at the time of
allocation, 2) the PID and the comm of the task that did the allocation.
The jiffies timestamp would be useful to see the age of the allocation,
and the PID/comm is useful for contex
On 27/12/06, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
On Wed, 2006-12-27 at 16:14 +, Catalin Marinas wrote:
> On 17/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > it would be nice to record 1) the jiffies value at the time of
> > allocation, 2) the PID and th
On 27/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Catalin Marinas <[EMAIL PROTECTED]> wrote:
> On 17/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >it would be nice to record 1) the jiffies value at the time of
> >allocation, 2) the PID and the comm of
On 27/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> The pure per-CPU design would have to embedd the CPU ID the object is
> attached to into the allocated object. If that is not feasible then
> only the global hash remains i think.
embedding the info sh
On 28/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Catalin Marinas <[EMAIL PROTECTED]> wrote:
> >memleak info is at a negative offset from the allocated pointer. I.e.
> >that if kmalloc() returns 'ptr', the memleak info could be at
> >ptr-sizeof(memle
d '--author' option to 'series'
Acknowledgements (generated with 'git shortlog'):
Catalin Marinas (10):
Make StGIT aware of the STGIT_DEBUG_LEVEL environment variable
Fix the behaviour when there is no user information configured
Allow importing mbox file
than stgitrc
* Patch ranges can be specified for 'export'
* '--missing' option for 'series' to list the patches on a branch
which are missing in current
* StGIT bash completion script
* Bug fixes
Acknowledgements (generated with 'git shortlog')
Hi,
Kmemleak found a possible memory leak in piix_init_one() in
drivers/ata/ata_piix.c. This only appeared after 2.6.19, maybe caused
by the recent patches to this area. Kmemleak cannot find any track of
the kzalloc'ed piix_host_priv structure allocated in the above
function and reports it. The a
Hi,
After 2.6.19, kmemleak reports several (few tens) orphan blocks
allocated in bio_alloc_bioset() via __blk_rq_map_user() in
block/ll_rq_blk.c. I think these came with commit
0e75f9063f5c55fb0b0b546a7c356f8ec186825e (support larger block pc
requests). The allocation backtrace for the "bio" stru
It makes more sense to end the stack trace with ULONG_MAX only if
nr_entries < max_entries. Otherwise, we lose one entry in the long
stack traces and cannot know whether the trace was complete or not.
Signed-off-by: Catalin Marinas <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/stacktrace
On 09/12/06, Catalin Marinas <[EMAIL PROTECTED]> wrote:
unreferenced object 0xdd9162b0 (size 64):
[] kmem_cache_alloc
[] mempool_alloc_slab
[] mempool_alloc
[] bio_alloc_bioset
[] bio_alloc
[] bio_copy_user
[] __blk_rq_map_user
[] blk_rq_map_user
[] sg_io
[] scsi_cmd
Tejun,
On 11/12/06, Tejun Heo <[EMAIL PROTECTED]> wrote:
piix_init_one() allocates host private data which should be freed by
piix_host_stop(). ich_pata_ops wasn't converted to piix_host_stop()
while merging, leaking 4 bytes on driver detach. Fix it.
I tried your patch last night but the lea
On 13/12/06, Catalin Marinas <[EMAIL PROTECTED]> wrote:
On 11/12/06, Tejun Heo <[EMAIL PROTECTED]> wrote:
> piix_init_one() allocates host private data which should be freed by
> piix_host_stop(). ich_pata_ops wasn't converted to piix_host_stop()
> while merging,
This patch adds a loadable module that deliberately leaks memory. It
is used for testing various memory leaking scenarios.
Signed-off-by: Catalin Marinas <[EMAIL PROTECTED]>
---
lib/Kconfig.debug | 11 ++
mm/Makefile |1 +
mm/memleak-test.c
This patch handles the kmemleak operations needed for modules loading so
that memory allocations from inside a module are properly tracked.
Signed-off-by: Catalin Marinas <[EMAIL PROTECTED]>
---
kernel/module.c | 56 +++
1 files chang
This patch adds the callbacks to memleak_(alloc|free) functions from
kmalloc/kfree, kmem_cache_(alloc|free), vmalloc/vfree etc.
Signed-off-by: Catalin Marinas <[EMAIL PROTECTED]>
---
include/linux/slab_def.h |6 ++
mm/page_alloc.c |2 ++
mm/slab.c
This patch adds the kmemleak-related entries to the vmlinux.lds.S
linker script.
Signed-off-by: Catalin Marinas <[EMAIL PROTECTED]>
---
arch/i386/kernel/vmlinux.lds.S |6 ++
include/asm-i386/thread_info.h | 18 --
2 files changed, 22 insertions(+), 2 deletions(-)
Signed-off-by: Catalin Marinas <[EMAIL PROTECTED]>
---
Documentation/kmemleak.txt | 161
1 files changed, 161 insertions(+), 0 deletions(-)
diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt
new file mode 100644
index 0
There are allocations for which the main pointer cannot be found but
they are not memory leaks. This patch fixes some of them. For more
information on false positives, see Documentation/kmemleak.txt.
Signed-off-by: Catalin Marinas <[EMAIL PROTECTED]>
---
arch/i386/kernel/s
this feature introduces an
overhead to memory allocations.
Signed-off-by: Catalin Marinas <[EMAIL PROTECTED]>
---
include/linux/kernel.h |7
include/linux/memleak.h | 111
init/main.c |3
lib/Kconfig.debug | 114
mm/Makefile |1
m
This patch adds the CONFIG_DEBUG_KEEP_INIT option which preserves the
.init.text section after initialization. Memory leaks happening during this
phase can be more easily tracked.
Signed-off-by: Catalin Marinas <[EMAIL PROTECTED]>
---
include/linux/init.h |5 +
lib/Kconfig
This series of patches represent version 0.13 of the kernel memory
leak detector. See the Documentation/kmemleak.txt file for a more
detailed description. The patches are downloadable from (the whole
patch or the broken-out series) http://www.procode.org/kmemleak/
What's new in this version:
- up
This patch adds the kmemleak-related entries to the vmlinux.lds.S
linker script.
Signed-off-by: Catalin Marinas <[EMAIL PROTECTED]>
---
arch/arm/kernel/vmlinux.lds.S |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/
Signed-off-by: Catalin Marinas <[EMAIL PROTECTED]>
---
MAINTAINERS |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index dea5b2a..fe186b4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1746,6 +1746,12 @@ L: [EMAIL PROTECT
Hi Ingo,
On 16/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
FYI, i'm working on integrating kmemleak into -rt. Firstly, i needed the
fixes below when applying it ontop of 2.6.19-rt15.
Do you need these fixes to avoid a compiler error? If yes, this is
caused by a bug in gcc-4.x. The kmemleak c
On 17/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
one more thing: after bootup i need to access the /debug/memleak file
twice to get any output from it - is that normal? The first 'cat
/debug/memleak' gives no output (but there's the usual scanning delay,
so memleak does do its work).
Yes, th
On 17/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
it would also be nice to have more information than this:
unreferenced object 0xf76f5af8 (size 512):
[] memleak_alloc
[] kmem_cache_zalloc
[] probe_hwif
[] probe_hwif_init_with_fixup
[] ide_setup_pci_device
[] amd74xx_probe
[] i
On 17/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Catalin Marinas <[EMAIL PROTECTED]> wrote:
> Do you need these fixes to avoid a compiler error? If yes, this is
> caused by a bug in gcc-4.x. The kmemleak container_of macro has
> protection for non-constant offsets passe
On 18/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Catalin Marinas <[EMAIL PROTECTED]> wrote:
> I could also use a simple allocator based on alloc_pages since
> kmemleak doesn't track pages. [...]
actually, i'm quite sure we want to track pages later on too, any
On 18/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Catalin Marinas <[EMAIL PROTECTED]> wrote:
> >> [...] It could be so simple that it would never need to free any
> >> pages, just grow the size as required and reuse the freed memleak
> >> object
On 18/12/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Catalin Marinas <[EMAIL PROTECTED]> wrote:
> >at freeing we only have to look up the tree belonging to object->cpu.
>
> At freeing, kmemleak only gets a pointer value which has to be looked
> up in the ha
dev->devt_attr is allocated in device_add() but it is never freed in
device_del() in the drivers/base/core.c file (reported by kmemleak).
Signed-off-by: Catalin Marinas <[EMAIL PROTECTED]>
---
I sent this patch before for 2.6.18 but it probably got lost. Anyway,
I found the bug ag
Signed-off-by: Catalin Marinas <[EMAIL PROTECTED]>
---
Documentation/kmemleak.txt | 161
1 files changed, 161 insertions(+), 0 deletions(-)
diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt
new file mode 100644
index 0
This series of patches represent version 0.12 of the kernel memory
leak detector. See the Documentation/kmemleak.txt file for a more
detailed description. The patches are downloadable from (the whole
patch or the broken-out series) http://www.procode.org/kmemleak/
What's new in this version:
- up
This patch adds the callbacks to memleak_(alloc|free) functions from
kmalloc/kfree, kmem_cache_(alloc|free), vmalloc/vfree etc.
Signed-off-by: Catalin Marinas <[EMAIL PROTECTED]>
---
include/linux/slab.h |6 ++
mm/page_alloc.c |2 ++
mm/slab.c
This patch handles the kmemleak operations needed for modules loading so
that memory allocations from inside a module are properly tracked.
Signed-off-by: Catalin Marinas <[EMAIL PROTECTED]>
---
kernel/module.c | 56 +++
1 files chang
would introduce an overhead to memory allocations.
Signed-off-by: Catalin Marinas <[EMAIL PROTECTED]>
---
include/linux/kernel.h |7
include/linux/memleak.h | 111
init/main.c |3
lib/Kconfig.debug | 114
mm/Makefile |1
m
This patch modifies the vmlinux.lds.S script and adds the backtrace support
for i386 to be used with kmemleak.
Signed-off-by: Catalin Marinas <[EMAIL PROTECTED]>
---
arch/i386/kernel/vmlinux.lds.S |4
include/asm-i386/thread_info.h | 10 +-
2 files changed, 13 inse
Signed-off-by: Catalin Marinas <[EMAIL PROTECTED]>
---
MAINTAINERS |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e182992..995486d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1722,6 +1722,12 @@ L: [EMAIL PROTECT
There are allocations for which the main pointer cannot be found but they
are not memory leaks. This patch fixes some of them.
Signed-off-by: Catalin Marinas <[EMAIL PROTECTED]>
---
arch/i386/kernel/setup.c |2 ++
drivers/base/platform.c|3 +++
driver
This patch modifies the vmlinux.lds.S script and adds the backtrace support
for ARM to be used with kmemleak.
Signed-off-by: Catalin Marinas <[EMAIL PROTECTED]>
---
arch/arm/kernel/vmlinux.lds.S |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/
This patch adds the CONFIG_DEBUG_KEEP_INIT option which preserves the
.init.text section after initialization. Memory leaks happening during this
phase can be more easily tracked.
Signed-off-by: Catalin Marinas <[EMAIL PROTECTED]>
---
include/linux/init.h |5 +
lib/Kconfig
This patch only contains some very simple testing at the moment. Proper
testing will be needed.
Signed-off-by: Catalin Marinas <[EMAIL PROTECTED]>
---
lib/Kconfig.debug | 11 ++
mm/Makefile |1 +
mm/memleak-test.c | 94 ++
Hi Eric,
I'm trying to track down a kmemleak report (on an ARM platform) which
seems to have appeared with commit
ab521dc0f8e117fd808d3e425216864d60390500. As I'm not familiar with the
TTY layer at all, is it possible that the above commit missed a
put_pid() call on some path?
The /sbin/init app
On 08/03/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
"Catalin Marinas" <[EMAIL PROTECTED]> writes:
> I'm trying to track down a kmemleak report (on an ARM platform) which
> seems to have appeared with commit
> ab521dc0f8e117fd808d3e425216864d60390500
tty->flags = 0;
tty->session = NULL;
tty->pgrp = NULL;
On 08/03/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
"Catalin Marinas" <[EMAIL PROTECTED]> writes:
> The /sbin/init application calls sys_clone() a few times but only one
> leak is rep
On 09/03/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
"Catalin Marinas" <[EMAIL PROTECTED]> writes:
> On 08/03/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> "Catalin Marinas" <[EMAIL PROTECTED]> writes:
>
> I think it'
On 09/03/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
If I can manage to focus on this, it looks like the information I need to
start fixing this.
I had a look at the second leak reported it seems to be caused by the
same proc_set_tty() call but, in this case, there is no
disassociate_tty()
On 13/03/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
"Catalin Marinas" <[EMAIL PROTECTED]> writes:
> void proc_clear_tty(struct task_struct *p)
> {
> + struct tty_struct *tty;
> +
> spin_lock_irq(&p->sighand->siglock)
On 14/03/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
How does this look?
It seems to fix the leak. I looked at the logs and proc_set_tty calls
put_pid twice for pid 245 (the unresolved leak) and get_pid for pid
296, which is later passed to put_pid via do_tty_hangup.
I still get the "erro
On 16/03/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
"Catalin Marinas" <[EMAIL PROTECTED]> writes:
> It seems to fix the leak. I looked at the logs and proc_set_tty calls
> put_pid twice for pid 245 (the unresolved leak) and get_pid for pid
> 296, which
patch makes data[] a zero-size array.
Signed-off-by: Catalin Marinas <[EMAIL PROTECTED]>
---
I came across this when trying to build kmemleak as the modified
container_of macro tries to get the size of the devres.data member and
sizeof cannot be applied to incomplete types.
drivers/base/de
Tejun,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Catalin Marinas wrote:
>> Commit 9ac7849e35f705830f7b016ff272b0ff1f7ff759 adds the devres
>> structure containing a flexible unsigned long long array, with a
>> comment about the guaranteed alignment. According to the gcc
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Catalin Marinas wrote:
>> It sounds to me like the alignment of an incomplete type is not
>> guaranteed (as you can't even enquire about it, though I might be
>> wrong). This is probably dependent on the compiler as well - wit
On Fri, Jul 08, 2016 at 12:35:44PM -0400, David Long wrote:
> From: "David A. Long"
>
> This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes patches,
> first seen in October 2013. This version attempts to address concerns
> raised by reviewers and also fixes problems discovered duri
On Wed, Jul 20, 2016 at 10:46:27AM +0800, Leizhen (ThunderTown) wrote:
> >>>> On 2016/7/8 21:54, Catalin Marinas wrote:
> >>>>> 8<
> >>>>> diff --git a/arch/arm64/mm/flush.c b/arch/arm64/mm/flush.c
> >>>&
On Wed, Jul 20, 2016 at 10:36:08AM +0100, Marc Zyngier wrote:
> On 08/07/16 17:35, David Long wrote:
> > +void __kprobes jprobe_return(void)
> > +{
> > + struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> > +
> > + /*
> > +* Jprobe handler return by entering break exception,
> > +* enco
On Fri, Jul 08, 2016 at 12:35:48PM -0400, David Long wrote:
> +#define MIN_STACK_SIZE(addr) (on_irq_stack(addr, raw_smp_processor_id()) ? \
> + min((unsigned long)IRQ_STACK_SIZE, \
> + IRQ_STACK_PTR(raw_smp_processor_id()) - (addr)) : \
> + min((unsigned long)MAX_STACK_SIZE, \
On Wed, Jul 20, 2016 at 05:09:28PM +0100, Marc Zyngier wrote:
> +static inline unsigned long min_stack_size(unsigned long addr)
> +{
> + unsigned long size;
> + struct kprobe_ctlblk *ctl;
> +
> + if (on_irq_stack(addr, raw_smp_processor_id()))
> + size = IRQ_STACK_PTR(raw_sm
On Wed, Jul 20, 2016 at 05:46:58PM +0100, Marc Zyngier wrote:
> From 0d120f95b3348e1946d8a789c7147f316c27ea6b Mon Sep 17 00:00:00 2001
> From: Marc Zyngier
> Date: Wed, 20 Jul 2016 17:36:42 +0100
> Subject: [PATCH] arm64: kprobes: Fix overflow when saving stack
>
> The MIN_STACK_SIZE macro tries
updated it's
> offset.
>
> Fixes: commit 4b998ff1885eec ("arm64: Delay cpuinfo_store_boot_cpu")
> Cc:
> Cc: Will Deacon
> Cc: Catalin Marinas
> Signed-off-by: Suzuki K Poulose
Applied. Thanks.
--
Catalin
axcpus >= 1, but broke maxcpus = 0.
>
> Fixes: commit 44dbcc93ab67145 ("arm64: Fix behavior of maxcpus=N")
> Cc: Will Deacon
> Cc: Catalin Marinas
> Cc: Mark Rutland
> Cc: James Morse
> Signed-off-by: Suzuki K Poulose
Queued for 4.8, with Mark's comment and a cc stable for 4.7
--
Catalin
On Thu, Jul 21, 2016 at 12:33:36PM -0400, David Long wrote:
> On 07/20/2016 12:09 PM, Marc Zyngier wrote:
> >On 08/07/16 17:35, David Long wrote:
> >>diff --git a/arch/arm64/include/asm/kprobes.h
> >>b/arch/arm64/include/asm/kprobes.h
> >>new file mode 100644
> >>index 000..79c9511
> >>--- /de
On Thu, Jul 21, 2016 at 02:33:52PM -0400, David Long wrote:
> On 07/21/2016 01:23 PM, Marc Zyngier wrote:
> >On 21/07/16 17:33, David Long wrote:
> >>On 07/20/2016 12:09 PM, Marc Zyngier wrote:
> >>>On 08/07/16 17:35, David Long wrote:
> +#define MAX_INSN_SIZE1
> +#defin
I can't find the original post (probably it only went to the
linux-fsdevel list), so replying to Nicholas here:
> On Thu, Jul 21, 2016 at 10:53:37PM -0400, Nicholas Krause wrote:
>> This fixes a memory leak on the error path if the call to
>> security_file_alloc fails to run successfully as detect
have
> elapsed, even though the system is fully initialised.
>
> We can fix this using interruptible sleep and checking if we're
> supposed to stop whenever we wake up (like the rest of the code does).
>
> Signed-off-by: Vegard Nossum
Acked-by: Catalin Marinas
Hi Pratyush,
On Tue, Aug 02, 2016 at 11:00:09AM +0530, Pratyush Anand wrote:
> --- a/arch/arm64/include/asm/debug-monitors.h
> +++ b/arch/arm64/include/asm/debug-monitors.h
> @@ -70,6 +70,9 @@
> #define BRK64_ESR_MASK 0x
> #define BRK64_ESR_KPROBES0x0004
> #define BRK64_OP
On Wed, Sep 21, 2016 at 04:30:47PM +0530, Pratyush Anand wrote:
> On 20/09/2016:05:59:46 PM, Catalin Marinas wrote:
> > On Tue, Aug 02, 2016 at 11:00:09AM +0530, Pratyush Anand wrote:
> > > --- a/arch/arm64/include/asm/thread_info.h
> > > +++ b/arch/arm64/include/asm/th
On Thu, Sep 22, 2016 at 08:53:28AM +0530, Pratyush Anand wrote:
> On 21/09/2016:06:04:04 PM, Catalin Marinas wrote:
> > On Wed, Sep 21, 2016 at 04:30:47PM +0530, Pratyush Anand wrote:
> > > On 20/09/2016:05:59:46 PM, Catalin Marinas wrote:
> > > > > +int arch_uprob
On Tue, Sep 20, 2016 at 11:46:35AM -0700, David Daney wrote:
> From: David Daney
>
> The wq_numa_init() function makes a private CPU to node map by calling
> cpu_to_node() early in the boot process, before the non-boot CPUs are
> brought online. Since the default implementation of cpu_to_node()
ke -jN Image Image.gz"
> would sometimes end up generating bad images where N > 1.
>
> Fix the dependency in arch/arm64/Makefile to avoid the race
> between "make Image" and "make Image.*".
>
> Signed-off-by: Masahiro Yamada
Acked-by: Catalin Marinas
On Wed, Jun 08, 2016 at 02:40:56PM -0700, Yang Shi wrote:
> The upstream commit 1771c6e1a567ea0ba20a4ffe68a1419fd8ef
> ("x86/kasan: instrument user memory access API") added KASAN instrument to
> x86 user memory access API, so added such instrument to ARM64 too.
>
> Define __copy_to/from_user
On Wed, Jun 08, 2016 at 05:49:59PM +0200, Arnd Bergmann wrote:
> On Wednesday, June 8, 2016 1:08:29 PM CEST Catalin Marinas wrote:
> > On Wed, Jun 08, 2016 at 03:53:46PM +0800, Jisheng Zhang wrote:
> > > static int __init arm64_dma_init(void)
> > > {
> > >
On Fri, Sep 23, 2016 at 09:42:30AM +0530, Pratyush Anand wrote:
> On 22/09/2016:05:50:30 PM, Catalin Marinas wrote:
> > On Thu, Sep 22, 2016 at 08:53:28AM +0530, Pratyush Anand wrote:
> > > On 21/09/2016:06:04:04 PM, Catalin Marinas wrote:
> > > > On Wed, Sep 21, 2016
Hi Linus,
Please pull a couple of last-minute arm64 fixes for 4.8. Thanks.
The following changes since commit 3be7988674ab33565700a37b210f502563d932e6:
Linux 4.8-rc7 (2016-09-18 17:27:41 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linu
On Sun, Sep 25, 2016 at 10:32:28PM +0530, Pratyush Anand wrote:
> On Fri, Sep 23, 2016 at 6:35 PM, Catalin Marinas
> wrote:
> > On Fri, Sep 23, 2016 at 09:42:30AM +0530, Pratyush Anand wrote:
> >> On 22/09/2016:05:50:30 PM, Catalin Marinas wrote:
> >> > On Thu,
On Mon, Sep 26, 2016 at 06:33:59PM +0530, Pratyush Anand wrote:
> On 26/09/2016:12:01:59 PM, Catalin Marinas wrote:
> > On Sun, Sep 25, 2016 at 10:32:28PM +0530, Pratyush Anand wrote:
> > > On Fri, Sep 23, 2016 at 6:35 PM, Catalin Marinas
> > > wrote:
> > >
On Wed, Jul 27, 2016 at 06:13:37PM -0400, David Long wrote:
> On 07/27/2016 07:50 AM, Daniel Thompson wrote:
> >On 25/07/16 23:27, David Long wrote:
> >>On 07/25/2016 01:13 PM, Catalin Marinas wrote:
> >>>The problem is that the original design was done on x86 f
On Tue, Sep 06, 2016 at 05:36:18PM -0400, David Long wrote:
> On 09/06/2016 12:11 PM, Catalin Marinas wrote:
> > On Tue, Aug 02, 2016 at 11:00:07AM +0530, Pratyush Anand wrote:
> > > --- a/arch/arm64/kernel/debug-monitors.c
> > > +++ b/arch/arm64/kernel/debug-monito
On Wed, Sep 07, 2016 at 12:59:52PM -0400, Jason Baron wrote:
> On 09/05/2016 01:25 PM, Catalin Marinas wrote:
> > This patch adds static keys transparently for all the cpu_hwcaps
> > features by implementing an array of default-false static keys and
> > enabling th
On Tue, Aug 30, 2016 at 02:35:12PM -0400, Nicholas Krause wrote:
> This fixes a issue in the current locking logic of the function,
> __delete_object where we are trying to attempt to lock the passed
> object structure's spinlock again after being previously held
> elsewhere by the kmemleak code. F
On Wed, Aug 31, 2016 at 09:41:23AM -0400, nick wrote:
> On 2016-08-31 03:54 AM, Catalin Marinas wrote:
> > On Tue, Aug 30, 2016 at 02:35:12PM -0400, Nicholas Krause wrote:
> >> This fixes a issue in the current locking logic of the function,
> >> __delete_object where
On Wed, Aug 31, 2016 at 02:30:40PM +0100, Vladimir Murzin wrote:
> On 30/08/16 10:07, Catalin Marinas wrote:
> > On Tue, Aug 30, 2016 at 02:35:31PM +0800, Kenneth Lee wrote:
> >> (add comment for the previous mail, sorry for the duplication)
> >>
> >> There is n
On Fri, Aug 26, 2016 at 10:22:13AM +0100, Suzuki K. Poulose wrote:
> On 25/08/16 18:26, Catalin Marinas wrote:
> > static inline int __attribute_const__
> >diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> >index 62272eac1352..919b2d0d68ae 10064
On Wed, Aug 24, 2016 at 05:00:50PM +0800, Leizhen (ThunderTown) wrote:
>
>
> On 2016/8/24 1:28, Catalin Marinas wrote:
> > On Mon, Aug 22, 2016 at 12:19:04PM +0800, Leizhen (ThunderTown) wrote:
> >> On 2016/7/20 17:19, Catalin Marinas wrote:
> >>> On W
On Thu, Aug 25, 2016 at 09:42:26AM +0800, Leizhen (ThunderTown) wrote:
> On 2016/8/24 18:30, Catalin Marinas wrote:
> >>>>>>>>>> On 2016/7/8 21:54, Catalin Marinas wrote:
> >>>>>>>>>>> 8<--
test.
Because of the early call to static_branch_enable() via
check_local_cpu_errata() -> update_cpu_capabilities(), the jump labels
are initialised in cpuinfo_store_boot_cpu().
Cc: Will Deacon
Cc: Suzuki K. Poulose
Signed-off-by: Catalin Marinas
---
arch/arm64/include/asm/cpufeature.h |
Corbet
Signed-off-by: Catalin Marinas
---
Documentation/static-keys.txt | 8
include/linux/jump_label.h| 12
2 files changed, 20 insertions(+)
diff --git a/Documentation/static-keys.txt b/Documentation/static-keys.txt
index 477927becacb..fd490f8b1cfa 100644
--- a
kernel, it will be more beneficial with new features like
TTBR0 PAN are which are used on hot paths (get_user/put_user, thread
switching).
Catalin Marinas (2):
jump_labels: Allow array initialisers
arm64: Use static keys for CPU features
Documentation/static-keys.txt | 8
arch
| 2 ++
> arch/arm64/mm/fault.c| 8 +++-
Not sure when/how this series will be merged (Will already picked patch
07/13 as a general clean-up) but this arm64 patch:
Reviewed-by: Catalin Marinas
On Fri, Aug 26, 2016 at 05:16:27PM +0100, Will Deacon wrote:
> On Fri, Aug 26, 2016 at 02:08:01PM +0100, Suzuki K Poulose wrote:
> > On 26/08/16 14:04, Suzuki K Poulose wrote:
> > >On 26/08/16 12:03, Ard Biesheuvel wrote:
> > >>IMO, this is a pattern that we should avoid: you are introducing one
>
On Tue, Jun 20, 2017 at 12:52:10AM +0300, Kirill A. Shutemov wrote:
> On Mon, Jun 19, 2017 at 06:09:12PM +0100, Catalin Marinas wrote:
> > On Mon, Jun 19, 2017 at 07:00:05PM +0300, Kirill A. Shutemov wrote:
> > > On Mon, Jun 19, 2017 at 04:22:29PM +0100, Catalin Marinas wrote:
&
as recommended by
> Linus and agreed by others.
>
> Based on next-20170609
> ---
> arch/arm64/include/asm/thread_info.h | 4 +++-
> arch/arm64/include/asm/uaccess.h | 3 +++
> arch/arm64/kernel/signal.c | 5 +
> 3 files changed, 11 insertions(+), 1 deletion(-)
For arm64:
Reviewed-by: Catalin Marinas
On Wed, Jun 21, 2017 at 12:53:03PM +0300, Kirill A. Shutemov wrote:
> On Tue, Jun 20, 2017 at 04:54:38PM +0100, Catalin Marinas wrote:
> > For arm64, I don't see the point of a cmpxchg, so something like below
> > would do (it needs proper testing though):
>
> Right. c
On Wed, Jun 21, 2017 at 12:53:03PM +0300, Kirill A. Shutemov wrote:
> > > > > > On Thu, Jun 15, 2017 at 05:52:22PM +0300, Kirill A. Shutemov wrote:
> > > > > > > We need an atomic way to setup pmd page table entry, avoiding
> > > > > > > races with
> > > > > > > CPU setting dirty/accessed bits. Th
On Fri, May 26, 2017 at 02:49:49PM +0100, Luis Henriques wrote:
> kmemleak has been reporting memory leaks since commit ac496bf48d97 ("fork:
> Optimize task creation by caching two thread stacks per CPU if
> CONFIG_VMAP_STACK=y"):
>
> unreferenced object 0xc92b (size 16384):
> comm "
On Fri, May 26, 2017 at 05:09:17PM +0100, Luis Henriques wrote:
> On Thu, May 25, 2017 at 04:42:16PM +0100, Catalin Marinas wrote:
> > The scan_block() function updates the number of references (pointers) to
> > objects, adding them to the gray_list when object->min_count is reac
On Fri, May 26, 2017 at 05:21:08PM +0100, Catalin Marinas wrote:
> On Fri, May 26, 2017 at 05:09:17PM +0100, Luis Henriques wrote:
> > On Thu, May 25, 2017 at 04:42:16PM +0100, Catalin Marinas wrote:
> > > The scan_block() function updates the number of references (pointers
Hi Linus,
Please pull the arm64 fix below. Thanks.
The following changes since commit 0b07194bb55ed836c2cc7c22e866b87a14681984:
Linux 4.14-rc7 (2017-10-29 13:58:38 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
for
501 - 600 of 3477 matches
Mail list logo
