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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E8FFAC433EF for ; Mon, 8 Nov 2021 00:58:07 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id AB83861288 for ; Mon, 8 Nov 2021 00:58:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org AB83861288 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=yQsbR2tMXanzjcf3Ps5aQGFrx0ahtSnl0dl8P0STqGE=; b=ynR2QUcG07entV TIakz0U+5MBM2/cjyeZo8JK8Ys7h+dV5bkV19sYdiuNCInhpkzTeF7GfoFF+Jc7tbPn9grOEpC9WJ pTZfzkzV34gwCE5uDNAk3oOGm//q/LGNBjpenm/GsrYPKyXD/tiqBUejoTcVC1SAofkH/2NOXQhQh XAK7KZVBEjr9go4883LJhrWqlbuDtvxLCulFA3P8Lbazl1OlBscOJL+LITonnjooZC+WRikrMdCpf Z3aXvjIAxYvCtgAXHAMSPVlBi59X1YkgUiZWFrf1LlSC9gpbdO2fqIboIiNnbnYmFcEw7NJo6YOZv 68QBaWgEHc42Ka2b7dwA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mjsxi-00FBGO-As; Mon, 08 Nov 2021 00:56:38 +0000 Received: from mail-wm1-f50.google.com ([209.85.128.50]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mjsxe-00FBEq-3v for linux-arm-kernel@lists.infradead.org; Mon, 08 Nov 2021 00:56:35 +0000 Received: by mail-wm1-f50.google.com with SMTP id 77-20020a1c0450000000b0033123de3425so13932901wme.0 for ; Sun, 07 Nov 2021 16:56:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=uzZdeX9n4CyJZmzyZ7xBIA2ZTAOzXaTvEy5MtTKwtCk=; b=mohrvMfjCY7TQCKs/cWj8Teq1raDTT58QTtqMdXg0xYS3kiOol7Dl//BWU4uJykGq/ BxE6bCZC4PeYOGQ3zLVaEt3kpe0+UQ7BVyKFk3NWqvWSpmB0XBKdJEfWYTBcXJTQPlhy 7XVQ9Fj6VWDEjU716KqC0UBLYEC+wcR1hHurDa4/gCNI0Zq0518BeWBez9kDQ8Bfseum 0DU2XDpUcF1YgTGD9+cDcyTdSdWaazR2PKFn6B4Tm/2vxagFEkg3NUDFt/LJJLVplLYe ci6knIc5hGojAkaVL9w7t5zA7WR9RllaNB3ppF+WFAl7htYoFn3d2G2yKi3oMh6ns4CA 0ljw== X-Gm-Message-State: AOAM531LorcDuzpbMVYTGZgcUUNhy0uzAtPC7Zn3rbN+MctzzO7oPEv9 vJh9de5pwyBnL6e9mmfE1D8= X-Google-Smtp-Source: ABdhPJzvGlgcAB4R6vHxU2waeO6Km3+TvSGbBM/R5GL2WDQXGpiCGlkjzQ9ug/rsiryjPPV44mmX0Q== X-Received: by 2002:a05:600c:ac2:: with SMTP id c2mr48557417wmr.118.1636332992660; Sun, 07 Nov 2021 16:56:32 -0800 (PST) Received: from rocinante ([95.155.85.46]) by smtp.gmail.com with ESMTPSA id g13sm13634578wmk.37.2021.11.07.16.56.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Nov 2021 16:56:32 -0800 (PST) Date: Mon, 8 Nov 2021 01:56:30 +0100 From: Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= To: Christophe JAILLET Cc: toan@os.amperecomputing.com, lorenzo.pieralisi@arm.com, robh@kernel.org, bhelgaas@google.com, linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org Subject: Re: [PATCH] PCI: xgene-msi: Use bitmap_zalloc() when applicable Message-ID: References: <32f3bc1fbfbd6ee0815e565012904758ca9eff7e.1635019243.git.christophe.jaillet@wanadoo.fr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211107_165634_190385_D324C15C X-CRM114-Status: GOOD ( 30.12 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Christophe! [...] > > I believe, after having a brief look, that we might have a few other > > candidates that we could also update: > > > > drivers/pci/controller/dwc/pcie-designware-ep.c > > 717: ep->ib_window_map = devm_kcalloc(dev, > > 724: ep->ob_window_map = devm_kcalloc(dev, > > drivers/pci/controller/pcie-iproc-msi.c > > 592: msi->bitmap = devm_kcalloc(pcie->dev, BITS_TO_LONGS(msi->nr_msi_vecs), > > drivers/pci/controller/pcie-xilinx-nwl.c > > 470: bit = bitmap_find_free_region(msi->bitmap, INT_PCI_MSI_NR, > > 567: msi->bitmap = kzalloc(size, GFP_KERNEL); > > 637: msi->bitmap = NULL; > > drivers/pci/controller/pcie-iproc-msi.c > > 262: hwirq = bitmap_find_free_region(msi->bitmap, msi->nr_msi_vecs, > > 290: bitmap_release_region(msi->bitmap, hwirq, > > drivers/pci/controller/pcie-xilinx-nwl.c > > 470: bit = bitmap_find_free_region(msi->bitmap, INT_PCI_MSI_NR, > > 494: bitmap_release_region(msi->bitmap, data->hwirq, > > drivers/pci/controller/pcie-brcmstb.c > > 537: hwirq = bitmap_find_free_region(&msi->used, msi->nr, 0); > > 546: bitmap_release_region(&msi->used, hwirq, 0); > > drivers/pci/controller/pcie-xilinx.c > > 240: hwirq = bitmap_find_free_region(port->msi_map, XILINX_NUM_MSI_IRQS, order_base_2(nr_irqs)); > > 263: bitmap_release_region(port->msi_map, d->hwirq, order_base_2(nr_irqs)); > > > > Some of the above could also potentially benefit from being converted to > > use the DECLARE_BITMAP() macro to create the bitmap that is then being > > embedded into some struct used to capture details and state, rather than > > store a pointer to later allocate memory dynamically. Some controller > > drivers already do this, so we could convert rest where appropriate. > > > > What do you think? > > Hi, > > my first goal was to simplify code that was not already spotted by a cocci > script proposed by Joe Perches (see [1]). Ahh, OK. I didn't know that Joe worked on adding new Coccinelle script to deal with the bitmap allocations and such. I assumed you did some code review and found some issues. I had a quick look at what the Coccinelle script found, and it seems I have missed when I did some search on my own: drivers/pci/controller/pcie-rcar-ep.c > I'll give a closer look at the opportunities spotted by Joe if they have not > already been fixed in the meantime. As per the thread you linked to, I can see that neither the new Coccinelle script nor the changes from Joe were accepted yet, or I couldn't see anything yet (at least not in the PCI tree). > Concerning the use of DECLARE_BITMAP instead of alloc/free memory, it can be > more tricky to spot it. Will try to give a look at it. A lot more code to read, indeed. However, the benefits are quite nice: simpler code, easier error handling and reducing probability of leaking memory. I think, a lot of the drivers we have in our tree could (and a lot already do) leverage the DECLARE_BITMAP() macro reserving space during build time over dealing with memory allocations and such. > > We also have this nudge from Coverity that we could fix, as per: > > > > 532 static int brcm_msi_alloc(struct brcm_msi *msi) > > 533 { > > 534 int hwirq; > > 535 > > 536 mutex_lock(&msi->lock); > > 1. address_of: Taking address with &msi->used yields a singleton pointer. > > CID 1468487 (#1 of 1): Out-of-bounds access (ARRAY_VS_SINGLETON)2. callee_ptr_arith: Passing &msi->used to function bitmap_find_free_region which uses it as an array. This might corrupt or misinterpret adjacent memory locations. [show details] > > 537 hwirq = bitmap_find_free_region(&msi->used, msi->nr, 0); > > 538 mutex_unlock(&msi->lock); > > 539 > > 540 return hwirq; > > 541 } > > 543 static void brcm_msi_free(struct brcm_msi *msi, unsigned long hwirq) > > 544 { > > 545 mutex_lock(&msi->lock); > > 1. address_of: Taking address with &msi->used yields a singleton pointer. > > CID 1468424 (#1 of 1): Out-of-bounds access (ARRAY_VS_SINGLETON)2. callee_ptr_arith: Passing &msi->used to function bitmap_release_region which uses it as an array. This might corrupt or misinterpret adjacent memory locations. [show details] > > 546 bitmap_release_region(&msi->used, hwirq, 0); > > 547 mutex_unlock(&msi->lock); > > 548 } > > > > We could look at addressing this too at the same time. > > I'll give it a look. Thank you! Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel