Re: [patch 1/1] Convert the semaphore to a mutex in net/tipc/socket.c
From: Andrew Morton <[EMAIL PROTECTED]> Date: Tue, 11 Dec 2007 16:44:45 -0800 > So I'd propose this: I've applied this to net-2.6, thanks Andrew. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/1] Convert the semaphore to a mutex in net/tipc/socket.c
From: Andrew Morton [EMAIL PROTECTED] Date: Tue, 11 Dec 2007 16:44:45 -0800 So I'd propose this: I've applied this to net-2.6, thanks Andrew. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 <[EMAIL PROTECTED]> 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(>sem);
if (!sock->sk) {
up(>sem);
return 0;
}
...
up(>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(>sem);
+ down(>sem);
if (!sock->sk) {
up(>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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
