All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Josh Triplett <josh@joshtriplett.org>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	Dan Carpenter <error27@gmail.com>,
	Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.de>,
	alsa-devel@alsa-project.org, kernel-janitors@vger.kernel.org,
	linux-sparse@vger.kernel.org
Subject: Re: [patch 1/2] OSS: soundcard: locking bug in sound_ioctl()
Date: Tue, 12 Oct 2010 08:39:14 +0200	[thread overview]
Message-ID: <201010120839.15257.arnd@arndb.de> (raw)
In-Reply-To: <20101011222307.GA10570@feather>

On Tuesday 12 October 2010 00:23:08 Josh Triplett wrote:
> Assuming that the underlying function only returns zero/non-zero and
> that the actual return value doesn't matter, then you can use the
> __cond_lock macro from compiler.h for this:
> 
> # define __cond_lock(x,c)       ((c) ? ({ __acquire(x); 1; }) : 0)
> 

The return from mutex_lock_{killable,interruptible} is an error
value, not true/false, so it actually matters. We know that the only
possible error that is currently returned is -EINTR though, so we
could do a similar trick and define another

#define __cond_mutex(x, c)	((!c) ? ({ __acquire(x); 0; }) : -EINTR)

My fear was that this would impact code generation.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Josh Triplett <josh@joshtriplett.org>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	Dan Carpenter <error27@gmail.com>,
	Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.de>,
	alsa-devel@alsa-project.org, kernel-janitors@vger.kernel.org,
	linux-sparse@vger.kernel.org
Subject: Re: [patch 1/2] OSS: soundcard: locking bug in sound_ioctl()
Date: Tue, 12 Oct 2010 06:39:14 +0000	[thread overview]
Message-ID: <201010120839.15257.arnd@arndb.de> (raw)
In-Reply-To: <20101011222307.GA10570@feather>

On Tuesday 12 October 2010 00:23:08 Josh Triplett wrote:
> Assuming that the underlying function only returns zero/non-zero and
> that the actual return value doesn't matter, then you can use the
> __cond_lock macro from compiler.h for this:
> 
> # define __cond_lock(x,c)       ((c) ? ({ __acquire(x); 1; }) : 0)
> 

The return from mutex_lock_{killable,interruptible} is an error
value, not true/false, so it actually matters. We know that the only
possible error that is currently returned is -EINTR though, so we
could do a similar trick and define another

#define __cond_mutex(x, c)	((!c) ? ({ __acquire(x); 0; }) : -EINTR)

My fear was that this would impact code generation.

	Arnd

  reply	other threads:[~2010-10-12  6:39 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-10 17:33 [patch 1/2] OSS: soundcard: locking bug in sound_ioctl() Dan Carpenter
2010-10-10 17:33 ` Dan Carpenter
2010-10-10 18:39 ` Arnd Bergmann
2010-10-10 18:39   ` Arnd Bergmann
2010-10-11  8:13   ` Arnd Bergmann
2010-10-11  8:13     ` Arnd Bergmann
2010-10-11  8:50     ` Johannes Berg
2010-10-11  8:50       ` Johannes Berg
2010-10-11 10:50       ` Arnd Bergmann
2010-10-11 10:50         ` Arnd Bergmann
2010-10-11 10:52         ` Johannes Berg
2010-10-11 10:52           ` Johannes Berg
2010-10-11 18:54           ` Josh Triplett
2010-10-11 18:54             ` Josh Triplett
2010-10-11 20:42             ` Arnd Bergmann
2010-10-11 20:42               ` Arnd Bergmann
2010-10-11 22:23               ` Josh Triplett
2010-10-11 22:23                 ` Josh Triplett
2010-10-12  6:39                 ` Arnd Bergmann [this message]
2010-10-12  6:39                   ` Arnd Bergmann
2010-10-12  6:43                   ` Josh Triplett
2010-10-12  6:43                     ` Josh Triplett
2010-10-11 11:59 ` Takashi Iwai
2010-10-11 11:59   ` Takashi Iwai

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=201010120839.15257.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=error27@gmail.com \
    --cc=johannes@sipsolutions.net \
    --cc=josh@joshtriplett.org \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-sparse@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=tiwai@suse.de \
    /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.