linux-kernel - Re: [PATCH RESEND] PCI: endpoint: Fix clearing start entry in configfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200225101825.GA4029@e121166-lin.cambridge.arm.com>
Date:   Tue, 25 Feb 2020 10:18:25 +0000
From:   Lorenzo Pieralisi <lorenzo.pieralisi@....com>
To:     Kunihiko Hayashi <hayashi.kunihiko@...ionext.com>
Cc:     Kishon Vijay Abraham I <kishon@...com>, linux-pci@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND] PCI: endpoint: Fix clearing start entry in
 configfs

On Tue, Feb 25, 2020 at 07:05:07PM +0900, Kunihiko Hayashi wrote:
> Hi Lorenzo,
> 
> On Fri, 21 Feb 2020 14:15:53 +0000 <lorenzo.pieralisi@....com> wrote:
> 
> > On Fri, Dec 20, 2019 at 09:24:37PM +0900, Kunihiko Hayashi wrote:
> > > The value of 'start' entry is no change whenever writing 0 to configfs.
> > > So the endpoint that stopped once can't restart.
> > > 
> > > The following command lines are an example restarting endpoint and
> > > reprogramming configurations after receiving bus-reset.
> > > 
> > >     echo 0 > controllers/66000000.pcie-ep/start
> > >     rm controllers/66000000.pcie-ep/func1
> > >     ln -s functions/pci_epf_test/func1 controllers/66000000.pcie-ep/
> > >     echo 1 > controllers/66000000.pcie-ep/start
> > > 
> > > However, the first 'echo' can't set 0 to 'start', so the last 'echo' can't
> > > restart endpoint.
> > 
> > I think your description is not correct - pci_epc_group->start is
> > just used to check if an endpoint has been started or not (in
> > pci_epc_epf_unlink() and that's a WARN_ON) but nonetheless this
> > looks like a bug and ought to be fixed.
> 
> When pci_epc_group->start keeps 1 after starting this controller with
> 'echo 1 > start', we can never unlink the func1 from the controller
> because of WARN_ON.

To me "I can never unlink" means that it can't be done, which
is not what's happening. What's happening is that unlinking triggers
a warning, which is different.

> I think that unlink/re-link play initialization role of configfs
> through 'unbind' and 'bind' functions. However, we can't re-initialize
> configfs.
> 
> If this is the intended behavior, my patch will make no sense.

Your patch makes sense, your commit log does not, see above.

> > I need Kishon's ACK to proceed.

Yes - then I am happy to merge this patch with a rewritten
commit log.

Thanks,
Lorenzo

> I think so, too.
> 
> Thank you,
> 
> > 
> > Thanks,
> > Lorenzo
> > 
> > > Fixes: d74679911610 ("PCI: endpoint: Introduce configfs entry for configuring EP functions")
> > > Cc: Kishon Vijay Abraham I <kishon@...com>
> > > Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@...ionext.com>
> > > ---
> > >  drivers/pci/endpoint/pci-ep-cfs.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/drivers/pci/endpoint/pci-ep-cfs.c b/drivers/pci/endpoint/pci-ep-cfs.c
> > > index d1288a0..4fead88 100644
> > > --- a/drivers/pci/endpoint/pci-ep-cfs.c
> > > +++ b/drivers/pci/endpoint/pci-ep-cfs.c
> > > @@ -58,6 +58,7 @@ static ssize_t pci_epc_start_store(struct config_item *item, const char *page,
> > >  
> > >  	if (!start) {
> > >  		pci_epc_stop(epc);
> > > +		epc_group->start = 0;
> > >  		return len;
> > >  	}
> > >  
> > > -- 
> > > 2.7.4
> > > 
> 
> ---
> Best Regards,
> Kunihiko Hayashi
>