Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp2897756pxb; Sun, 15 Nov 2020 23:11:38 -0800 (PST) X-Google-Smtp-Source: ABdhPJxLjNtBqMMftitVlgwgRiG5F00CVw+1uxAHLJhNZZnTSftoT3ooAOGzVugcpxD22V80fLNH X-Received: by 2002:aa7:d1d8:: with SMTP id g24mr15130519edp.324.1605510698731; Sun, 15 Nov 2020 23:11:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605510698; cv=none; d=google.com; s=arc-20160816; b=wrswyS/9aZbaLDrCZB3OseGAwNdpl1sL9PPaUGcMy0nxxTA6Dzn4f6r3pinljDLXhx Pbo4oDY6H76JgTa0s4Bg9Yo6s8Pbx8UlMEzlaO3jEZWEMdwzcV8GVDDzE6EPBA7SZRhI Z1fBsCqKtji2vyLwseMyqM+H+Ro6dj/FxGJ/Mq5VlazJiOtDVQPNIzaa5M3TQUPwKge8 p7+2EOJaQwv+hUsJl0kA/3velzr5xLpixvQE6QQacRmjHPTZSxyy0uEXTeZRiz7Si+rI 57BmkcjzdxT+l4zLq8CDhWhsnn3jPHPeNsMo8rZEp2GlEf8N1AshtVN92a9H1YQ2dwfV CeeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=yiSVixBzWFRrc5F0VIHSOyW+ZLBve41qKR5fsnIR0cc=; b=CcSEamk26B/2pVDwhQ7d+6YGvX9S5649xadhiOzadnxI8e85wCY61Id8f33j5Fg1us toyxuF0eoCkiT6Qfwk5+8i2M1KKJdnVj2WSBsl/r/UEpvWkGFxknhkaiMmBPsxUBel8R pppqDaL5/UIOhVQXuK8fe0xwlR7yIzZvOSDl/gdZtU7Y+9E9D1e9kn5HSIQHEsHMchhB SumU7HJV5lKqPBzcF7loCP17tKO7bu8ai776FdFUSqKavs1j5A4d7SxMNXvDj3a4ZGsj ThjpoFCXhNPP1mXYRfO2gG/JTphCREB9nd31V3D6RYS951BR7rhZmm51dRRal1DmLpG9 NEkw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="kp/kq64M"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g23si11332200edr.322.2020.11.15.23.11.15; Sun, 15 Nov 2020 23:11:38 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="kp/kq64M"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726859AbgKPHIr (ORCPT + 99 others); Mon, 16 Nov 2020 02:08:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60990 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725819AbgKPHIr (ORCPT ); Mon, 16 Nov 2020 02:08:47 -0500 Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C87BAC0613CF; Sun, 15 Nov 2020 23:08:46 -0800 (PST) Received: by mail-lj1-x243.google.com with SMTP id 11so18964017ljf.2; Sun, 15 Nov 2020 23:08:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yiSVixBzWFRrc5F0VIHSOyW+ZLBve41qKR5fsnIR0cc=; b=kp/kq64MevP2otQ4mOzUUPbmumwm/olcWFs2tn8XQ25HbaPVfWe/CRo0+hTXfxuBZy 3YQE2ojPjuOKYD0KuwRi/vd6qgB0GylXp8BlPmGZLiBObFxBI7MSMM2pwqCWlpZAO7LC N84PGHgBxMTmZbUyOzojdzRVoneUyYZxgZq1GpBgPo3BIQDswb7Yglq6l2IW+F9X90NP 4HZ1Wm210Bm3hUBnXL+Gh3j/ZzsT5U6MTl/SAkOux9sQ2GqSkCATk7KWioFCBwwAc68V st/KqcMttugibCjMluGI3b64OIMSRtEx4ydhrZ21sPpHyCk2AjMvpULRTyMKaDc5trQv HCtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yiSVixBzWFRrc5F0VIHSOyW+ZLBve41qKR5fsnIR0cc=; b=fsFrkuLdf9ijdPnENU2/LnU4rayVW8h3aILtEdDOb4aJV2K+dAv3yTHqVdeYSqWUKE oJdmNuhcp29WWJBmrPebR0jN5H9e702E2tTirEX8lDhURdwOoraomnSWFNgo2QXWZZrs p1wDaO+ItT2ZzipYQwxdcbXoCzk0ZXAi8OZVF/OTuiAV0ZUlh0Zo6REm+z2oPiuCYxgw LwqZQ2tUNJP76TwZohKtmXHYiPdoa+ybofptuulZ1+Z8jI8WXFHNwKKtSU7YfivBpVeB C0mfmNdlqJRsDYUB6Fi5hme9/tXNG0geDatkPRguSbewTHiJQtmgfCehbRb+cSa4i8S3 LYag== X-Gm-Message-State: AOAM530VzNgnL0arbDSwvdV42d/2pfWDppBo7pbcYikp6a75XTgQV9s/ vZqGZ1bHe7CAk4p9iliC+m88CCJQ017CjpyG558= X-Received: by 2002:a2e:95cf:: with SMTP id y15mr5151725ljh.209.1605510525308; Sun, 15 Nov 2020 23:08:45 -0800 (PST) MIME-Version: 1.0 References: <20201026035710.593-1-zhenzhong.duan@gmail.com> <20201113224723.GA1139246@bjorn-Precision-5520> In-Reply-To: <20201113224723.GA1139246@bjorn-Precision-5520> From: Zhenzhong Duan Date: Mon, 16 Nov 2020 15:08:26 +0800 Message-ID: Subject: Re: [PATCH v2] PCI: check also dynamic IDs for duplicate in new_id_store() To: Bjorn Helgaas Cc: linux-kernel , linux-pci@vger.kernel.org, Bjorn Helgaas , Christoph Hellwig , Alex Williamson , Cornelia Huck Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Bjorn, On Sat, Nov 14, 2020 at 6:47 AM Bjorn Helgaas wrote: > > [+cc Alex, Cornelia in case VFIO cares about new_id/remove_id > semantics] > > On Mon, Oct 26, 2020 at 11:57:10AM +0800, Zhenzhong Duan wrote: > > When a device ID data is writen to /sys/bus/pci/drivers/.../new_id, > > only static ID table is checked for duplicate and multiple dynamic ID > > entries of same kind are allowed to exist in a dynamic linked list. > > This doesn't quite say what the problem is. > > I see that currently new_id_store() uses pci_match_id() to see if the > new device ID is in the static id_table, so adding the same ID twice > adds multiple entries to the dynids list. That does seem wrong, and I > think we should fix it. > > But I would like to clarify this commit log so we know whether the > current behavior causes user-visible broken behavior. The dynids list > is mostly used by pci_match_device(), and it looks like duplicate > entries shouldn't cause it a problem. > > I guess remove_id_store() will only remove one of the duplicate > entries, so if we add an ID several times, we would have to remove it > the same number of times before it's completely gone. Current behavior doesn't cause user-visible broken behavior, only not user friendly. One has to remove an ID at least twice to ensure it's really removed if he doesn't know how many times it has been added before. > > > Fix it by calling pci_match_device() which checks both dynamic and static > > IDs. > > > > After fix, it shows below result which is expected. > > > > echo "1af4:1000" > /sys/bus/pci/drivers/vfio-pci/new_id > > echo "1af4:1000" > /sys/bus/pci/drivers/vfio-pci/new_id > > -bash: echo: write error: File exists > > > > Drop the static specifier and add a prototype to avoid build error. > > I don't get this part. You added a prototype in include/linux/pci.h, > which means you expect callers outside drivers/pci. But there aren't > any. > > In fact, you're only adding a call in the same file where > pci_match_device() is defined. The usual way to resolve that is to > move the pci_match_device() definition before the call, so no forward > declaration is needed and the function can remain static. > > I think pci_match_id() and pci_match_device() should both be moved so > they remain together. It would be nice if the move itself were a > no-op patch separate from the one that changes new_id_store(). Yes, that's better, will do, thanks for your suggestions. Zhenzhong