linux-kernel - Re: [PATCH]: mutex: Fix !CONFIG_MUTEX_SPIN_ON

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:	Fri, 28 May 2010 00:40:24 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Prarit Bhargava <prarit@...hat.com>, Ingo Molnar <mingo@...e.hu>
Cc:	linux-kernel@...r.kernel.org, hpa@...or.com,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH]: mutex: Fix !CONFIG_MUTEX_SPIN_ON_OWNER compile warning

On Thu, May 27, 2010 at 03:07:40PM -0400, Prarit Bhargava wrote:
> Fixes linux-next !CONFIG_MUTEX_SPIN_ON_OWNER compile warning:
> 
> kernel/mutex.c: In function ‘__mutex_lock_common’:
> kernel/mutex.c:148: error: unused variable ‘timeout’
> 
> timeout is only used if CONFIG_MUTEX_SPIN_ON_OWNER is on.
> 
> Signed-off-by: Prarit Bhargava <prarit@...hat.com>
> 
> diff --git a/kernel/mutex.c b/kernel/mutex.c
> index 7d4626b..c262942 100644
> --- a/kernel/mutex.c
> +++ b/kernel/mutex.c
> @@ -145,7 +145,9 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
>  	struct task_struct *task = current;
>  	struct mutex_waiter waiter;
>  	unsigned long flags;
> +#ifdef CONFIG_MUTEX_SPIN_ON_OWNER
>  	unsigned long timeout;
> +#endif
>  
>  	preempt_disable();
>  	mutex_acquire(&lock->dep_map, subclass, 0, ip);



In fact the situation is a bit more complicated.

There are two things that are related to this build warning:

- the lock inversion prevention against the bkl
- the timeout for other purposes, basically to limit too long spins

And the lock inversion fix needs to be standalone because it should
be backported to the stable branches.

So it seems that the plans are more:

1) have a clean patch that only prevents from the bkl lock inversion
2) thinking about the timeout, may be find something better if we can

All in one, I suspect these patches will be refactored rather than
improved incrementally, to make the backport of 1) easier.

So the warning issue will probably disappear in the meantime.

--
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/