From: BlaisorBlade <blaisorblade_spam@yahoo.it>
To: user-mode-linux-devel@lists.sourceforge.net
Subject: [uml-devel] Replacement of A-04 patch for mm/memory.c for UML/2.6
Date: Sat, 3 Jan 2004 16:59:10 +0100 [thread overview]
Message-ID: <200401031659.10844.blaisorblade_spam@yahoo.it> (raw)
It turned out that replacing that patch is probably easier than I thought.
This is the B-02 patch that I will post on my web space:
--- linux-2.6.0/mm/memory.c.memFix 2004-01-03 13:39:37.000000000 +0100
+++ linux-2.6.0/mm/memory.c 2004-01-03 13:42:17.000000000 +0100
@@ -44,6 +44,7 @@
#include <linux/highmem.h>
#include <linux/pagemap.h>
#include <linux/rmap-locking.h>
+#include <linux/init.h>
#include <linux/module.h>
#include <asm/pgalloc.h>
@@ -680,6 +681,24 @@
}
+static struct vm_area_struct fixmap_vma = {
+ /* Catch users - if there are any valid
+ ones, we can make this be "&init_mm" or
+ something. */
+ .vm_mm = NULL,
+ .vm_page_prot = PAGE_READONLY,
+ .vm_flags = VM_READ | VM_EXEC,
+};
+
+static int init_fixmap_vma(void)
+{
+ fixmap_vma.vm_start = FIXADDR_USER_START;
+ fixmap_vma.vm_end = FIXADDR_USER_END;
+ return(0);
+}
+
+__initcall(init_fixmap_vma);
+
int get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
unsigned long start, int len, int write, int force,
struct page **pages, struct vm_area_struct **vmas)
@@ -703,16 +722,6 @@
#ifdef FIXADDR_USER_START
if (!vma &&
start >= FIXADDR_USER_START && start < FIXADDR_USER_END) {
- static struct vm_area_struct fixmap_vma = {
- /* Catch users - if there are any valid
- ones, we can make this be "&init_mm" or
- something. */
- .vm_mm = NULL,
- .vm_start = FIXADDR_USER_START,
- .vm_end = FIXADDR_USER_END,
- .vm_page_prot = PAGE_READONLY,
- .vm_flags = VM_READ | VM_EXEC,
- };
unsigned long pg = start & PAGE_MASK;
pgd_t *pgd;
pmd_t *pmd;
The difference with the A-04 patch is that while that one replaces
FIXADDR_USER_* with FIXADDR_*, while this one doesn't apply this change.
I've done this because I've seen that old 2.5 kernels used FIXADDR_* macros;
then FIXADDR_USER_* was introduced but Jeff Dike, probably, didn't notice
this.
The change was (and in this version it is) only a syntactic one.
Looking at the change itself, I think that this version makes more sense: that
code is used to map in the address space of a process the page containing the
vsyscall code. But it should not be possible to map the other "fixed" virtual
pages inside a process's address space, right?
Obviously all in my very humble opinion. I'm posting this patch here for
comments and corrections (as I'm still a newbie about Linux internals, and
too careless at times).
Besides, after applying it, I got a non-reproducible segmentation fault the
first time I ran the resulting binary (I've not been able to reproduce that
crash). I'm not sure the fault was related to my code, but however this is
the output:
$ ./linux ubd0=~/Uml/root_fs_toms1.7.205 root=/dev/ubd0
Checking for the skas3 patch in the host...found
Checking for /proc/mm...found
Linux version 2.6.0-1um (paolo@blaisorblade) (gcc version 3.2.2 (Mandrake
Linux 9.1 3.2.2-3mdk)) #12 Sat Jan 3 13:50:46 CET 2004
On node 0 totalpages: 8192
DMA zone: 8192 pages, LIFO batch:2
Normal zone: 0 pages, LIFO batch:1
HighMem zone: 0 pages, LIFO batch:1
Building zonelist for node : 0
Kernel command line: ubd0=/home/paolo/Uml/root_fs_toms1.7.205 root=/dev/ubd0
PID hash table entries: 16 (order 4: 128 bytes)
Memory: 30680k available
Calibrating delay loop... 681.57 BogoMIPS
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Checking for host processor cmov support...Yes
Checking for host processor xmm support...No
Checking that ptrace can change system call numbers...OK
Segmentation fault
--
cat <<EOSIGN
Paolo Giarrusso, aka Blaisorblade
Linux Kernel 2.4.23/2.6.0 on an i686; Linux registered user n. 292729
EOSIGN
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
reply other threads:[~2004-01-03 16:01 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=200401031659.10844.blaisorblade_spam@yahoo.it \
--to=blaisorblade_spam@yahoo.it \
--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;
as well as URLs for NNTP newsgroup(s).