From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754931AbbIPKWp (ORCPT ); Wed, 16 Sep 2015 06:22:45 -0400 Received: from www.linutronix.de ([62.245.132.108]:47733 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754591AbbIPKWn (ORCPT ); Wed, 16 Sep 2015 06:22:43 -0400 Date: Wed, 16 Sep 2015 12:22:09 +0200 (CEST) From: Thomas Gleixner To: Zhu Jefferry cc: "linux-kernel@vger.kernel.org" , "bigeasy@linutronix.de" Subject: RE: [PATCH v2] futex: lower the lock contention on the HB lock during wake up In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 16 Sep 2015, Zhu Jefferry wrote: > The application is a multi-thread program, to use the pairs of mutex_lock and > mutex_unlock to protect the shared data structure. The type of this mutex > is PTHREAD_MUTEX_PI_RECURSIVE_NP. After running long time, to say several days, > the mutex_lock data structure in user space looks like corrupt. > > thread 0 can do mutex_lock/unlock > __lock = this thread | FUTEX_WAITERS > __owner = 0, should be this thread The kernel does not know about __owner. > __counter keep increasing, although there is no recursive mutex_lock call. > > thread 1 will be stuck > > The primary debugging shows the content of __lock is wrong in first. After a call of > Mutex_unlock, the value of __lock should not be this thread self. But we observed > The value of __lock is still self after unlock. So, other threads will be stuck, How did you observe that? > This thread could lock due to recursive type and __counter keep increasing, > although mutex_unlock return fails, due to the wrong value of __owner, > but the application did not check the return value. So the thread 0 looks > like fine. But thread 1 will be stuck forever. Oh well. So thread 0 looks all fine, despite not checking return values. Thanks, tglx