From: Benjamin LaHaise <bcrl@redhat.com>
To: Andrea Arcangeli <andrea@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.4.10pre13aa1
Date: Fri, 21 Sep 2001 13:18:41 -0400 [thread overview]
Message-ID: <20010921131841.A15773@redhat.com> (raw)
In-Reply-To: <20010921095721.A725@athlon.random>
In-Reply-To: <20010921095721.A725@athlon.random>; from andrea@suse.de on Fri, Sep 21, 2001 at 09:57:21AM +0200
On Fri, Sep 21, 2001 at 09:57:21AM +0200, Andrea Arcangeli wrote:
> Only in 2.4.10pre13aa1: 00_unmap-dirty-pte-1
>
> I grepped over the whole 600 pages of the latest x86 system developer
> manual and I couldn't find the proof that I'm wrong.
>
> We can have pagecache pages with pte writeable and non dirty at some
> point.
>
> Now what happens if the userspace task in the other cpu touches the
> writeable page between our "ptep_get_and_clear" and the
> "flush_tlb_page"? Is the resulting pte still zero and the task get into
> a page fault? Or as I am worried it could also just end with the pte
> with only the dirty bit set? Does somebody know for sure? I can
> imagine the cpu finding the tlb state writeable, and issuing just a
> locked bit test and set in the pte without caring to check if the pte
> is zero or not.
>
> If the cpu just set the bit this patch will avoid to lose a shared
> mapping update. Otherwise it's a safe noop so I keep it applied
> until this issue is sorted out.
I've tested this on all the machines I could get my hands on, and every
single CPU will take a page fault if the pte is not present on dirtying
the page. If people are truely paranoid, then make it a boot time assertion.
-ben
next prev parent reply other threads:[~2001-09-21 17:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20010921095721.A725@athlon.random>
2001-09-21 8:06 ` 2.4.0 and QoS installation Radivoje Todorovic
2001-09-21 8:39 ` Marco Colombo
2001-09-21 17:18 ` Benjamin LaHaise [this message]
2001-09-22 7:28 ` 2.4.10pre13aa1 Andrea Arcangeli
2001-09-22 22:39 ` 2.4.10pre13aa1 Benjamin LaHaise
2001-09-23 9:46 2.4.10pre13aa1 Manfred Spraul
2001-09-23 14:32 ` 2.4.10pre13aa1 Andrea Arcangeli
2001-09-23 18:28 ` 2.4.10pre13aa1 Benjamin LaHaise
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=20010921131841.A15773@redhat.com \
--to=bcrl@redhat.com \
--cc=andrea@suse.de \
--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 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.