All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org,
	Manfred Spraul <manfred@colorfullife.com>,
	Davidlohr Bueso <davidlohr@hp.com>,
	Rafael Aquini <aquini@redhat.com>
Subject: Re: [PATCH] ipc,sem block sem_lock on sma->lock during sma initialization
Date: Fri, 21 Nov 2014 15:29:27 -0500	[thread overview]
Message-ID: <546FA0A7.2010507@redhat.com> (raw)
In-Reply-To: <20141121120930.3cd8d0f233f9670d689de672@linux-foundation.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/21/2014 03:09 PM, Andrew Morton wrote:
> On Fri, 21 Nov 2014 14:52:26 -0500 Rik van Riel <riel@redhat.com>
> wrote:
> 
>> When manipulating just one semaphore with semop, sem_lock only
>> takes that single semaphore's lock. This creates a problem during
>> initialization of the semaphore array, when the data structures
>> used by sem_lock have not been set up yet. The sma->lock is
>> already held by newary, and we just have to make sure everything
>> else waits on that lock during initialization.
>> 
>> Luckily it is easy to make sem_lock wait on the sma->lock, by
>> pretending there is a complex operation in progress while the sma
>> is being initialized.
>> 
>> The newary function already zeroes sma->complex_count before
>> unlocking the sma->lock.
> 
> What are the runtime effects of the bug?
> 

NULL pointer dereference in spin_lock from sem_lock,
if it is called before sma->sem_base has been pointed
somewhere valid.

- -- 
All rights reversed
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUb6CnAAoJEM553pKExN6Dh8oH/iFVqwrukMkZp7ViFTC84DVK
m8rw6CWk76kEvi6BWx977nT26e7ZfiOCxrhyy/gETOnUDJMgQrn7cFMFd6Ja/2yG
uGCq5WcvVLDiLw7ij9Rqu4C6aHcICserzgfXwWV0XAa5TZOEqvg6FKZgCUHN6sxM
ek0TV0oq/VQvRwAQk/MFDOv38PydH2LH1Z3wXk7JVlhEMX062a4EoxTAe8Teed2p
X5+mTOl4jezog2rFJxFe0Cp8PxpqAi4f1kDugQKohZ3TpUFqH4VKZYmTtvHvpNDH
oeHjnRv632N8KuU2lvIi7EGJGu0Y+ReyOr+NQtozlRYCTPuY/rezkbBmgVwu4iY=
=CDvy
-----END PGP SIGNATURE-----

  reply	other threads:[~2014-11-21 20:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-21 19:52 [PATCH] ipc,sem block sem_lock on sma->lock during sma initialization Rik van Riel
2014-11-21 20:07 ` Rafael Aquini
2014-11-21 20:09 ` Andrew Morton
2014-11-21 20:29   ` Rik van Riel [this message]
2014-11-21 20:42     ` Andrew Morton
2014-11-21 23:03       ` Rik van Riel
2014-11-22  0:56         ` Davidlohr Bueso
2014-11-22  3:40           ` Rik van Riel
2014-11-22 13:56             ` Manfred Spraul
2014-11-22 15:53               ` Rik van Riel
2014-11-22 19:14     ` Manfred Spraul
2014-11-22 20:14       ` Rik van Riel
2014-11-23 18:23 ` Manfred Spraul
2014-11-23 21:03   ` Rik van Riel
2014-11-23 21:36     ` Davidlohr Bueso
2014-11-24 10:41       ` Rafael Aquini
2014-11-24 20:49   ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=546FA0A7.2010507@redhat.com \
    --to=riel@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=aquini@redhat.com \
    --cc=davidlohr@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.