SHM stuff - Reason for Oopsen discovered

From: Russell King (
Date: Thu May 25 2000 - 07:32:14 EST


I've found the following "oddities" in the shm code:

1. shm_alloc seems to assume that "sizeof(*pte) * PTRS_PER_PTE < PAGE_SIZE"
   Is this true of all architectures? It's a little wasteful on ARM because
   sizeof(*pte) * PTRS_PER_PTE == 1024, PAGE_SIZE == 4096.

   A cleaner way would be to define and use PTRS_PER_PAGE, especially since
   it doesn't actually reflect a page table, or even better and preferred
   use vmalloc() to allocate a virtually-contiguous area.

   I'm assuming that shm_alloc is doing all this crud so that it can allocate
   enough memory.

2. It appears that zshm (and therefore sysvipc) is now required for anonymous
   mmap()s. If you configure a kernel without sysvipc, you can no longer
   do anonymous mmap()s - is this expected?

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.

Also, I've found my problem, and its ARM specific! It's related to point
(1) above.

On the ARM, we don't have enough bits in the page tables to store the pte
bits, so what we do is the following:

           | |
           | | cpu ptes
           | |
 pteptr -> | |
           | |
           | | kernel-visible ptes
           | |
           | |

Unfortunately, because ipc/shm.c assumes that it can make assumptions about
pte pointers and the actions that pte_clear does and so forth, it doesn't
work well. On the ARM, the memory before the pteptr will get corrupted.

Really, the code in shm.c needs to be re-written so its not making these
braindead assumptions, and if its necessary to use the pte stuff, it MUST
use the architecture functions to allocate pte tables and the like.

Currently, I view the shm code as broken to the extreme. I'm not sure what
the correct way to proceed is - I've been trying to steer away from the
Linux memory management stuff recently, so I'm reluctant to get more
involved with this, since its going to require a re-write in the shm
allocation/fault/swapping area.
  |_____| ------------------------------------------------- ---+---+-
  | | Russell King --- ---
  | | | | / / |
  | +-+-+ --- -+-
  / | THE developer of ARM Linux |+| /|\
 / | | | --- |
    +-+-+ ------------------------------------------------- /\\\ |

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:14 EST