From: Josh Triplett <josh@joshtriplett.org>
To: Arnd Bergmann <arnd@arndb.de>
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: Mon, 11 Oct 2010 23:43:26 -0700 [thread overview]
Message-ID: <20101012064326.GB1702@feather> (raw)
In-Reply-To: <201010120839.15257.arnd@arndb.de>
On Tue, Oct 12, 2010 at 08:39:14AM +0200, Arnd Bergmann wrote:
> 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.
If __cond_lock doesn't fit, then you could just define a generic wrapper
to capture the pattern of preserving a function's return value, and use
that for all the mutex calls. And if you just preserve the return
value, and __acquire compiles to nothing for GCC, then GCC should just
optimize away the extra copy into a local variable.
- Josh Triplett
WARNING: multiple messages have this Message-ID (diff)
From: Josh Triplett <josh@joshtriplett.org>
To: Arnd Bergmann <arnd@arndb.de>
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:43:26 +0000 [thread overview]
Message-ID: <20101012064326.GB1702@feather> (raw)
In-Reply-To: <201010120839.15257.arnd@arndb.de>
On Tue, Oct 12, 2010 at 08:39:14AM +0200, Arnd Bergmann wrote:
> 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.
If __cond_lock doesn't fit, then you could just define a generic wrapper
to capture the pattern of preserving a function's return value, and use
that for all the mutex calls. And if you just preserve the return
value, and __acquire compiles to nothing for GCC, then GCC should just
optimize away the extra copy into a local variable.
- Josh Triplett
next prev parent reply other threads:[~2010-10-12 6:43 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
2010-10-12 6:39 ` Arnd Bergmann
2010-10-12 6:43 ` Josh Triplett [this message]
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=20101012064326.GB1702@feather \
--to=josh@joshtriplett.org \
--cc=alsa-devel@alsa-project.org \
--cc=arnd@arndb.de \
--cc=error27@gmail.com \
--cc=johannes@sipsolutions.net \
--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.