Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755096AbbB0RwV (ORCPT ); Fri, 27 Feb 2015 12:52:21 -0500 Received: from linuxhacker.ru ([217.76.32.60]:60924 "EHLO fiona.linuxhacker.ru" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1754947AbbB0RwS convert rfc822-to-8bit (ORCPT ); Fri, 27 Feb 2015 12:52:18 -0500 Subject: Re: [PATCH 0/2] incorrect cpumask behavior with CPUMASK_OFFSTACK Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Oleg Drokin In-Reply-To: <87pp8vlgqu.fsf@rustcorp.com.au> Date: Fri, 27 Feb 2015 12:51:59 -0500 Cc: Andrew Morton , "David S. Miller" , " Mailing List" Content-Transfer-Encoding: 8BIT Message-Id: References: <1424931551-11757-1-git-send-email-green@linuxhacker.ru> <87pp8vlgqu.fsf@rustcorp.com.au> To: Rusty Russell X-Mailer: Apple Mail (2.1283) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2313 Lines: 58 Hello! On Feb 27, 2015, at 6:46 AM, Rusty Russell wrote: > green@linuxhacker.ru writes: >> From: Oleg Drokin >> >> I just got a report today from Tyson Whitehead >> that Lustre crashes when CPUMASK_OFFSTACK is enabled. >> >> A little investigation revealed that this code: >> cpumask_t mask; >> ... >> cpumask_copy(&mask, topology_thread_cpumask(0)); >> weight = cpus_weight(mask); > Yes. cpumask_weight should have been used here. The old cpus_* are > deprecated. Oh! I guess we missed the announcement. I'll convert it over. Should I also do a patch converting all other users and removing the deprecated functions while I am at it? >> The second patch that I am not sure if we wnat, but it seems to be useful >> until struct cpumask is fully dynamic is to convert what looks like >> whole-set operations e.g. copies, namely: >> cpumask_setall, cpumask_clear, cpumask_copy to always operate on NR_CPUS >> bits to ensure there's no stale garbage left in the mask should the >> cpu count increases later. > You can't do this, because dynamically allocated cpumasks don't have > NR_CPUS bits. Well, right now they certainly have. As in, it's a static define and we allocate a bitmap to fit the (in my case) up to 8192 bits into such off-stack masks. The concern is since number of cpus is not really a fixed variable, when you do cpumask initialization, and then number of cpus grows, the end of the mask could be garbage? Am I overthinking this and it's not really a problem? > Let's just kill all the cpus_ functions. This wasn't done originally > because archs which didn't care about offline cpumasks didn't want the > churn. In particular, they must not copy struct cpumask by assignment, > and fixing those is a fair bit of churn. Ah, copy masks by assignment, I see. Well, I guess we can eliminate the users outside of the affected arch trees (I assume in x86 there would be no objections?) and perhaps add a warning to checkpatch.pl? Thanks! Bye, Oleg-- 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/