Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759636Ab0D3VSd (ORCPT ); Fri, 30 Apr 2010 17:18:33 -0400 Received: from mga09.intel.com ([134.134.136.24]:60552 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754191Ab0D3VSa (ORCPT ); Fri, 30 Apr 2010 17:18:30 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.52,304,1270450800"; d="scan'208";a="514087644" Date: Fri, 30 Apr 2010 14:18:29 -0700 (Pacific Daylight Time) From: Peter P Waskiewicz Jr To: Thomas Gleixner cc: Ben Hutchings , "davem@davemloft.net" , "arjan@linux.jf.intel.com" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH linux-next v3 1/2] irq: Add CPU mask affinity hint In-Reply-To: Message-ID: References: <20100430202343.4591.66240.stgit@ppwaskie-hc2.jf.intel.com> <1272661345.2110.28.camel@achroite.uk.solarflarecom.com> X-X-Sender: ppwaskie@imapmail.glb.intel.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1606 Lines: 45 On Fri, 30 Apr 2010, Thomas Gleixner wrote: > On Fri, 30 Apr 2010, Ben Hutchings wrote: >> On Fri, 2010-04-30 at 13:23 -0700, Peter P Waskiewicz Jr wrote: >>> +int irq_register_affinity_hint(unsigned int irq, const struct cpumask *m) >>> +{ >>> + struct irq_desc *desc = irq_to_desc(irq); >>> + unsigned long flags; >>> + >>> + if (!desc) >>> + return -EINVAL; >> >> Is it possible for irq_to_desc(irq) to be NULL? This function already >> assumes that the caller 'owns' the IRQ. > > Oh come on. Driver writers get everything wrong and not checking on an > invalid irq number is better than crashing :) > >>> +static int irq_affinity_hint_proc_show(struct seq_file *m, void *v) >>> +{ >>> + struct irq_desc *desc = irq_to_desc((long)m->private); >>> + unsigned long flags; >>> + cpumask_var_t mask; >>> + int ret = -EINVAL; >> >> I don't think this should be returning -EINVAL if the affinity hint is >> missing. That means 'invalid argument', but there is nothing invalid >> about trying to read() the corresponding file. The file should simply >> be empty if there is no hint. (Actually it might be better if it didn't >> appear at all, but that would be a pain to implement.) > > I agree that -EINVAL is not really a good match. > > How about just returning CPU_MASK_ALL if desc->affinity_hint is not > set ? That seems reasonable to me. cheers, -PJ -- 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/