Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755916Ab3JIPne (ORCPT ); Wed, 9 Oct 2013 11:43:34 -0400 Received: from mail-qa0-f46.google.com ([209.85.216.46]:59141 "EHLO mail-qa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755838Ab3JIPn3 (ORCPT ); Wed, 9 Oct 2013 11:43:29 -0400 Date: Wed, 9 Oct 2013 11:43:23 -0400 From: Tejun Heo To: Alexander Gordeev Cc: Benjamin Herrenschmidt , Ben Hutchings , linux-kernel@vger.kernel.org, Bjorn Helgaas , Ralf Baechle , Michael Ellerman , Martin Schwidefsky , Ingo Molnar , Dan Williams , Andy King , Jon Mason , Matt Porter , linux-pci@vger.kernel.org, linux-mips@linux-mips.org, linuxppc-dev@lists.ozlabs.org, linux390@de.ibm.com, linux-s390@vger.kernel.org, x86@kernel.org, linux-ide@vger.kernel.org, iss_storagedev@hp.com, linux-nvme@lists.infradead.org, linux-rdma@vger.kernel.org, netdev@vger.kernel.org, e1000-devel@lists.sourceforge.net, linux-driver@qlogic.com, Solarflare linux maintainers , "VMware, Inc." , linux-scsi@vger.kernel.org Subject: Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern Message-ID: <20131009154323.GB22495@htj.dyndns.org> References: <1380840585.3419.50.camel@bwh-desktop.uk.level5networks.com> <20131004082920.GA4536@dhcp-26-207.brq.redhat.com> <1380922156.3214.49.camel@bwh-desktop.uk.level5networks.com> <20131005142054.GA11270@dhcp-26-207.brq.redhat.com> <1381009586.645.141.camel@pasglop> <20131006060243.GB28142@dhcp-26-207.brq.redhat.com> <1381040386.645.143.camel@pasglop> <20131006071027.GA29143@dhcp-26-207.brq.redhat.com> <20131007180111.GC2481@htj.dyndns.org> <20131009125715.GC32733@dhcp-26-207.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131009125715.GC32733@dhcp-26-207.brq.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1137 Lines: 28 Hello, On Wed, Oct 09, 2013 at 02:57:16PM +0200, Alexander Gordeev wrote: > On Mon, Oct 07, 2013 at 02:01:11PM -0400, Tejun Heo wrote: > > Hmmm... yean, the race condition could be an issue as multiple msi > > allocation might fail even if the driver can and explicitly handle > > multiple allocation if the quota gets reduced inbetween. > > BTW, should we care about the quota getting increased inbetween? > That would entail.. kind of pci_get_msi_limit() :), but IMHO it is > not worth it. I think we shouldn't. If the resource was low during a point in time during allocation, it's fine to base the result on that - the resource was actually low and which answer we return is just a question of timing and both are correct. The only reason the existing race condition is problematic is because it may fail even if the resource never falls below the failure point. Thanks. -- tejun -- 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/