From: Pekka Enberg <penberg@cs.helsinki.fi>
To: Vegard Nossum <vegard.nossum@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Daniel Walker <dwalker@mvista.com>, Ingo Molnar <mingo@elte.hu>,
Richard Knutsson <ricknu-0@student.ltu.se>,
Andi Kleen <andi@firstfloor.org>,
Christoph Lameter <clameter@sgi.com>
Subject: Re: [PATCH 1/4] kmemcheck v4
Date: Thu, 14 Feb 2008 22:45:51 +0200 [thread overview]
Message-ID: <47B4A87F.8020800@cs.helsinki.fi> (raw)
In-Reply-To: <47B49DB2.2090402@gmail.com>
Vegard Nossum wrote:
> +DEFINE_PER_CPU(bool, kmemcheck_busy) = false;
> +DEFINE_PER_CPU(uint32_t, kmemcheck_addr1) = 0;
> +DEFINE_PER_CPU(uint32_t, kmemcheck_addr2) = 0;
> +DEFINE_PER_CPU(uint32_t, kmemcheck_reg_flags) = 0;
> +
> +DEFINE_PER_CPU(int, kmemcheck_num) = 0;
> +DEFINE_PER_CPU(int, kmemcheck_balance) = 0;
No need to explicitly initialize these, they're automatically zeroed.
> +
> +/*
> + * Called from the #PF handler.
> + */
> +void
> +kmemcheck_show(struct pt_regs *regs)
> +{
> + int n;
> +
> + BUG_ON(!irqs_disabled());
> +
> + if (__get_cpu_var(kmemcheck_balance) != 0) {
> + oops_in_progress = 1;
Why?
> + panic("kmemcheck: extra #PF");
> + }
> +
> +/*
> + * Called from the #DB handler.
> + */
> +void
> +kmemcheck_hide(struct pt_regs *regs)
> +{
> + BUG_ON(!irqs_disabled());
> +
> + --__get_cpu_var(kmemcheck_balance);
> + if (unlikely(__get_cpu_var(kmemcheck_balance) != 0)) {
> + oops_in_progress = 1;
ditto
> + panic("kmemcheck: extra #DB");
> + }
> +
> +static void
> +kmemcheck_read(struct pt_regs *regs, uint32_t address, unsigned int size)
> +{
> + void *shadow;
> + enum shadow status;
> +
> + shadow = address_get_shadow(address);
> + if (!shadow)
> + return;
> +
> + status = test(shadow, size);
> + if (status == SHADOW_INITIALIZED)
> + return;
> +
> + /* Don't warn about it again. */
> + set(shadow, size);
> +
> + oops_in_progress = 1;
I don't see you setting that to zero anywhere. What's this doing here
anyway?
> + error_save(status, address, size, regs);
> +}
> +
> +/*
> + * A faster implementation of memset() when tracking is enabled. We cannot
> + * assume that all pages within the range are tracked, so copying has
> to be
> + * split into page-sized (or smaller, for the ends) chunks.
> + */
> +void
> +kmemcheck_memset(unsigned long s, int c, size_t n)
> +{
> + unsigned long a_page, a_offset;
> + unsigned long b_page, b_offset;
Uhm, s/a_page/start_page/g, s/b_page/end_page/g and same for the offsets
too.
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index 0c6ce51..2138d64 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -50,8 +50,9 @@ struct vm_area_struct;
> #define __GFP_THISNODE ((__force gfp_t)0x40000u)/* No fallback, no
> policies */
> #define __GFP_RECLAIMABLE ((__force gfp_t)0x80000u) /* Page is
> reclaimable */
> #define __GFP_MOVABLE ((__force gfp_t)0x100000u) /* Page is movable */
> +#define __GFP_NOTRACK ((__force gfp_t)0x200000u) /* Don't track
> with kmemcheck */
I think we can set __GFP_NOTRACK to zero to eliminate all dead code when
CONFIG_KMEMCHECK is disabled?
> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> index bbad43f..1593859 100644
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -90,6 +90,8 @@
> #define PG_reclaim 17 /* To be reclaimed asap */
> #define PG_buddy 19 /* Page is free, on buddy lists */
>
> +#define PG_tracked 20 /* Page is tracked by kmemcheck */
> +
I think we should re-use PG_owner_priv_1 for this (see PG_pinned, for
example).
next prev parent reply other threads:[~2008-02-14 20:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-14 19:59 [PATCH 1/4] kmemcheck v4 Vegard Nossum
2008-02-14 20:01 ` [PATCH 2/4] " Vegard Nossum
2008-02-14 20:02 ` [PATCH 3/4] " Vegard Nossum
2008-02-14 20:18 ` Pekka Enberg
2008-02-14 20:02 ` [PATCH 4/4] " Vegard Nossum
2008-02-14 20:12 ` Pekka Enberg
2008-02-14 20:31 ` Vegard Nossum
2008-02-14 21:49 ` Andi Kleen
2008-02-15 19:18 ` Vegard Nossum
2008-02-14 20:45 ` Pekka Enberg [this message]
2008-02-14 21:05 ` [PATCH 1/4] " Randy Dunlap
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=47B4A87F.8020800@cs.helsinki.fi \
--to=penberg@cs.helsinki.fi \
--cc=andi@firstfloor.org \
--cc=clameter@sgi.com \
--cc=dwalker@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=ricknu-0@student.ltu.se \
--cc=vegard.nossum@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.