From: cakturk@gmail.com (Cihangir Akturk)
To: kernelnewbies@lists.kernelnewbies.org
Subject: ACCESS_ONCE usage inside llist_add_batch function
Date: Wed, 4 Mar 2015 02:41:07 +0200 [thread overview]
Message-ID: <20150304004106.GA19781@lg> (raw)
In-Reply-To: <CAK-9PRCf_fzfACMhTbwDezz-ZZhXOUCShswMoQe_YjqOd+XGvw@mail.gmail.com>
On Tue, Mar 03, 2015 at 12:08:41PM +0530, Chinmay V S wrote:
> On Tue, Mar 3, 2015 at 11:51 AM, John de la Garza <john@jjdev.com> wrote:
> > On Sat, Feb 28, 2015 at 10:12:23PM +0200, Cihangir Akturk wrote:
> >> Reading the lib/llist.c file in the kernel sources, I came across
> >> the llist_add_bach function defined like this;
> >>
> >> bool llist_add_batch(struct llist_node *new_first, struct llist_node *new_last,
> >> struct llist_head *head)
> >> {
> >> struct llist_node *first;
> >>
> >> do {
> >> new_last->next = first = ACCESS_ONCE(head->first);
> >> } while (cmpxchg(&head->first, first, new_first) != first);
> >>
> >> return !first;
> >> }
> >>
> >> One thing bugging my mind is the ACCESS_ONCE macro. Is it really
> >> needed here ? I mean I would write this function with ACCES_ONCE
> >> moved outside the loop like as follows;
>
> Replace ACCESS_ONCE() with volatile and you would most likely
> understand that it is not what it looks like.
> A very unfortunate consequence of what the macro is named.
> A better name probably would have been - REALLY_REALLY_ACCESS_ONCE()
Thanks for the reply but this isn't the question I asked.
> Checkout http://lwn.net/Articles/624126/ for some obscure bugs and
> future plans for this.
I didn't know the non-scalar type related issue and there is a
READ_ONCE macro out there but again there is nothing to do with
my question because as you can see there isn't any non-scalar
access being done in the code.
So my question is this; do we really need to use
ACCESS_ONCE(head->first) on every iteration instead of just using the
return value of cmpxchg function like as follows ? [1]
[1] sample code
struct llist_node *first, *old_first;
old_first = ACCESS_ONCE(head->first);
for (;;) {
first = old_first;
new_last->next = old_first;
old_first = cmpxchg(&head->first, first, new_first);
if (old_first == first)
break;
}
next prev parent reply other threads:[~2015-03-04 0:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-28 20:12 ACCESS_ONCE usage inside llist_add_batch function Cihangir Akturk
2015-03-03 6:21 ` John de la Garza
2015-03-03 6:38 ` Chinmay V S
2015-03-04 0:41 ` Cihangir Akturk [this message]
2015-03-04 8:34 ` Arun KS
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=20150304004106.GA19781@lg \
--to=cakturk@gmail.com \
--cc=kernelnewbies@lists.kernelnewbies.org \
/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.