linux-um archives
 help / color / mirror / Atom feed
From: Blaisorblade <blaisorblade@yahoo.it>
To: user-mode-linux-devel@lists.sourceforge.net
Cc: Jeff Dike <jdike@addtoit.com>, linux-kernel@vger.kernel.org
Subject: Re: [uml-devel] Re: [patch 1/3] uml: share page bits handling between 2 and 3 level pagetables
Date: Sun, 4 Sep 2005 13:33:30 +0200	[thread overview]
Message-ID: <200509041333.30466.blaisorblade@yahoo.it> (raw)
In-Reply-To: <20050902201749.GA9104@ccure.user-mode-linux.org>

On Friday 02 September 2005 22:17, Jeff Dike wrote:
> On Wed, Aug 10, 2005 at 09:37:28PM +0200, Blaisorblade wrote:
> > Also look, on the "set_pte" theme, at the attached patch.

> +       WARN_ON(!pte_young(*pte) || pte_write(*pte) && !pte_dirty(*pte));

> This one has been firing on me, and I decided to figure out why.  The
> culprit is this code in do_no_page:

> 	if (pte_none(*page_table)) {
> 		if (!PageReserved(new_page))
> 			inc_mm_counter(mm, rss);
>
> 		flush_icache_page(vma, new_page);
> 		entry = mk_pte(new_page, vma->vm_page_prot);
> 		if (write_access)
> 			entry = maybe_mkwrite(pte_mkdirty(entry), vma);
> 		set_pte_at(mm, address, page_table, entry);
>
> The first mk_pte immediately sets the pte to the protection limits of
> the VMA, regardless of the access type.

> So, if it's a read access on 
> a writeable page, we get a writeable, but not dirty pte, since the
> mkdirty never happens.  The exercises the warning you added.
Thanks for noticing - I had really this doubt when writing some code (in the 
patch, I've added a dirty PTEs on read accesses because I was unsure, and 
even because of my warning).

> This seems somewhat bogus to me.  If we set the pte protection to its
> limits, then the maybe_mkwrite is unneccesary.

> This doesn't seem to harm our dirty bit emulation.  fix_range_common
> checks the dirty and accessed bits and disables read and write
> protection as appropriate.

> So, it seems like the warning could be dropped, or perhaps made more
> selective, like checking for is_write == 0 and VM_WRITE, but then the
> test is getting complicated.

No, just replace pte_write() with is_write, as below. They might not coincide, 
but if on a write fault we return with a clean PTE, we'll loop indefinitely 
(experienced while hacking on remap_f_p), so the warning above is definitely 
correct.

       WARN_ON(!pte_young(*pte) || is_write && !pte_dirty(*pte));
> 				Heff

-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

		
___________________________________ 
Yahoo! Messenger: chiamate gratuite in tutto il mondo 
http://it.beta.messenger.yahoo.com



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

  parent reply	other threads:[~2005-09-04 11:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-28 18:56 [uml-devel] [patch 1/3] uml: share page bits handling between 2 and 3 level pagetables blaisorblade
2005-07-30 16:02 ` [uml-devel] " Jeff Dike
2005-07-30 18:54   ` Blaisorblade
2005-08-10 19:37   ` Blaisorblade
2005-08-12 17:05     ` Jeff Dike
2005-09-02 20:17     ` Jeff Dike
2005-09-03  5:08       ` Hugh Dickins
2005-09-04 11:33       ` Blaisorblade [this message]
2005-08-12 18:37   ` Blaisorblade

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=200509041333.30466.blaisorblade@yahoo.it \
    --to=blaisorblade@yahoo.it \
    --cc=jdike@addtoit.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /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