[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAA8EJprs9dvjm5R-hhrTKTwm9RxJd9GJy=eFFHC0y7110p_+ew@mail.gmail.com>
Date: Fri, 25 Feb 2022 21:26:56 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc: kishon@...com, lorenzo.pieralisi@....com, omp@...dia.com,
vidyas@...dia.com, linux-pci@...r.kernel.org,
linux-kernel@...r.kernel.org, bjorn.andersson@...aro.org
Subject: Re: PCI: endpoint: Usage of atomic notifier chain
On Fri, 25 Feb 2022 at 21:23, Manivannan Sadhasivam
<manivannan.sadhasivam@...aro.org> wrote:
>
> Hi,
>
> While working with the PCI endpoint subsystem, I stumbled upon the sleeping
> in atomic context bug during CORE_INIT phase. The issue seems to be due to the
> usage of "epc lock" (mutex) in functions such as set_msi, set_msix,
> write_header, etc...
>
> These functions are supposed to be used in the atomic notifier chain by the
> CORE_INIT notifier. While using the lock is necessary in these functions as
> pci_epc_create() would've been called, I see two possible workarounds:
>
> 1. Using non-atomic notifier chains such as blocking or raw.
> 2. Modifying the EPF drivers to use workqueue in CORE_INIT notifier chain. But
> this has the implication of missing the workqueue execution before hitting other
> PCI events as there might be a delay in scheduling the work item.
Just a note: using workqueue wouldn't help if one has to process link
down events.
The driver would expect that after dispatching the link down event it
can disable the hardware, thus making worker access disabled hw
instance.
--
With best wishes
Dmitry
Powered by blists - more mailing lists