Re: SHM stuff - Reason for Oopsen discovered

From: Christoph Rohland (
Date: Sat May 27 2000 - 13:33:59 EST

Hi Russel,

Russell King <> 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
> 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:19 EST