Skip to contentSkip to conversation

fixes for net-2.6.23

PATCH Applied Ursula Braun 2 participants 7 messages Jul 13, 2007 – Jul 15, 2007

Subsystems (4)
Networking Network drivers s390 s390 iucv network layer
lore
Share & tools
lore

Ursula Braun

author
#0 lore raw

cover fixes for net-2.6.23

Signature · 8 lines
Dave,

following three small patches contain:
- a configuration improvement for AF_IUCV socket support
- two fixes for iucv, the base code for IUCV related actions in z/VM

Thank you.
Ursula
author
#1 lore raw

PATCH 1/3 From: Jennifer Hunt <[email protected]>

[PATCH] s390: iucv Kconfig.

Improve description of IUCV and AFIUCV configuration options.

Signed-off-by Jennifer Hunt <[email protected]>
Signed-off-by Ursula Braun >[email protected]>
Acked-by Frank Pavlic <[email protected]>

---

 net/iucv/Kconfig |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)
net/iucv/Kconfig +4 -4
Index: net-2.6-uschi/net/iucv/Kconfig
===================================================================
@@ -1,13 +1,13 @@
 config IUCV
-	tristate "IUCV support (VM only)"
+	tristate "IUCV support (S390 - z/VM only)"
 	depends on S390
 	help
-	  Select this option if you want to use inter-user communication under
-	  VM or VIF sockets. If you run on z/VM, say "Y" to enable a fast
+	  Select this option if you want to use inter-user communication
+	  under VM or VIF. If you run on z/VM, say "Y" to enable a fast
 	  communication link between VM guests.
 
 config AFIUCV
-	tristate "AF_IUCV support (VM only)"
+	tristate "AF_IUCV support (S390 - z/VM only)"
 	depends on IUCV
 	help
 	  Select this option if you want to use inter-user communication under
author
#3 lore raw

PATCH 2/3 s390: iucv - avoid deadlock between iucv_path_connect and tasklet

In reply to Ursula Braun

From: Ursula Braun <[email protected]>

An iucv deadlock may occur, where one CPU is spinning on the iucv_table_lock for iucv_tasklet_fn(), while another CPU is holding the iucv_table_lock for an iucv_path_connect() and is waiting for the first CPU in an smp_call_function.
Solution: replace spin_lock in iucv_tasklet_fn by spin_trylock and reschedule tasklet in case of non-granted lock.

Signed-off-by Ursula Braun <[email protected]>
Acked-by Frank Pavlic <[email protected]>

---

 net/iucv/iucv.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletion(-)
net/iucv/iucv.c +4 -1
Index: net-2.6-uschi/net/iucv/iucv.c
===================================================================
@@ -1494,7 +1494,10 @@ static void iucv_tasklet_fn(unsigned lon
 	struct iucv_irq_list *p, *n;
 
 	/* Serialize tasklet, iucv_path_sever and iucv_path_connect. */
-	spin_lock(&iucv_table_lock);
+	if (!spin_trylock(&iucv_table_lock)) {
+		tasklet_schedule(&iucv_tasklet);
+		return;
+	}
 	iucv_active_cpu = smp_processor_id();
 
 	spin_lock_irq(&iucv_queue_lock);
maintainer Applied
#4 lore raw

Re: [patch 2/3] s390: iucv - avoid deadlock between iucv_path_connect and tasklet

From: Ursula Braun <[email protected]>
Date: Fri, 13 Jul 2007 10:50:55 +0200

Quoted 11 lines

From: Ursula Braun <[email protected]>

An iucv deadlock may occur, where one CPU is spinning on the iucv_table_lock for iucv_tasklet_fn(), while another CPU is holding the iucv_table_lock for an iucv_path_connect() and is waiting for the first CPU in an smp_call_function.
Solution: replace spin_lock in iucv_tasklet_fn by spin_trylock and reschedule tasklet in case of non-granted lock.

Signed-off-by Ursula Braun <[email protected]>
Acked-by Frank Pavlic <[email protected]>

Applied.

author
#5 lore raw

PATCH 3/3 s390: af_iucv: add lock when updating accept_q

In reply to Ursula Braun

From: Ursula Braun <[email protected]>

The accept_queue of an af_iucv socket will be corrupted, if adding and deleting of entries in this queue occurs at the same time (connect request from one client, while accept call is processed for another client).
Solution: add locking when updating accept_q

Signed-off-by Ursula Braun <[email protected]>
Acked-by Frank Pavlic <[email protected]>

---

 include/net/iucv/af_iucv.h |    1 +
 net/iucv/af_iucv.c         |   16 ++++++++++++++--
 2 files changed, 15 insertions(+), 2 deletions(-)
include/net/iucv/af_iucv.h +1 -0
Index: net-2.6-uschi/include/net/iucv/af_iucv.h
===================================================================
@@ -60,6 +60,7 @@ struct iucv_sock {
 	char			dst_user_id[8];
 	char			dst_name[8];
 	struct list_head	accept_q;
+	spinlock_t		accept_q_lock;
 	struct sock		*parent;
 	struct iucv_path	*path;
 	struct sk_buff_head	send_skb_q;
net/iucv/af_iucv.c +14 -2
Index: net-2.6-uschi/net/iucv/af_iucv.c
===================================================================
@@ -219,6 +219,7 @@ static struct sock *iucv_sock_alloc(stru
 
 	sock_init_data(sock, sk);
 	INIT_LIST_HEAD(&iucv_sk(sk)->accept_q);
+	spin_lock_init(&iucv_sk(sk)->accept_q_lock);
 	skb_queue_head_init(&iucv_sk(sk)->send_skb_q);
 	skb_queue_head_init(&iucv_sk(sk)->backlog_skb_q);
 	iucv_sk(sk)->send_tag = 0;

@@ -274,15 +275,25 @@ void iucv_sock_unlink(struct iucv_sock_l
 
 void iucv_accept_enqueue(struct sock *parent, struct sock *sk)
 {
+	unsigned long flags;
+	struct iucv_sock *par = iucv_sk(parent);
+
 	sock_hold(sk);
-	list_add_tail(&iucv_sk(sk)->accept_q, &iucv_sk(parent)->accept_q);
+	spin_lock_irqsave(&par->accept_q_lock, flags);
+	list_add_tail(&iucv_sk(sk)->accept_q, &par->accept_q);
+	spin_unlock_irqrestore(&par->accept_q_lock, flags);
 	iucv_sk(sk)->parent = parent;
 	parent->sk_ack_backlog++;
 }
 
 void iucv_accept_unlink(struct sock *sk)
 {
+	unsigned long flags;
+	struct iucv_sock *par = iucv_sk(iucv_sk(sk)->parent);
+
+	spin_lock_irqsave(&par->accept_q_lock, flags);
 	list_del_init(&iucv_sk(sk)->accept_q);
+	spin_unlock_irqrestore(&par->accept_q_lock, flags);
 	iucv_sk(sk)->parent->sk_ack_backlog--;
 	iucv_sk(sk)->parent = NULL;
 	sock_put(sk);

@@ -298,8 +309,8 @@ struct sock *iucv_accept_dequeue(struct 
 		lock_sock(sk);
 
 		if (sk->sk_state == IUCV_CLOSED) {
-			release_sock(sk);
 			iucv_accept_unlink(sk);
+			release_sock(sk);
 			continue;
 		}
 

@@ -879,6 +890,7 @@ static int iucv_callback_connreq(struct 
 	/* Find out if this path belongs to af_iucv. */
 	read_lock(&iucv_sk_list.lock);
 	iucv = NULL;
+	sk = NULL;
 	sk_for_each(sk, node, &iucv_sk_list.head)
 		if (sk->sk_state == IUCV_LISTEN &&
 		    !memcmp(&iucv_sk(sk)->src_name, src_name, 8)) {
maintainer
#6 lore raw

Re: [patch 3/3] s390: af_iucv: add lock when updating accept_q

From: Ursula Braun <[email protected]>
Date: Fri, 13 Jul 2007 10:50:56 +0200

Quoted 10 lines

From: Ursula Braun <[email protected]>

The accept_queue of an af_iucv socket will be corrupted, if adding and deleting of entries in this queue occurs at the same time (connect request from one client, while accept call is processed for another client).
Solution: add locking when updating accept_q

Signed-off-by Ursula Braun <[email protected]>
Acked-by Frank Pavlic <[email protected]>

Also applied, thanks.

In the future please us consistent formatting of your changelog header lines. I have to edit them by hand and I'd like to stop having to do that.

Use something like:

[AF_IUCV]: Blah blah blah.

Thanks :)