Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755647Ab0GFN0a (ORCPT ); Tue, 6 Jul 2010 09:26:30 -0400 Received: from a.mx.secunet.com ([195.81.216.161]:49141 "EHLO a.mx.secunet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752208Ab0GFN03 (ORCPT ); Tue, 6 Jul 2010 09:26:29 -0400 Date: Tue, 6 Jul 2010 15:28:25 +0200 From: Steffen Klassert To: Dan Kruchinin Cc: LKML , Herbert Xu Subject: Re: [PATCH 1/3] padata: separate serial and parallel cpumasks Message-ID: <20100706132825.GT10072@secunet.com> References: <20100702091726.GH10072@secunet.com> <20100702111138.GI10072@secunet.com> <20100706053612.GQ10072@secunet.com> <20100706054406.GR10072@secunet.com> <20100706074641.GS10072@secunet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 06 Jul 2010 13:26:27.0374 (UTC) FILETIME=[D662D4E0:01CB1D0E] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1547 Lines: 49 On Tue, Jul 06, 2010 at 12:31:21PM +0400, Dan Kruchinin wrote: > > Would't it be the same as with a pointer to cpumask_var_t? I mean: Using a pointer to cpumask_var_t is a bit problematic because you don't know a priori about the type of cpumask_var_t. The type depends whether the cpumasks are on/off stack. So the easiest thing is to embed it to a struct, then you don't need to care about the type. If you allocate a struct of type pcrypt_cpumask you get what you want to have. > struct pcrypt { > ... > struct pcrypt_cpumask *mask; > ... > } pencrypt; > > To assign a pointer via RCU: > > int cpumask_change_nitify(...) { > ... > struct pcrypt_cpumask *new_mask = kmalloc(sizeof(*mask), GFP); > struct pcrypt_cpumask *old_mask = pencrypt.mask; > > if (!new_mask) > error(); > if (!alloc_cpumask_var(&new_mask->smask, GFP_KERNEL)) > error(); > > get_serial_cpumask_from_padata(new_mask->mask); > rcu_assign_pointer(pencrypt.mask, new_mask); > synchronize_rcu_bh(); > > free_cpumask_var(old_mask->smask); > kfree(old_mask); > ... > } > > It's a bit hard to read this code because at the first sight it > appears unclear and odd why we allocate the structure with only one > member. > We can easily add a code comment if this appears to be unclear :) -- 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/