All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: nick <xerofoify@gmail.com>,
	Valdis.Kletnieks@vt.edu,
	Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm:Avoid soft lockup due to possible attempt of double locking object's lock in __delete_object
Date: Tue, 06 Sep 2016 20:51:51 -0400	[thread overview]
Message-ID: <1473209511.32433.179.camel@redhat.com> (raw)
In-Reply-To: <6b5d162b-c09d-85c0-752f-a18f35bbbb5c@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3054 bytes --]

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@gmail.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@gmail.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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2016-09-07  0:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-30 18:35 [PATCH] mm:Avoid soft lockup due to possible attempt of double locking object's lock in __delete_object Nicholas Krause
2016-08-31  7:54 ` Catalin Marinas
2016-08-31  7:54   ` Catalin Marinas
2016-08-31 13:24   ` nick
2016-09-07  0:45     ` Rik van Riel
2016-08-31 13:41   ` nick
2016-08-31 14:35     ` Catalin Marinas
2016-08-31 14:35       ` Catalin Marinas
2016-08-31 21:08   ` Valdis.Kletnieks
2016-08-31 21:28     ` nick
2016-09-07  0:51       ` Rik van Riel [this message]
2016-09-07  1:12         ` nick
2016-09-07  1:22           ` Rik van Riel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1473209511.32433.179.camel@redhat.com \
    --to=riel@redhat.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=catalin.marinas@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=xerofoify@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.