Re: ipc,sem: sysv semaphore scalability

From: Andrew Morton
Date: Thu Mar 21 2013 - 17:11:07 EST

On Wed, 20 Mar 2013 15:55:30 -0400 Rik van Riel <riel@xxxxxxxxxxx> wrote:

> This series makes the sysv semaphore code more scalable,
> by reducing the time the semaphore lock is held, and making
> the locking more scalable for semaphore arrays with multiple
> semaphores.
> The first four patches were written by Davidlohr Buesso, and
> reduce the hold time of the semaphore lock.
> The last three patches change the sysv semaphore code locking
> to be more fine grained, providing a performance boost when
> multiple semaphores in a semaphore array are being manipulated
> simultaneously.

These patches conflict pretty badly with Peter's:


(they're at

We're in a bit of a mess at present.

Last month Peter sent a ten-patch series which fixed an oops (Subject:
"ipc MSG_COPY fixes"). The series did other stuff, so we merged into
mainline just two bugfix patches. Then davej hit a trinity oops
(Subject: "ipc/testmsg GPF.") and testing confirmed that the remaining
eight patches in Peter's series fixed that up. Nobody has yet
identified which of the eight does the good deed. So we need to

a) revert the original two fixes "ipc: fix potential oops when src
msg > 4k w/ MSG_COPY" and "ipc: don't allocate a copy larger than
max" or

b) try reverting "ipc: don't allocate a copy larger than max", as
"ipc: fix potential oops when src msg > 4k w/ MSG_COPY" looks pretty
harmless or

c) work out which of the remaining 8 fixes the new oops and merge that or

d) merge all 8 fixes or

e) something else.

Whichever way we go, we should get a wiggle on - this has been hanging
around for too long. Dave, do you have time to determine whether
reverting 88b9e456b1649722673ff ("ipc: don't allocate a copy larger
than max") fixes things up?

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