Re: [linux-audio-dev] shared memory problems

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] shared memory problems
From: Paul Davis (pbd_AT_Op.Net)
Date: Sun Nov 11 2001 - 17:14:51 EET


>> if you call shmat(2) or mmap(2) with a specific address, the kernel
>> assumes that you know what you're doing and unmaps anything thats
>> already mapped there.
>
>No it doesnt.

did you even bother to run my test program? look at the message from
reynald where he posted his results, then go read
linux/mm/mmap.c:do_mmap_pgoff(). it unconditionally calls:

        /* Clear old maps */
        error = -ENOMEM;
        if (do_munmap(mm, addr, len))
                goto free_vma;

this code is reached from sys_shmat() without any check on an existing
mapping at a *specified* address. use the source :)

>Whee - you're not trying to use pointers stored within a shared memory
>segment, no? Thats obviously broken and _will_ fail badly sooner than
>you think of it. Use offsets to the shared memory segment instead.

its not obviously broken. its one of the most well known uses of
shared memory, and its precisely why shmat (id, 0, 0) is documented to
work in the particular way that it does. this is a technique i've used
in the past on Interactive Unix, on Mach, on Ultrix and on Solaris.

>See above - you shalt not depend on being able to attach a shared memory
>segment to the same address in different processes.

yes, you can't *depend* on it. in theory, it might not work. but if 2
conditions are satisfied, it will:

           1) for the particular set of mappings in question,
              they are all initiated in the "client" processes
              before other calls to mmap(2) and shmat(2) with 0
              as the requested address.

           2) shmat works in the fashion described by the man page,
              using an unmapped area that other mechanisms will not
              operate on (like ld.so)

these are easy enough to satisfy (with a small wrapper around
shmat(2)). i've also written to the kernel list to ask why sys_shmat()
doesn't conform to the SVID specification in its use of the "unmapped
area".

the one limitation is if you use *2* API's that try this trick in the
same process. that one is going to be very hard to make work without
doing old-x86 style "segment:offset" addressing. for now, i don't want
to go there.
                     
--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sun Nov 11 2001 - 17:14:14 EET