linux-kernel - Re: [PATCH 3/3] pciehp: Fix race condition handling surprise link-down

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] [day] [month] [year] [list]

Message-ID: <20161209211109.GA18093@otc-nc-03>
Date:   Fri, 9 Dec 2016 13:11:09 -0800
From:   "Raj, Ashok" <ashok.raj@...el.com>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     Keith Busch <keith.busch@...el.com>, linux-pci@...r.kernel.org,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        ashok.raj@...el.com
Subject: Re: [PATCH 3/3] pciehp: Fix race condition handling surprise
 link-down

Hi Bjorn

Thanks. I have resent the last patch again with consistent lock usage as you
had requested.

I did attempt to make things a bit more easier to understand in one my
earlier experiments, but that resulted in very substantial changes. 
Certainly something we should look in future to make the state machine 
more robust.

Cheers,
Ashok

On Thu, Dec 08, 2016 at 11:50:09AM -0600, Bjorn Helgaas wrote:
> > Yes, the alloc_ordered_workqueue is what I had in mind, though switching
> > to that is not as simple as calling the different API. I am looking into
> > that for longer term, but for the incremental fix, do you think we can
> > go forward with Raj's proposal?
> 
> I'd like to at least see a consistent locking strategy for protecting
> p_slot->state.  All the existing updates are protected by
> p_slot->lock, but the one Raj is adding is protected by
> p_slot->hotplug_lock.
> 
> Bjorn