Menu
▾
▴
user-mode-linux-devel
|
From: Jeff D. <jd...@ad...> - 2005-03-03 05:53:19
|
Since 2.6.11 is out, it's time to decide what patches go into mainline first. Here's my cut: Plain bug-fixes - build no-kexec no-bb slirp-is-not-ethernet no-grep-st-ino fix-hostfs-gid usercopy-confusion fix-tlb-rounding ubd-config failed-net-hang long-command-line Safe - cleanup-userspace - rearranges code syscall-speedup - removes code syscall-debug - makes some code configurable pread - adds a comment remove-useless-code - removes a no-op wrapper user-obj-cleanup - build cleanup x86_64-ldt - eliminates a reference to mm_indirect x86-64-warning - changes some errors from panics to printks error-reporting - prints out warnings where there weren't any before static-tty-chan - makes a bunch of things static stack-expansion - makes UML behave like the underlying arch no-mo-perl - generate config.c with sed That's 23 of the 78. We also need to resurrect the SA_NODEFER patch. The skas0 stuff needs more baking. The os-dependent code movement I'm going to sit on until we have it all in hand and can clean it up. After that, some of the cleanups like the ubd-mmap removal and tlb flush cleaning can go. winch-crash will be nice to get in once we have agreement that it's correct. no-sys-ptrace seems OK, but it's large, which makes me nervous. Maybe that's a reason to get it in early. fp-state is probably another good early candidate, as is no-bb. user-constants-dep seems OK, but I just dropped in without understanding it. random is OK, but needs a bit more work, in particular, it needs to be configurable. Jeff |
|
From: Rob L. <ro...@la...> - 2005-03-03 06:11:53
|
On Thursday 03 March 2005 03:22 am, Jeff Dike wrote:
> Since 2.6.11 is out, it's time to decide what patches go into mainline
> first.
>
> Here's my cut:
Well, just in case your job was too easy, here's one more. Using the
"quiet" option shows a couple of lines being printed out by printf that
should be printed out by printk (so they'll _shut_up_ when you ask it to).
signed-off-by: Rob Landley
diff -ru linux-2.6.10/arch/um/kernel/mem_user.c linux-2.6.10-new/arch/um/kernel/mem_user.c
--- linux-2.6.10/arch/um/kernel/mem_user.c 2005-02-15 08:16:48.000000000 -0600
+++ linux-2.6.10-new/arch/um/kernel/mem_user.c 2005-02-17 05:06:25.000000000 -0600
@@ -88,8 +88,8 @@
addr = mmap(NULL, UM_KERN_PAGE_SIZE,
PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE, fd, 0);
- printf("Checking PROT_EXEC mmap in /tmp...");
- fflush(stdout);
+ /* Honor "quiet" option */
+ printk("Checking PROT_EXEC mmap in /tmp...");
if(addr == MAP_FAILED){
err = errno;
perror("failed");
@@ -97,7 +97,7 @@
printf("/tmp must be not mounted noexec\n");
exit(1);
}
- printf("OK\n");
+ printk("OK\n");
munmap(addr, UM_KERN_PAGE_SIZE);
os_close_file(fd);
diff -ru linux-2.6.10/arch/um/kernel/tt/tracer.c linux-2.6.10-new/arch/um/kernel/tt/tracer.c
--- linux-2.6.10/arch/um/kernel/tt/tracer.c 2005-02-15 08:16:49.000000000 -0600
+++ linux-2.6.10-new/arch/um/kernel/tt/tracer.c 2005-02-17 05:04:57.000000000 -0600
@@ -192,7 +192,7 @@
signal(SIGPIPE, SIG_IGN);
setup_tracer_winch();
tracing_pid = os_getpid();
- printf("tracing thread pid = %d\n", tracing_pid);
+ printk("tracing thread pid = %d\n", tracing_pid);
pid = clone(signal_tramp, sp, CLONE_FILES | SIGCHLD, init_proc);
CATCH_EINTR(n = waitpid(pid, &status, WUNTRACED));
> The skas0 stuff needs more baking. The os-dependent code movement I'm
> going to sit on until we have it all in hand and can clean it up.
I'm very interested in this (since I want to run UML on an unmodified host
and TT mode means a gcc compile under UML has 2/3 of the CPU usage
accounted to "system" instead of "user". Unfortunately, I can't find out
where to go for more information. (Every time I'm pointed at your huge
patch list I drown in x86-64 patches. Possibly breaking out the ones that
ONLY affect a specific architecture or at least clearly marking them would
be good...)
Rob
|
|
From: Jeff D. <jd...@ad...> - 2005-03-03 16:15:35
|
ro...@la... said: > Well, just in case your job was too easy, here's one more. Using the > "quiet" option shows a couple of lines being printed out by printf > that should be printed out by printk (so they'll _shut_up_ when you > ask it to). Those are printfs for a reason. Early boot mesages (before the kernel is actually running) won't be seen if they are printk-d and the thing crashes before the console is initialized. The messages will be stuck in the printk buffer, and you will be none the wiser. So, they can be made quiet if you really want, but that's not the way. Jeff |
|
From: Rob L. <ro...@la...> - 2005-03-04 03:28:20
|
On Thursday 03 March 2005 01:43 pm, Jeff Dike wrote: > ro...@la... said: > > Well, just in case your job was too easy, here's one more. Using the > > "quiet" option shows a couple of lines being printed out by printf > > that should be printed out by printk (so they'll _shut_up_ when you > > ask it to). > > Those are printfs for a reason. Early boot mesages (before the kernel is > actually running) won't be seen if they are printk-d and the thing crashes > before the console is initialized. The messages will be stuck in the > printk buffer, and you will be none the wiser. > > So, they can be made quiet if you really want, but that's not the way. I suspected there was a reason, nice to know what it is. It would be nice if they could be made quiet, because I'm in the process of doing a gross hack to run an independent process wrapped in UML. Basically, my nefarious scheme is to add the squashfs patch to UML, append a squashfs image to the end of the UML executable, and have a cpio ramfs init script search through /proc/self/exe for the 32 bytes that were at the start of the squashfs (which includes a 4 byte magic signature thingy) to determine offset to pass to "losetup -o $OFFSET /dev/loop0 /proc/self/exe", and then mount /dev/loop0 / and run the executable I want out of that filesystem. And there's a cheap and dirty way to get a self contained program running under UML. (I hope to actually have an example working this evening using 2.6.11.) The down side is that UML (even with the quiet option) just won't shut up about its init stuff. Hence me looking into cleaning that up... > Jeff Rob |
|
From: Blaisorblade <bla...@ya...> - 2005-03-05 16:05:14
|
On Friday 04 March 2005 03:11, Rob Landley wrote: > On Thursday 03 March 2005 01:43 pm, Jeff Dike wrote: > > ro...@la... said: > > > Well, just in case your job was too easy, here's one more. Using the > > > "quiet" option shows a couple of lines being printed out by printf > > > that should be printed out by printk (so they'll _shut_up_ when you > > > ask it to). > > > > Those are printfs for a reason. Early boot mesages (before the kernel is > > actually running) won't be seen if they are printk-d and the thing > > crashes before the console is initialized. The messages will be stuck in > > the printk buffer, and you will be none the wiser. > > I suspected there was a reason, nice to know what it is. It would be nice > if they could be made quiet, because I'm in the process of doing a gross > hack to run an independent process wrapped in UML. > Basically, my nefarious scheme is to add the squashfs patch to UML, append > a squashfs image to the end of the UML executable, and have a cpio ramfs > init script search through /proc/self/exe for the 32 bytes that were at the > start of the squashfs (which includes a 4 byte magic signature thingy) to > determine offset to pass to "losetup -o $OFFSET /dev/loop0 /proc/self/exe", > and then mount /dev/loop0 / and run the executable I want out of that > filesystem. First, compliments.... we need such stuff going. Please note that unless I'm mistaken the above scheme does not work since /proc/self/exe contains what you want on the host, not on the guest. If you use hostfs then it's ok, otherwise you'll have to pack the squashfs within the cpio image (if it's possible, the cpio image could not be ready to cope with so much data). Also, made sure adding stuff at the end of an exec. file is accepted without problems? Seems reasonable but not obvious. No experience with such stuff, but isn't it a bit risky this way (a signature being there by mistake)? If you still go for grepping the exec. image, I would add a header in the end giving the size of the squashfs image, and parse it. With the -s option to losetup you can cut at the end the area seeing by the loop device. > And there's a cheap and dirty way to get a self contained program running > under UML. (I hope to actually have an example working this evening using > 2.6.11.) > > > > So, they can be made quiet if you really want, but that's not the way. > The down side is that UML (even with the quiet option) just won't shut up > about its init stuff. Hence me looking into cleaning that up... Add early_printk which is a printf but shuts down when the quiet option is used. -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
|
From: Rob L. <ro...@la...> - 2005-03-06 21:02:25
|
On Saturday 05 March 2005 10:57 am, Blaisorblade wrote: > > Basically, my nefarious scheme is to add the squashfs patch to UML, > > append a squashfs image to the end of the UML executable, and have a > > cpio ramfs init script search through /proc/self/exe for the 32 bytes > > that were at the start of the squashfs (which includes a 4 byte magic > > signature thingy) to determine offset to pass to "losetup -o $OFFSET > > /dev/loop0 /proc/self/exe", and then mount /dev/loop0 / and run the > > executable I want out of that filesystem. > > First, compliments.... we need such stuff going. > > Please note that unless I'm mistaken the above scheme does not work > since /proc/self/exe contains what you want on the host, not on the guest. > If you use hostfs then it's ok, otherwise you'll have to pack the squashfs > within the cpio image (if it's possible, the cpio image could not be ready > to cope with so much data). That would suck mightily, since it would decompress it into ram and then eat swap space instead of using the file as backing store. No, I'm a big fan of hostfs. Part of this will probably involve changing the default command line of UML to something like: rootfstype=hostfs rootflags=/ rw quiet mem=48M Or some such. Then /proc/self/exe is quite happy, and I can find my file to loopback mount it. I can also chdir to (a readlink of) /proc/self/cwd, so that whatever application I'm running is working in the right current directory. I think I can make it relatively transparent to the hosted application, even. If I want to get silly I can su away from root so things like tar aren't confused that they can't do mknod and chown and such, or else I can mount a loopback ext2 filesystem on /tmp or some such hack to give it space it can play permission games with... > Also, made sure adding stuff at the end of an > exec. file is accepted without problems? Seems reasonable but not obvious. If it's ELF, life should be good because the elf sections say where everything is and how long it is. (Non-elf, you're on your own.) I pondered making all this an elf section, but don't know how off the top of my head... > No experience with such stuff, but isn't it a bit risky this way (a > signature being there by mistake)? If you still go for grepping the exec. > image, I would add a header in the end giving the size of the squashfs > image, and parse it. With the -s option to losetup you can cut at the end > the area seeing by the loop device. I could do that. Squashfs starts with a (4 byte) magic number, and I was worried that was insufficient so I'm grabbing the first 32 bytes to reduce the possibility of collisions. (The random occurrence of 32 identical bytes is really really unlikely if those bytes are at all well distributed. Not quite 1 in 2^256 unlikely, but pretty darn up there. I'm basically waiting for the easy way to break, and implementing something else if it does.) Sticking the length on the end is another quite valid option. I don't even have to tell losetup to truncate the loop device because none of the filesystems I care about are put off by trailing garbage... > Add early_printk which is a printf but shuts down when the quiet option is > used. Cool. Will do. Thanks, Rob |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X