Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934013AbbGUXPF (ORCPT ); Tue, 21 Jul 2015 19:15:05 -0400 Received: from mail-wi0-f171.google.com ([209.85.212.171]:33116 "EHLO mail-wi0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933239AbbGUXPD (ORCPT ); Tue, 21 Jul 2015 19:15:03 -0400 MIME-Version: 1.0 In-Reply-To: References: <20150718163149.GP7557@n2100.arm.linux.org.uk> Date: Wed, 22 Jul 2015 01:15:01 +0200 X-Google-Sender-Auth: 29bGwcD3ja_6gkftn9cKjWzXunA Message-ID: Subject: Re: [PATCH] cpufreq: Avoid double addition/removal of sysfs links From: "Rafael J. Wysocki" To: Viresh Kumar Cc: Rafael Wysocki , Russell King - ARM Linux , Lists linaro-kernel , "linux-pm@vger.kernel.org" , open list Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1520 Lines: 34 Hi VIresh, On Mon, Jul 20, 2015 at 11:47 AM, Viresh Kumar wrote: > Consider a dual core (0/1) system with two CPUs: > - sharing clock/voltage rails and hence cpufreq-policy > - CPU1 is offline while the cpufreq driver is registered > > - cpufreq_add_dev() is called from subsys callback for CPU0 and we > create the policy for the CPUs and create link for CPU1. > - cpufreq_add_dev() is called from subsys callback for CPU1, we find > that the cpu is offline and we try to create a sysfs link for CPU1. So the problem is that the cpu_is_offline(cpu) check in cpufreq_add_dev() matches two distinct cases: (1) the CPU was not present before and it is just being hot-added and (2) the CPU is initially offline, but present, and this is the first time its device is registered. In the first case we can expect that the CPU will become online shortly (although that is not guaranteed too), but in the second case that very well may not happen. We need to be able to distinguish between those two cases and your patch does that, but I'm not sure if this really is the most straightforward way to do it. I'm also unsure why you're changing the removal code paths. Is there any particular failure scenario you're concerned about? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/