Hi Russel,
Russell King <rmk@arm.linux.org.uk> writes:
> Christoph Rohland writes:
> > Or the ARM one? (The basic principle of shm was always the same
> > and this could have been noticed when the ARM pte handling was
> > designed.)
>
> ARM pte handling has not changed since 2.3.0. I think you
> overlooked the way the ARM handles its ptes. ;(
Yes, you are right. I did not carefully check your explanation of the
ARM pte handling. The breakage was of course introduced with S/390
requirement to use something else than memset.
> > I think we should simply allocate the indirect blocks with pte_alloc
> > in chunks like we do it now with kmalloc. In 2.5 the shm code should
> > definitely integrated into the page cache.
> >
> > I will work out a patch beginning of next week. I just now have no
> > access to the current kernel sources.
>
> Hmm, do we need larger vmalloc areas? Already, one of the ARM architectures
> has up to 512MB bytes of vmalloc area rather than the conventional 256MB
> limit.
We cannot increase it since this would further reduce the available
kernel address space.
> > > 3. Is shmctl(..., SHM_LOCK, ...) honoured? It looks like there
> > > is code present to set a flag (PRV_LOCKED), and return the
> > > status of this bit to usermode via SHM_STAT/IPC_STAT, but
> > > nothing to actually prevent the shared memory segment being
> > > swapped.
> >
> > This is honoured in shm_swap.
>
> Are you sure? PRV_LOCKED != SHM_LOCKED. Here are the definitions:
[...]
> However, shm_swap only checks the SHM_LOCKED bit, which is NOT the same as
> PRV_LOCKED:
>
> shp = shm_get(swap_id);
> if(shp==NULL || shp->shm_flags & SHM_LOCKED) {
> next_id:
> swap_idx = 0;
> if (++swap_id > shm_ids.max_id) {
>
> Hence, setting SHM_LOCK on an ID does not set SHM_LOCKED in shp->shm_flags,
> and therefore does not lock that region.
And here you are right again. This is also a typo. It should of course
check PRV_LOCKED instead of SHM_LOCKED. SHM_LOCKED is only used for
ABI compatibility.
Thanks for spotting this.
Greetings
Christoph
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:19 EST