All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: "Vegard Nossum" <vegard.nossum@gmail.com>
Cc: mingo@elte.hu, linux-kernel@vger.kernel.org,
	torvalds@linux-foundation.org, tglx@linutronix.de, hpa@zytor.com
Subject: Re: [v2.6.26] what's brewing in x86.git for v2.6.26
Date: Thu, 17 Apr 2008 12:43:53 -0700	[thread overview]
Message-ID: <20080417124353.30fe1d06.akpm@linux-foundation.org> (raw)
In-Reply-To: <19f34abd0804171147l4403d49aoeab005105a90392b@mail.gmail.com>

On Thu, 17 Apr 2008 20:47:06 +0200
"Vegard Nossum" <vegard.nossum@gmail.com> wrote:

> On Thu, Apr 17, 2008 at 11:36 AM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
> > On Thu, 17 Apr 2008 11:30:25 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> >  > you mean kmemcheck? Yes, that's planned. We've been working 4 months
> >  > non-stop on kmemcheck to make it mergeable and usable, it's at version 7
> >  > right now, and it caught a handful of real bugs already (such as
> >  > 63a7138671c - unfortunately not credited in the log to kmemcheck). But
> >  > because it touches SLUB (because it has to - and they are acked by
> >  > Pekka) i never had the chance to move it into the for-akpm branch.
> >
> >  Does it really really really need to consume one of our few remaining page
> >  flags?  We'll be in a mess when we run out.
> 
> Actually it doesn't. I attach a patch which gets rid of the page flag,
> and we rely instead on the PTE flag for page-trackedness.
> 
> The reason we didn't do this at once is that the making of kmemcheck
> has been pretty much my first introduction to SLUB, x86, page flags,
> etc., and the actual semantics of the various introduced flags have
> varied since the first version of kmemcheck. At this point, the struct
> page flags weren't actually needed anymore, but they were convenient.
> 
> My apologies for not inlining the patch -- I don't have a mail client
> that won't mess up whitespace. It can also be downloaded at:
> http://folk.uio.no/vegardno/linux/0001-kmemcheck-remove-use-of-tracked-page-flag.patch
> 
> The patch has received minimal amount of testing, but I've
> double-checked the logic. It boots fine on my laptop, boot log at:
> http://folk.uio.no/vegardno/linux/kmemcheck-20080417.txt
> 
> Ingo, will you take this for some additional testing?
> 

If you're OK with doing it this way then it would be preferable.

> diff --git a/arch/x86/kernel/kmemcheck.c b/arch/x86/kernel/kmemcheck.c
> index 16dce10..d82f35d 100644
> --- a/arch/x86/kernel/kmemcheck.c
> +++ b/arch/x86/kernel/kmemcheck.c
> @@ -233,12 +233,27 @@ param_kmemcheck(char *str)
>  	if (!str)
>  		return -EINVAL;
>  
> -	sscanf("%d", str, &kmemcheck_enabled);
> +	sscanf(str, "%d", &kmemcheck_enabled);
>  	return 0;
>  }

whoops.  Note to Ingo: unrelated bugfix in there.

>  early_param("kmemcheck", param_kmemcheck);

kmemcheck= is documented in at least three places, which is nice, but it
isn't mentioned in the place where we document kernel-parameters:
Documentation/kernel-parameters.txt.  A brief section there which directs
the user to the extended docs would be fine.

early_param() is unusual - we normally use __setup().  I assume there's a
reason for using early_param(), but that reason cannot be discerned from
reading the code.  A /*comment*/ is the way to fix that.

> +static pte_t *
> +address_get_pte(unsigned int address)

This is not the preferred way of laying out function declarations but I've
basically given up on this one.

> +{
> +	pte_t *pte;
> +	int level;
> +
> +	pte = lookup_address(address, &level);
> +	if (!pte)
> +		return NULL;
> +	if (!pte_hidden(*pte))
> +		return NULL;
> +
> +	return pte;
> +}
> +
>  /*
>   * Return the shadow address for the given address. Returns NULL if the
>   * address is not tracked.
> @@ -249,88 +264,53 @@ early_param("kmemcheck", param_kmemcheck);
>  static void *
>  address_get_shadow(unsigned long address)
>  {
> +	pte_t *pte;
>  	struct page *page;
>  	struct page *head;
>  
>  	if (!virt_addr_valid(address))
>  		return NULL;
>  
> +	pte = address_get_pte(address);
> +	if (!pte)
> +		return NULL;
> +
>  	/* The accessed page */
>  	page = virt_to_page(address);
> -	if (!PageCompound(page))
> -		return NULL;
> +	BUG_ON(!PageCompound(page));
>  
>  	/* The head page */
>  	head = compound_head(page);
> -	if (!PageTracked(head))
> -		return NULL;
> +	BUG_ON(compound_order(head) == 0);
>  
>  	return (void *) address + (PAGE_SIZE << (compound_order(head) - 1));
>  }

	(void *)address

is more common, but I'm close to giving up on that too.

>  static int
> -show_addr(uint32_t addr)
> +show_addr(uint32_t address)

u32 is preferred, but ditto.

>  {
>  	pte_t *pte;
> -	int level;
> -
> -	if (!address_get_shadow(addr))
> -		return 0;
> -
> -	pte = lookup_address(addr, &level);
> -	BUG_ON(!pte);
> -
> -	if (level != PG_LEVEL_4K)
> -		return 0;
> -
> -	set_pte(pte, __pte(pte_val(*pte) | _PAGE_PRESENT));
> -	__flush_tlb_one(addr);
> -	return 1;
> -}
>
> ...
>
> --- a/include/linux/kmemcheck.h
> +++ b/include/linux/kmemcheck.h
> @@ -9,6 +9,8 @@ void kmemcheck_init(void);
>  void kmemcheck_show_pages(struct page *p, unsigned int n);
>  void kmemcheck_hide_pages(struct page *p, unsigned int n);
>  
> +bool kmemcheck_page_is_tracked(struct page *p);
> +
>  void kmemcheck_mark_unallocated(void *address, unsigned int n);
>  void kmemcheck_mark_uninitialized(void *address, unsigned int n);
>  void kmemcheck_mark_initialized(void *address, unsigned int n);
> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> index 63f5fd8..3696889 100644
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -89,7 +89,6 @@
>  #define PG_mappedtodisk		16	/* Has blocks allocated on-disk */
>  #define PG_reclaim		17	/* To be reclaimed asap */
>  #define PG_buddy		19	/* Page is free, on buddy lists */
> -#define PG_tracked		20	/* Tracked by kmemcheck */
>  
>  /* PG_readahead is only used for file reads; PG_reclaim is only for writes */
>  #define PG_readahead		PG_reclaim /* Reminder to do async read-ahead */
> @@ -297,10 +296,6 @@ static inline void __ClearPageTail(struct page *page)
>  #define SetPageUncached(page)	set_bit(PG_uncached, &(page)->flags)
>  #define ClearPageUncached(page)	clear_bit(PG_uncached, &(page)->flags)
>  
> -#define PageTracked(page)	test_bit(PG_tracked, &(page)->flags)
> -#define SetPageTracked(page)	set_bit(PG_tracked, &(page)->flags)
> -#define ClearPageTracked(page)	clear_bit(PG_tracked, &(page)->flags)
> -

That's about 15 less rejects I have to fix ;)
 
>  struct page;	/* forward declaration */
>  
> diff --git a/mm/slub.c b/mm/slub.c
> index 9b58979..7a544e6 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -1125,7 +1125,7 @@ static void __free_slab(struct kmem_cache *s, struct page *page)
>  		ClearSlabDebug(page);
>  	}
>  
> -	if (PageTracked(page) && !(s->flags & SLAB_NOTRACK)) {
> +	if (kmemcheck_page_is_tracked(page) && !(s->flags & SLAB_NOTRACK)) {
>  		kmemcheck_free_slab(s, page, pages);
>  		return;
>  	}

Perhaps we should get all this code onto the list(s) for re-review.  It's
been a while..


  parent reply	other threads:[~2008-04-17 19:44 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-16 20:23 [v2.6.26] what's brewing in x86.git for v2.6.26 Ingo Molnar
2008-04-16 20:37 ` Roland Dreier
2008-04-16 22:18   ` Suresh Siddha
2008-04-16 20:50 ` Andi Kleen
2008-04-17 10:06   ` Alexander van Heukelum
2008-04-17 10:51     ` Andi Kleen
2008-04-17 13:33       ` Alexander van Heukelum
2008-04-18  8:38     ` Ingo Molnar
2008-04-18 10:51       ` Andi Kleen
2008-04-17  7:25 ` Andrew Morton
2008-04-17  7:45   ` Pekka Enberg
2008-04-17  8:20     ` Andrew Morton
2008-04-17  8:32       ` Pekka J Enberg
2008-04-17  8:34         ` Pekka Enberg
2008-04-17  8:40           ` Ingo Molnar
2008-04-17  8:42           ` Andrew Morton
2008-04-17 11:49             ` Christoph Hellwig
2008-04-17 11:56               ` Ingo Molnar
2008-04-17 18:01               ` Andrew Morton
2008-04-17 18:51                 ` Ingo Molnar
2008-04-17 19:57                   ` Andrew Morton
2008-04-17 20:18                     ` Ingo Molnar
2008-04-18  9:33                   ` Tomasz Kłoczko
2008-04-18  9:42                     ` Ingo Molnar
2008-04-17  8:14   ` Andrew Morton
2008-04-17  8:57     ` Avi Kivity
2008-04-17 10:32     ` Johannes Weiner
2008-04-17 10:50       ` Andrew Morton
2008-04-17 11:49     ` Christoph Hellwig
2008-04-17 17:36       ` Andrew Morton
2008-04-17  8:30   ` Ingo Molnar
2008-04-17  8:40     ` Andrew Morton
2008-04-17  8:45       ` David Miller
2008-04-17  8:54         ` Andrew Morton
2008-04-17  8:56           ` Andrew Morton
2008-04-17  9:19           ` David Miller
2008-04-17  9:33             ` Andrew Morton
2008-04-17  9:06       ` Ingo Molnar
2008-04-17  9:18         ` Andrew Morton
2008-04-17  9:30           ` Ingo Molnar
2008-04-17  9:36             ` Andrew Morton
2008-04-17  9:46               ` Ingo Molnar
2008-04-17 10:06                 ` Andrew Morton
2008-04-17 10:11               ` Andi Kleen
2008-04-17 10:18                 ` Andrew Morton
2008-04-17 10:29                   ` Andi Kleen
2008-04-17 10:19               ` Pekka Enberg
2008-04-17 10:33                 ` Andrew Morton
2008-04-17 10:38                   ` Ingo Molnar
2008-04-17 10:42                     ` Pekka Enberg
2008-04-18 11:12                       ` Nick Piggin
2008-04-17 14:01                     ` Arjan van de Ven
2008-04-17 15:26                       ` Ingo Molnar
2008-04-18 12:41                       ` Ingo Molnar
2008-04-17 10:41                   ` Pekka Enberg
2008-04-17 18:47               ` Vegard Nossum
2008-04-17 19:27                 ` Ingo Molnar
2008-04-17 19:35                   ` Ingo Molnar
2008-04-17 19:39                     ` Vegard Nossum
2008-04-17 19:43                 ` Andrew Morton [this message]
2008-04-17 20:39                   ` Vegard Nossum
2008-04-17 20:55                     ` Andrew Morton
2008-04-17  9:53             ` Andrew Morton
2008-04-17  7:48 ` Andrew Morton
2008-04-18  6:27 ` Andrew Morton
2008-04-18  6:38   ` David Miller
2008-04-18  7:47     ` Ingo Molnar
2008-04-18  8:00       ` Andrew Morton
2008-04-18  8:11         ` Christoph Hellwig
2008-04-18  8:18           ` David Miller
2008-04-18 12:48             ` Ingo Molnar

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=20080417124353.30fe1d06.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --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.