[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5711217A.6050003@hpe.com>
Date: Fri, 15 Apr 2016 13:14:34 -0400
From: Waiman Long <waiman.long@....com>
To: Boqun Feng <boqun.feng@...il.com>
CC: Alexander Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.com>,
Jeff Layton <jlayton@...chiereds.net>,
"J. Bruce Fields" <bfields@...ldses.org>,
Tejun Heo <tj@...nel.org>,
Christoph Lameter <cl@...ux-foundation.org>,
<linux-fsdevel@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Andi Kleen <andi@...stfloor.org>,
Dave Chinner <dchinner@...hat.com>,
Scott J Norton <scott.norton@....com>,
Douglas Hatch <doug.hatch@....com>
Subject: Re: [PATCH v7 1/4] lib/percpu-list: Per-cpu list with associated
per-cpu locks
On 04/14/2016 07:33 PM, Boqun Feng wrote:
> On Wed, Apr 13, 2016 at 01:38:33PM -0400, Waiman Long wrote:
>> On 04/12/2016 10:09 PM, Boqun Feng wrote:
>>> Hi Waiman,
>>>
>>> On Tue, Apr 12, 2016 at 06:54:43PM -0400, Waiman Long wrote:
>>> [...]
>>>> +
>>>> +/*
>>>> + * Initialize the per-cpu list head
>>>> + */
>>>> +int init_pcpu_list_head(struct pcpu_list_head **ppcpu_head)
>>>> +{
>>>> + struct pcpu_list_head *pcpu_head = alloc_percpu(struct pcpu_list_head);
>>>> + int cpu;
>>>> +
>>>> + if (!pcpu_head)
>>>> + return -ENOMEM;
>>>> +
>>>> + for_each_possible_cpu(cpu) {
>>>> + struct pcpu_list_head *head = per_cpu_ptr(pcpu_head, cpu);
>>>> +
>>>> + INIT_LIST_HEAD(&head->list);
>>>> + head->lock = __SPIN_LOCK_UNLOCKED(&head->lock);
>>>> + lockdep_set_class(&head->lock,&percpu_list_key);
>>>> + }
>>>> +
>>>> + *ppcpu_head = pcpu_head;
>>>> + return 0;
>>>> +}
>>> The first time I looked at this patch, I had a hard time to figure out
>>> which "struct pcpu_list_head" pointer is pointing to percpu data(the
>>> pointer could be the parameter for per/this_cpu_ptr()), and which
>>> pointer is pointing to actual structure. For example, 'pcpu_head' and
>>> 'head' above are different types of pointers.
>>>
>>> So besides improving my code reading skills, I think the following patch
>>> helps ;-) Also it can resolve several splats of sparse when running
>>> 'make C=1 lib/'.
>>>
>>> Thoughts?
>> Yes, I think your patch is helpful. I will include your patch in my
>> patchset.
>>
> Given that a renaming will happen in the next version, carrying this as
> a standalone patch will be a pain, I think. So feel free to squash this
> into the patch #1, if that could make your job eariser ;-)
>
> Regards,
> Boqun
>
>
That is not a problem. I do want to acknowledge your contribution to
this patchset.
Cheers,
Longman
Powered by blists - more mailing lists