On Tue, Sep 29, 2020 at 12:45 AM Kuppuswamy, Sathyanarayanan <sathyanarayanan.kuppuswamy@xxxxxxxxx> wrote: > > > On 9/28/20 9:43 AM, Sinan Kaya wrote: > > On 9/28/2020 7:10 AM, Sinan Kaya wrote: > >> On 9/27/2020 10:01 PM, Zhao, Haifeng wrote: > >>> Sinan, > >>> I explained the reason why locks don't protect this case in the patch description part. > >>> Write side and read side hold different semaphore and mutex. > >>> > >> I have been thinking about it some time but is there any reason why we > >> have to handle all port AER/DPC/HP events in different threads? > >> > >> Can we go to single threaded event loop for all port drivers events? > >> > >> This will require some refactoring but it wlll eliminate the lock > >> nightmares we are having. > >> > >> This means no sleeping. All sleeps need to happen outside of the loop. > >> > >> I wanted to see what you all are thinking about this. > >> > >> It might become a performance problem if the system is > >> continuously observing a hotplug/aer/dpc events. > >> > >> I always think that these should be rare events. > > If restructuring would be too costly, the preferred solution should be > > to fix the locks in hotplug driver rather than throwing there a random > > wait call. > Since the current race condition is detected between DPC and > hotplug, I recommend synchronizing them. The locks are the first place to root cause and try to fix. but not so easy to refactor the remove-scan-semaphore and the bus-walk-mutex. too expensive work. --- rework every piece of code that uses them. Thanks, Ethan > > -- > Sathyanarayanan Kuppuswamy > Linux Kernel Developer >
