[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 11 Dec 2007 16:44:45 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Kevin Winchester <kjwinchester@...il.com>
Cc: mingo@...e.hu, per.liden@...csson.com, jon.maloy@...csson.com,
allan.stephens@...driver.com,
tipc-discussion@...ts.sourceforge.net,
linux-kernel@...r.kernel.org, kjwinchester@...il.com,
netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>
Subject: Re: [patch 1/1] Convert the semaphore to a mutex in
net/tipc/socket.c
On Sun, 09 Dec 2007 21:17:42 -0400
Kevin Winchester <kjwinchester@...il.com> wrote:
> Note also that in the release method, down_interruptible() was being called
> without checking the return value. I converted it to mutex_lock_interruptible()
> and made the interrupted case return -ERESTARTSYS, as was done for all other
> calls to down_interruptible() in the file.
That's an outright bug.
static int release(struct socket *sock)
{
struct tipc_sock *tsock = tipc_sk(sock->sk);
struct sock *sk = sock->sk;
int res = TIPC_OK;
struct sk_buff *buf;
dbg("sock_delete: %x\n",tsock);
if (!tsock)
return 0;
down_interruptible(&tsock->sem);
if (!sock->sk) {
up(&tsock->sem);
return 0;
}
...
up(&tsock->sem);
...
}
So if the calling process has signal_pending(), down_interruptible() will
return without having downed the semaphore and then we merrily proceed to
do up() on it, so a subsequent down() won't actually take the lock and
things will deteriorate from there.
So I'd propose this:
--- a/net/tipc/socket.c~a
+++ a/net/tipc/socket.c
@@ -253,7 +253,7 @@ static int release(struct socket *sock)
dbg("sock_delete: %x\n",tsock);
if (!tsock)
return 0;
- down_interruptible(&tsock->sem);
+ down(&tsock->sem);
if (!sock->sk) {
up(&tsock->sem);
return 0;
_
as a for-2.6.24 bugfix. And for 2.6.23. But someone who knows what
they're doing should take a look at this...
--
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