[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87k1pkrj84.fsf@vitty.brq.redhat.com>
Date: Tue, 24 Jul 2018 13:00:59 +0200
From: Vitaly Kuznetsov <vkuznets@...hat.com>
To: Yidong Ren <Yidong.Ren@...rosoft.com>
Cc: KY Srinivasan <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
Stephen Hemminger <sthemmin@...rosoft.com>,
"David S. Miller" <davem@...emloft.net>,
"devel\@linuxdriverproject.org" <devel@...uxdriverproject.org>,
"netdev\@vger.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
Madhan Sivakumar <madhans@...rosoft.com>
Subject: Re: [PATCH v3] hv_netvsc: Add per-cpu ethtool stats for netvsc
Yidong Ren <Yidong.Ren@...rosoft.com> writes:
>> From: Yidong Ren <yidren@...uxonhyperv.com>
>> Sent: Monday, July 23, 2018 6:26 PM
>> + pcpu_sum = kvmalloc(sizeof(struct netvsc_ethtool_pcpu_stats) *
>> + num_present_cpus(), GFP_KERNEL);
>
> Since there is no plan for CPU hotplug in Hyper-V in short term, it is fine
> to use num_present_cpus for now. We can move to debugfs later if necessary.
While you do for_each_present_cpu() in netvsc_get_ethtool_stats(),
netvsc_get_pcpu_stats() does for_each_possible_cpu(). This looks
inconsistent.
The allocation you're doing here is short-lived so I would suggest you
use possible_cpus everywhere. Even knowing there's no CPU hotplug on
Hyper-V at this moment, it can appear later and we'll get a hard-to-find
issue. Moreover, we may consider using netvsc driver on e.g. KVM with
Hyper-V enlightenments and KVM has CPU hotplug already.
--
Vitaly
Powered by blists - more mailing lists