]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
.27 patches
authorGreg Kroah-Hartman <gregkh@suse.de>
Tue, 10 Feb 2009 18:43:20 +0000 (10:43 -0800)
committerGreg Kroah-Hartman <gregkh@suse.de>
Tue, 10 Feb 2009 18:43:20 +0000 (10:43 -0800)
queue-2.6.27/genirq-null-struct-irq_desc-s-member-name-in-dynamic_irq_cleanup.patch [new file with mode: 0644]
queue-2.6.27/sctp-fix-another-socket-race-during-accept-peeloff.patch [new file with mode: 0644]
queue-2.6.27/series

diff --git a/queue-2.6.27/genirq-null-struct-irq_desc-s-member-name-in-dynamic_irq_cleanup.patch b/queue-2.6.27/genirq-null-struct-irq_desc-s-member-name-in-dynamic_irq_cleanup.patch
new file mode 100644 (file)
index 0000000..321b5e2
--- /dev/null
@@ -0,0 +1,40 @@
+From b6f3b7803a9231eddc36d0a2a6d2d8105ef89344 Mon Sep 17 00:00:00 2001
+From: Dean Nelson <dcn@sgi.com>
+Date: Sat, 18 Oct 2008 16:06:56 -0700
+Subject: genirq: NULL struct irq_desc's member 'name' in dynamic_irq_cleanup()
+
+From: Dean Nelson <dcn@sgi.com>
+
+commit b6f3b7803a9231eddc36d0a2a6d2d8105ef89344 upstream.
+
+If the member 'name' of the irq_desc structure happens to point to a
+character string that is resident within a kernel module, problems ensue
+if that module is rmmod'd (at which time dynamic_irq_cleanup() is called)
+and then later show_interrupts() is called by someone.
+
+It is also not a good thing if the character string resided in kmalloc'd
+space that has been kfree'd (after having called dynamic_irq_cleanup()).
+dynamic_irq_cleanup() fails to NULL the 'name' member and
+show_interrupts() references it on a few architectures (like h8300, sh and
+x86).
+
+Signed-off-by: Dean Nelson <dcn@sgi.com>
+Signed-off-by: Ingo Molnar <mingo@elte.hu>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Ingo Molnar <mingo@elte.hu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ kernel/irq/chip.c |    1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/kernel/irq/chip.c
++++ b/kernel/irq/chip.c
+@@ -78,6 +78,7 @@ void dynamic_irq_cleanup(unsigned int ir
+       desc->chip_data = NULL;
+       desc->handle_irq = handle_bad_irq;
+       desc->chip = &no_irq_chip;
++      desc->name = NULL;
+       spin_unlock_irqrestore(&desc->lock, flags);
+ }
diff --git a/queue-2.6.27/sctp-fix-another-socket-race-during-accept-peeloff.patch b/queue-2.6.27/sctp-fix-another-socket-race-during-accept-peeloff.patch
new file mode 100644 (file)
index 0000000..9ad4d4b
--- /dev/null
@@ -0,0 +1,59 @@
+From ae53b5bd77719fed58086c5be60ce4f22bffe1c6 Mon Sep 17 00:00:00 2001
+From: Vlad Yasevich <vladislav.yasevich@hp.com>
+Date: Thu, 22 Jan 2009 14:53:23 -0800
+Subject: sctp: Fix another socket race during accept/peeloff
+
+From: Vlad Yasevich <vladislav.yasevich@hp.com>
+
+commit ae53b5bd77719fed58086c5be60ce4f22bffe1c6 upstream.
+
+There is a race between sctp_rcv() and sctp_accept() where we
+have moved the association from the listening socket to the
+accepted socket, but sctp_rcv() processing cached the old
+socket and continues to use it.
+
+The easy solution is to check for the socket mismatch once we've
+grabed the socket lock.  If we hit a mis-match, that means
+that were are currently holding the lock on the listening socket,
+but the association is refrencing a newly accepted socket.  We need
+to drop the lock on the old socket and grab the lock on the new one.
+
+A more proper solution might be to create accepted sockets when
+the new association is established, similar to TCP.  That would
+eliminate the race for 1-to-1 style sockets, but it would still
+existing for 1-to-many sockets where a user wished to peeloff an
+association.  For now, we'll live with this easy solution as
+it addresses the problem.
+
+Reported-by: Michal Hocko <mhocko@suse.cz>
+Reported-by: Karsten Keil <kkeil@suse.de>
+Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ net/sctp/input.c |   13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+--- a/net/sctp/input.c
++++ b/net/sctp/input.c
+@@ -249,6 +249,19 @@ int sctp_rcv(struct sk_buff *skb)
+        */
+       sctp_bh_lock_sock(sk);
++      if (sk != rcvr->sk) {
++              /* Our cached sk is different from the rcvr->sk.  This is
++               * because migrate()/accept() may have moved the association
++               * to a new socket and released all the sockets.  So now we
++               * are holding a lock on the old socket while the user may
++               * be doing something with the new socket.  Switch our veiw
++               * of the current sk.
++               */
++              sctp_bh_unlock_sock(sk);
++              sk = rcvr->sk;
++              sctp_bh_lock_sock(sk);
++      }
++
+       if (sock_owned_by_user(sk)) {
+               SCTP_INC_STATS_BH(SCTP_MIB_IN_PKT_BACKLOG);
+               sctp_add_backlog(sk, skb);
index 0613c7f36b3362777aa2c079d891f7a67624b09b..64a16240abebd844207156344137e3e255c6a84e 100644 (file)
@@ -52,3 +52,5 @@ usb-new-id-for-ti_usb_3410_5052-driver.patch
 usb-option-new-mobile-broadband-modems-to-be-supported.patch
 usb-two-more-usb-ids-for-ti_usb_3410_5052.patch
 usb-usb-storage-add-pentax-to-the-bad-vendor-list.patch
+sctp-fix-another-socket-race-during-accept-peeloff.patch
+genirq-null-struct-irq_desc-s-member-name-in-dynamic_irq_cleanup.patch