All of lore.kernel.org
 help / color / mirror / Atom feed
* [uml-devel] vmalloc and shared memory question
@ 2007-09-18 21:00 Bradshaw, James
  2007-09-19  0:34 ` Jeff Dike
  0 siblings, 1 reply; 2+ messages in thread
From: Bradshaw, James @ 2007-09-18 21:00 UTC (permalink / raw)
  To: user-mode-linux-devel


[-- Attachment #1.1: Type: text/plain, Size: 6355 bytes --]

Hi,

 

I'm running into a problem with a 2.6.14.7 UML kernel and I wonder if
anyone can help. The issue appears to be that memory allocated by a call
to vmalloc lies outside the UML's virtual memory map, so that a
subsequent pointer dereference ends up causing a seg fault. The vmalloc
call is in cramfs_uncompress_init:

 

int cramfs_uncompress_init(void)

{

        if (!initialized++) {

                stream.workspace =
vmalloc(zlib_inflate_workspacesize()); 

                if ( !stream.workspace ) {

                        initialized = 0;

                        return -ENOMEM;

                }

                stream.next_in = NULL;

                stream.avail_in = 0;

                zlib_inflateInit(&stream);

        }

        return 0;

}

 

The value of stream.workspace after the call to vmalloc is 0xa800000;
the value returned by zlib_inflate_workspacesize() is 46912. I am
running a 2.6.9 host with the skas3-v8.2 patch applied. Looking at the
/proc/pid/maps shows the following:

 

$ cat /proc/20723/maps

0072f000-00731000 r-xp 00000000 03:02 1680732    /lib/libutil-2.3.4.so

00731000-00733000 rwxp 00001000 03:02 1680732    /lib/libutil-2.3.4.so

008f2000-00907000 r-xp 00000000 03:02 1678838    /lib/ld-2.3.4.so

00907000-00908000 r-xp 00015000 03:02 1678838    /lib/ld-2.3.4.so

00908000-00909000 rwxp 00016000 03:02 1678838    /lib/ld-2.3.4.so

0090f000-00a33000 r-xp 00000000 03:02 1680726    /lib/tls/libc-2.3.4.so

00a33000-00a34000 r-xp 00124000 03:02 1680726    /lib/tls/libc-2.3.4.so

00a34000-00a37000 rwxp 00125000 03:02 1680726    /lib/tls/libc-2.3.4.so

00a37000-00a39000 rwxp 00a37000 00:00 0

08048000-0826d000 rwxp 00000000 00:5a 6373586
/net/ramones/export2/views/jbradsha/jbradsha_2.6.vws/.s/00051/8000009d46
bfc2aflinux

0826d000-082b6000 rwxp 0826d000 00:00 0

082b6000-0a048000 rwxs 0026e000 00:11 2645087    /dev/shm/vm_file-uPBwQg
(deleted)

b7ffd000-b8000000 rwxp b7ffd000 00:00 0

bfffd000-c0000000 rwxp bfffd000 00:00 0

ffffe000-fffff000 ---p 00000000 00:00 0

 

I note that 0xa800000 is not in any of the mapped regions. Prior to the
vmalloc() call, the following log messages are seen:

 

Checking that ptrace can change system call numbers...OK

Checking syscall emulation patch for ptrace...OK

Checking advanced syscall emulation patch for ptrace...OK

Checking for tmpfs mount on /dev/shm...OK

Checking PROT_EXEC mmap in /dev/shm/...OK

Checking for the skas3 patch in the host:

  - /proc/mm...found

  - PTRACE_FAULTINFO...found

  - PTRACE_LDT...found

UML running in SKAS3 mode

Checking that ptrace can change system call numbers...OK

Checking syscall emulation patch for ptrace...OK

Checking advanced syscall emulation patch for ptrace...OK

 

 

I have 1G of physical memory, and I start the UML with the "mem=768M"
argument. Pertinent shared memory information may be:

 

 $ mount | grep shm

none on /dev/shm type tmpfs (rw,size=1G)

 

$ df /dev/shm/

Filesystem           1K-blocks      Used Available Use% Mounted on

none                   1048576      1160   1047416   1% /dev/shm

 

Continuing past the breakpoint results in a seg fault:

 

Breakpoint 1, cramfs_uncompress_init () at
/ccase/wrlinux/build/mxs_cm_t0/build/linux-2.6.14-cgl/fs/cramfs/uncompre
ss.c:58

(gdb) cont

 

Program received signal SIGSEGV, Segmentation fault.

zlib_inflateInit2_ (z=0x8281c80, w=15, version=0xa80005c <Address
0xa80005c out of bounds>, stream_size=48) at
/ccase/wrlinux/build/mxs_cm_t0/build/linux-2.6.14-cgl/lib/zlib_inflate/i
nflate.c:58

 

  44 int zlib_inflateInit2_(

  45         z_streamp z,

  46         int w,

  47         const char *version,

  48         int stream_size

  49 )

  50 {

  51   if (version == NULL || version[0] != ZLIB_VERSION[0] ||

  52       stream_size != sizeof(z_stream) || z->workspace == NULL)

  53       return Z_VERSION_ERROR;

  54 

  55   /* initialize state */

  56   z->msg = NULL;

  57   z->state = &WS(z)->internal_state;

  58   z->state->blocks = NULL;

  59

 

(gdb) p *z

$11 = {next_in = 0x0, avail_in = 0, total_in = 0, next_out = 0x0,
avail_out = 0, total_out = 0, msg = 0x0, state = 0xa80005c, workspace =
0xa800000, data_type = 0, adler = 0, reserved = 0}

 

The backtrace is:

 

(gdb) bt

#0  zlib_inflateInit2_ (z=0x8281c80, w=15, version=0xa80005c <Address
0xa80005c out of bounds>, stream_size=48) at
/ccase/wrlinux/build/mxs_cm_t0/build/linux-2.6.14-cgl/lib/zlib_inflate/i
nflate.c:58

#1  0x0814c546 in zlib_inflateInit_ (z=0x8281c80, version=0x820e4a9
"1.1.3", stream_size=48) at
/ccase/wrlinux/build/mxs_cm_t0/build/linux-2.6.14-cgl/lib/zlib_inflate/i
nflate.c:110

#2  0x0810c95f in cramfs_uncompress_init () at
/ccase/wrlinux/build/mxs_cm_t0/build/linux-2.6.14-cgl/fs/cramfs/uncompre
ss.c:66

#3  0x08051d88 in init_cramfs_fs () at
/ccase/wrlinux/build/mxs_cm_t0/build/linux-2.6.14-cgl/fs/cramfs/inode.c:
577

#4  0x08049618 in do_initcalls () at
/ccase/wrlinux/build/mxs_cm_t0/build/linux-2.6.14-cgl/init/main.c:589

#5  0x080496d1 in do_basic_setup () at
/ccase/wrlinux/build/mxs_cm_t0/build/linux-2.6.14-cgl/init/main.c:631

#6  0x08058496 in init (unused=0x0) at
/ccase/wrlinux/build/mxs_cm_t0/build/linux-2.6.14-cgl/init/main.c:704

#7  0x0806c148 in run_kernel_thread (fn=0x8058460 <init>, arg=0x0,
jmp_ptr=0xa80005c) at
/ccase/wrlinux/build/mxs_cm_t0/build/linux-2.6.14-cgl/arch/um/os-Linux/p
rocess.c:285

#8  0x0805e24c in new_thread_handler (sig=10) at
include2/asm/thread_info.h:49

#9  <signal handler called>

 

The value of the argument "z" in frames #0 and #1 is the address of the
static variable "stream," of type z_stream, declared in uncompress.c.

 

Naively, I would say that vmalloc is misbehaving by returning a value
outside the process virtual memory map (also strange is that the shared
memory file has been deleted-is that significant?), but I'm sure there's
more to it than that-or maybe my analysis is just wrong. Can anyone
help?

 

Thanks in advance.

 

James T. Bradshaw

Firmware Engineer

Enterasys Networks

50 Minuteman Rd.

Andover, MA 01810

USA

Tel. (978) 684-1544 


[-- Attachment #1.2: Type: text/html, Size: 14755 bytes --]

[-- Attachment #2: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #3: Type: text/plain, Size: 194 bytes --]

_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [uml-devel] vmalloc and shared memory question
  2007-09-18 21:00 [uml-devel] vmalloc and shared memory question Bradshaw, James
@ 2007-09-19  0:34 ` Jeff Dike
  0 siblings, 0 replies; 2+ messages in thread
From: Jeff Dike @ 2007-09-19  0:34 UTC (permalink / raw)
  To: Bradshaw, James; +Cc: user-mode-linux-devel

On Tue, Sep 18, 2007 at 05:00:39PM -0400, Bradshaw, James wrote:
> I'm running into a problem with a 2.6.14.7 UML kernel and I wonder if
> anyone can help. The issue appears to be that memory allocated by a call
> to vmalloc lies outside the UML's virtual memory map, so that a
> subsequent pointer dereference ends up causing a seg fault.

> Continuing past the breakpoint results in a seg fault:

I think this is probably OK.  UML uses SIGSEGV for page faults, and
vmalloc memory is faulted in just like process memory.

(gdb) handle SIGSEGV nostop noprint pass

should have the effect that you want.

				Jeff

-- 
Work email - jdike at linux dot intel dot com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2007-09-19  0:35 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-09-18 21:00 [uml-devel] vmalloc and shared memory question Bradshaw, James
2007-09-19  0:34 ` Jeff Dike

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.