[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1364320767.5146.11.camel@buesod1.americas.hpqcorp.net>
Date: Tue, 26 Mar 2013 10:59:27 -0700
From: Davidlohr Bueso <davidlohr.bueso@...com>
To: Emmanuel Benisty <benisty.e@...il.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Rik van Riel <riel@...riel.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>, hhuang@...hat.com,
"Low, Jason" <jason.low2@...com>,
Michel Lespinasse <walken@...gle.com>,
Larry Woodman <lwoodman@...hat.com>,
"Vinod, Chegu" <chegu_vinod@...com>
Subject: Re: ipc,sem: sysv semaphore scalability
On Mon, 2013-03-25 at 20:47 +0700, Emmanuel Benisty wrote:
> On Mon, Mar 25, 2013 at 12:10 AM, Linus Torvalds
> <torvalds@...ux-foundation.org> 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 <davidlohr.bueso@...com>
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 <davidlohr.bueso@...com>
---
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);
--
1.7.11.7
--
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