Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760110Ab3CZSfg (ORCPT ); Tue, 26 Mar 2013 14:35:36 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:50556 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753510Ab3CZSff (ORCPT ); Tue, 26 Mar 2013 14:35:35 -0400 Date: Tue, 26 Mar 2013 11:35:33 -0700 From: Andrew Morton To: Davidlohr Bueso Cc: Emmanuel Benisty , Linus Torvalds , Rik van Riel , Linux Kernel Mailing List , hhuang@redhat.com, "Low, Jason" , Michel Lespinasse , Larry Woodman , "Vinod, Chegu" Subject: Re: ipc,sem: sysv semaphore scalability Message-Id: <20130326113533.41ad9ee33b2d010b2a83e7c0@linux-foundation.org> In-Reply-To: <1364320767.5146.11.camel@buesod1.americas.hpqcorp.net> References: <1363809337-29718-1-git-send-email-riel@surriel.com> <1364320767.5146.11.camel@buesod1.americas.hpqcorp.net> X-Mailer: Sylpheed 3.2.0beta5 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2088 Lines: 69 On Tue, 26 Mar 2013 10:59:27 -0700 Davidlohr Bueso wrote: > On Mon, 2013-03-25 at 20:47 +0700, Emmanuel Benisty wrote: > > On Mon, Mar 25, 2013 at 12:10 AM, Linus Torvalds > > wrote: > > > And you never see this problem without Rik's patches? > > > > No, never. > > > > > Could you bisect > > > *which* patch it starts with? Are the first four ones ok (the moving > > > of the locking around, but without the fine-grained ones), for > > > example? > > > > With the first four patches only, I got some X server freeze (just tried once). > > Going over the code again, I found a potential recursive spinlock scenario. > Andrew, if you have no objections, please queue this up. > > Thanks. > > ---8<--- > > From: Davidlohr Bueso > Subject: [PATCH] ipc, sem: prevent possible deadlock > > In semctl_main(), when cmd == GETALL, we're locking > sma->sem_perm.lock (through sem_lock_and_putref), yet > after the conditional, we lock it again. > Unlock sma right after exiting the conditional. > > Signed-off-by: Davidlohr Bueso > --- > ipc/sem.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/ipc/sem.c b/ipc/sem.c > index 1a2913d..f257afe 100644 > --- a/ipc/sem.c > +++ b/ipc/sem.c > @@ -1243,6 +1243,7 @@ static int semctl_main(struct ipc_namespace *ns, int semid, int semnum, > err = -EIDRM; > goto out_free; > } > + sem_unlock(sma, -1); > } > > sem_lock(sma, NULL, -1); Looks right. Do we need the locking at all? What does it actually do? sem_lock_and_putref(sma); if (sma->sem_perm.deleted) { sem_unlock(sma, -1); err = -EIDRM; goto out_free; } sem_unlock(sma, -1); We're taking the lock, testing an int and then dropping the lock. What's the point in that? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/