From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 32ED2C43214 for ; Thu, 26 Aug 2021 19:41:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1ADA860F4C for ; Thu, 26 Aug 2021 19:41:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243619AbhHZTmM (ORCPT ); Thu, 26 Aug 2021 15:42:12 -0400 Received: from mail-wr1-f47.google.com ([209.85.221.47]:34809 "EHLO mail-wr1-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243574AbhHZTmE (ORCPT ); Thu, 26 Aug 2021 15:42:04 -0400 Received: by mail-wr1-f47.google.com with SMTP id h13so6824684wrp.1; Thu, 26 Aug 2021 12:41:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=zFKJpcZRXuno0WjXg2R7y6rFWbVh+fx1jWVSUxs/tIA=; b=TeStLouYxnE/wF57tZ54P/g8vv6Zgdk9Sn9wnn0Dpenzq2yNt7UgdeKjiQw7DblK/i 0Cnr+ciL8xvfSUfVBW0aqy4mk33HjwJAEi2ArvdUJa/4/YKob+lKG4feEH7AQ4G1pQPF hu4/KICS12lWPMyi6ElGR5aVar/SFXo3cPDhAa9qTGfyKp/0cnjNDUnZJHP8GO0bnWg4 edhTM6GMXO7kr5/nVUrGRFivPDxoNEl7gNkagv7xwYAPzTwTS3xE1M8K9L/IysfHJzXJ TaUZhPthHVsLUM7p2RTrj5/xg27Z3VGglRBMgj6bbxQ7fKjXSHsWGkjKXuDswhivY8Mu kb/g== X-Gm-Message-State: AOAM5327Mos7ZTOp4x0Fr7E5vkHyqoUQ3flcIwc5huZcPK9ZLqBig60p jf+CxptjzrFZmo2biZMFyfI= X-Google-Smtp-Source: ABdhPJyYQ0G4CSHB1wqw3b1I7jOBw0uYRxWgiCHEpZMCVYG6ZAqRuSkaACh+Oyc+AJvMo1InJnMM7Q== X-Received: by 2002:adf:f645:: with SMTP id x5mr6028408wrp.353.1630006875366; Thu, 26 Aug 2021 12:41:15 -0700 (PDT) Received: from liuwe-devbox-debian-v2 ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id b2sm3610591wmd.3.2021.08.26.12.41.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Aug 2021 12:41:14 -0700 (PDT) Date: Thu, 26 Aug 2021 19:41:13 +0000 From: Wei Liu To: Michael Kelley Cc: Long Li , Wei Liu , "longli@linuxonhyperv.com" , "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-hyperv@vger.kernel.org" , KY Srinivasan , Haiyang Zhang , Stephen Hemminger , Dexuan Cui , Lorenzo Pieralisi , Rob Herring , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Bjorn Helgaas , Dan Carpenter Subject: Re: [PATCH] PCI: hv: Fix a bug on removing child devices on the bus Message-ID: <20210826194113.yihk7ete4n4ej4gz@liuwe-devbox-debian-v2> References: <1629789620-11049-1-git-send-email-longli@linuxonhyperv.com> <20210824110208.xd57oqm5rii4rr4n@liuwe-devbox-debian-v2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 26, 2021 at 04:50:28PM +0000, Michael Kelley wrote: > From: Long Li Sent: Wednesday, August 25, 2021 1:25 PM > > > > > > > I thought list_for_each_entry_safe() is for use when list manipulation is *not* > > > protected by a lock and you want to safely walk the list even if an entry gets > > > removed. If the list is protected by a lock or not subject to contention (as is the > > > case here), then > > > list_for_each_entry() is the simpler implementation. The original > > > implementation didn't need to use the _safe version because of the spin lock. > > > > > > Or do I have it backwards? > > > > > > Michael > > > > I think we need list_for_each_entry_safe() because we delete the list elements while going through them: > > > > Here is the comment on list_for_each_entry_safe(): > > /** > > * Loop through the list, keeping a backup pointer to the element. This > > * macro allows for the deletion of a list element while looping through the > > * list. > > * > > * See list_for_each_entry for more details. > > */ > > > > Got it. Thanks (and to Rob Herring). I read that comment but > with the wrong assumptions and didn't understand it correctly. > > Interestingly, pci-hyperv.c has another case of looping through > this list and removing items where the _safe version is not used. > See pci_devices_present_work() where the missing children are > moved to a list on the stack. That can be converted too, I think. The original code is not wrong per-se. It is just not as concise as using list_for_each_entry_safe. Wei. > > Michael