]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
4.4-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 19 Apr 2017 13:18:02 +0000 (15:18 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 19 Apr 2017 13:18:02 +0000 (15:18 +0200)
added patches:
mips-fix-select-have_irq_exit_on_irq_stack-patch.patch
sctp-deny-peeloff-operation-on-asocs-with-threads-sleeping-on-it.patch

queue-4.4/mips-fix-select-have_irq_exit_on_irq_stack-patch.patch [new file with mode: 0644]
queue-4.4/sctp-deny-peeloff-operation-on-asocs-with-threads-sleeping-on-it.patch [new file with mode: 0644]
queue-4.4/series

diff --git a/queue-4.4/mips-fix-select-have_irq_exit_on_irq_stack-patch.patch b/queue-4.4/mips-fix-select-have_irq_exit_on_irq_stack-patch.patch
new file mode 100644 (file)
index 0000000..0c50252
--- /dev/null
@@ -0,0 +1,47 @@
+From foo@baz Wed Apr 19 15:14:54 CEST 2017
+Date: Wed, 19 Apr 2017 15:14:54 +0200
+To: Greg KH <gregkh@linuxfoundation.org>
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Subject: MIPS: fix Select HAVE_IRQ_EXIT_ON_IRQ_STACK patch.
+
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+Commit f017e58da4aba293e4a6ab62ca5d4801f79cc929 which was commit
+3cc3434fd6307d06b53b98ce83e76bf9807689b9 upstream, was misapplied to the
+4.4 stable kernel.
+
+This patch fixes this and moves the chunk to the proper Kconfig area.
+
+Reported-by: "Maciej W. Rozycki" <macro@linux-mips.org>
+Cc: Matt Redfearn <matt.redfearn@imgtec.com>
+Cc: Jason A. Donenfeld <jason@zx2c4.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Ralf Baechle <ralf@linux-mips.org>
+Cc: Amit Pundir <amit.pundir@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+
+---
+ arch/mips/Kconfig |    4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/mips/Kconfig
++++ b/arch/mips/Kconfig
+@@ -1413,7 +1413,7 @@ config CPU_MIPS32_R6
+       select CPU_SUPPORTS_MSA
+       select GENERIC_CSUM
+       select HAVE_KVM
+-      select MIPS_O32_FP64_SUPPORT if 32BIT
++      select MIPS_O32_FP64_SUPPORT
+       help
+         Choose this option to build a kernel for release 6 or later of the
+         MIPS32 architecture.  New MIPS processors, starting with the Warrior
+@@ -1464,7 +1464,7 @@ config CPU_MIPS64_R6
+       select CPU_SUPPORTS_HIGHMEM
+       select CPU_SUPPORTS_MSA
+       select GENERIC_CSUM
+-      select MIPS_O32_FP64_SUPPORT if MIPS32_O32
++      select MIPS_O32_FP64_SUPPORT if 32BIT || MIPS32_O32
+       help
+         Choose this option to build a kernel for release 6 or later of the
+         MIPS64 architecture.  New MIPS processors, starting with the Warrior
diff --git a/queue-4.4/sctp-deny-peeloff-operation-on-asocs-with-threads-sleeping-on-it.patch b/queue-4.4/sctp-deny-peeloff-operation-on-asocs-with-threads-sleeping-on-it.patch
new file mode 100644 (file)
index 0000000..f846f86
--- /dev/null
@@ -0,0 +1,66 @@
+From dfcb9f4f99f1e9a49e43398a7bfbf56927544af1 Mon Sep 17 00:00:00 2001
+From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
+Date: Thu, 23 Feb 2017 09:31:18 -0300
+Subject: sctp: deny peeloff operation on asocs with threads sleeping on it
+
+From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
+
+commit dfcb9f4f99f1e9a49e43398a7bfbf56927544af1 upstream.
+
+commit 2dcab5984841 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf")
+attempted to avoid a BUG_ON call when the association being used for a
+sendmsg() is blocked waiting for more sndbuf and another thread did a
+peeloff operation on such asoc, moving it to another socket.
+
+As Ben Hutchings noticed, then in such case it would return without
+locking back the socket and would cause two unlocks in a row.
+
+Further analysis also revealed that it could allow a double free if the
+application managed to peeloff the asoc that is created during the
+sendmsg call, because then sctp_sendmsg() would try to free the asoc
+that was created only for that call.
+
+This patch takes another approach. It will deny the peeloff operation
+if there is a thread sleeping on the asoc, so this situation doesn't
+exist anymore. This avoids the issues described above and also honors
+the syscalls that are already being handled (it can be multiple sendmsg
+calls).
+
+Joint work with Xin Long.
+
+Fixes: 2dcab5984841 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf")
+Cc: Alexander Popov <alex.popov@linux.com>
+Cc: Ben Hutchings <ben@decadent.org.uk>
+Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
+Signed-off-by: Xin Long <lucien.xin@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/sctp/socket.c |    8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/net/sctp/socket.c
++++ b/net/sctp/socket.c
+@@ -4422,6 +4422,12 @@ int sctp_do_peeloff(struct sock *sk, sct
+       if (!asoc)
+               return -EINVAL;
++      /* If there is a thread waiting on more sndbuf space for
++       * sending on this asoc, it cannot be peeled.
++       */
++      if (waitqueue_active(&asoc->wait))
++              return -EBUSY;
++
+       /* An association cannot be branched off from an already peeled-off
+        * socket, nor is this supported for tcp style sockets.
+        */
+@@ -6960,8 +6966,6 @@ static int sctp_wait_for_sndbuf(struct s
+                */
+               release_sock(sk);
+               current_timeo = schedule_timeout(current_timeo);
+-              if (sk != asoc->base.sk)
+-                      goto do_error;
+               lock_sock(sk);
+               *timeo_p = current_timeo;
index 15ea943a79db856ab0dd60aeba1f3bb272e06d23..e717c088da559c354c8c2b98b0ee9c520cf26eb0 100644 (file)
@@ -41,3 +41,5 @@ ibmveth-calculate-gso_segs-for-large-packets.patch
 sunrpc-fix-refcounting-problems-with-auth_gss-messages.patch
 tty-serial-atmel-rs485-half-duplex-w-dma-enable-rx-after-tx-is-done.patch
 net-ipv6-check-route-protocol-when-deleting-routes.patch
+sctp-deny-peeloff-operation-on-asocs-with-threads-sleeping-on-it.patch
+mips-fix-select-have_irq_exit_on_irq_stack-patch.patch