|
From: Tom H. <to...@co...> - 2005-10-04 12:13:45
|
It turns out that shmdt is a bit broken since the merge... The problem is that the post handler unmaps the whole of the segment containing the specified address which is really bad if the shared memory segment has been merged with an adjacent segment by the address space manager because they are compatible. I think the old system mostly got away with it because there was a special flag for shared memory which probably stopped it merging most of the time. I suspect that this problem is the current cause of the shared memory problem reported on the users list recently. The real problem is that shmdt is only given an address and I don't think there is any way (other than walking /proc/self/maps) to get the size from that to do the unmap properly. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Tom H. <to...@co...> - 2005-10-04 13:57:25
|
In message <yek...@de...>
Tom Hughes <to...@co...> wrote:
> It turns out that shmdt is a bit broken since the merge...
>
> The problem is that the post handler unmaps the whole of the segment
> containing the specified address which is really bad if the shared
> memory segment has been merged with an adjacent segment by the address
> space manager because they are compatible.
>
> I think the old system mostly got away with it because there was a
> special flag for shared memory which probably stopped it merging most
> of the time.
I've had a go at fixing this and my best scheme so far is to
create a new SkShmC segment type for shared memory segments and
then prevent the address space manager from merging those segments.
The only problem with that is notifying aspacem that the memory is
a shared memory segment - I've stolen a bit from the mmap flags at
the moment but that is nasty so I'm thinking that adding a special
notify function to aspacem for shm segments might be better?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-10-04 15:16:23
|
> > I think the old system mostly got away with it because there was a > > special flag for shared memory which probably stopped it merging most > > of the time. > > I've had a go at fixing this and my best scheme so far is to > create a new SkShmC segment type for shared memory segments and > then prevent the address space manager from merging those segments. > > The only problem with that is notifying aspacem that the memory is > a shared memory segment - I've stolen a bit from the mmap flags at > the moment but that is nasty so I'm thinking that adding a special > notify function to aspacem for shm segments might be better? SkShmC and a new notify function sounds good to me. Can I just check (semantics): a shared memory segment cannot also be a file or anonymous mapping, is that correct? J |
|
From: Tom H. <to...@co...> - 2005-10-04 15:26:19
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
>> I've had a go at fixing this and my best scheme so far is to
>> create a new SkShmC segment type for shared memory segments and
>> then prevent the address space manager from merging those segments.
>>
>> The only problem with that is notifying aspacem that the memory is
>> a shared memory segment - I've stolen a bit from the mmap flags at
>> the moment but that is nasty so I'm thinking that adding a special
>> notify function to aspacem for shm segments might be better?
>
> SkShmC and a new notify function sounds good to me.
>
> Can I just check (semantics): a shared memory segment
> cannot also be a file or anonymous mapping, is that correct?
Effectively - as is noted in the source there is (on linux) an inode
and filename associated with the mapping in the kernel but those aren't
really exposed to user space beyond appearing in the maps file.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|