mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/14] kmemleak: Add the base support
Date: Tue, 30 Dec 2008 10:48:15 +0000	[thread overview]
Message-ID: <1230634095.1693.22.camel@pc1117.cambridge.arm.com> (raw)
In-Reply-To: <20081229162314.1cc7a549.akpm@linux-foundation.org>

Andrew,

On Mon, 2008-12-29 at 16:23 -0800, Andrew Morton wrote:
> On Fri, 19 Dec 2008 18:13:02 +0000
> Catalin Marinas <catalin.marinas@arm.com> wrote:
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -56,6 +56,7 @@
> >  #include <linux/debug_locks.h>
> >  #include <linux/debugobjects.h>
> >  #include <linux/lockdep.h>
> > +#include <linux/kmemleak.h>
> >  #include <linux/pid_namespace.h>
> >  #include <linux/device.h>
> >  #include <linux/kthread.h>
> > @@ -653,6 +654,8 @@ asmlinkage void __init start_kernel(void)
> >  	enable_debug_pagealloc();
> >  	cpu_hotplug_init();
> >  	kmem_cache_init();
> > +	prio_tree_init();
> > +	kmemleak_init();
> 
> prio_tree_init() can be moved waaaay early, so we might as well do that
> now, rather than just moving it a little bit.

OK.

> > +#define print_helper(seq, x...)	do {	\
> > +	if (seq)			\
> > +		seq_printf(seq, x);	\
> > +	else				\
> > +		pr_info(x);		\
> > +} while (0)
> 
> grumblemutter.  Evaluates `seq' more than once.

OK. Anyway, in this particular case "seq" is just a pointer variable, so
I don't think there is much to evaluate.

> > +static void print_unreferenced(struct seq_file *seq,
> > +			       struct kmemleak_object *object)
> > +{
> > +	char namebuf[KSYM_NAME_LEN + 1] = "";
> > +	char *modname;
> > +	unsigned long symsize;
> > +	int i;
> > +
> > +	print_helper(seq, "unreferenced object 0x%08lx (size %zu):\n",
> > +		     object->pointer, object->size);
> > +	print_helper(seq, "  comm \"%s\", pid %d, jiffies %lu\n",
> > +		     object->comm, object->pid, object->jiffies);
> > +	print_helper(seq, "  backtrace:\n");
> > +
> > +	for (i = 0; i < object->trace_len; i++) {
> > +		unsigned long trace = object->trace[i];
> > +		unsigned long offset = 0;
> > +
> > +		kallsyms_lookup(trace, &symsize, &offset, &modname, namebuf);
> > +		print_helper(seq, "    [<%08lx>] %s\n", trace, namebuf);
> 
> Can this use the %p magic?

It can if I cast "trace" to (void *).

> > +static void scan_yield(void)
> > +{
> > +	might_sleep();
> > +
> > +	if (time_is_before_eq_jiffies(next_scan_yield)) {
> > +		schedule();
> > +		next_scan_yield = jiffies + jiffies_scan_yield;
> > +	}
> 
> I bet you could use __ratelimit() here.  Although that probably won't
> clarify anything, and it's slower ;)

The __ratelimit() seems slower indeed and it also takes a spinlock
(which I think would be better per ratelimit_state structure rather than
global).

> > +static int scan_should_stop(void)
> > +{
> > +	if (!atomic_read(&kmemleak_enabled))
> > +		return 1;
> > +	/*
> > +	 * This function may be called from either process or kthread context,
> > +	 * hence the need to check for both stop conditions.
> > +	 */
> > +	if ((current->mm && signal_pending(current)) ||
> > +	    (!current->mm && kthread_should_stop()))
> > +		return 1;
> > +	return 0;
> > +}
> 
> 	if (current->mm)
> 		return signal_pending(current);
> 	else
> 		return kthread_should_stop();
> 
> nicer, no?

Yes.

> > +/*
> > + * Stop the automatic memory scanning thread. This function must be called
> > + * with the kmemleak_mutex held.
> > + */
> > +void stop_scan_thread(void)
> > +{
> > +	if (scan_thread) {
> > +		kthread_stop(scan_thread);
> > +		scan_thread = NULL;
> > +	}
> > +}
> 
> so... why do we need a kernel thread?

This was requested by Ingo (and he already replied). I personally don't
mind either.

> We could have (for the sake of argument) a sys_kmemleak_scan() which
> does a single scan then returns.  Or something like that.  That way,
> userspace directly gets to set the scanning frequency, thread priority,
> etc.

You can also trigger a memory scanning from user space by reading
the /sys/kernel/debug/kmemleak file (this was the only way in previous
versions of kmemleak). My initial thoughts were for a user space daemon
(or just "cat") reading this file periodically.

> > +static ssize_t kmemleak_write(struct file *file, const char __user *user_buf,
> > +			      size_t size, loff_t *ppos)
> > +{
> > +	char buf[64];
> > +	int buf_size;
> > +
> > +	if (!atomic_read(&kmemleak_enabled))
> > +		return -EBUSY;
> > +
> > +	buf_size = min(size, (sizeof(buf) - 1));
> > +	if (copy_from_user(buf, user_buf, buf_size))
> > +		return -EFAULT;
> > +	buf[buf_size] = 0;
> 
> maybe strncpy_from_user()?

OK.

> > +static void kmemleak_cleanup(void)
> > +{
> > +	struct task_struct *cleanup_thread;
> > +
> > +	cleanup_thread = kthread_run(kmemleak_cleanup_thread, NULL,
> > +				     "kmemleak-cleanup");
> 
> #define TASK_COMM_LEN 16
> 
> So the above kernel thread will appear in `ps' output as "kmemleak-cleanu",
> won't it?

OK (it used to be called "memleak-cleanup").

Thanks for your comments.

-- 
Catalin


  parent reply	other threads:[~2008-12-30 10:48 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-19 18:12 [PATCH 00/14] Kernel memory leak detector Catalin Marinas
2008-12-19 18:13 ` [PATCH 01/14] kmemleak: Add the base support Catalin Marinas
2008-12-19 20:08   ` Pekka Enberg
2008-12-19 22:02     ` Ingo Molnar
2008-12-19 22:14       ` Andrew Morton
2008-12-22 13:05         ` Catalin Marinas
2008-12-30  0:23   ` Andrew Morton
2008-12-30  7:38     ` Ingo Molnar
2008-12-30  7:44       ` Andrew Morton
2008-12-30  7:52         ` Ingo Molnar
2008-12-30  7:59           ` Andrew Morton
2008-12-30 10:48     ` Catalin Marinas [this message]
2008-12-19 18:13 ` [PATCH 02/14] kmemleak: Add documentation on the memory leak detector Catalin Marinas
2008-12-19 18:30   ` Randy Dunlap
2008-12-19 18:13 ` [PATCH 03/14] kmemleak: Add the slab memory allocation/freeing hooks Catalin Marinas
2008-12-19 20:05   ` Pekka Enberg
2008-12-19 18:13 ` [PATCH 04/14] kmemleak: Add the slob " Catalin Marinas
2008-12-19 18:13 ` [PATCH 05/14] kmemleak: Add the slub " Catalin Marinas
2008-12-19 20:05   ` Pekka Enberg
2008-12-19 18:13 ` [PATCH 06/14] kmemleak: Add the vmalloc " Catalin Marinas
2008-12-19 18:13 ` [PATCH 07/14] kmemleak: Add kmemleak_alloc callback from alloc_large_system_hash Catalin Marinas
2008-12-19 18:13 ` [PATCH 08/14] kmemleak: Add modules support Catalin Marinas
2008-12-19 18:13 ` [PATCH 09/14] x86: Provide _sdata in the vmlinux_*.lds.S files Catalin Marinas
2008-12-19 18:13 ` [PATCH 10/14] arm: Provide _sdata and __bss_stop in the vmlinux.lds.S file Catalin Marinas
2008-12-19 18:13 ` [PATCH 11/14] kmemleak: Remove some of the kmemleak false positives Catalin Marinas
2008-12-19 20:15   ` Pekka Enberg
2008-12-22 12:04     ` Catalin Marinas
2008-12-19 18:14 ` [PATCH 12/14] kmemleak: Enable the building of the memory leak detector Catalin Marinas
2008-12-19 18:14 ` [PATCH 13/14] kmemleak: Simple testing module for kmemleak Catalin Marinas
2008-12-19 18:14 ` [PATCH 14/14] kmemleak: Add the corresponding MAINTAINERS entry Catalin Marinas
2008-12-30  0:23 ` [PATCH 00/14] Kernel memory leak detector Andrew Morton
2008-12-30 11:43   ` Catalin Marinas
2009-01-08 22:45 ` Andrew Morton
2009-01-12  9:51   ` Catalin Marinas
2009-01-12 10:21     ` Andrew Morton
2009-01-12 10:33       ` Stephen Rothwell
2009-01-12 11:13         ` Catalin Marinas
2009-01-14 12:30         ` Catalin Marinas
2009-01-14 14:01           ` Stephen Rothwell
2009-01-14 14:50             ` Catalin Marinas
2009-01-15 22:09               ` Mike Snitzer
2009-01-16  9:22                 ` Catalin Marinas
2009-04-24 16:40 Catalin Marinas
2009-04-24 16:41 ` [PATCH 01/14] kmemleak: Add the base support Catalin Marinas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1230634095.1693.22.camel@pc1117.cambridge.arm.com \
    --to=catalin.marinas@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome