From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Niklas Cassel <cassel@kernel.org>
Cc: "Krzysztof Wilczyński" <kw@linux.com>,
"Kishon Vijay Abraham I" <kishon@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
"Dan Carpenter" <dan.carpenter@linaro.org>
Subject: Re: [PATCH] PCI: endpoint: pci-epf-test: Make use of cached 'epc_features' in pci_epf_test_core_init()
Date: Thu, 18 Apr 2024 13:00:23 +0530 [thread overview]
Message-ID: <20240418073023.GA4331@thinkpad> (raw)
In-Reply-To: <ZiDITzuUXsTZ7U4T@ryzen>
On Thu, Apr 18, 2024 at 09:14:23AM +0200, Niklas Cassel wrote:
> On Thu, Apr 18, 2024 at 12:23:08PM +0530, Manivannan Sadhasivam wrote:
> > On Thu, Apr 18, 2024 at 08:46:47AM +0200, Niklas Cassel wrote:
> > > On Thu, Apr 18, 2024 at 11:13:19AM +0530, Manivannan Sadhasivam wrote:
> > > > On Wed, Apr 17, 2024 at 07:49:45PM +0200, Niklas Cassel wrote:
> > > > > On Wed, Apr 17, 2024 at 10:47:25PM +0530, Manivannan Sadhasivam wrote:
> > > > > > Instead of getting the epc_features from pci_epc_get_features() API, use
> > > > > > the cached pci_epf_test::epc_features value to avoid the NULL check. Since
> > > > > > the NULL check is already performed in pci_epf_test_bind(), having one more
> > > > > > check in pci_epf_test_core_init() is redundant and it is not possible to
> > > > > > hit the NULL pointer dereference. This also leads to the following smatch
> > > > > > warning:
> > > > > >
> > > > > > drivers/pci/endpoint/functions/pci-epf-test.c:784 pci_epf_test_core_init()
> > > > > > error: we previously assumed 'epc_features' could be null (see line 747)
> > > > > >
> > > > > > Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
> > > > > > Closes: https://lore.kernel.org/linux-pci/024b5826-7180-4076-ae08-57d2584cca3f@moroto.mountain/
> > > > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > > > >
> > > > > I think you forgot:
> > > > > Fixes: a01e7214bef9 ("PCI: endpoint: Remove "core_init_notifier" flag")
> > > > >
> > > >
> > > > No, that's not the correct fixes tag I suppose. This redudant check is
> > > > introduced by commit, 5e50ee27d4a5 ("PCI: pci-epf-test: Add support to defer
> > > > core initialization") and this commit removes the redundant check (fixing smatch
> > > > warning is a side effect). So if the fixes tag needs to be added, then this
> > > > commit should be referenced.
> > >
> > > Well, you have a Closes: tag that links to a bug report about a smatch
> > > warning that was introduced with 5e50ee27d4a5 ("PCI: pci-epf-test: Add
> > > support to defer core initialization").
> > >
> > > So if you want to reference another commit, then you should probably
> > > drop the Closes: tag.
> > >
> >
> > Then checkpatch will complain... But I think I can keep the two tags? One is for
> > fixing the redudant check and another is for the smatch warning reported.
>
> Yes, I think so too.
>
> You can have Fixes: to the commit that introduced the redundant check,
That is 5e50ee27d4a5.
> since this was obviously not the correct thing to do, and then perhaps
> just mention commit 5e50ee27d4a5 ("PCI: pci-epf-test: Add support to
> defer core initialization") somewhere in the commit log.
You mean a01e7214bef9 here?
- Mani
--
மணிவண்ணன் சதாசிவம்
next prev parent reply other threads:[~2024-04-18 7:30 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-17 17:17 [PATCH] PCI: endpoint: pci-epf-test: Make use of cached 'epc_features' in pci_epf_test_core_init() Manivannan Sadhasivam
2024-04-17 17:49 ` Niklas Cassel
2024-04-17 17:54 ` Dan Carpenter
2024-04-17 17:54 ` Niklas Cassel
2024-04-18 5:47 ` Manivannan Sadhasivam
2024-04-18 5:43 ` Manivannan Sadhasivam
2024-04-18 6:46 ` Niklas Cassel
2024-04-18 6:53 ` Manivannan Sadhasivam
2024-04-18 7:14 ` Niklas Cassel
2024-04-18 7:30 ` Manivannan Sadhasivam [this message]
2024-04-18 7:40 ` Niklas Cassel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240418073023.GA4331@thinkpad \
--to=manivannan.sadhasivam@linaro.org \
--cc=bhelgaas@google.com \
--cc=cassel@kernel.org \
--cc=dan.carpenter@linaro.org \
--cc=kishon@kernel.org \
--cc=kw@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.