Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1243836
| From | Manfred Spraul <manfred@colorfullife.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: PROBLEM: Concurrency issue in sem_lock |
| Date | 2015-10-10 09:00 +0200 |
| Message-ID | <qhWim-1C7-5@gated-at.bofh.it> (permalink) |
| References | <qhBdT-54V-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
[Multipart message — attachments visible in raw view] - view raw
Hi,
On 10/09/2015 10:24 AM, Felix Hübner wrote:
> Hi all,
>
> I have just reported a concurrency issue in the implementation of
> sem_lock, see https://bugzilla.kernel.org/show_bug.cgi?id=105651
>
> [...]
> # P0 does spin_lock(&sem->lock); in line 336.
>
> spin_lock(&sem->lock);
[...]
> # P2 performs rest of semtimedop, increments complex_count and ends up
> in line 1961 and starts to sleep.
>
> return -1;
> }
That is the problem: semtimedop() increments complex_count - thus
sem_wait_array() returns without a spin_unlock_wait() loop - but P0
already owns spin_lock(&sem->lock).
How do we want to fix it?
- revert my patch (simplify code, but slower for one corner case)
- add the missing sem_wait_array (more complex, but also better for
complex semops).
what do you think?
(patch untested)
--
Manfred
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
PROBLEM: Concurrency issue in sem_lock Felix Hübner <felixh@informatik.uni-bremen.de> - 2015-10-09 10:30 +0200 Re: PROBLEM: Concurrency issue in sem_lock Manfred Spraul <manfred@colorfullife.com> - 2015-10-10 09:00 +0200
csiph-web