From: Randy Dunlap <rdunlap-/UHa2rfvQTnk1uMJSBkQmQ@public.gmane.org>
To: Hugh Dickins <hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Cc: Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Eric Dumazet
<eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>,
Manfred Spraul <manfred-nhLOkwUX5cPe2c5cEj3t2g@public.gmane.org>,
KAMEZAWA Hiroyuki
<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>,
Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
Ying Han <yinghan-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Greg Thelen <gthelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 1/3] idr: make idr_get_next() good for rcu_read_lock()
Date: Sat, 21 Jan 2012 12:43:02 -0800 [thread overview]
Message-ID: <4F1B2356.4040302@xenotime.net> (raw)
In-Reply-To: <alpine.LSU.2.00.1201201922110.1396-fupSdm12i1nKWymIFiNcPA@public.gmane.org>
On 01/20/2012 07:45 PM, Hugh Dickins wrote:
> On Fri, 20 Jan 2012, Andrew Morton wrote:
>> On Thu, 19 Jan 2012 12:48:48 -0800 (PST)
>> Hugh Dickins <hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
>>> Copied comment on RCU locking from idr_find().
>>>
>>> + *
>>> + * This function can be called under rcu_read_lock(), given that the leaf
>>> + * pointers lifetimes are correctly managed.
>>
>> Awkward comment. It translates to "..., because the leaf pointers
>> lifetimes are correctly managed".
>>
>> Is that what we really meant? Or did we mean "..., provided the leaf
>> pointers lifetimes are correctly managed"?
>
> You are right, and part of me realized that even as I copied in the
> comment. I wanted to express the same optimism for idr_get_next()
> as was already expressed for idr_find() - whatever it meant ;)
>
> I thought it was meaning a bit of both: idr.c is managing its end well
> enough that rcu_read_lock() can now be used, but the caller has to
> manage their locking and lifetimes appropriately too.
>
>>
>> Also, "pointers" should have been "pointer" or "pointer's"!
>
> You're afraid of Linus turning his "its/it's" wrath from Al to yourself.
>
> Since "lifetimes" is in the plural, I think it would have to be
> "pointers'" - I _think_ that's correct, rather than "pointers's".
That seems correct to me also.
> But then, it's not the lifetimes of the pointers, but the lifetimes
> of the objects that they point to, that's in question. So what it
> ought to say is...
>
> ... falls asleep.
ack.
and thanks for doing all of that radix tree test harness work, Hugh.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
WARNING: multiple messages have this Message-ID (diff)
From: Randy Dunlap <rdunlap@xenotime.net>
To: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Tejun Heo <tj@kernel.org>, Eric Dumazet <eric.dumazet@gmail.com>,
Li Zefan <lizf@cn.fujitsu.com>,
Manfred Spraul <manfred@colorfullife.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Ying Han <yinghan@google.com>, Greg Thelen <gthelen@google.com>,
cgroups@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] idr: make idr_get_next() good for rcu_read_lock()
Date: Sat, 21 Jan 2012 12:43:02 -0800 [thread overview]
Message-ID: <4F1B2356.4040302@xenotime.net> (raw)
In-Reply-To: <alpine.LSU.2.00.1201201922110.1396@eggly.anvils>
On 01/20/2012 07:45 PM, Hugh Dickins wrote:
> On Fri, 20 Jan 2012, Andrew Morton wrote:
>> On Thu, 19 Jan 2012 12:48:48 -0800 (PST)
>> Hugh Dickins <hughd@google.com> wrote:
>>> Copied comment on RCU locking from idr_find().
>>>
>>> + *
>>> + * This function can be called under rcu_read_lock(), given that the leaf
>>> + * pointers lifetimes are correctly managed.
>>
>> Awkward comment. It translates to "..., because the leaf pointers
>> lifetimes are correctly managed".
>>
>> Is that what we really meant? Or did we mean "..., provided the leaf
>> pointers lifetimes are correctly managed"?
>
> You are right, and part of me realized that even as I copied in the
> comment. I wanted to express the same optimism for idr_get_next()
> as was already expressed for idr_find() - whatever it meant ;)
>
> I thought it was meaning a bit of both: idr.c is managing its end well
> enough that rcu_read_lock() can now be used, but the caller has to
> manage their locking and lifetimes appropriately too.
>
>>
>> Also, "pointers" should have been "pointer" or "pointer's"!
>
> You're afraid of Linus turning his "its/it's" wrath from Al to yourself.
>
> Since "lifetimes" is in the plural, I think it would have to be
> "pointers'" - I _think_ that's correct, rather than "pointers's".
That seems correct to me also.
> But then, it's not the lifetimes of the pointers, but the lifetimes
> of the objects that they point to, that's in question. So what it
> ought to say is...
>
> ... falls asleep.
ack.
and thanks for doing all of that radix tree test harness work, Hugh.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Randy Dunlap <rdunlap@xenotime.net>
To: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Tejun Heo <tj@kernel.org>, Eric Dumazet <eric.dumazet@gmail.com>,
Li Zefan <lizf@cn.fujitsu.com>,
Manfred Spraul <manfred@colorfullife.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Ying Han <yinghan@google.com>, Greg Thelen <gthelen@google.com>,
cgroups@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] idr: make idr_get_next() good for rcu_read_lock()
Date: Sat, 21 Jan 2012 12:43:02 -0800 [thread overview]
Message-ID: <4F1B2356.4040302@xenotime.net> (raw)
In-Reply-To: <alpine.LSU.2.00.1201201922110.1396@eggly.anvils>
On 01/20/2012 07:45 PM, Hugh Dickins wrote:
> On Fri, 20 Jan 2012, Andrew Morton wrote:
>> On Thu, 19 Jan 2012 12:48:48 -0800 (PST)
>> Hugh Dickins <hughd@google.com> wrote:
>>> Copied comment on RCU locking from idr_find().
>>>
>>> + *
>>> + * This function can be called under rcu_read_lock(), given that the leaf
>>> + * pointers lifetimes are correctly managed.
>>
>> Awkward comment. It translates to "..., because the leaf pointers
>> lifetimes are correctly managed".
>>
>> Is that what we really meant? Or did we mean "..., provided the leaf
>> pointers lifetimes are correctly managed"?
>
> You are right, and part of me realized that even as I copied in the
> comment. I wanted to express the same optimism for idr_get_next()
> as was already expressed for idr_find() - whatever it meant ;)
>
> I thought it was meaning a bit of both: idr.c is managing its end well
> enough that rcu_read_lock() can now be used, but the caller has to
> manage their locking and lifetimes appropriately too.
>
>>
>> Also, "pointers" should have been "pointer" or "pointer's"!
>
> You're afraid of Linus turning his "its/it's" wrath from Al to yourself.
>
> Since "lifetimes" is in the plural, I think it would have to be
> "pointers'" - I _think_ that's correct, rather than "pointers's".
That seems correct to me also.
> But then, it's not the lifetimes of the pointers, but the lifetimes
> of the objects that they point to, that's in question. So what it
> ought to say is...
>
> ... falls asleep.
ack.
and thanks for doing all of that radix tree test harness work, Hugh.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
next prev parent reply other threads:[~2012-01-21 20:43 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-19 6:05 [PATCH] memcg: restore ss->id_lock to spinlock, using RCU for next Hugh Dickins
2012-01-19 6:05 ` Hugh Dickins
[not found] ` <alpine.LSU.2.00.1201182155480.7862-fupSdm12i1nKWymIFiNcPA@public.gmane.org>
2012-01-19 6:58 ` KAMEZAWA Hiroyuki
2012-01-19 6:58 ` KAMEZAWA Hiroyuki
2012-01-19 6:58 ` KAMEZAWA Hiroyuki
2012-01-19 7:33 ` Eric Dumazet
2012-01-19 7:33 ` Eric Dumazet
2012-01-19 7:33 ` Eric Dumazet
2012-01-19 12:28 ` Tejun Heo
2012-01-19 12:28 ` Tejun Heo
2012-01-19 12:28 ` Tejun Heo
2012-01-19 13:30 ` Eric Dumazet
2012-01-19 13:30 ` Eric Dumazet
2012-01-19 13:30 ` Eric Dumazet
2012-01-19 20:46 ` Hugh Dickins
2012-01-19 20:46 ` Hugh Dickins
2012-01-19 20:48 ` [PATCH 1/3] idr: make idr_get_next() good for rcu_read_lock() Hugh Dickins
2012-01-19 20:48 ` Hugh Dickins
2012-01-20 23:48 ` Andrew Morton
2012-01-20 23:48 ` Andrew Morton
2012-01-21 3:45 ` Hugh Dickins
2012-01-21 3:45 ` Hugh Dickins
[not found] ` <alpine.LSU.2.00.1201201922110.1396-fupSdm12i1nKWymIFiNcPA@public.gmane.org>
2012-01-21 20:43 ` Randy Dunlap [this message]
2012-01-21 20:43 ` Randy Dunlap
2012-01-21 20:43 ` Randy Dunlap
[not found] ` <alpine.LSU.2.00.1201191235330.29542-fupSdm12i1nKWymIFiNcPA@public.gmane.org>
2012-01-19 20:50 ` [PATCH 2/3] cgroup: revert ss_id_lock to spinlock Hugh Dickins
2012-01-19 20:50 ` Hugh Dickins
2012-01-19 20:50 ` Hugh Dickins
2012-01-19 20:51 ` [PATCH 3/3] memcg: let css_get_next() rely upon rcu_read_lock() Hugh Dickins
2012-01-19 20:51 ` Hugh Dickins
[not found] ` <alpine.LSU.2.00.1201191250210.29542-fupSdm12i1nKWymIFiNcPA@public.gmane.org>
2012-01-19 20:53 ` Tejun Heo
2012-01-19 20:53 ` Tejun Heo
2012-01-19 20:53 ` Tejun Heo
2012-01-19 7:31 ` [PATCH] memcg: restore ss->id_lock to spinlock, using RCU for next Li Zefan
2012-01-19 7:31 ` Li Zefan
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=4F1B2356.4040302@xenotime.net \
--to=rdunlap-/uha2rfvqtnk1umjsbkqmq@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=gthelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org \
--cc=manfred-nhLOkwUX5cPe2c5cEj3t2g@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=yinghan-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.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.