linux-kernel - Re: [PATCH] workqueue: fix possible bug which may silence the pool

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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 5 Mar 2013 10:04:46 -0800
From:	Tejun Heo <tj@...nel.org>
To:	Lai Jiangshan <laijs@...fujitsu.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] workqueue: fix possible bug which may silence the pool

Hello, Lai.

On Tue, Mar 05, 2013 at 09:17:16AM +0800, Lai Jiangshan wrote:
> > But can we please just addd wake_up_worker() in the
> > for_each_std_worker_pool() loop?  
> 
> wake_up_worker() needed be put on the same loop which do set %WORKER_UNBOUND.
> 
> mutex_lock(&pool->assoc_mutex);
> do set %WORKER_UNBOUND for normal_pri pool
> mutex_unlock(&pool->assoc_mutex);
> 
> // no wakeup for normal_pri pool
> // but all workers of normal_pri pool goto sleep
> 
> // try to  do set %WORKER_UNBOUND for high_pri pool
> mutex_lock(&pool->assoc_mutex);
> 	waiting forever here due to high_pri pool's manage_workers()
> 	waiting on allocating memory forever(waiting normal_pri pool
> 	free memory, but normal_pri pool is silenced)
> mutex_unlock(&pool->assoc_mutex);

Hmmm.... I see.  Can you please separate it into two patches then?
One to restructure the loop into one and the other to add wake up,
and add comment explaining why the loop has to be per-pool?

Thanks.

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