mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
To: Thomas Gleixner <tglx@tglx.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Tony Lindgren <tony@atomide.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Pavel Machek <pavel@ucw.cz>,
	Linus Walleij <linus.walleij@linaro.org>,
	Grygorii Strashko <grygorii.strashko@ti.com>
Subject: Re: [GIT pull] irq updates for 4.13
Date: Wed, 12 Jul 2017 00:51:13 +0200	[thread overview]
Message-ID: <20170711225113.2acaer6jepx2rwph@earth> (raw)
In-Reply-To: <alpine.DEB.2.20.1707112307490.15368@nanos>

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

Hi,

On Tue, Jul 11, 2017 at 11:41:52PM +0200, Thomas Gleixner wrote:
> [...]
>
> Here is a revised version of the previous patch with the conditional
> locking removed and a bunch of comments added.

That one also fixes Droid 4 boot.

Tested-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>

-- Sebastian

> 8<----------------------------
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -1090,6 +1090,16 @@ setup_irq_thread(struct irqaction *new,
>  /*
>   * Internal function to register an irqaction - typically used to
>   * allocate special interrupts that are part of the architecture.
> + *
> + * Locking rules:
> + *
> + * desc->request_mutex	Provides serialization against a concurrent free_irq()
> + *   chip_bus_lock	Provides serialization for slow bus operations
> + *     desc->lock	Provides serialization against hard interrupts
> + *
> + * chip_bus_lock and desc->lock are sufficient for all other management and
> + * interrupt related functions. desc->request_mutex solely serializes
> + * request/free_irq().
>   */
>  static int
>  __setup_irq(unsigned int irq, struct irq_desc *desc, struct irqaction *new)
> @@ -1167,20 +1177,35 @@ static int
>  	if (desc->irq_data.chip->flags & IRQCHIP_ONESHOT_SAFE)
>  		new->flags &= ~IRQF_ONESHOT;
>  
> +	/*
> +	 * Protects against a concurrent __free_irq() call which might wait
> +	 * for synchronize_irq() to complete without holding the optional
> +	 * chip bus lock and desc->lock.
> +	 */
>  	mutex_lock(&desc->request_mutex);
> +
> +	/*
> +	 * Acquire bus lock as the irq_request_resources() callback below
> +	 * might rely on the serialization or the magic power management
> +	 * functions which are abusing the irq_bus_lock() callback,
> +	 */
> +	chip_bus_lock(desc);
> +
> +	/* First installed action requests resources. */
>  	if (!desc->action) {
>  		ret = irq_request_resources(desc);
>  		if (ret) {
>  			pr_err("Failed to request resources for %s (irq %d) on irqchip %s\n",
>  			       new->name, irq, desc->irq_data.chip->name);
> -			goto out_mutex;
> +			goto out_bus_unlock;
>  		}
>  	}
>  
> -	chip_bus_lock(desc);
> -
>  	/*
>  	 * The following block of code has to be executed atomically
> +	 * protected against a concurrent interrupt and any of the other
> +	 * management calls which are not serialized via
> +	 * desc->request_mutex or the optional bus lock.
>  	 */
>  	raw_spin_lock_irqsave(&desc->lock, flags);
>  	old_ptr = &desc->action;
> @@ -1286,10 +1311,8 @@ static int
>  			ret = __irq_set_trigger(desc,
>  						new->flags & IRQF_TRIGGER_MASK);
>  
> -			if (ret) {
> -				irq_release_resources(desc);
> +			if (ret)
>  				goto out_unlock;
> -			}
>  		}
>  
>  		desc->istate &= ~(IRQS_AUTODETECT | IRQS_SPURIOUS_DISABLED | \
> @@ -1385,12 +1408,10 @@ static int
>  out_unlock:
>  	raw_spin_unlock_irqrestore(&desc->lock, flags);
>  
> -	chip_bus_sync_unlock(desc);
> -
>  	if (!desc->action)
>  		irq_release_resources(desc);
> -
> -out_mutex:
> +out_bus_unlock:
> +	chip_bus_sync_unlock(desc);
>  	mutex_unlock(&desc->request_mutex);
>  
>  out_thread:
> @@ -1472,6 +1493,7 @@ static struct irqaction *__free_irq(unsi
>  			WARN(1, "Trying to free already-free IRQ %d\n", irq);
>  			raw_spin_unlock_irqrestore(&desc->lock, flags);
>  			chip_bus_sync_unlock(desc);
> +			mutex_unlock(&desc->request_mutex);
>  			return NULL;
>  		}
>  
> @@ -1498,6 +1520,20 @@ static struct irqaction *__free_irq(unsi
>  #endif
>  
>  	raw_spin_unlock_irqrestore(&desc->lock, flags);
> +	/*
> +	 * Drop bus_lock here so the changes which were done in the chip
> +	 * callbacks above are synced out to the irq chips which hang
> +	 * behind a slow bus (I2C, SPI) before calling synchronize_irq().
> +	 *
> +	 * Aside of that the bus_lock can also be taken from the threaded
> +	 * handler in irq_finalize_oneshot() which results in a deadlock
> +	 * because synchronize_irq() would wait forever for the thread to
> +	 * complete, which is blocked on the bus lock.
> +	 *
> +	 * The still held desc->request_mutex() protects against a
> +	 * concurrent request_irq() of this irq so the release of resources
> +	 * and timing data is properly serialized.
> +	 */
>  	chip_bus_sync_unlock(desc);
>  
>  	unregister_handler_proc(irq, action);
> @@ -1530,8 +1566,15 @@ static struct irqaction *__free_irq(unsi
>  		}
>  	}
>  
> +	/* Last action releases resources */
>  	if (!desc->action) {
> +		/*
> +		 * Reaquire bus lock as irq_release_resources() might
> +		 * require it to deallocate resources over the slow bus.
> +		 */
> +		chip_bus_lock(desc);
>  		irq_release_resources(desc);
> +		chip_bus_sync_unlock(desc);
>  		irq_remove_timings(desc);
>  	}
>  

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2017-07-11 22:51 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-09  8:49 Thomas Gleixner
2017-07-10 13:35 ` Sebastian Reichel
2017-07-10 17:01   ` Linus Torvalds
2017-07-10 19:38     ` Pavel Machek
2017-07-10 20:15     ` Sebastian Reichel
2017-07-10 21:29       ` Linus Torvalds
2017-07-11  6:55     ` Thomas Gleixner
2017-07-11  9:26       ` Sebastian Reichel
2017-07-11  9:55         ` Thomas Gleixner
2017-07-11 10:52           ` Thomas Gleixner
2017-07-11 11:21             ` Sebastian Reichel
2017-07-11 13:27               ` Thomas Gleixner
2017-07-11 13:51               ` Marc Zyngier
2017-07-11 14:39                 ` Sebastian Reichel
2017-07-11  9:47       ` Thomas Gleixner
2017-07-11 13:51         ` Tony Lindgren
2017-07-11 14:41           ` Thomas Gleixner
2017-07-11 15:07             ` Thomas Gleixner
2017-07-11 15:43               ` Tony Lindgren
2017-07-11 15:39             ` Grygorii Strashko
2017-07-11 16:17               ` Tony Lindgren
2017-07-12  8:00               ` Geert Uytterhoeven
2017-07-11 15:40             ` Linus Torvalds
2017-07-11 16:14               ` Sebastian Reichel
2017-07-11 16:15               ` Tony Lindgren
2017-07-11 17:17                 ` Thomas Gleixner
2017-07-11 17:39                   ` Tony Lindgren
2017-07-11 16:19               ` Thomas Gleixner
2017-07-11 16:31                 ` Linus Torvalds
2017-07-11 17:52                   ` Thomas Gleixner
2017-07-11 18:16                     ` Linus Torvalds
2017-07-11 21:30                       ` Sebastian Reichel
2017-07-11 21:41                       ` Thomas Gleixner
2017-07-11 22:04                         ` Linus Torvalds
2017-07-11 22:51                         ` Sebastian Reichel [this message]
2017-07-12  5:29                           ` Tony Lindgren
2017-07-15 20:24                             ` Pavel Machek
2017-07-17  6:21                               ` Tony Lindgren
2017-07-17 20:01                               ` Linus Torvalds
2017-07-17 21:33                                 ` Pavel Machek
2017-07-11 16:34                 ` Tony Lindgren
2017-07-11 14:41           ` Sebastian Reichel
2017-07-11 16:20             ` Tony Lindgren
2017-07-11 16:34               ` Sebastian Reichel
  -- strict thread matches above, loose matches on Subject: below --
2017-07-03  7:42 Thomas Gleixner
2017-07-04  0:00 ` Linus Torvalds
2017-07-04  8:12   ` Thomas Gleixner
2017-07-04 10:29     ` Thomas Gleixner
2017-07-04 15:17   ` Jens Axboe
2017-07-04 18:34     ` Linus Torvalds
2017-07-04 19:10       ` Thomas Gleixner
2017-07-04 20:48         ` Max Gurtovoy
2017-07-06 13:58           ` Max Gurtovoy
2017-07-04 21:56       ` Jens Axboe
2017-07-05 15:14   ` Christoph Hellwig

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=20170711225113.2acaer6jepx2rwph@earth \
    --to=sebastian.reichel@collabora.co.uk \
    --cc=akpm@linux-foundation.org \
    --cc=grygorii.strashko@ti.com \
    --cc=hpa@zytor.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=pavel@ucw.cz \
    --cc=tglx@linutronix.de \
    --cc=tglx@tglx.de \
    --cc=tony@atomide.com \
    --cc=torvalds@linux-foundation.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®