linux-kernel - Re: [PATCH] mm:Avoid soft lockup due to possible attempt of double locking object's lock in __delete

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

Message-ID: <1473209511.32433.179.camel@redhat.com>
Date:   Tue, 06 Sep 2016 20:51:51 -0400
From:   Rik van Riel <riel@...hat.com>
To:     nick <xerofoify@...il.com>, Valdis.Kletnieks@...edu,
        Catalin Marinas <catalin.marinas@....com>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm:Avoid soft lockup due to possible attempt of double
 locking object's lock in __delete_object

On Wed, 2016-08-31 at 17:28 -0400, nick wrote:
> 
> Rather then argue since that will go nowhere. I am posing actual
> patches that have been tested on
> hardware. 

But not by you, apparently.

The patch below was first posted by somebody else
in 2013: https://lkml.org/lkml/2013/7/11/93

When re-posting somebody else's patch, you need to
preserve their From: and Signed-off-by: headers.

See Documentation/SubmittingPatches for the details
on that.

Pretending that other people's code is your own
is not only very impolite, it also means that
the origin of the code, and permission to distribute
it under the GPL, are in question.

Will you promise to not claim other people's code as
your own?

Otherwise there is another very good reason to refuse
ever accepting code posted by you into the kernel.
We cannot merge code when there is no clear permission
from the actual author to distribute it under the GPL.

> From 719ad39496679523c70c7dda006e6da31d9004b3 Mon Sep 17 00:00:00
> 2001
> From: Nicholas Krause <xerofoify@...il.com>
> Date: Wed, 24 Aug 2016 02:09:39 -0400
> Subject: [PATCH] pciehp: Avoid not bringing up device if already
> existing on
>  bus
> 
> This fixes pcihp_resume to now avoid incorrectly bailing out if the
> device is already live in the pci bus but currently suspended.
> Further
> more this issue is caused by incorrectly checking the status of the
> device adapter directly, instead since this adapter can be shared
> we must instead also check if the pci_bus has no more links to this
> adapter by checking if the pci_bus used by this adapter's device list
> is also empty before enabling it. Finally do the opposite of checking
> that the list is not empty before disabling in order to avoid the
> same issue on disabling the slot instead.
> 
> Signed-off-by: Nicholas Krause <xerofoify@...il.com>
> ---
>  drivers/pci/hotplug/pciehp_core.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pci/hotplug/pciehp_core.c
> b/drivers/pci/hotplug/pciehp_core.c
> index ac531e6..1ce725e 100644
> --- a/drivers/pci/hotplug/pciehp_core.c
> +++ b/drivers/pci/hotplug/pciehp_core.c
> @@ -291,7 +291,7 @@ static int pciehp_resume(struct pcie_device *dev)
>  	struct controller *ctrl;
>  	struct slot *slot;
>  	u8 status;
> -
> +	struct pci_bus *pbus = dev->port->subordinate;
>  	ctrl = get_service_data(dev);
>  
>  	/* reinitialize the chipset's event detection logic */
> @@ -302,10 +302,12 @@ static int pciehp_resume(struct pcie_device
> *dev)
>  	/* Check if slot is occupied */
>  	pciehp_get_adapter_status(slot, &status);
>  	mutex_lock(&slot->hotplug_lock);
> -	if (status)
> -		pciehp_enable_slot(slot);
> -	else
> +	if (status) {
> +		if (list_empty(&pbus->devices))
> +			pciehp_enable_slot(slot);
> +	} else if (!list_empty(&pbus->devices))
>  		pciehp_disable_slot(slot);
> +
>  	mutex_unlock(&slot->hotplug_lock);
>  	return 0;
>  }
> 
-- 

All Rights Reversed.
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)