From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Linus Torvalds <torvalds@transmeta.com>,
Rik van Riel <riel@nl.linux.org>, Ingo Molnar <mingo@redhat.com>,
linux-mm@kvack.org
Subject: Re: PATCH [2.4.0test10]: Kiobuf#02, fault-in fix
Date: Thu, 02 Nov 2000 09:30:10 -0500 [thread overview]
Message-ID: <3A017A72.ECBA2051@mandrakesoft.com> (raw)
In-Reply-To: 20001102134021.B1876@redhat.com
"Stephen C. Tweedie" wrote:
> Next part of the kiobuf diffs: fix the fact that handle_mm_fault
> doesn't guarantee to complete the operation in all cases; doesn't
> guarantee that the resulting pte is writable if write access was
> requested; and doesn't pin the page against immediately being swapped
> back out.
Dumb question time, if you don't mind. :) All code examples are from
mm/memory.c.
This seems to imply datain means 'read access':
int datain = (rw == READ);
This seems to further imply datain means 'read access':
if (((datain) && (!(vma->vm_flags & VM_WRITE))) ||
And then we pass 'datain' as the 'write_access' arg of handle_mm_fault:
if (handle_mm_fault(current->mm, vma, ptr, datain) <= 0)
Further down in make_pages_present, there seems to be the opposite:
write = (vma->vm_flags & VM_WRITE) != 0;
[...]
if (handle_mm_fault(mm, vma, addr, write) < 0)
So, why do we pass 'datain' as the 'write_access' arg of
handle_mm_fault?
(and now in your 02-faultfix.diff patch, as the 'write' arg of
follow_page)
Regards,
Jeff
--
Jeff Garzik | Dinner is ready when
Building 1024 | the smoke alarm goes off.
MandrakeSoft | -/usr/games/fortune
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
next prev parent reply other threads:[~2000-11-02 14:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-02 13:40 PATCH [2.4.0test10]: Kiobuf#02, fault-in fix Stephen C. Tweedie
2000-11-02 14:30 ` Jeff Garzik [this message]
2000-11-02 15:58 ` Stephen C. Tweedie
2000-11-04 1:28 ` Eric Lowe
2000-11-03 22:27 ` Andrea Arcangeli
2000-11-04 1:36 ` Eric Lowe
2000-11-04 2:07 ` Andrea Arcangeli
2000-11-06 15:05 ` Stephen C. Tweedie
2000-11-06 16:12 ` Andrea Arcangeli
2000-11-06 16:54 ` Stephen C. Tweedie
2000-11-06 22:34 ` Andrea Arcangeli
2000-11-07 11:17 ` Stephen C. Tweedie
2000-11-06 17:23 ` Linus Torvalds
2000-11-07 11:57 ` Stephen C. Tweedie
2000-11-07 13:37 ` Andrea Arcangeli
2000-11-08 12:31 ` Stephen C. Tweedie
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=3A017A72.ECBA2051@mandrakesoft.com \
--to=jgarzik@mandrakesoft.com \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--cc=riel@nl.linux.org \
--cc=sct@redhat.com \
--cc=torvalds@transmeta.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.