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]
Date:	Thu, 12 Sep 2013 16:42:23 +0200
From:	Gerlando Falauto <gerlando.falauto@...mile.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	John Stultz <john.stultz@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Richard Cochran <richardcochran@...il.com>,
	Prarit Bhargava <prarit@...hat.com>,
	"Brunck, Holger" <Holger.Brunck@...mile.com>,
	"Longchamp, Valentin" <Valentin.Longchamp@...mile.com>,
	"Bigler, Stefan" <Stefan.Bigler@...mile.com>, sboyd@...eaurora.org
Subject: Re: kernel deadlock

Hi Peter,

sorry for the slow response...

On 09/09/2013 12:08 PM, Peter Zijlstra wrote:
> On Tue, Sep 03, 2013 at 10:26:19AM -0700, John Stultz wrote:
>> Enabling the SCHED_FEAT(HRTICK, true) bit tends to cause lots of issues
>> on the various hardware I have, tripping the lockdep warnings on various
>> other issues:
>
> Does whatever kernel you guys are running have this commit:

That didn't seem to make a difference (it had already been pointed out 
by Stephen Boyd).
In any case, latest patch from John fixes the problem... Hooray! :-)

Thanks again John!
Gerlando


>
> ---
> commit 971ee28cbd1ccd87b3164facd9359a534c1d2892
> Author: Peter Zijlstra <peterz@...radead.org>
> Date:   Fri Jun 28 11:18:53 2013 +0200
>
>      sched: Fix HRTICK
>
>      David reported that the HRTICK sched feature was borken; which was enough
>      motivation for me to finally fix it ;-)
>
>      We should not allow hrtimer code to do softirq wakeups while holding scheduler
>      locks. The hrtimer code only needs this when we accidentally try to program an
>      expired time. We don't much care about those anyway since we have the regular
>      tick to fall back to.
>
>      Reported-by: David Ahern <dsahern@...il.com>
>      Tested-by: David Ahern <dsahern@...il.com>
>      Signed-off-by: Peter Zijlstra <peterz@...radead.org>
>      Link: http://lkml.kernel.org/r/20130628091853.GE29209@dyad.programming.kicks-ass.net
>      Signed-off-by: Ingo Molnar <mingo@...nel.org>
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 9b1f2e5..0d8eb45 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -370,13 +370,6 @@ static struct rq *this_rq_lock(void)
>   #ifdef CONFIG_SCHED_HRTICK
>   /*
>    * Use HR-timers to deliver accurate preemption points.
> - *
> - * Its all a bit involved since we cannot program an hrt while holding the
> - * rq->lock. So what we do is store a state in in rq->hrtick_* and ask for a
> - * reschedule event.
> - *
> - * When we get rescheduled we reprogram the hrtick_timer outside of the
> - * rq->lock.
>    */
>
>   static void hrtick_clear(struct rq *rq)
> @@ -404,6 +397,15 @@ static enum hrtimer_restart hrtick(struct hrtimer *timer)
>   }
>
>   #ifdef CONFIG_SMP
> +
> +static int __hrtick_restart(struct rq *rq)
> +{
> +	struct hrtimer *timer = &rq->hrtick_timer;
> +	ktime_t time = hrtimer_get_softexpires(timer);
> +
> +	return __hrtimer_start_range_ns(timer, time, 0, HRTIMER_MODE_ABS_PINNED, 0);
> +}
> +
>   /*
>    * called from hardirq (IPI) context
>    */
> @@ -412,7 +414,7 @@ static void __hrtick_start(void *arg)
>   	struct rq *rq = arg;
>
>   	raw_spin_lock(&rq->lock);
> -	hrtimer_restart(&rq->hrtick_timer);
> +	__hrtick_restart(rq);
>   	rq->hrtick_csd_pending = 0;
>   	raw_spin_unlock(&rq->lock);
>   }
> @@ -430,7 +432,7 @@ void hrtick_start(struct rq *rq, u64 delay)
>   	hrtimer_set_expires(timer, time);
>
>   	if (rq == this_rq()) {
> -		hrtimer_restart(timer);
> +		__hrtick_restart(rq);
>   	} else if (!rq->hrtick_csd_pending) {
>   		__smp_call_function_single(cpu_of(rq), &rq->hrtick_csd, 0);
>   		rq->hrtick_csd_pending = 1;
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ