mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: randy_dunlap <rdunlap@xenotime.net>
To: <Stuart_Hayes@Dell.com>
Cc: ak@suse.de, riel@redhat.com, andrea@suse.de,
	linux-kernel@vger.kernel.org
Subject: Re: page allocation/attributes question (i386/x86_64 specific)
Date: Tue, 5 Jul 2005 15:00:19 -0700	[thread overview]
Message-ID: <20050705150019.2d9d8f1c.rdunlap@xenotime.net> (raw)
In-Reply-To: <B1939BC11A23AE47A0DBE89A37CB26B4074360@ausx3mps305.aus.amer.dell.com>

On Tue, 5 Jul 2005 16:35:51 -0500 Stuart_Hayes@Dell.com wrote:

| randy_dunlap wrote:
| > On Tue, 5 Jul 2005 15:02:26 -0500 Stuart_Hayes@Dell.com wrote:
| > 
| >> Andi--
| >> 
| >> I made another pass at this.  This does roughly the same thing, but
| >> it doesn't create the new "change_page_attr_perm()" functions.  With
| >> this patch, the change to init.c (cleanup_nx_in_kerneltext()) is
| >> optional. I changed __change_page_attr() so that, if the page to be
| >> changed is part of a large executable page, it splits the page up
| >> *keeping the executability of the extra 511 pages*, and then marks
| >> the new PTE page as reserved so that it won't be reverted.
| >> 
| >> So, basically, without the changes to init.c, the NX bits for data in
| >> the first two big pages won't get fixed until someone calls
| >> change_page_attr() on them.  If NX is disabled, these patches have
| >> no functional effect at all. 
| >> 
| >> How does this look?
| > 
| > Look?  It has lots of bad line breaks and other style issues.
| > 
| > But I'll let Andi comment on the technical issues.
| > 
| >> -----
| >> 
| >> diff -purN linux-2.6.12grep/arch/i386/mm/init.c
| >> linux-2.6.12/arch/i386/mm/init.c
| >> --- linux-2.6.12grep/arch/i386/mm/init.c	2005-07-01
| >> 15:09:27.000000000 -0500 +++
| >> linux-2.6.12/arch/i386/mm/init.c	2005-07-05 14:32:57.000000000
| -0500
| >>  @@ -666,6 +666,28 @@ static int noinline do_test_wp_bit(void) 
| >> return flag; } 
| >> 
| >> +/*
| >> + * In kernel_physical_mapping_init(), any big pages that contained
| >> kernel text area were + * set up as big executable pages.  This
| >> function should be called + when the initmem
| >> + * is freed, to correctly set up the executable & non-executable +
| >> pages in this area.
| >> + */
| >> +static void cleanup_nx_in_kerneltext(void) {
| >> +	unsigned long from, to;
| >> +
| >> +	if (!nx_enabled) return;
| > 
| > return; on separate line.
| > 
| >> +	from = PAGE_OFFSET;
| >> +	to = (unsigned long)_text & PAGE_MASK;
| >> +	for (; from<to; from += PAGE_SIZE)
| > 	       from < to
| > 
| > (i.e., use the spacebar)
| > 
| >> +		change_page_attr(virt_to_page(from), 1, PAGE_KERNEL); +
| >> +	from = ((unsigned long)_etext + PAGE_SIZE - 1) & PAGE_MASK;
| >> +	to = ((unsigned long)__init_end + LARGE_PAGE_SIZE) &
| >> LARGE_PAGE_MASK; +	for (; from<to; from += PAGE_SIZE)
| > 
| > add spaces:    from < to
| > 
| >> +		change_page_attr(virt_to_page(from), 1, PAGE_KERNEL); }
| +
| >>  void free_initmem(void)
| >>  {
| >>  	unsigned long addr;
| > 
| > 
| > ---
| > ~Randy
| 
| Thanks for the feedback.  I know it looks like crap with the line
| wrapping, but I have no way of sending non-automatically-line-broken
| email right now, which is why I attached the file in addition to the
| inline text.  I apologize for that.

My apologies also, I completely missed seeing the attachment.

| I'll correct those cosmetic issues, thanks.

---
~Randy

  reply	other threads:[~2005-07-05 22:08 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-05 21:35 Stuart_Hayes
2005-07-05 22:00 ` randy_dunlap [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-07-20 19:24 Stuart_Hayes
2005-07-20 15:06 Stuart_Hayes
2005-07-20 20:45 ` Ingo Molnar
2005-07-20 14:51 Stuart_Hayes
2005-07-20 15:00 ` Ingo Molnar
2005-07-19 21:20 Stuart Hayes
2005-07-19 22:04 ` Ingo Molnar
2005-07-07 17:21 Stuart_Hayes
2005-07-05 20:02 Stuart_Hayes
2005-07-05 21:27 ` randy_dunlap
2005-07-07 14:33 ` Andi Kleen
2005-07-01 20:33 Stuart_Hayes
2005-06-30 19:11 Stuart_Hayes
2005-06-30 17:14 Stuart_Hayes
2005-06-30 16:56 Stuart_Hayes
2005-06-30 17:34 ` Arjan van de Ven
2005-06-29 17:20 Stuart_Hayes
2005-06-28 20:16 Stuart_Hayes
2005-06-30 16:15 ` Andi Kleen
2005-06-24 18:20 Stuart_Hayes
2005-06-25  2:28 ` Andi Kleen
2005-06-22 17:11 Stuart_Hayes
2005-06-22 23:54 ` Rik Van Riel

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=20050705150019.2d9d8f1c.rdunlap@xenotime.net \
    --to=rdunlap@xenotime.net \
    --cc=Stuart_Hayes@Dell.com \
    --cc=ak@suse.de \
    --cc=andrea@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®