Thanks for the answer. I bumped CONFIG_KERNEL_STACK_ORDER to 3, but it doesn't help.
I have a system call that does nothing but execute my code to parse my file in the host. When I said that using malloc didn't work, I meant the following: I'm using malloc to allocate a buffer in the UML kernel. I'm not passing a user level buffer to the system call. Then, when I use fread to read my file into this buffer, if I read a small number of bytes, it works. However when I try to fread the entire file (38k), fread returns 0. The same thing using a buffer returned by um_kmalloc works perfectly (i.e. returns 1 and the buffer is filled with the file data). Later on, I use sscanf to parse my buffer. No matter what happens, sscanf returns 0, which is wrong even if there is no error. The exact same code compiled in the host works perfectly. Again, thank you for your help, I really appreciate. Olivier On 4/5/06, Jeff Dike <[EMAIL PROTECTED]> wrote: > On Wed, Apr 05, 2006 at 07:16:22PM +0200, Olivier Crameri wrote: > > Unfortunately, I'm having some weird issues that I can't really > > understand. I can read the file using fread, but only in a buffer > > that I allocated using um_kmalloc. If I use a buffer allocated by > > malloc, the fread fails. Then, even if I replace all my mallocs by > > um_kmallocs, some libc functions (such as sscanf) don't seem to work > > properly. I guess I'm missing something, but I can't figure out what. > > Define "fails" and "don't seem to work properly". > > If your buffers are larger than 128K, then libc malloc gets turned into > UML kernel vmalloc. In this case, the buffer isn't mapped, and > passing it into a system call will make it return -EFAULT. The > easiest workaround for this is to memset the thing immediately after > allocating it. > > Also, if you're using the libc things you're talking about, watch out > for your stack consumption. By default, you get two pages (8K). > printf will completely use it up, so it is unusable in kernel code. > > UML kernel stack size is configurable - CONFIG_KERNEL_STACK_ORDER - > bumping that to 3 will double the kernel stack size. If problems then > go away, then you know that libc is overflowing your stack. > > Jeff > ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
