[20:05:28] hello again, are you there ? [20:05:30] Yes [20:05:33] hi [20:05:57] Hi! I've been seeing your messages [20:06:13] great, I have a few questions [20:06:19] I've been working on merging an OpenMosix patch + your v2.4.25 patch on a 2.4.26 kernel [20:06:27] SKAS patch that is [20:06:36] and since I don't know anything about OpenMosix, I don't know where the problem could be, in the moment. But you can ask what you want. [20:06:49] Yes, I understand. [20:07:30] well, I was just wonder what the "void map(int fd, " in mem_user.c is for. how important is it to the core of skas ? [20:08:08] It's the SKAS core. In SKAS you have one process managing the mmap()ings of tons of child processes. [20:08:22] One mm_struct contains all info about one proc's mmaps(). [20:08:53] I see [20:09:06] Now, each different process must have a different mm_struct, (but threads share it, right). [20:09:10] you use mm_struct in various places. I see, that some functions pass mm_struct as an argument [20:09:26] Yes. Now, about SKAS itself. [20:10:02] Jeff decided that it was better to use one host thread only, which runs the code of any UML guest. [20:10:40] what is /proc/mm and how is it used ? [20:11:05] So, (see PTRACE_SWITCH_MM) when UML goes running another child, it must switch the MM_struct used by the other child. [20:11:28] Now, when you open /proc/mm, you get a new mm_struct. That is done when you start a userspace process inside UML. [20:12:05] And to modify the new mm_struct (with things like mmap(), munmap(), mprotect()) you write something to the /proc/mm descriptor. [20:12:19] Which is managed in mm/proc_mm.c [20:14:10] [20:14:10] Normally, in fact, current->mm points to the mm_struct used by the "current" task. current is a (struct task_struct *), pointing to the task which just made a syscall. [20:14:47] When UML starts one child, it wants to say the host: this child thread will have these memory mappings. [20:16:15] So it creates a mm_struct by opening /proc/mm write-only, writes some requests to it (handled in write_proc_mm in mm/proc_mm.c) to set up the mappings to the host file holding the datas (that is the one in $TMPDIR), which is like calling mmap() in place of the child. [20:16:31] (We don't want the child to do it itself). [20:18:59] Ah, void map actually setups the request to write on the host fd. [20:19:46] when uml starts a child, are those processes in uml space or system kernel space ? i mean does it exist as a pid on the hosts [20:19:50] ? [20:20:33] Well, in TT mode, it exists as a pid on the host. [20:20:57] ahh, but not in skas mode. [20:21:13] In SKAS mode, it's "almost" that way: since we do context switching by hand, anyway, UML compresses everything on the host as one PID. [20:21:26] The EIP and other registers value are managed by UML. [20:21:39] But for the mm_struct, we ask help to the host. [20:22:34] ok [20:22:56] When you get the point of mm/proc_mm.c code, you're done. Together with that, the complement is the implementation of PTRACE_SWITCH_MM in arch/i386/kernel/ptrace.c [20:23:24] Because, when we do a memory switch, the single host pid must run with a different mm_struct. [20:23:25] ok, I understand a little more. this is very helpful [20:23:59] how often would write_proc_mm be called ? [20:24:54] write_proc_mm will be called when UML must add a physical mapping to a guest (like changing the Page Table), which is not on mmap(), but on page-faults. [20:24:54] [20:24:54] Now, what you need to fixup the patch: mmap() and friends think that they are modifying mapping for the called processes (which is represented by current). [20:25:04] So, they modify current->mm. [20:26:24] what should they modify ? [20:26:52] But when UML runs void map(), the calling process is UML, while they should modify the mm_struct we use for the single host pid representing UML processes. [20:29:13] That struct is the mm var in this code: [20:29:13] [20:29:13] static ssize_t write_proc_mm(struct file *file, const char *buffer, [20:29:13] size_t count, loff_t *ppos) [20:29:13] { [20:29:13] struct mm_struct *mm = file->private_data; [20:30:05] And file->private_data is set when opening proc_mm. [20:31:19] So, while in the vanilla code mmap() and friends act on current->mm, we must add a parameter for every time we pass it down, so they use it instead of current->mm. [20:32:17] list_add() writes to mm, which is then read by "file->privatedata = mm" ? [20:32:41] Where? [20:32:54] in proc_mm.c [20:33:02] You mean this? [20:33:02] list_add(&mm->mmlist, ¤t->mm->mmlist); [20:33:08] yeah [20:33:24] That is part of the tasks you must do when creating a new mm. [20:33:43] There is a linked list containing all mm_structs in the system. [20:34:04] That line means "add mm to this list after current->mm". [20:34:18] ok [20:34:40] In the linux kernel, linked list are done with a couple of "prev,next" pointers, which are inside a member of what you link. [20:35:01] That couple is a "struct list_head". [20:35:39] so I imagine if write_proc_mm puts invalid data or no data in mm, that would help cause the error I am getting ? [20:35:46] You can look at it on include/linux/list.h if you want. [20:36:45] About EBADF: well, that error is returned by the generic linux code handling files (the VFS), don't ask me where, so there is something messed up a lot. [20:37:02] A closed file descriptor would cause that. [20:37:11] , for instance. [20:39:22] hmm, it is possible that the skas code works, but the problem may lay inside the core of the kernel somewhere ? or does skas make major modifications to the core of the kernel. I apoligize for all the newbie questions... [20:39:22] A failed open would, too. [20:40:07] JRandomHacker: no, assume the core kernel is correct, and SKAS is, too, on his own. [20:40:19] OpenMosix is the bigger patch... [20:42:18] ok, so I was probably not careful enough. because both patches make modifications to a few of the same functions [20:43:25] Yes, that is the assumption when doing so big work. [20:44:04] I thought some times "well, this is buggy", not following the principle, but at the beginning I was always wrong. [20:44:35] After some time, I started being correct - that's it, kernel hacking world. [20:45:48] JRandomHacker, any problem if I save this chat? [20:46:25] I may publish it as a "SKAS explaination" start... if you're shy, I'll edit it to remove your comments. [20:46:45] But I'd like to publish it as-is, if it's ok for you. [20:47:28] sure, go for it [20:47:40] Thanks! [20:49:18] thank you much for the explanation. It does actually help me