From: Greg Kroah-Hartman Date: Wed, 29 Aug 2012 20:22:03 +0000 (-0700) Subject: 3.0-stable patches X-Git-Tag: v3.5.4~38 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=8f4caa27e62d91b3a2b5a1d12b33e771fbeeb6ee;p=thirdparty%2Fkernel%2Fstable-queue.git 3.0-stable patches added patches: acpi-export-symbol-acpi_get_table_with_size.patch cciss-fix-incorrect-scsi-status-reporting.patch svcrpc-fix-bug-in-svc_tcp_clear_pages.patch svcrpc-fix-svc_xprt_enqueue-svc_recv-busy-looping.patch svcrpc-sends-on-closed-socket-should-stop-immediately.patch --- diff --git a/queue-3.0/acpi-export-symbol-acpi_get_table_with_size.patch b/queue-3.0/acpi-export-symbol-acpi_get_table_with_size.patch new file mode 100644 index 00000000000..5389ae2d3cf --- /dev/null +++ b/queue-3.0/acpi-export-symbol-acpi_get_table_with_size.patch @@ -0,0 +1,29 @@ +From 4f81f986761a7663db7d24d24cd6ae68008f1fc2 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Mon, 20 Aug 2012 10:57:22 -0400 +Subject: ACPI: export symbol acpi_get_table_with_size + +From: Alex Deucher + +commit 4f81f986761a7663db7d24d24cd6ae68008f1fc2 upstream. + +We need it in the radeon drm module to fetch +and verify the vbios image on UEFI systems. + +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/acpi/acpica/tbxface.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/acpi/acpica/tbxface.c ++++ b/drivers/acpi/acpica/tbxface.c +@@ -435,6 +435,7 @@ acpi_get_table_with_size(char *signature + + return (AE_NOT_FOUND); + } ++ACPI_EXPORT_SYMBOL(acpi_get_table_with_size) + + acpi_status + acpi_get_table(char *signature, diff --git a/queue-3.0/cciss-fix-incorrect-scsi-status-reporting.patch b/queue-3.0/cciss-fix-incorrect-scsi-status-reporting.patch new file mode 100644 index 00000000000..36f779cfc74 --- /dev/null +++ b/queue-3.0/cciss-fix-incorrect-scsi-status-reporting.patch @@ -0,0 +1,46 @@ +From b0cf0b118c90477d1a6811f2cd2307f6a5578362 Mon Sep 17 00:00:00 2001 +From: "Stephen M. Cameron" +Date: Tue, 21 Aug 2012 16:15:49 -0700 +Subject: cciss: fix incorrect scsi status reporting + +From: "Stephen M. Cameron" + +commit b0cf0b118c90477d1a6811f2cd2307f6a5578362 upstream. + +Delete code which sets SCSI status incorrectly as it's already been set +correctly above this incorrect code. The bug was introduced in 2009 by +commit b0e15f6db111 ("cciss: fix typo that causes scsi status to be +lost.") + +Signed-off-by: Stephen M. Cameron +Reported-by: Roel van Meer +Tested-by: Roel van Meer +Cc: Jens Axboe +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/block/cciss_scsi.c | 11 +---------- + 1 file changed, 1 insertion(+), 10 deletions(-) + +--- a/drivers/block/cciss_scsi.c ++++ b/drivers/block/cciss_scsi.c +@@ -763,16 +763,7 @@ static void complete_scsi_command(Comman + { + case CMD_TARGET_STATUS: + /* Pass it up to the upper layers... */ +- if( ei->ScsiStatus) +- { +-#if 0 +- printk(KERN_WARNING "cciss: cmd %p " +- "has SCSI Status = %x\n", +- c, ei->ScsiStatus); +-#endif +- cmd->result |= (ei->ScsiStatus << 1); +- } +- else { /* scsi status is zero??? How??? */ ++ if (!ei->ScsiStatus) { + + /* Ordinarily, this case should never happen, but there is a bug + in some released firmware revisions that allows it to happen diff --git a/queue-3.0/series b/queue-3.0/series index d9c23ebd8a7..1b272a948e7 100644 --- a/queue-3.0/series +++ b/queue-3.0/series @@ -17,3 +17,8 @@ nfsv4.1-remove-a-bogus-bug_on-in-nfs4_layoutreturn_done.patch nfs-alias-the-nfs-module-to-nfs4.patch audit-don-t-free_chunk-after-fsnotify_add_mark.patch audit-fix-refcounting-in-audit-tree.patch +svcrpc-fix-bug-in-svc_tcp_clear_pages.patch +svcrpc-fix-svc_xprt_enqueue-svc_recv-busy-looping.patch +svcrpc-sends-on-closed-socket-should-stop-immediately.patch +cciss-fix-incorrect-scsi-status-reporting.patch +acpi-export-symbol-acpi_get_table_with_size.patch diff --git a/queue-3.0/svcrpc-fix-bug-in-svc_tcp_clear_pages.patch b/queue-3.0/svcrpc-fix-bug-in-svc_tcp_clear_pages.patch new file mode 100644 index 00000000000..c05d5308b1b --- /dev/null +++ b/queue-3.0/svcrpc-fix-bug-in-svc_tcp_clear_pages.patch @@ -0,0 +1,42 @@ +From be1e44441a560c43c136a562d49a1c9623c91197 Mon Sep 17 00:00:00 2001 +From: "J. Bruce Fields" +Date: Thu, 9 Aug 2012 18:12:28 -0400 +Subject: svcrpc: fix BUG() in svc_tcp_clear_pages + +From: "J. Bruce Fields" + +commit be1e44441a560c43c136a562d49a1c9623c91197 upstream. + +Examination of svc_tcp_clear_pages shows that it assumes sk_tcplen is +consistent with sk_pages[] (in particular, sk_pages[n] can't be NULL if +sk_tcplen would lead us to expect n pages of data). + +svc_tcp_restore_pages zeroes out sk_pages[] while leaving sk_tcplen. +This is OK, since both functions are serialized by XPT_BUSY. However, +that means the inconsistency must be repaired before dropping XPT_BUSY. + +Therefore we should be ensuring that svc_tcp_save_pages repairs the +problem before exiting svc_tcp_recv_record on error. + +Symptoms were a BUG() in svc_tcp_clear_pages. + +Signed-off-by: J. Bruce Fields +Signed-off-by: Greg Kroah-Hartman + +--- + net/sunrpc/svcsock.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/sunrpc/svcsock.c ++++ b/net/sunrpc/svcsock.c +@@ -1122,9 +1122,9 @@ static int svc_tcp_recvfrom(struct svc_r + if (len >= 0) + svsk->sk_tcplen += len; + if (len != want) { ++ svc_tcp_save_pages(svsk, rqstp); + if (len < 0 && len != -EAGAIN) + goto err_other; +- svc_tcp_save_pages(svsk, rqstp); + dprintk("svc: incomplete TCP record (%d of %d)\n", + svsk->sk_tcplen, svsk->sk_reclen); + goto err_noclose; diff --git a/queue-3.0/svcrpc-fix-svc_xprt_enqueue-svc_recv-busy-looping.patch b/queue-3.0/svcrpc-fix-svc_xprt_enqueue-svc_recv-busy-looping.patch new file mode 100644 index 00000000000..b4e11f9c39c --- /dev/null +++ b/queue-3.0/svcrpc-fix-svc_xprt_enqueue-svc_recv-busy-looping.patch @@ -0,0 +1,71 @@ +From d10f27a750312ed5638c876e4bd6aa83664cccd8 Mon Sep 17 00:00:00 2001 +From: "J. Bruce Fields" +Date: Fri, 17 Aug 2012 17:31:53 -0400 +Subject: svcrpc: fix svc_xprt_enqueue/svc_recv busy-looping + +From: "J. Bruce Fields" + +commit d10f27a750312ed5638c876e4bd6aa83664cccd8 upstream. + +The rpc server tries to ensure that there will be room to send a reply +before it receives a request. + +It does this by tracking, in xpt_reserved, an upper bound on the total +size of the replies that is has already committed to for the socket. + +Currently it is adding in the estimate for a new reply *before* it +checks whether there is space available. If it finds that there is not +space, it then subtracts the estimate back out. + +This may lead the subsequent svc_xprt_enqueue to decide that there is +space after all. + +The results is a svc_recv() that will repeatedly return -EAGAIN, causing +server threads to loop without doing any actual work. + +Reported-by: Michael Tokarev +Tested-by: Michael Tokarev +Signed-off-by: J. Bruce Fields +Signed-off-by: Greg Kroah-Hartman + +--- + net/sunrpc/svc_xprt.c | 7 ++----- + 1 file changed, 2 insertions(+), 5 deletions(-) + +--- a/net/sunrpc/svc_xprt.c ++++ b/net/sunrpc/svc_xprt.c +@@ -323,7 +323,6 @@ static bool svc_xprt_has_something_to_do + */ + void svc_xprt_enqueue(struct svc_xprt *xprt) + { +- struct svc_serv *serv = xprt->xpt_server; + struct svc_pool *pool; + struct svc_rqst *rqstp; + int cpu; +@@ -369,8 +368,6 @@ void svc_xprt_enqueue(struct svc_xprt *x + rqstp, rqstp->rq_xprt); + rqstp->rq_xprt = xprt; + svc_xprt_get(xprt); +- rqstp->rq_reserved = serv->sv_max_mesg; +- atomic_add(rqstp->rq_reserved, &xprt->xpt_reserved); + pool->sp_stats.threads_woken++; + wake_up(&rqstp->rq_wait); + } else { +@@ -650,8 +647,6 @@ int svc_recv(struct svc_rqst *rqstp, lon + if (xprt) { + rqstp->rq_xprt = xprt; + svc_xprt_get(xprt); +- rqstp->rq_reserved = serv->sv_max_mesg; +- atomic_add(rqstp->rq_reserved, &xprt->xpt_reserved); + + /* As there is a shortage of threads and this request + * had to be queued, don't allow the thread to wait so +@@ -748,6 +743,8 @@ int svc_recv(struct svc_rqst *rqstp, lon + else + len = xprt->xpt_ops->xpo_recvfrom(rqstp); + dprintk("svc: got len=%d\n", len); ++ rqstp->rq_reserved = serv->sv_max_mesg; ++ atomic_add(rqstp->rq_reserved, &xprt->xpt_reserved); + } + svc_xprt_received(xprt); + diff --git a/queue-3.0/svcrpc-sends-on-closed-socket-should-stop-immediately.patch b/queue-3.0/svcrpc-sends-on-closed-socket-should-stop-immediately.patch new file mode 100644 index 00000000000..1d303ccea05 --- /dev/null +++ b/queue-3.0/svcrpc-sends-on-closed-socket-should-stop-immediately.patch @@ -0,0 +1,42 @@ +From f06f00a24d76e168ecb38d352126fd203937b601 Mon Sep 17 00:00:00 2001 +From: "J. Bruce Fields" +Date: Mon, 20 Aug 2012 16:04:40 -0400 +Subject: svcrpc: sends on closed socket should stop immediately + +From: "J. Bruce Fields" + +commit f06f00a24d76e168ecb38d352126fd203937b601 upstream. + +svc_tcp_sendto sets XPT_CLOSE if we fail to transmit the entire reply. +However, the XPT_CLOSE won't be acted on immediately. Meanwhile other +threads could send further replies before the socket is really shut +down. This can manifest as data corruption: for example, if a truncated +read reply is followed by another rpc reply, that second reply will look +to the client like further read data. + +Symptoms were data corruption preceded by svc_tcp_sendto logging +something like + + kernel: rpc-srv/tcp: nfsd: sent only 963696 when sending 1048708 bytes - shutting down socket + +Reported-by: Malahal Naineni +Tested-by: Malahal Naineni +Signed-off-by: J. Bruce Fields +Signed-off-by: Greg Kroah-Hartman + +--- + net/sunrpc/svc_xprt.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/net/sunrpc/svc_xprt.c ++++ b/net/sunrpc/svc_xprt.c +@@ -801,7 +801,8 @@ int svc_send(struct svc_rqst *rqstp) + + /* Grab mutex to serialize outgoing data. */ + mutex_lock(&xprt->xpt_mutex); +- if (test_bit(XPT_DEAD, &xprt->xpt_flags)) ++ if (test_bit(XPT_DEAD, &xprt->xpt_flags) ++ || test_bit(XPT_CLOSE, &xprt->xpt_flags)) + len = -ENOTCONN; + else + len = xprt->xpt_ops->xpo_sendto(rqstp);