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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).