From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933589AbcI1RW2 (ORCPT ); Wed, 28 Sep 2016 13:22:28 -0400 Received: from mx2.suse.de ([195.135.220.15]:44451 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932977AbcI1RWU (ORCPT ); Wed, 28 Sep 2016 13:22:20 -0400 Subject: Re: [Xen-devel] [PATCH v3 2/3] xen/pciback: avoid multiple entries in slot list To: David Vrabel , Boris Ostrovsky , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org References: <1474533941-6976-1-git-send-email-jgross@suse.com> <1474533941-6976-3-git-send-email-jgross@suse.com> <57E500C3.1000209@citrix.com> From: Juergen Gross Message-ID: Date: Wed, 28 Sep 2016 19:22:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <57E500C3.1000209@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23/09/16 12:15, David Vrabel wrote: > On 22/09/16 22:02, Boris Ostrovsky wrote: >> On 09/22/2016 04:45 AM, Juergen Gross wrote: >>> The Xen pciback driver has a list of all pci devices it is ready to >>> seize. There is no check whether a to be added entry already exists. >>> While this might be no problem in the common case it might confuse >>> those which consume the list via sysfs. >>> >>> Modify the handling of this list by not adding an entry which already >>> exists. As this will be needed later split out the list handling into >>> a separate function. >>> >>> Signed-off-by: Juergen Gross >>> --- >>> drivers/xen/xen-pciback/pci_stub.c | 39 ++++++++++++++++++++++++++++++-------- >>> 1 file changed, 31 insertions(+), 8 deletions(-) >>> >>> diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c >>> index 79a9e4d..0179333 100644 >>> --- a/drivers/xen/xen-pciback/pci_stub.c >>> +++ b/drivers/xen/xen-pciback/pci_stub.c >>> @@ -478,6 +478,36 @@ static int __init pcistub_init_devices_late(void) >>> return 0; >>> } >>> >>> +static void pcistub_device_id_add_list(struct pcistub_device_id *new, >>> + int domain, int bus, unsigned int devfn) > > I think this should allocate the new pcistub_device_id if needed. You > can pass in GFP flags if needed. > > Then it can return the newly allocated one, or the existing one. > > static struct pcistub_device_id *pcistub_device_id_add_list( > int domain, int bus, unsigned int devfn) Patch 3 will be very nasty then: in case of an allocation failure all of the actions done in pcistub_seize() will have to be undone again. I'd really like to avoid that. Juergen