From: Al Viro <viro@ZenIV.linux.org.uk>
To: Lionel Debroux <lionel_debroux@yahoo.fr>
Cc: linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] drm: make variable named "refcount" atomic, like most refcounts in the kernel.
Date: Sat, 26 Apr 2014 16:35:37 +0000 [thread overview]
Message-ID: <20140426163537.GF18016@ZenIV.linux.org.uk> (raw)
In-Reply-To: <248367.21250.bm@smtp144.mail.ir2.yahoo.com>
On Sat, Apr 26, 2014 at 06:06:15PM +0200, Lionel Debroux wrote:
> Based on PaX.
Lovely - cargo-cult at its finest. "Most refcounts are atomic, must be
good medicine. Shaman has spoken".
> - int refcount;
> + atomic_t refcount;
... therefore, all places that modify that sucker will have to be visible
in the patch. And those are
> - ++item->refcount;
> + atomic_inc(&item->refcount);
> ref->object = item->object;
> mutex_unlock(&item->mutex);
and
> mutex_lock(&item->mutex);
> - BUG_ON(item->refcount = 0);
> + BUG_ON(atomic_read(&item->refcount) = 0);
> BUG_ON(ref->object != item->object);
> - if (--item->refcount = 0) {
> + if (atomic_dec_and_test(&item->refcount)) {
> ref->release(ref);
> item->object = NULL;
Mind explaining how could we manage to reach either without item->mutex
being held, serializing the modifications?
NAK, in case it's not obvious from the above...
WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Lionel Debroux <lionel_debroux@yahoo.fr>
Cc: linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] drm: make variable named "refcount" atomic, like most refcounts in the kernel.
Date: Sat, 26 Apr 2014 17:35:37 +0100 [thread overview]
Message-ID: <20140426163537.GF18016@ZenIV.linux.org.uk> (raw)
In-Reply-To: <248367.21250.bm@smtp144.mail.ir2.yahoo.com>
On Sat, Apr 26, 2014 at 06:06:15PM +0200, Lionel Debroux wrote:
> Based on PaX.
Lovely - cargo-cult at its finest. "Most refcounts are atomic, must be
good medicine. Shaman has spoken".
> - int refcount;
> + atomic_t refcount;
... therefore, all places that modify that sucker will have to be visible
in the patch. And those are
> - ++item->refcount;
> + atomic_inc(&item->refcount);
> ref->object = item->object;
> mutex_unlock(&item->mutex);
and
> mutex_lock(&item->mutex);
> - BUG_ON(item->refcount == 0);
> + BUG_ON(atomic_read(&item->refcount) == 0);
> BUG_ON(ref->object != item->object);
> - if (--item->refcount == 0) {
> + if (atomic_dec_and_test(&item->refcount)) {
> ref->release(ref);
> item->object = NULL;
Mind explaining how could we manage to reach either without item->mutex
being held, serializing the modifications?
NAK, in case it's not obvious from the above...
next prev parent reply other threads:[~2014-04-26 16:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-26 16:06 [PATCH] drm: make variable named "refcount" atomic, like most refcounts in the kernel Lionel Debroux
2014-04-26 16:06 ` Lionel Debroux
2014-04-26 16:35 ` Al Viro [this message]
2014-04-26 16:35 ` Al Viro
2014-04-26 17:03 ` Mateusz Guzik
2014-04-26 17:03 ` Mateusz Guzik
2014-04-26 20:09 ` Lionel Debroux
2014-04-26 20:09 ` Lionel Debroux
2014-04-26 23:00 ` Al Viro
2014-04-26 23:00 ` Al Viro
2014-04-26 23:42 ` Mateusz Guzik
2014-04-26 23:42 ` Mateusz Guzik
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=20140426163537.GF18016@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lionel_debroux@yahoo.fr \
/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.