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]
Message-ID: <20100527224022.GE5390@nowhere>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ