scsi: lpfc_scsi: Remove unused variables
This is my first time patch submission. The commit message should explain the issue. commit ba8c7a7a629b736fdc1abceaa3ec49f8820aec08 Author: Richard Yao r...@cs.stonybrook.edu Date: Thu Jun 7 01:44:31 2012 -0400 scsi: lpfc_scsi: Remove unused variables Kernels built with CONFIG_SCSI_LPFC fail to compile due to the use of -Werror=unused-variable. We solve that by removing some unused variables. Signed-off-by: Richard Yao r...@cs.stonybrook.edu diff --git a/drivers/scsi/lpfc/lpfc_scsi.c b/drivers/scsi/lpfc/lpfc_scsi.c index 88f3a83..7f20599 100644 --- a/drivers/scsi/lpfc/lpfc_scsi.c +++ b/drivers/scsi/lpfc/lpfc_scsi.c @@ -1897,7 +1897,6 @@ lpfc_bg_setup_bpl(struct lpfc_hba *phba, struct scsi_cmnd *sc, dma_addr_t physaddr; int i = 0, num_bde = 0, status; int datadir = sc-sc_data_direction; - uint32_t rc; uint32_t checking = 1; uint32_t reftag; unsigned blksize; @@ -2034,7 +2033,6 @@ lpfc_bg_setup_bpl_prot(struct lpfc_hba *phba, struct scsi_cmnd *sc, int datadir = sc-sc_data_direction; unsigned char pgdone = 0, alldone = 0; unsigned blksize; - uint32_t rc; uint32_t checking = 1; uint32_t reftag; uint8_t txop, rxop; @@ -2253,7 +2251,6 @@ lpfc_bg_setup_sgl(struct lpfc_hba *phba, struct scsi_cmnd *sc, uint32_t reftag; unsigned blksize; uint8_t txop, rxop; - uint32_t rc; uint32_t checking = 1; uint32_t dma_len; uint32_t dma_offset = 0; @@ -2383,7 +2380,6 @@ lpfc_bg_setup_sgl_prot(struct lpfc_hba *phba, struct scsi_cmnd *sc, uint32_t reftag; uint8_t txop, rxop; uint32_t dma_len; - uint32_t rc; uint32_t checking = 1; uint32_t dma_offset = 0; int num_sge = 0;
Re: scsi: lpfc_scsi: Remove unused variables
On 06/07/12 02:12, Jonathan Nieder wrote: Hi Richard, Richard Yao wrote: This is my first time patch submission. The commit message should explain the issue. commit ba8c7a7a629b736fdc1abceaa3ec49f8820aec08 Author: Richard Yao r...@cs.stonybrook.edu Date: Thu Jun 7 01:44:31 2012 -0400 scsi: lpfc_scsi: Remove unused variables Kernels built with CONFIG_SCSI_LPFC fail to compile due to the use of -Werror=unused-variable. We solve that by removing some unused variables. Wouldn't a saner fix be to stop using -Werror=unused-variable, or am I missing something subtle? (Since v3.4-rc1~6^2~48 the makefile seems to use plain -Werror, which seems even worse, since it means any random compiler bug that triggers a new warning will break the build.) Thanks and hope that helps, Jonathan Using -Werror enables us to catch potential runtime issues before they happen. This one is not a runtime issue, but the compiler is right in stating that these variables serve no purpose. My opinion is that occasional noise due to -Werror won't be a problem. Also, decisions on -Werror probably should be made by either the subsystem maintainer or the branch maintainer. -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi: lpfc_scsi: Remove unused variables
On Thu, Jun 07, 2012 at 01:59:39AM -0400, Richard Yao wrote: This is my first time patch submission. The commit message should explain the issue. formletter This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.txt for how to do this properly. /formletter -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi: lpfc_scsi: Remove unused variables
On Thu, Jun 07, 2012 at 01:12:56AM -0500, Jonathan Nieder wrote: Hi Richard, Richard Yao wrote: This is my first time patch submission. The commit message should explain the issue. commit ba8c7a7a629b736fdc1abceaa3ec49f8820aec08 Author: Richard Yao r...@cs.stonybrook.edu Date: Thu Jun 7 01:44:31 2012 -0400 scsi: lpfc_scsi: Remove unused variables Kernels built with CONFIG_SCSI_LPFC fail to compile due to the use of -Werror=unused-variable. We solve that by removing some unused variables. Wouldn't a saner fix be to stop using -Werror=unused-variable, or am I missing something subtle? Yes, that is correct, older versions of gcc, and sometimes newer ones, get this logic wrong and incorrectly flag variables that really are used due to bugs in their detection logic. Don't require a developer to have a gcc version that is different from what the rest of the kernel requires, as that is not allowed. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi: lpfc_scsi: Remove unused variables
Richard Yao wrote: Using -Werror enables us to catch potential runtime issues before they happen. You have more trust in GCC and other compilers than I do. If you'd like some entertainment, then for example see: http://gcc.gnu.org/PR52798 http://gcc.gnu.org/PR25509 Bugs and misdesigned features do not have to be involved for this to be a problem --- all it takes is a gcc upgrade that adds a new warning, and suddenly you've turned your existing potential code cleanliness improvements into failed builds and lots of wasted time for innocent sysadmins. -Werror is great for development, but using it in production turns out to be pretty much always a terrible idea. Thanks for the chance to vent about this. :) It's bad, bad, bad. Ciao, Jonathan -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] x86, AMD: Fix crash as Xen Dom0 on AMD Trinity systems
On Wed, Jun 06, 2012 at 03:00:14PM -0700, H. Peter Anvin wrote:
On 06/01/2012 07:52 AM, Borislav Petkov wrote:
From: Andre Przywara andre.przyw...@amd.com
f7f286a910221 (x86/amd: Re-enable CPU topology extensions in case BIOS
has disabled it) wrongfully added code which used the AMD-specific
{rd,wr}msr variants for no real reason.
This caused boot panics on xen which wasn't initializing the
{rd,wr}msr_safe_regs pv_ops members properly.
This, in turn, caused a heated discussion leading to us reviewing all
uses of the AMD-specific variants and removing them where unneeded
(almost everywhere except an obscure K8 BIOS fix, see 6b0f43ddfa358).
Finally, this patch switches to the standard {rd,wr}msr*_safe* variants
which should've been used in the first place anyway and avoided unneeded
excitation with xen.
Signed-off-by: Andre Przywara andre.przyw...@amd.com
Cc: Andreas Herrmann andreas.herrma...@amd.com
Cc: stable@vger.kernel.org # 3.4+
Link:
http://lkml.kernel.org/r/1338383402-3838-1-git-send-email-andre.przyw...@amd.com
[Boris: correct and expand commit message]
Signed-off-by: Borislav Petkov borislav.pet...@amd.com
Why -stable? I though we had agreed that we didn't have an active
problem (unclean hack, yes, but not an active problem) in 3.4/3.5 as it
currently sits?
Yes, AFAICT, we need at least one fix for 3.4 where the original patch
f7f286a910221 broke xen.
So either this one or 1ab46fd319bc should be backported to stable, if
I'm not mistaken. If the second, I'll drop the stable tag from this one
and resend.
Konrad, what do you want wrt xen paravirt nullptr breakage for
3.4-stable?
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] x86, mce, AMD: Fix misconfiguration of the mce threshold lvt offset
On Thu, Jun 07, 2012 at 10:35:04AM +0900, Greg KH wrote: On Wed, Jun 06, 2012 at 05:13:29PM +0200, Robert Richter wrote: Minimal stable backport of f227d4306cf30e1d5b6f231e8ef9006c34f3d186. Minimal doesn't begin to describe this. A totally different patch is more like it. Why wasn't it done this way originally? I really don't like diverging from Linus's tree in large ways like this. Borislav, what do you think about this version? Any reason why your original patch shouldn't just be applied to 3.4 instead? Right, so Robert thought the original patch is too big for stable, that's why. But the main change is lvt_interrupt_supported() while the rest are contextual changes to accomodate that first thing. And I don't think it is too big, so if you were to ask me, I'd backport the original patch which is already upstream and widely tested... Oh, and the other thing is, this patch indirectly fixes IBS registration so if you want to use IBS with perf on -stable, you need that patch and I didn't say that in the commit message. And this is actually the main reason why we want it in stable - to enable precise instruction tracing on AMD. Thanks. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] x86, AMD: Fix crash as Xen Dom0 on AMD Trinity systems
On 06/07/2012 09:21 AM, Borislav Petkov wrote:
On Wed, Jun 06, 2012 at 03:00:14PM -0700, H. Peter Anvin wrote:
On 06/01/2012 07:52 AM, Borislav Petkov wrote:
From: Andre Przywaraandre.przyw...@amd.com
f7f286a910221 (x86/amd: Re-enable CPU topology extensions in case BIOS
has disabled it) wrongfully added code which used the AMD-specific
{rd,wr}msr variants for no real reason.
This caused boot panics on xen which wasn't initializing the
{rd,wr}msr_safe_regs pv_ops members properly.
This, in turn, caused a heated discussion leading to us reviewing all
uses of the AMD-specific variants and removing them where unneeded
(almost everywhere except an obscure K8 BIOS fix, see 6b0f43ddfa358).
Finally, this patch switches to the standard {rd,wr}msr*_safe* variants
which should've been used in the first place anyway and avoided unneeded
excitation with xen.
Signed-off-by: Andre Przywaraandre.przyw...@amd.com
Cc: Andreas Herrmannandreas.herrma...@amd.com
Cc: stable@vger.kernel.org # 3.4+
Link:http://lkml.kernel.org/r/1338383402-3838-1-git-send-email-andre.przyw...@amd.com
[Boris: correct and expand commit message]
Signed-off-by: Borislav Petkovborislav.pet...@amd.com
Why -stable? I though we had agreed that we didn't have an active
problem (unclean hack, yes, but not an active problem) in 3.4/3.5 as it
currently sits?
This is probably a leftover from the original patch, before Konrad's
patch got committed.
Yes, AFAICT, we need at least one fix for 3.4 where the original patch
f7f286a910221 broke xen.
So either this one or 1ab46fd319bc should be backported to stable, if
I'm not mistaken. If the second, I'll drop the stable tag from this one
and resend.
Konrad, what do you want wrt xen paravirt nullptr breakage for
3.4-stable?
Greg just sent out the review mail for 1ab46fd319bc, so we can drop the
stable tag from this one.
Regards,
Andre.
Original Message
Subject: [ 21/82] x86, amd, xen: Avoid NULL pointer paravirt references
Date: Thu, 7 Jun 2012 13:03:57 +0900
From: Greg KH gre...@linuxfoundation.org
To: linux-ker...@vger.kernel.org, stable@vger.kernel.org
CC: torva...@linux-foundation.org, a...@linux-foundation.org,
a...@lxorguk.ukuu.org.uk, Andre Przywara andre.przyw...@amd.com, H.
Peter Anvin h...@zytor.com
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Konrad Rzeszutek Wilk kon...@darnok.org
commit 1ab46fd319bcf1fcd9fb6311727d532b580e4eba upstream.
Stub out MSR methods that aren't actually needed. This fixes a crash
as Xen Dom0 on AMD Trinity systems. A bigger patch should be added to
remove the paravirt machinery completely for the methods which
apparently have no users!
.
--
Andre Przywara
AMD-OSRC (Dresden)
Tel: x29712
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] x86, mce, AMD: Fix misconfiguration of the mce threshold lvt offset
On Thu, Jun 07, 2012 at 09:49:01AM +0200, Borislav Petkov wrote: On Thu, Jun 07, 2012 at 10:35:04AM +0900, Greg KH wrote: On Wed, Jun 06, 2012 at 05:13:29PM +0200, Robert Richter wrote: Minimal stable backport of f227d4306cf30e1d5b6f231e8ef9006c34f3d186. Minimal doesn't begin to describe this. A totally different patch is more like it. Why wasn't it done this way originally? I really don't like diverging from Linus's tree in large ways like this. Borislav, what do you think about this version? Any reason why your original patch shouldn't just be applied to 3.4 instead? Right, so Robert thought the original patch is too big for stable, that's why. But the main change is lvt_interrupt_supported() while the rest are contextual changes to accomodate that first thing. And I don't think it is too big, so if you were to ask me, I'd backport the original patch which is already upstream and widely tested... I'd prefer to take the original patch as well. Oh, and the other thing is, this patch indirectly fixes IBS registration so if you want to use IBS with perf on -stable, you need that patch and I didn't say that in the commit message. And this is actually the main reason why we want it in stable - to enable precise instruction tracing on AMD. What patch would this be that is needed also? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] x86, AMD: Fix crash as Xen Dom0 on AMD Trinity systems
On Thu, Jun 07, 2012 at 09:49:01AM +0200, Andre Przywara wrote:
On 06/07/2012 09:21 AM, Borislav Petkov wrote:
On Wed, Jun 06, 2012 at 03:00:14PM -0700, H. Peter Anvin wrote:
On 06/01/2012 07:52 AM, Borislav Petkov wrote:
From: Andre Przywaraandre.przyw...@amd.com
f7f286a910221 (x86/amd: Re-enable CPU topology extensions in case BIOS
has disabled it) wrongfully added code which used the AMD-specific
{rd,wr}msr variants for no real reason.
This caused boot panics on xen which wasn't initializing the
{rd,wr}msr_safe_regs pv_ops members properly.
This, in turn, caused a heated discussion leading to us reviewing all
uses of the AMD-specific variants and removing them where unneeded
(almost everywhere except an obscure K8 BIOS fix, see 6b0f43ddfa358).
Finally, this patch switches to the standard {rd,wr}msr*_safe* variants
which should've been used in the first place anyway and avoided unneeded
excitation with xen.
Signed-off-by: Andre Przywaraandre.przyw...@amd.com
Cc: Andreas Herrmannandreas.herrma...@amd.com
Cc: stable@vger.kernel.org # 3.4+
Link:http://lkml.kernel.org/r/1338383402-3838-1-git-send-email-andre.przyw...@amd.com
[Boris: correct and expand commit message]
Signed-off-by: Borislav Petkovborislav.pet...@amd.com
Why -stable? I though we had agreed that we didn't have an active
problem (unclean hack, yes, but not an active problem) in 3.4/3.5 as it
currently sits?
This is probably a leftover from the original patch, before Konrad's
patch got committed.
Yes, AFAICT, we need at least one fix for 3.4 where the original patch
f7f286a910221 broke xen.
So either this one or 1ab46fd319bc should be backported to stable, if
I'm not mistaken. If the second, I'll drop the stable tag from this one
and resend.
Konrad, what do you want wrt xen paravirt nullptr breakage for
3.4-stable?
Greg just sent out the review mail for 1ab46fd319bc, so we can drop
the stable tag from this one.
Regards,
Andre.
What? So I don't need to do anything?
Totally confused,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dmaengine: pl330: dont complete descriptor for cyclic dma
On Wed, 2012-05-23 at 16:47 +0530, Tushar Behera wrote:
Commit eab215855803 (dmaengine: pl330: dont complete descriptor for
cyclic dma) wrongly completes descriptor for cyclic dma, hence following
BUG_ON is still hit with cyclic DMA operations.
kernel BUG at drivers/dma/dmaengine.h:53!
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
drivers/dma/pl330.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index fa3fb21..8c44f17 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2322,7 +2322,7 @@ static void pl330_tasklet(unsigned long data)
/* Pick up ripe tomatoes */
list_for_each_entry_safe(desc, _dt, pch-work_list, node)
if (desc-status == DONE) {
- if (pch-cyclic)
+ if (!pch-cyclic)
dma_cookie_complete(desc-txd);
list_move_tail(desc-node, list);
}
Applied thanks. I have cc'ed stable.
--
~Vinod
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] x86, AMD: Fix crash as Xen Dom0 on AMD Trinity systems
On 06/07/2012 10:08 AM, Greg KH wrote:
On Thu, Jun 07, 2012 at 09:49:01AM +0200, Andre Przywara wrote:
On 06/07/2012 09:21 AM, Borislav Petkov wrote:
On Wed, Jun 06, 2012 at 03:00:14PM -0700, H. Peter Anvin wrote:
On 06/01/2012 07:52 AM, Borislav Petkov wrote:
From: Andre Przywaraandre.przyw...@amd.com
f7f286a910221 (x86/amd: Re-enable CPU topology extensions in case BIOS
has disabled it) wrongfully added code which used the AMD-specific
{rd,wr}msr variants for no real reason.
This caused boot panics on xen which wasn't initializing the
{rd,wr}msr_safe_regs pv_ops members properly.
This, in turn, caused a heated discussion leading to us reviewing all
uses of the AMD-specific variants and removing them where unneeded
(almost everywhere except an obscure K8 BIOS fix, see 6b0f43ddfa358).
Finally, this patch switches to the standard {rd,wr}msr*_safe* variants
which should've been used in the first place anyway and avoided unneeded
excitation with xen.
Signed-off-by: Andre Przywaraandre.przyw...@amd.com
Cc: Andreas Herrmannandreas.herrma...@amd.com
Cc: stable@vger.kernel.org # 3.4+
Link:http://lkml.kernel.org/r/1338383402-3838-1-git-send-email-andre.przyw...@amd.com
[Boris: correct and expand commit message]
Signed-off-by: Borislav Petkovborislav.pet...@amd.com
Why -stable? I though we had agreed that we didn't have an active
problem (unclean hack, yes, but not an active problem) in 3.4/3.5 as it
currently sits?
This is probably a leftover from the original patch, before Konrad's
patch got committed.
Yes, AFAICT, we need at least one fix for 3.4 where the original patch
f7f286a910221 broke xen.
So either this one or 1ab46fd319bc should be backported to stable, if
I'm not mistaken. If the second, I'll drop the stable tag from this one
and resend.
Konrad, what do you want wrt xen paravirt nullptr breakage for
3.4-stable?
Greg just sent out the review mail for 1ab46fd319bc, so we can drop
the stable tag from this one.
Regards,
Andre.
What? So I don't need to do anything?
Totally confused,
Sorry for that.
To fix the issue, we need only one of those patches.
Mine (Fix crash as Xen Dom0 on AMD Trinity systems, removing _amd
from the rd/wrmsr calls) was sent out earlier, so I added the stable tag.
A bit later Konrad sent his patch (1ab46fd319bc, initializing the
forgotten PVOPS members), which hpa took (dropping mine). So this fix is
in 3.5-rc1 and should also be in -stable.
Now for making things smoother Boris sent out mine again - for 3.6 - and
more or less accidentally kept the stable tag in it.
Long story short: everything is fine, just apply the one you sent the
review message for.
HTH,
Andre.
--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] x86, mce, AMD: Fix misconfiguration of the mce threshold lvt offset
On 07.06.12 17:04:26, Greg KH wrote: On Thu, Jun 07, 2012 at 09:49:01AM +0200, Borislav Petkov wrote: On Thu, Jun 07, 2012 at 10:35:04AM +0900, Greg KH wrote: On Wed, Jun 06, 2012 at 05:13:29PM +0200, Robert Richter wrote: Minimal stable backport of f227d4306cf30e1d5b6f231e8ef9006c34f3d186. Minimal doesn't begin to describe this. A totally different patch is more like it. Why wasn't it done this way originally? I really don't like diverging from Linus's tree in large ways like this. Borislav, what do you think about this version? Any reason why your original patch shouldn't just be applied to 3.4 instead? Right, so Robert thought the original patch is too big for stable, that's why. But the main change is lvt_interrupt_supported() while the rest are contextual changes to accomodate that first thing. And I don't think it is too big, so if you were to ask me, I'd backport the original patch which is already upstream and widely tested... I'd prefer to take the original patch as well. Oh, and the other thing is, this patch indirectly fixes IBS registration so if you want to use IBS with perf on -stable, you need that patch and I didn't say that in the commit message. And this is actually the main reason why we want it in stable - to enable precise instruction tracing on AMD. What patch would this be that is needed also? It is either f227d4306cf30e1d5b6f231e8ef9006c34f3d186 or this stable one. I am fine with both. Both patches effectivly run setup_APIC_mce() with the lvt offset from bank 4 which fixes the IBS setup issue. There is a small conflict with the original patch version and at least v3.0, but this can easily be solved. Ideally the original patch would have been splitted in a stable fix and a new implementation. But I missed this too while reviewing it. Thanks, -Robert -- Advanced Micro Devices, Inc. Operating System Research Center -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] x86, mce, AMD: Fix misconfiguration of the mce threshold lvt offset
On Thu, Jun 07, 2012 at 11:23:27AM +0200, Robert Richter wrote: What patch would this be that is needed also? It is either f227d4306cf30e1d5b6f231e8ef9006c34f3d186 or this stable one. I am fine with both. So, to make long story short: take the original patch f227d4306cf30e1d5b6f231e8ef9006c34f3d186 and all is fine. -- Regards/Gruss, Boris. osrc-ker...@elbe.amd.com - where all your Linux questions get answered. Operating Systems Research Center Advanced Micro Devices, Inc. -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/nouveau/disp: fix dithering not being enabled on some eDP macbooks
Upstream commit a6a1785
I would like this backported to v3.2, v3.3 and v3.4
v3.2 requires patch 6322175 and c843536 as pre-depend
v3.3 requires c843536
---
commit a6a17859f1bdf607650ee055101f54c5f207762b
Author: Ben Skeggs bske...@redhat.com
Date: Sat May 5 00:39:21 2012 +1000
drm/nouveau/disp: fix dithering not being enabled on some eDP macbooks
Signed-off-by: Ben Skeggs bske...@redhat.com
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index fa86035..7b11edb 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -654,7 +654,13 @@ nouveau_connector_detect_depth(struct drm_connector
*connector)
if (nv_connector-edid connector-display_info.bpc)
return;
- /* if not, we're out of options unless we're LVDS, default to 8bpc */
+ /* EDID 1.4 is *supposed* to be supported on eDP, but, Apple... */
+ if (nv_connector-type == DCB_CONNECTOR_eDP) {
+ connector-display_info.bpc = 6;
+ return;
+ }
+
+ /* we're out of options unless we're LVDS, default to 8bpc */
if (nv_encoder-dcb-type != OUTPUT_LVDS) {
connector-display_info.bpc = 8;
return;
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpiolib: wm8994: Pay attention to the value set when enabling as output
On Tue, Jun 5, 2012 at 7:12 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: + if (value) + value = WM8994_GPN_LVL; + return wm8994_set_bits(wm8994, WM8994_GPIO_1 + offset, - WM8994_GPN_DIR, 0); + WM8994_GPN_DIR | WM8994_GPN_LVL, value); } The commit message is so terse compared to what the code does that I cannot claim to understand what this patch is doing. Could you elaborate on the problem ans symptoms, just for a nice commit log? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] iwlwifi: fix the Transmit Frame Descriptor rings
commit ebed633c61c023e5d1aa4ed159cd67406e9e37c2 upstream.
The logic that allows to have a short TFD queue was completely wrong.
We do maintain 256 Transmit Frame Descriptors, but they point to
recycled buffers. We used to attach and de-attach different TFDs for
the same buffer and it worked since they pointed to the same buffer.
Also zero the number of BDs after unmapping a TFD. This seems not
necessary since we don't reclaim the same TFD twice, but I like
housekeeping.
This patch solves this warning:
[ 6427.079855] WARNING: at lib/dma-debug.c:866 check_unmap+0x727/0x7a0()
[ 6427.079859] Hardware name: Latitude E6410
[ 6427.079865] iwlwifi :02:00.0: DMA-API: device driver tries to free DMA
memory it has not allocated [device address=0x296d393c] [size=8 bytes]
[ 6427.079870] Modules linked in: ...
[ 6427.079950] Pid: 6613, comm: ifconfig Tainted: G O 3.3.3 #5
[ 6427.079954] Call Trace:
[ 6427.079963] [c10337a2] warn_slowpath_common+0x72/0xa0
[ 6427.079982] [c1033873] warn_slowpath_fmt+0x33/0x40
[ 6427.079988] [c12dcb77] check_unmap+0x727/0x7a0
[ 6427.079995] [c12dcdaa] debug_dma_unmap_page+0x5a/0x80
[ 6427.080024] [fe2312ac] iwlagn_unmap_tfd+0x12c/0x180 [iwlwifi]
[ 6427.080048] [fe231349] iwlagn_txq_free_tfd+0x49/0xb0 [iwlwifi]
[ 6427.080071] [fe228e37] iwl_tx_queue_unmap+0x67/0x90 [iwlwifi]
[ 6427.080095] [fe22d221] iwl_trans_pcie_stop_device+0x341/0x7b0 [iwlwifi]
[ 6427.080113] [fe204b0e] iwl_down+0x17e/0x260 [iwlwifi]
[ 6427.080132] [fe20efec] iwlagn_mac_stop+0x6c/0xf0 [iwlwifi]
[ 6427.080168] [fd8480ce] ieee80211_stop_device+0x5e/0x190 [mac80211]
[ 6427.080198] [fd833208] ieee80211_do_stop+0x288/0x620 [mac80211]
[ 6427.080243] [fd8335b7] ieee80211_stop+0x17/0x20 [mac80211]
[ 6427.080250] [c148dac1] __dev_close_many+0x81/0xd0
[ 6427.080270] [c148db3d] __dev_close+0x2d/0x50
[ 6427.080276] [c148d152] __dev_change_flags+0x82/0x150
[ 6427.080282] [c148e3e3] dev_change_flags+0x23/0x60
[ 6427.080289] [c14f6320] devinet_ioctl+0x6a0/0x770
[ 6427.080296] [c14f8705] inet_ioctl+0x95/0xb0
[ 6427.080304] [c147a0f0] sock_ioctl+0x70/0x270
Change-Id: I93ec41b9919159c058f94f8f0197ae8da3f07c47
Cc: stable@vger.kernel.org
Reported-by: Antonio Quartulli or...@autistici.org
Tested-by: Antonio Quartulli or...@autistici.org
Signed-off-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h |2 +-
drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c | 20 +---
drivers/net/wireless/iwlwifi/iwl-trans-pcie.c |4 +---
3 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h
b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h
index 1c2fe87..3b844b7 100644
--- a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h
+++ b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h
@@ -342,7 +342,7 @@ void iwl_trans_pcie_tx_agg_setup(struct iwl_trans *trans,
enum iwl_rxon_context_id ctx,
int sta_id, int tid, int frame_limit, u16 ssn);
void iwlagn_txq_free_tfd(struct iwl_trans *trans, struct iwl_tx_queue *txq,
- int index, enum dma_data_direction dma_dir);
+enum dma_data_direction dma_dir);
int iwl_tx_queue_reclaim(struct iwl_trans *trans, int txq_id, int index,
struct sk_buff_head *skbs);
int iwl_queue_space(const struct iwl_queue *q);
diff --git a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c
b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c
index e92972f..d7964b1 100644
--- a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c
@@ -237,32 +237,38 @@ static void iwlagn_unmap_tfd(struct iwl_trans *trans,
struct iwl_cmd_meta *meta,
for (i = 1; i num_tbs; i++)
dma_unmap_single(trans-dev, iwl_tfd_tb_get_addr(tfd, i),
iwl_tfd_tb_get_len(tfd, i), dma_dir);
+
+ tfd-num_tbs = 0;
}
/**
* iwlagn_txq_free_tfd - Free all chunks referenced by TFD [txq-q.read_ptr]
* @trans - transport private data
* @txq - tx queue
- * @index - the index of the TFD to be freed
- *@dma_dir - the direction of the DMA mapping
+ * @dma_dir - the direction of the DMA mapping
*
* Does NOT advance any TFD circular buffer read/write indexes
* Does NOT free the TFD itself (which is within circular buffer)
*/
void iwlagn_txq_free_tfd(struct iwl_trans *trans, struct iwl_tx_queue *txq,
- int index, enum dma_data_direction dma_dir)
+enum dma_data_direction dma_dir)
{
struct iwl_tfd *tfd_tmp = txq-tfds;
+ /* rd_ptr is bounded by n_bd and idx is bounded by n_window */
+ int rd_ptr = txq-q.read_ptr;
+ int idx = get_cmd_index(txq-q, rd_ptr);
+
lockdep_assert_held(txq-lock);
- iwlagn_unmap_tfd(trans, txq-meta[index], tfd_tmp[index],
RE: [PATCH] iwlwifi: fix the Transmit Frame Descriptor rings
Subject: [PATCH] iwlwifi: fix the Transmit Frame Descriptor rings commit ebed633c61c023e5d1aa4ed159cd67406e9e37c2 upstream. The logic that allows to have a short TFD queue was completely wrong. We do maintain 256 Transmit Frame Descriptors, but they point to recycled buffers. We used to attach and de-attach different TFDs for the same buffer and it worked since they pointed to the same buffer. Also zero the number of BDs after unmapping a TFD. This seems not necessary since we don't reclaim the same TFD twice, but I like housekeeping. Please ignore - will resubmit in a minute - Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.4] iwlwifi: fix the Transmit Frame Descriptor rings
commit ebed633c61c023e5d1aa4ed159cd67406e9e37c2 upstream.
The logic that allows to have a short TFD queue was completely wrong.
We do maintain 256 Transmit Frame Descriptors, but they point to
recycled buffers. We used to attach and de-attach different TFDs for
the same buffer and it worked since they pointed to the same buffer.
Also zero the number of BDs after unmapping a TFD. This seems not
necessary since we don't reclaim the same TFD twice, but I like
housekeeping.
This patch solves this warning:
[ 6427.079855] WARNING: at lib/dma-debug.c:866 check_unmap+0x727/0x7a0()
[ 6427.079859] Hardware name: Latitude E6410
[ 6427.079865] iwlwifi :02:00.0: DMA-API: device driver tries to free DMA
memory it has not allocated [device address=0x296d393c] [size=8 bytes]
[ 6427.079870] Modules linked in: ...
[ 6427.079950] Pid: 6613, comm: ifconfig Tainted: G O 3.3.3 #5
[ 6427.079954] Call Trace:
[ 6427.079963] [c10337a2] warn_slowpath_common+0x72/0xa0
[ 6427.079982] [c1033873] warn_slowpath_fmt+0x33/0x40
[ 6427.079988] [c12dcb77] check_unmap+0x727/0x7a0
[ 6427.079995] [c12dcdaa] debug_dma_unmap_page+0x5a/0x80
[ 6427.080024] [fe2312ac] iwlagn_unmap_tfd+0x12c/0x180 [iwlwifi]
[ 6427.080048] [fe231349] iwlagn_txq_free_tfd+0x49/0xb0 [iwlwifi]
[ 6427.080071] [fe228e37] iwl_tx_queue_unmap+0x67/0x90 [iwlwifi]
[ 6427.080095] [fe22d221] iwl_trans_pcie_stop_device+0x341/0x7b0 [iwlwifi]
[ 6427.080113] [fe204b0e] iwl_down+0x17e/0x260 [iwlwifi]
[ 6427.080132] [fe20efec] iwlagn_mac_stop+0x6c/0xf0 [iwlwifi]
[ 6427.080168] [fd8480ce] ieee80211_stop_device+0x5e/0x190 [mac80211]
[ 6427.080198] [fd833208] ieee80211_do_stop+0x288/0x620 [mac80211]
[ 6427.080243] [fd8335b7] ieee80211_stop+0x17/0x20 [mac80211]
[ 6427.080250] [c148dac1] __dev_close_many+0x81/0xd0
[ 6427.080270] [c148db3d] __dev_close+0x2d/0x50
[ 6427.080276] [c148d152] __dev_change_flags+0x82/0x150
[ 6427.080282] [c148e3e3] dev_change_flags+0x23/0x60
[ 6427.080289] [c14f6320] devinet_ioctl+0x6a0/0x770
[ 6427.080296] [c14f8705] inet_ioctl+0x95/0xb0
[ 6427.080304] [c147a0f0] sock_ioctl+0x70/0x270
Cc: stable@vger.kernel.org
Reported-by: Antonio Quartulli or...@autistici.org
Tested-by: Antonio Quartulli or...@autistici.org
Signed-off-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h |2 +-
drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c | 20 +---
drivers/net/wireless/iwlwifi/iwl-trans-pcie.c |4 +---
3 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h
b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h
index 1c2fe87..3b844b7 100644
--- a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h
+++ b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h
@@ -342,7 +342,7 @@ void iwl_trans_pcie_tx_agg_setup(struct iwl_trans *trans,
enum iwl_rxon_context_id ctx,
int sta_id, int tid, int frame_limit, u16 ssn);
void iwlagn_txq_free_tfd(struct iwl_trans *trans, struct iwl_tx_queue *txq,
- int index, enum dma_data_direction dma_dir);
+enum dma_data_direction dma_dir);
int iwl_tx_queue_reclaim(struct iwl_trans *trans, int txq_id, int index,
struct sk_buff_head *skbs);
int iwl_queue_space(const struct iwl_queue *q);
diff --git a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c
b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c
index e92972f..d7964b1 100644
--- a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c
@@ -237,32 +237,38 @@ static void iwlagn_unmap_tfd(struct iwl_trans *trans,
struct iwl_cmd_meta *meta,
for (i = 1; i num_tbs; i++)
dma_unmap_single(trans-dev, iwl_tfd_tb_get_addr(tfd, i),
iwl_tfd_tb_get_len(tfd, i), dma_dir);
+
+ tfd-num_tbs = 0;
}
/**
* iwlagn_txq_free_tfd - Free all chunks referenced by TFD [txq-q.read_ptr]
* @trans - transport private data
* @txq - tx queue
- * @index - the index of the TFD to be freed
- *@dma_dir - the direction of the DMA mapping
+ * @dma_dir - the direction of the DMA mapping
*
* Does NOT advance any TFD circular buffer read/write indexes
* Does NOT free the TFD itself (which is within circular buffer)
*/
void iwlagn_txq_free_tfd(struct iwl_trans *trans, struct iwl_tx_queue *txq,
- int index, enum dma_data_direction dma_dir)
+enum dma_data_direction dma_dir)
{
struct iwl_tfd *tfd_tmp = txq-tfds;
+ /* rd_ptr is bounded by n_bd and idx is bounded by n_window */
+ int rd_ptr = txq-q.read_ptr;
+ int idx = get_cmd_index(txq-q, rd_ptr);
+
lockdep_assert_held(txq-lock);
- iwlagn_unmap_tfd(trans, txq-meta[index], tfd_tmp[index], dma_dir);
+ /* We have only q-n_window
[PATCH] e1000: save skb counts in TX to avoid cache misses
[Upstream commit 31c15a2f24ebdab14333d9bf5df49757842ae2ec with paths
adjusted to compensate for the drivers/net/ethernet/intel reorg in
dee1ad47f2ee75f5146d83ca757c1b7861c34c3b]
Author: Dean Nelson dnel...@redhat.com
Date: Thu Aug 25 14:39:24 2011 +
e1000: save skb counts in TX to avoid cache misses
Virtual Machines with emulated e1000 network adapter running on Parallels'
server were seeing kernel panics due to the e1000 driver dereferencing an
unexpected NULL pointer retrieved from buffer_info-skb.
The problem has been addressed for the e1000e driver, but not for the e1000.
Since the two drivers share similar code in the affected area, a port of the
following e1000e driver commit solves the issue for the e1000 driver:
commit 9ed318d546a29d7a591dbe648fd1a2efe3be1180
Author: Tom Herbert therb...@google.com
Date: Wed May 5 14:02:27 2010 +
e1000e: save skb counts in TX to avoid cache misses
In e1000_tx_map, precompute number of segements and bytecounts which
are derived from fields in skb; these are stored in buffer_info. When
cleaning tx in e1000_clean_tx_irq use the values in the associated
buffer_info for statistics counting, this eliminates cache misses
on skb fields.
Signed-off-by: Dean Nelson dnel...@redhat.com
Acked-by: Jeff Kirsher jeffrey.t.kirs...@intel.com
Signed-off-by: David S. Miller da...@davemloft.net
Signed-off-by: Roman Kagan rka...@parallels.com
---
drivers/net/e1000/e1000.h |2 ++
drivers/net/e1000/e1000_main.c | 18 +-
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h
index 8676899..2c71884 100644
--- a/drivers/net/e1000/e1000.h
+++ b/drivers/net/e1000/e1000.h
@@ -150,6 +150,8 @@ struct e1000_buffer {
unsigned long time_stamp;
u16 length;
u16 next_to_watch;
+ unsigned int segs;
+ unsigned int bytecount;
u16 mapped_as_page;
};
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 76e8af0..99525f9 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -2798,7 +2798,7 @@ static int e1000_tx_map(struct e1000_adapter *adapter,
struct e1000_buffer *buffer_info;
unsigned int len = skb_headlen(skb);
unsigned int offset = 0, size, count = 0, i;
- unsigned int f;
+ unsigned int f, bytecount, segs;
i = tx_ring-next_to_use;
@@ -2899,7 +2899,13 @@ static int e1000_tx_map(struct e1000_adapter *adapter,
}
}
+ segs = skb_shinfo(skb)-gso_segs ?: 1;
+ /* multiply data chunks by size of headers */
+ bytecount = ((segs - 1) * skb_headlen(skb)) + skb-len;
+
tx_ring-buffer_info[i].skb = skb;
+ tx_ring-buffer_info[i].segs = segs;
+ tx_ring-buffer_info[i].bytecount = bytecount;
tx_ring-buffer_info[first].next_to_watch = i;
return count;
@@ -3573,14 +3579,8 @@ static bool e1000_clean_tx_irq(struct e1000_adapter
*adapter,
cleaned = (i == eop);
if (cleaned) {
- struct sk_buff *skb = buffer_info-skb;
- unsigned int segs, bytecount;
- segs = skb_shinfo(skb)-gso_segs ?: 1;
- /* multiply data chunks by size of headers */
- bytecount = ((segs - 1) * skb_headlen(skb)) +
- skb-len;
- total_tx_packets += segs;
- total_tx_bytes += bytecount;
+ total_tx_packets += buffer_info-segs;
+ total_tx_bytes += buffer_info-bytecount;
}
e1000_unmap_and_free_tx_resource(adapter, buffer_info);
tx_desc-upper.data = 0;
--
1.7.10.2
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ToDo: backport to v3.4 , v3.3 , v3.2 patches 1b) db63a4c8115a libata 1) cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default Fw: use hv_storvsc instead of ata_piix for IDE disks ( but
Hi!
Shortly:
Tested ( but, in early implementaition): Ubuntu 12.04 + OpenSUSE
+
I'm test kernel v3.5 on Arch Linux -- all related this patches work Ok
Greg: ( in any case: accept backport patches or not) might be very usefull info: what lines from this rules: [. .
.] doesn't meet?
are You read _all_ info/materials [ VVM: sended _later_ Youre first answer ] about problem? See P.S. [ and later in
this e-mail]
==
-- _but_ this is bug in (drivers_set(ata_piix + hv_storvsc))
I.e. it is _bug_ in any case
of cource, solution of ( bug in (drivers_set(ata_piix + hv_storvsc)) )
problem need
changing the behavior of the ata driver [ VVM: ata_piix ] to accommodate Hyper-V [ VVM: Hyper-V SCSIATA driver (
hv_storvsc) ]
==
---
Full:
{
Hyper-V admins need _worked_ Linux v3.4.X / v3.3.X / v3.2.X
Please, _fix_ errors related use hv_storvsc instead of ata_piix to
handle the IDE disks devices ( but not for the CD-ROM)
i.e. need backport to all actual version after 3.1
cd006086fa5d ata_piix: defer disks to the Hyper-V drivers by default
and its prerequisite
db63a4c8115a libata: add a host flag to ignore detected ATA devices
}
K.Y.S. will be nice to have this patch in previous stable releases.
greg k-h Lots of things would be nice,
greg k-h but as this doesn't meet the stable_kernel_rules.txt rules, sorry, I
can't take them.
1)
Greg: ( in any case: accept backport patches or not) might be very usefull
info: what lines from this rules
==
Rules on what kind of patches are accepted, and which ones are not, into the
-stable tree:
- It must be obviously correct and tested.
- It cannot be bigger than 100 lines, with context.
- It must fix only one thing.
- It must fix a real bug that bothers people (not a, This could be a
problem... type thing).
- It must fix a problem that causes a build error (but not for things
marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
security issue, or some oh, that's not good issue. In short, something
critical.
- New device IDs and quirks are also accepted.
- No theoretical race condition issues, unless an explanation of how the
race can be exploited is also provided.
- It cannot contain any trivial fixes in it (spelling changes,
whitespace cleanups, etc).
- It must follow the Documentation/SubmittingPatches rules.
- It or an equivalent fix must already exist in Linus' tree (upstream).
==
2)
are You read _all_ info/materials about problem? See P.S.
Some additional info:
{
MS this is not a bug in the ata_piix driver
-- not bug in ata_piix driver itself
-- _but_ this is bug in (drivers_set(ata_piix + hv_storvsc))
I.e. it is _bug_ in any case
of cource, solution of ( bug in (drivers_set(ata_piix + hv_storvsc)) )
problem need
changing the behavior of the ata driver [ VVM: ata_piix ] to accommodate Hyper-V [ VVM: Hyper-V SCSIATA driver (
hv_storvsc) ]
}
{
- Original Message -
From: Victor Miasnikov
To: Greg KH
Sent: Wednesday, June 06, 2012 7:00 PM
I'm test kernel v3.5 on Arch Linux -- all related this patches work Ok
And {
- It must be obviously correct and tested.
Tested ( but, in early implementaition): Ubuntu 12.04 + OpenSUSE
}
}
Best regards, Victor Miasnikov
Blog: http://vvm.blog.tut.by/
P.S.
History of question:
http://lkml.org/lkml/2012/6/5/23
==
- Original Message -
From: Victor Miasnikov
To: Jonathan Nieder
Sent: Tuesday, June 05, 2012 9:50:16 +0300 AM
. . .
J.N. {
A workaround is to blacklist the ata_piix module.
However, that means losing access to CD and DVD drives
which are exposed by ata_piix and not hv_storvsc.
}
Yes: work without CD-ROM is not super-fine,
{
best backport patches from v3.5 ( de-facto reincarnation _tested_(!) patches
from Ubuntu v12.04 and/or OpenSUSE )
. . .
==
very good description of problem and possible solution:
http://lkml.org/lkml/2012/6/5/6
==
- Original Message -
From: Jonathan Nieder
To: . . . Cc: . . .
Sent: Tuesday, June 05, 2012 7:59 AM
Subject: Re: [PATCH 2/2] ata_piix: defer disks to the Hyper-V drivers by default
. . .
If I understand correctly,
the problem is that ata_piix and hv_storvsc both claim the (virtual) hard disk.
That sounds worth fixing.
The patch works by making ata_piix skip the disk during enumeration
if hv_storvsc is enabled as a built-in driver or module.
A workaround is to blacklist the ata_piix module.
However, that means losing access to CD and DVD drives
which are exposed by ata_piix and not hv_storvsc.
--
==
http://lkml.org/lkml/2012/6/4/200
==
- Original Message -
From: Victor Miasnikov
To: _ _ Cc: _ _
Sent: Monday, June 04, 2012 3:33 PM
Subject: Re: Linux on Hyper-V 1) cd006086fa5d ata_piix: defer disks to the
Hyper-V drivers by default 2) db63a4c8115a
libata: add a host flag to ignore detected ATA device FW: use hv_storvsc
instead of ata_piix to handle the IDE disks
devices ( but not for the ...
. . .
patches does meet the stable_kernel_rules.txt rules by
Re: [ 08/82] mm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP race condition
Hi, On Thu, Jun 07, 2012 at 09:42:55AM -0400, Josh Boyer wrote: On Thu, Jun 7, 2012 at 12:03 AM, Greg KH gre...@linuxfoundation.org wrote: 3.4-stable review patch. If anyone has any objections, please let me know. -- From: Andrea Arcangeli aarca...@redhat.com commit 26c191788f18129af0eb32a358cdaea0c7479626 upstream. When holding the mmap_sem for reading, pmd_offset_map_lock should only run on a pmd_t that has been read atomically from the pmdp pointer, otherwise we may read only half of it leading to this crash. This one is important, but it can break Xen apparently: http://permalink.gmane.org/gmane.comp.emulators.xen.devel/132522 https://bugzilla.redhat.com/show_bug.cgi?id=829016 Not sure if you want to hold off on it or see if Andrea comes up with a follow up fix? Not knowing exactly why Xen trips on the atomic64_read on a PAE 32bit pmd on my side, I don't know what's the best direction to fix it yet. I knew this fix has been tested and was working fine with Xen + CONFIG_TRANSPARENT_HUGEPAGE=n + 32bit + x86 + PAE. And when THP=n I could fix the problem without having to use a slightly more expensive cmpxchg8b for every pmd read happening with the mmap_sem hold in read mode. It was totally unexpected to run into trouble with Xen + CONFIG_TRANSPARENT_HUGEPAGE=y + 32bit + x86 + PAE, apologies. From the oops it looks like atomic64_read trips on a dangling pmdp pointer, but if the problem doesn't happen with Xen then the pointer value shouldn't be the problem, and in turn the lock cmpxchg8b used to access the pointer is likely the problem. I gave a few suggestions on how to fix it, that should work regardless of why this is happening, but I'd prefer the Xen developers to comment on that. https://bugzilla.redhat.com/attachment.cgi?id=589620 f0 0f c7 09 c3 8d 76 0 f0 0f is the infamous opcode lock cmpxchg8b so it confirms it trips exactly on the pmdp read. ecx/edx = dcaea360 and BUG: unable to handle kernel paging request at dcaea360 are probably all right, my best guess is that the insn used to read the pmd is unexpected. -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [V2 PATCH 1/2] aio: make kiocb-private NUll in init_sync_kiocb()
Junxiao Bi junxiao...@oracle.com writes: Ocfs2 uses kiocb.*private as a flag of unsigned long size. In commit a11f7e6 ocfs2: serialize unaligned aio, the unaligned io flag is involved in it to serialize the unaligned aio. As *private is not initialized in init_sync_kiocb() of do_sync_write(), this unaligned io flag may be unexpectly set in an aligned dio. And this will cause OCFS2_I(inode)-ip_unaligned_aio decreased to -1 in ocfs2_dio_end_io(), thus the following unaligned dio will hang forever at ocfs2_aiodio_wait() in ocfs2_file_aio_write(). Signed-off-by: Junxiao Bi junxiao...@oracle.com Acked-by: Jeff Moyer jmo...@redhat.com -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] x86, AMD: Fix crash as Xen Dom0 on AMD Trinity systems
On 06/07/2012 01:08 AM, Greg KH wrote: What? So I don't need to do anything? Correct, you're fine as-is. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] block: Move general unplug callback function from md/raid to blk-core
Well, I think I will take your suggestions. I am sending another version of the patch. Thanks, -Tao -Original Message- From: shliker...@gmail.com [mailto:shliker...@gmail.com] On Behalf Of Shaohua Li Sent: Wednesday, June 06, 2012 10:07 AM To: Guo, Tao Cc: glorious...@gmail.com; linux-ker...@vger.kernel.org; ne...@suse.de; ax...@kernel.dk; stable@vger.kernel.org; a...@linux-foundation.org Subject: Re: [PATCH 1/2] block: Move general unplug callback function from md/raid to blk-core 2012/6/5 tao@emc.com: If you ever tried to implement unplug function in umem, you would find the code was almost identical as in dm/raid driver. For other components which also need such unplug mechanism, it will much more convenient to have such facilities. It's just several lines of code and your usage actually doesn't need the counter. It's unclear to me your usage requires to move the callback to list head. PS: What's your specific concern about blk_plug_cb handles each request_queue? the blk_plug_cb stores request_queue, which is incorrect to me. Why can't one plug cb unplug two or more request_queues? -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] umem: fix up unplugging
Fix a regression introduced by 7eaceaccab5f40 (block: remove per-queue
plugging). In that patch, Jens removed the whole mm_unplug_device()
function, which used to be the trigger to make umem start to work.
We need to implement unplugging to make umem start to work, or I/O will
never be triggered.
Signed-off-by: Tao Guo tao@emc.com
Cc: Neil Brown ne...@suse.de
Cc: Jens Axboe ax...@kernel.dk
Cc: Shaohua Li s...@kernel.org
Cc: stable@vger.kernel.org
---
drivers/block/umem.c | 40
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/drivers/block/umem.c b/drivers/block/umem.c
index aa27120..9a72277 100644
--- a/drivers/block/umem.c
+++ b/drivers/block/umem.c
@@ -513,6 +513,44 @@ static void process_page(unsigned long data)
}
}
+struct mm_plug_cb {
+ struct blk_plug_cb cb;
+ struct cardinfo *card;
+};
+
+static void mm_unplug(struct blk_plug_cb *cb)
+{
+ struct mm_plug_cb *mmcb = container_of(cb, struct mm_plug_cb, cb);
+
+ spin_lock_irq(mmcb-card-lock);
+ activate(mmcb-card);
+ spin_unlock_irq(mmcb-card-lock);
+ kfree(mmcb);
+}
+
+static int mm_check_plugged(struct cardinfo *card)
+{
+ struct blk_plug *plug = current-plug;
+ struct mm_plug_cb *mmcb;
+
+ if (!plug)
+ return 0;
+
+ list_for_each_entry(mmcb, plug-cb_list, cb.list) {
+ if (mmcb-cb.callback == mm_unplug mmcb-card == card)
+ return 1;
+ }
+ /* Not currently on the callback list */
+ mmcb = kmalloc(sizeof(*mmcb), GFP_ATOMIC);
+ if (!mmcb)
+ return 0;
+
+ mmcb-card = card;
+ mmcb-cb.callback = mm_unplug;
+ list_add(mmcb-cb.list, plug-cb_list);
+ return 1;
+}
+
static void mm_make_request(struct request_queue *q, struct bio *bio)
{
struct cardinfo *card = q-queuedata;
@@ -523,6 +561,8 @@ static void mm_make_request(struct request_queue *q, struct
bio *bio)
*card-biotail = bio;
bio-bi_next = NULL;
card-biotail = bio-bi_next;
+ if (bio-bi_rw REQ_SYNC || !mm_check_plugged(card))
+ activate(card);
spin_unlock_irq(card-lock);
return;
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ 08/82] mm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP race condition
On Thu, Jun 7, 2012 at 7:42 AM, Andrea Arcangeli aarca...@redhat.com wrote: From the oops it looks like atomic64_read trips on a dangling pmdp pointer, but if the problem doesn't happen with Xen then the pointer value shouldn't be the problem, and in turn the lock cmpxchg8b used to access the pointer is likely the problem. So I assume that Xen just turns the page tables read-only in order to track them, and then assumes that nobody modifies them in the particular section. And the cmpxchg64 looks like a modification, even if we only use it to read things. Andrea, do we have any guarantees like once it has turned into a regular page table, we won't see it turn back if we hold the mmap sem? Or anything like that? Because it is possible that we could do this entirely with some ordering guarantee - something like the attached patch? Totally untested, of course. Linus patch.diff Description: Binary data
Re: [ 08/82] mm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP race condition
On Thu, Jun 07, 2012 at 01:03:44PM +0900, Greg KH wrote:
3.4-stable review patch. If anyone has any objections, please let me know.
It breaks Linux running under Amazon EC2 under 32-bit. Please
don't apply it to any 3.x kernels until we figure out a
fix to this.
--
From: Andrea Arcangeli aarca...@redhat.com
commit 26c191788f18129af0eb32a358cdaea0c7479626 upstream.
When holding the mmap_sem for reading, pmd_offset_map_lock should only
run on a pmd_t that has been read atomically from the pmdp pointer,
otherwise we may read only half of it leading to this crash.
PID: 11679 TASK: f06e8000 CPU: 3 COMMAND: do_race_2_panic
#0 [f06a9dd8] crash_kexec at c049b5ec
#1 [f06a9e2c] oops_end at c083d1c2
#2 [f06a9e40] no_context at c0433ded
#3 [f06a9e64] bad_area_nosemaphore at c043401a
#4 [f06a9e6c] __do_page_fault at c0434493
#5 [f06a9eec] do_page_fault at c083eb45
#6 [f06a9f04] error_code (via page_fault) at c083c5d5
EAX: 01fb470c EBX: fff35000 ECX: 0003 EDX: 0100 EBP:
DS: 007b ESI: 9e201000 ES: 007b EDI: 01fb4700 GS: 00e0
CS: 0060 EIP: c083bc14 ERR: EFLAGS: 00010246
#7 [f06a9f38] _spin_lock at c083bc14
#8 [f06a9f44] sys_mincore at c0507b7d
#9 [f06a9fb0] system_call at c083becd
start len
EAX: ffda EBX: 9e20 ECX: 1000 EDX: 6228537f
DS: 007b ESI: ES: 007b EDI: 003d0f00
SS: 007b ESP: 62285354 EBP: 62285388 GS: 0033
CS: 0073 EIP: 00291416 ERR: 00da EFLAGS: 0286
This should be a longstanding bug affecting x86 32bit PAE without THP.
Only archs with 64bit large pmd_t and 32bit unsigned long should be
affected.
With THP enabled the barrier() in pmd_none_or_trans_huge_or_clear_bad()
would partly hide the bug when the pmd transition from none to stable,
by forcing a re-read of the *pmd in pmd_offset_map_lock, but when THP is
enabled a new set of problem arises by the fact could then transition
freely in any of the none, pmd_trans_huge or pmd_trans_stable states.
So making the barrier in pmd_none_or_trans_huge_or_clear_bad()
unconditional isn't good idea and it would be a flakey solution.
This should be fully fixed by introducing a pmd_read_atomic that reads
the pmd in order with THP disabled, or by reading the pmd atomically
with cmpxchg8b with THP enabled.
Luckily this new race condition only triggers in the places that must
already be covered by pmd_none_or_trans_huge_or_clear_bad() so the fix
is localized there but this bug is not related to THP.
NOTE: this can trigger on x86 32bit systems with PAE enabled with more
than 4G of ram, otherwise the high part of the pmd will never risk to be
truncated because it would be zero at all times, in turn so hiding the
SMP race.
This bug was discovered and fully debugged by Ulrich, quote:
[..]
pmd_none_or_trans_huge_or_clear_bad() loads the content of edx and
eax.
496 static inline int pmd_none_or_trans_huge_or_clear_bad(pmd_t
*pmd)
497 {
498 /* depend on compiler for an atomic pmd read */
499 pmd_t pmdval = *pmd;
// edi = pmd pointer
0xc0507a74 sys_mincore+548: mov0x8(%esp),%edi
...
// edx = PTE page table high address
0xc0507a84 sys_mincore+564: mov0x4(%edi),%edx
...
// eax = PTE page table low address
0xc0507a8e sys_mincore+574: mov(%edi),%eax
[..]
Please note that the PMD is not read atomically. These are two mov
instructions where the high order bits of the PMD entry are fetched
first. Hence, the above machine code is prone to the following race.
- The PMD entry {high|low} is 0x.
The mov at 0xc0507a84 loads 0x into edx.
- A page fault (on another CPU) sneaks in between the two mov
instructions and instantiates the PMD.
- The PMD entry {high|low} is now 0x0003fda38067.
The mov at 0xc0507a8e loads 0xfda38067 into eax.
Reported-by: Ulrich Obergfell uober...@redhat.com
Signed-off-by: Andrea Arcangeli aarca...@redhat.com
Cc: Mel Gorman mgor...@suse.de
Cc: Hugh Dickins hu...@google.com
Cc: Larry Woodman lwood...@redhat.com
Cc: Petr Matousek pmato...@redhat.com
Cc: Rik van Riel r...@redhat.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
arch/x86/include/asm/pgtable-3level.h | 50
++
include/asm-generic/pgtable.h | 22 +-
2 files changed, 70 insertions(+), 2 deletions(-)
--- a/arch/x86/include/asm/pgtable-3level.h
+++ b/arch/x86/include/asm/pgtable-3level.h
@@ -31,6 +31,56 @@ static inline void native_set_pte(pte_t
ptep-pte_low = pte.pte_low;
}
+#define
Re: [PATCH 1/2] xhci: Fix invalid loop check in xhci_free_tt_info()
On Fri, Jun 01, 2012 at 10:06:23AM +0200, Takashi Iwai wrote:
xhci_free_tt_info() may access the invalid memory when it removes the
last entry but the list is not empty. Then tt_next reaches to the
list head but it still tries to check the tt_info of that entry.
This patch fixes the bug and cleans up the messy code by rewriting
with a simple list_for_each_entry_safe().
Cc: stable@vger.kernel.org
Reviewed-by: Oliver Neukum oneu...@suse.de
Signed-off-by: Takashi Iwai ti...@suse.de
Ok, this looks correct. I'll send it off to Greg in my next 3.5 pull
request.
Sarah Sharp
---
drivers/usb/host/xhci-mem.c | 38 +-
1 file changed, 9 insertions(+), 29 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index ec4338e..4e1da7f 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -793,10 +793,9 @@ static void xhci_free_tt_info(struct xhci_hcd *xhci,
struct xhci_virt_device *virt_dev,
int slot_id)
{
- struct list_head *tt;
struct list_head *tt_list_head;
- struct list_head *tt_next;
- struct xhci_tt_bw_info *tt_info;
+ struct xhci_tt_bw_info *tt_info, *next;
+ bool slot_found = false;
/* If the device never made it past the Set Address stage,
* it may not have the real_port set correctly.
@@ -808,34 +807,15 @@ static void xhci_free_tt_info(struct xhci_hcd *xhci,
}
tt_list_head = (xhci-rh_bw[virt_dev-real_port - 1].tts);
- if (list_empty(tt_list_head))
- return;
-
- list_for_each(tt, tt_list_head) {
- tt_info = list_entry(tt, struct xhci_tt_bw_info, tt_list);
- if (tt_info-slot_id == slot_id)
+ list_for_each_entry_safe(tt_info, next, tt_list_head, tt_list) {
+ /* Multi-TT hubs will have more than one entry */
+ if (tt_info-slot_id == slot_id) {
+ slot_found = true;
+ list_del(tt_info-tt_list);
+ kfree(tt_info);
+ } else if (slot_found)
break;
}
- /* Cautionary measure in case the hub was disconnected before we
- * stored the TT information.
- */
- if (tt_info-slot_id != slot_id)
- return;
-
- tt_next = tt-next;
- tt_info = list_entry(tt, struct xhci_tt_bw_info,
- tt_list);
- /* Multi-TT hubs will have more than one entry */
- do {
- list_del(tt);
- kfree(tt_info);
- tt = tt_next;
- if (list_empty(tt_list_head))
- break;
- tt_next = tt-next;
- tt_info = list_entry(tt, struct xhci_tt_bw_info,
- tt_list);
- } while (tt_info-slot_id == slot_id);
}
int xhci_alloc_tt_info(struct xhci_hcd *xhci,
--
1.7.9.2
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ 08/82] mm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP race condition
On Thu, Jun 07, 2012 at 10:46:44AM -0700, Linus Torvalds wrote:
So I assume that Xen just turns the page tables read-only in order to
track them, and then assumes that nobody modifies them in the
particular section. And the cmpxchg64 looks like a modification, even
if we only use it to read things.
Agreed, the implicit write could be the trigger.
Andrea, do we have any guarantees like once it has turned into a
regular page table, we won't see it turn back if we hold the mmap
sem? Or anything like that? Because it is possible that we could do
Yes if it turns in a regular page table it will stop changing.
The problem is this is the THP case. Without THP it can only change
from nono to regular page table. With THP it can change from none to
trans_huge to none to trans_huge and it only stops if it eventually
becomes a regular page table.
this entirely with some ordering guarantee - something like the
attached patch?
It's possible to do it with a loop like in the patch, gup_fast does it
that way (and gup_fast does it on the pte so the pte is susciptible to
the exact same instability that the pmd has even when THP=n, as
madvise/pagefault can run under gup_fast), but I'm not sure if it's
safe especially with irqs enabled. Maybe gup_fast is safe because it
disables irqs to stop MADV_DONTNEED?
The race would be:
l = pmd.low
smp_rmb()
h = pmd.high
smp_rmb()
pmd points to page 4G
MADV_DONTNEED
page fault allocates page at 8G
l = pmd.low
Disabling irqs may be enough to hang MADV_DONTNEED on the tlb flush
IPI. But my feeling is the page fault can happen even while
MADV_DONTNEED waits on the tlb flush IPI. So the above could still
happen on gup_fast too? But of course gup_fast troubles are irrelevant
here, but I was thinking about this one before... so I mentioned it
too as it's the same problem.
The simple idea in pmd_none_or_trans_huge_or_clear_bad is that we
need an atomic snapshot of the pmdval, stabilize it in register or
local stack, and do the computations on it to know if the pmd is
stable or unstable.
But the more complex idea would be to relay on the below barrier and
deal with half corrupted pmds.
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
barrier();
#endif
the barrier prevents the *pmdp read to be cached across the return of
pmd_none_or_trans_huge_or_clear_bad when THP=y (our problem case). And
all we need is to compute those checks atomically on the low part.
if (pmd_none(pmdval))
return 1;
if (unlikely(pmd_bad(pmdval))) {
if (!pmd_trans_huge(pmdval))
pmd_clear_bad(pmd);
return 1;
}
If we remove the #ifdef CONFIG_TRANSPARENT_HUGEPAGE around the
barrier(), we can get rid of pmd_read_atomic entirely and just do *pmd
as before the fix (however note that if we triggered the crash in
madvise with 32bit pae THP=n it means the value was cached by gcc and
the corrupted pmdval was used for running pte_offset). So if we make
the barrier() unconditional we'll force a second access to
memory. This is the whole point of the barrier() conditional (to avoid
screwing with gcc good work when not absolutely necessary).
Anyway I made a patch below to take advantage of the barrier() and
deal with corrupted pmds on pae 32bit x86 THP=y which I hope could fix
this more optimally:
diff --git a/arch/x86/include/asm/pgtable-3level.h
b/arch/x86/include/asm/pgtable-3level.h
index 43876f1..149d968 100644
--- a/arch/x86/include/asm/pgtable-3level.h
+++ b/arch/x86/include/asm/pgtable-3level.h
@@ -31,7 +31,6 @@ static inline void native_set_pte(pte_t *ptep, pte_t pte)
ptep-pte_low = pte.pte_low;
}
-#define pmd_read_atomic pmd_read_atomic
/*
* pte_offset_map_lock on 32bit PAE kernels was reading the pmd_t with
* a *pmdp dereference done by gcc. Problem is, in certain places
@@ -53,10 +52,18 @@ static inline void native_set_pte(pte_t *ptep, pte_t pte)
*
* With THP if the mmap_sem is hold for reading, the pmd can become
* THP or null or point to a pte (and in turn become stable) at any
- * time under pmd_read_atomic, so it's mandatory to read it atomically
- * with cmpxchg8b.
+ * time under pmd_read_atomic. We could read it atomically here with a
+ * pmd_read_atomic using atomic64_read for the THP case, but instead
+ * we let the generic version of pmd_read_atomic run, and we instead
+ * relay on the barrier() in pmd_none_or_trans_huge_or_clear_bad() to
+ * prevent gcc to cache the potentially corrupted pmdval in pte_offset
+ * later. The barrier() will force the re-reading of the pmd and the
+ * checks in pmd_none_or_trans_huge_or_clear_bad() will only care
+ * about the low part of the pmd, regardless if the high part is
+ * consistent.
*/
#ifndef CONFIG_TRANSPARENT_HUGEPAGE
+#define pmd_read_atomic pmd_read_atomic
Re: [PATCH] IA64: Export asm/cmpxchg.h to userland
On Thu, Jun 07, 2012 at 04:54:56PM +, Luck, Tony wrote:
Parts of asm/intrinsics.h were moved to asm/cmpxchg.h, and the
former now includes the latter. The former is exported to userland
so the latter must be too.
Already received and applied a patch that does this (though it added
the cmpxchg.h a few lines earlier that you did).
See commit: 98e4cff73
It didn't get marked for stable though ... so if you need this to
get pulled into the stable branches you'll need to poke Greg etc.
manually.
Greg, please cherry-pick commit
85f8f7759e418c814ee2ceacf73eddb9bed39492 ('[IA64] Add cmpxchg.h to
exported userspace headers') for 3.4.y.
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ToDo: backport to etc etc
Hi Victor, Victor Miasnikov wrote: Hi! Shortly: Tested ( but, in early implementaition): Ubuntu 12.04 + OpenSUSE + Your mails are hard to read. Please see http://www.tux.org/lkml/#s3-9 if you would like to change that. Hope that helps, Jonathan -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ 08/82] mm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP race condition
Hi,
this should avoid the cmpxchg8b (to make Xen happy) but without
reintroducing the race condition. It's actually going to be faster
too, but it's conceptually more complicated as the pmd high/low may be
inconsistent at times, but at those times we're going to declare the
pmd unstable and ignore it anyway so it's ok.
NOTE: in theory I could also drop the high part when THP=y thanks to
the barrier() in the caller (and the barrier is needed for the generic
version anyway):
static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
{
pmdval_t ret;
u32 *tmp = (u32 *)pmdp;
ret = (pmdval_t) (*tmp);
+#ifndef CONFIG_TRANSPARENT_HUGEPAGE
if (ret) {
/*
* If the low part is null, we must not read the high part
* or we can end up with a partial pmd.
*/
smp_rmb();
ret |= ((pmdval_t)*(tmp + 1)) 32;
}
+#endif
return (pmd_t) { ret };
}
But it's not worth the extra complexity. It looks cleaner if we deal
with good pmds if they're later found pointing to a pte (even if we
discard them and force pte_offset to re-read the *pmd).
Andrea Arcangeli (1):
thp: avoid atomic64_read in pmd_read_atomic for 32bit PAE
arch/x86/include/asm/pgtable-3level.h | 30 +-
include/asm-generic/pgtable.h | 10 ++
2 files changed, 27 insertions(+), 13 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] thp: avoid atomic64_read in pmd_read_atomic for 32bit PAE
In the x86 32bit PAE CONFIG_TRANSPARENT_HUGEPAGE=y case while holding
the mmap_sem for reading, cmpxchg8b cannot be used to read pmd
contents under Xen.
So instead of dealing only with consistent pmdvals in
pmd_none_or_trans_huge_or_clear_bad() (which would be conceptually
simpler) we let pmd_none_or_trans_huge_or_clear_bad() deal with pmdvals
where the low 32bit and high 32bit could be inconsistent (to avoid
having to use cmpxchg8b).
The only guarantee we get from pmd_read_atomic is that if the low part
of the pmd was found null, the high part will be null too (so the pmd
will be considered unstable). And if the low part of the pmd is found
stable later, then it means the whole pmd was read atomically
(because after a pmd is stable, neither MADV_DONTNEED nor page faults
can alter it anymore, and we read the high part after the low part).
In the 32bit PAE x86 case, it is enough to read the low part of the
pmdval atomically to declare the pmd as stable and that's true for
THP and no THP, furthermore in the THP case we also have a barrier()
that will prevent any inconsistent pmdvals to be cached by a later
re-read of the *pmd.
Signed-off-by: Andrea Arcangeli aarca...@redhat.com
---
arch/x86/include/asm/pgtable-3level.h | 30 +-
include/asm-generic/pgtable.h | 10 ++
2 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/arch/x86/include/asm/pgtable-3level.h
b/arch/x86/include/asm/pgtable-3level.h
index 43876f1..cb00ccc 100644
--- a/arch/x86/include/asm/pgtable-3level.h
+++ b/arch/x86/include/asm/pgtable-3level.h
@@ -47,16 +47,26 @@ static inline void native_set_pte(pte_t *ptep, pte_t pte)
* they can run pmd_offset_map_lock or pmd_trans_huge or other pmd
* operations.
*
- * Without THP if the mmap_sem is hold for reading, the
- * pmd can only transition from null to not null while pmd_read_atomic runs.
- * So there's no need of literally reading it atomically.
+ * Without THP if the mmap_sem is hold for reading, the pmd can only
+ * transition from null to not null while pmd_read_atomic runs. So
+ * we can always return atomic pmd values with this function.
*
* With THP if the mmap_sem is hold for reading, the pmd can become
- * THP or null or point to a pte (and in turn become stable) at any
- * time under pmd_read_atomic, so it's mandatory to read it atomically
- * with cmpxchg8b.
+ * trans_huge or none or point to a pte (and in turn become stable)
+ * at any time under pmd_read_atomic. We could read it really
+ * atomically here with a atomic64_read for the THP enabled case (and
+ * it would be a whole lot simpler), but to avoid using cmpxchg8b we
+ * only return an atomic pmdval if the low part of the pmdval is later
+ * found stable (i.e. pointing to a pte). And we're returning a none
+ * pmdval if the low part of the pmd is none. In some cases the high
+ * and low part of the pmdval returned may not be consistent if THP is
+ * enabled (the low part may point to previously mapped hugepage,
+ * while the high part may point to a more recently mapped hugepage),
+ * but pmd_none_or_trans_huge_or_clear_bad() only needs the low part
+ * of the pmd to be read atomically to decide if the pmd is unstable
+ * or not, with the only exception of when the low part of the pmd is
+ * zero in which case we return a none pmd.
*/
-#ifndef CONFIG_TRANSPARENT_HUGEPAGE
static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
{
pmdval_t ret;
@@ -74,12 +84,6 @@ static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
return (pmd_t) { ret };
}
-#else /* CONFIG_TRANSPARENT_HUGEPAGE */
-static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
-{
- return (pmd_t) { atomic64_read((atomic64_t *)pmdp) };
-}
-#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
static inline void native_set_pte_atomic(pte_t *ptep, pte_t pte)
{
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index ae39c4b..0ff87ec 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -484,6 +484,16 @@ static inline int
pmd_none_or_trans_huge_or_clear_bad(pmd_t *pmd)
/*
* The barrier will stabilize the pmdval in a register or on
* the stack so that it will stop changing under the code.
+*
+* When CONFIG_TRANSPARENT_HUGEPAGE=y on x86 32bit PAE,
+* pmd_read_atomic is allowed to return a not atomic pmdval
+* (for example pointing to an hugepage that has never been
+* mapped in the pmd). The below checks will only care about
+* the low part of the pmd with 32bit PAE x86 anyway, with the
+* exception of pmd_none(). So the important thing is that if
+* the low part of the pmd is found null, the high part will
+* be also null or the pmd_none() check below would be
+* confused.
*/
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
barrier();
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to
Re: [ 08/82] mm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP race condition
On Thu, Jun 07, 2012 at 09:04:14PM +0200, Andrea Arcangeli wrote:
#ifndef CONFIG_TRANSPARENT_HUGEPAGE
+#define pmd_read_atomic pmd_read_atomic
static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
{
pmdval_t ret;
@@ -74,11 +81,6 @@ static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
return (pmd_t) { ret };
}
-#else /* CONFIG_TRANSPARENT_HUGEPAGE */
-static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
-{
- return (pmd_t) { atomic64_read((atomic64_t *)pmdp) };
-}
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
static inline void native_set_pte_atomic(pte_t *ptep, pte_t pte)
This actually wasn't safe because if the high part wasn't none and the
low part was none, the pmd_none check would fail. I sent an updated
version that will fix this hopefully for good and it turns out the
same pmd_read_atomic will work for THP=n/y without need of cmpxchg8b
even if it's slightly less obviously safe than if we used
atomic64_read for THP=y. Still safe that is...
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 12/12] mm: correctly synchronize rss-counters at exit/exec
From: Konstantin Khlebnikov khlebni...@openvz.org
Subject: mm: correctly synchronize rss-counters at exit/exec
mm-rss_stat counters have per-task delta: task-rss_stat. Before
changing task-mm pointer the kernel must flush this delta with
sync_mm_rss().
do_exit() already calls sync_mm_rss() to flush the rss-counters before
committing the rss statistics into task-signal-maxrss, taskstats, audit
and other stuff. Unfortunately the kernel does this before calling
mm_release(), which can call put_user() for processing
task-clear_child_tid. So at this point we can trigger page-faults and
task-rss_stat becomes non-zero again. As a result mm-rss_stat becomes
inconsistent and check_mm() will print something like this:
| BUG: Bad rss-counter state mm:88020813c380 idx:1 val:-1
| BUG: Bad rss-counter state mm:88020813c380 idx:2 val:1
This patch moves sync_mm_rss() into mm_release(), and moves mm_release()
out of do_exit() and calls it earlier. After mm_release() there should be
no pagefaults.
[a...@linux-foundation.org: tweak comment]
Signed-off-by: Konstantin Khlebnikov khlebni...@openvz.org
Reported-by: Markus Trippelsdorf mar...@trippelsdorf.de
Cc: Hugh Dickins hu...@google.com
Cc: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
Cc: Oleg Nesterov o...@redhat.com
Cc: stable@vger.kernel.org[3.4.x]
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
fs/exec.c |1 -
kernel/exit.c | 13 -
kernel/fork.c |8
3 files changed, 16 insertions(+), 6 deletions(-)
diff -puN fs/exec.c~mm-correctly-synchronize-rss-counters-at-exit-exec fs/exec.c
--- a/fs/exec.c~mm-correctly-synchronize-rss-counters-at-exit-exec
+++ a/fs/exec.c
@@ -819,7 +819,6 @@ static int exec_mmap(struct mm_struct *m
/* Notify parent that we're no longer interested in the old VM */
tsk = current;
old_mm = current-mm;
- sync_mm_rss(old_mm);
mm_release(tsk, old_mm);
if (old_mm) {
diff -puN kernel/exit.c~mm-correctly-synchronize-rss-counters-at-exit-exec
kernel/exit.c
--- a/kernel/exit.c~mm-correctly-synchronize-rss-counters-at-exit-exec
+++ a/kernel/exit.c
@@ -423,6 +423,7 @@ void daemonize(const char *name, ...)
* user space pages. We don't need them, and if we didn't close them
* they would be locked into memory.
*/
+ mm_release(current, current-mm);
exit_mm(current);
/*
* We don't want to get frozen, in case system-wide hibernation
@@ -640,7 +641,6 @@ static void exit_mm(struct task_struct *
struct mm_struct *mm = tsk-mm;
struct core_state *core_state;
- mm_release(tsk, mm);
if (!mm)
return;
/*
@@ -960,9 +960,13 @@ void do_exit(long code)
preempt_count());
acct_update_integrals(tsk);
- /* sync mm's RSS info before statistics gathering */
- if (tsk-mm)
- sync_mm_rss(tsk-mm);
+
+ /* Set exit_code before complete_vfork_done() in mm_release() */
+ tsk-exit_code = code;
+
+ /* Release mm and sync mm's RSS info before statistics gathering */
+ mm_release(tsk, tsk-mm);
+
group_dead = atomic_dec_and_test(tsk-signal-live);
if (group_dead) {
hrtimer_cancel(tsk-signal-real_timer);
@@ -975,7 +979,6 @@ void do_exit(long code)
tty_audit_exit();
audit_free(tsk);
- tsk-exit_code = code;
taskstats_exit(tsk, group_dead);
exit_mm(tsk);
diff -puN kernel/fork.c~mm-correctly-synchronize-rss-counters-at-exit-exec
kernel/fork.c
--- a/kernel/fork.c~mm-correctly-synchronize-rss-counters-at-exit-exec
+++ a/kernel/fork.c
@@ -619,6 +619,14 @@ void mmput(struct mm_struct *mm)
module_put(mm-binfmt-module);
mmdrop(mm);
}
+
+ /*
+* Final rss-counter synchronization. After this point there must be
+* no pagefaults into this mm from the current context. Otherwise
+* mm-rss_stat will be inconsistent.
+*/
+ if (mm)
+ sync_mm_rss(mm);
}
EXPORT_SYMBOL_GPL(mmput);
_
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 10/12] btree: fix tree corruption in btree_get_prev()
From: Roland Dreier rol...@purestorage.com
Subject: btree: fix tree corruption in btree_get_prev()
The memory the parameter __key points to is used as an iterator in
btree_get_prev(), so if we save off a bkey() pointer in retry_key and then
assign that to __key, we'll end up corrupting the btree internals when we
do eg
longcpy(__key, bkey(geo, node, i), geo-keylen);
to return the key value. What we should do instead is use longcpy() to
copy the key value that retry_key points to __key.
This can cause a btree to get corrupted by seemingly read-only operations
such as btree_for_each_safe.
[a...@linux-foundation.org: avoid the double longcpy()]
Signed-off-by: Roland Dreier rol...@purestorage.com
Acked-by: Joern Engel jo...@logfs.org
Cc: stable@vger.kernel.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
lib/btree.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -puN lib/btree.c~btree-fix-tree-corruption-in-btree_get_prev lib/btree.c
--- a/lib/btree.c~btree-fix-tree-corruption-in-btree_get_prev
+++ a/lib/btree.c
@@ -319,8 +319,8 @@ void *btree_get_prev(struct btree_head *
if (head-height == 0)
return NULL;
-retry:
longcpy(key, __key, geo-keylen);
+retry:
dec_key(geo, key);
node = head-node;
@@ -351,7 +351,7 @@ retry:
}
miss:
if (retry_key) {
- __key = retry_key;
+ longcpy(key, retry_key, geo-keylen);
retry_key = NULL;
goto retry;
}
_
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] e1000: save skb counts in TX to avoid cache misses
On 06/07/2012 05:49 AM, Roman Kagan wrote: [Upstream commit 31c15a2f24ebdab14333d9bf5df49757842ae2ec with paths adjusted to compensate for the drivers/net/ethernet/intel reorg in dee1ad47f2ee75f5146d83ca757c1b7861c34c3b] Author: Dean Nelson dnel...@redhat.com Date: Thu Aug 25 14:39:24 2011 + e1000: save skb counts in TX to avoid cache misses Virtual Machines with emulated e1000 network adapter running on Parallels' server were seeing kernel panics due to the e1000 driver dereferencing an unexpected NULL pointer retrieved from buffer_info-skb. The problem has been addressed for the e1000e driver, but not for the e1000. Since the two drivers share similar code in the affected area, a port of the following e1000e driver commit solves the issue for the e1000 driver: commit 9ed318d546a29d7a591dbe648fd1a2efe3be1180 Author: Tom Herbert therb...@google.com Date: Wed May 5 14:02:27 2010 + e1000e: save skb counts in TX to avoid cache misses In e1000_tx_map, precompute number of segements and bytecounts which are derived from fields in skb; these are stored in buffer_info. When cleaning tx in e1000_clean_tx_irq use the values in the associated buffer_info for statistics counting, this eliminates cache misses on skb fields. Signed-off-by: Dean Nelson dnel...@redhat.com Acked-by: Jeff Kirsher jeffrey.t.kirs...@intel.com Signed-off-by: David S. Miller da...@davemloft.net Signed-off-by: Roman Kagan rka...@parallels.com --- drivers/net/e1000/e1000.h |2 ++ drivers/net/e1000/e1000_main.c | 18 +- 2 files changed, 11 insertions(+), 9 deletions(-) Thanks! I have applied the patch to my queue signature.asc Description: OpenPGP digital signature
Re: [PATCH] e1000: save skb counts in TX to avoid cache misses
From: Jeff Kirsher tar...@gmail.com Date: Thu, 07 Jun 2012 14:38:17 -0700 Thanks! I have applied the patch to my queue Why? My impression is that this is a patch already in the tree, and it's being submitted for -stable but such minor performance hacks are absolutely not appropriate for -stable submission. -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpiolib: wm8994: Pay attention to the value set when enabling as output
On Thu, Jun 07, 2012 at 01:11:20PM +0200, Linus Walleij wrote: broo...@opensource.wolfsonmicro.com wrote: + ? ? ? if (value) + ? ? ? ? ? ? ? value = WM8994_GPN_LVL; ? ? ? ?return wm8994_set_bits(wm8994, WM8994_GPIO_1 + offset, - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?WM8994_GPN_DIR, 0); + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?WM8994_GPN_DIR | WM8994_GPN_LVL, value); ?} The commit message is so terse compared to what the code does that I cannot claim to understand what this patch is doing. Could you elaborate on the problem ans symptoms, just for a nice commit log? I'm not really sure what more there is to say... previously we were ignoring the value that's set as part of setting output mode so if someone wanted to set a value different to the one the chip happened to have that wouldn't happen. Ignoring the vaue that the user is trying to set seems like an obvious enough bug in itself. -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] e1000: save skb counts in TX to avoid cache misses
On 06/07/2012 02:43 PM, David Miller wrote: From: Jeff Kirsher tar...@gmail.com Date: Thu, 07 Jun 2012 14:38:17 -0700 Thanks! I have applied the patch to my queue Why? My impression is that this is a patch already in the tree, and it's being submitted for -stable but such minor performance hacks are absolutely not appropriate for -stable submission. I did not catch that Roman was trying to get this into stable because there was no mention of what stable kernels this was applicable back to (and the fact that it was a performance). I thought he had found an issue with the previous commits and was suggesting a fix to the previous patches. Since he is trying to get this into -stable, disregard my statement about adding it to my tree. signature.asc Description: OpenPGP digital signature
[PATCH 3.0-stable] xhci: Avoid dead ports when CONFIG_USB_XHCI_HCD=n
If the user chooses to say no to CONFIG_USB_XHCI_HCD on a system
with an Intel Panther Point chipset, the PCI quirks code or the EHCI
driver will switch the ports over to the xHCI host, but the xHCI driver
will never load. The ports will be powered off and seem dead to the
user.
Fix this by only switching the ports over if CONFIG_USB_XHCI_HCD is
either compiled in, or compiled as a module.
This patch should be backported to the 3.0 stable kernel, since it
contains the commit 69e848c2090aebba5698a1620604c7dccb448684 Intel
xhci: Support EHCI/xHCI port switching.
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
Reported-by: Eric Anholt eric.anh...@intel.com
Reported-by: David Bein d.b...@f5.com
Cc: stable@vger.kernel.org
---
Hi Greg,
This patch should build against the 3.0-stable branch. Please queue it
for 3.0.
Thanks,
Sarah Sharp
drivers/usb/host/pci-quirks.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 0757b19..d0cf708 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -757,6 +757,7 @@ void usb_enable_xhci_ports(struct pci_dev *xhci_pdev)
{
u32 ports_available;
+#if defined(CONFIG_USB_XHCI_HCD) || defined(CONFIG_USB_XHCI_HCD_MODULE)
ports_available = 0x;
/* Write USB3_PSSEN, the USB 3.0 Port SuperSpeed Enable
* Register, to turn on SuperSpeed terminations for all
@@ -782,6 +783,20 @@ void usb_enable_xhci_ports(struct pci_dev *xhci_pdev)
ports_available);
dev_dbg(xhci_pdev-dev, USB 2.0 ports that are now switched over
to xHCI: 0x%x\n, ports_available);
+#else
+ /* Don't switchover the ports if the user hasn't compiled the xHCI
+* driver. Otherwise they will see dead USB ports that don't power
+* the devices.
+*/
+ if (!IS_ENABLED(CONFIG_USB_XHCI_HCD)) {
+ dev_warn(xhci_pdev-dev,
+ CONFIG_USB_XHCI_HCD is turned off,
+ defaulting to EHCI.\n);
+ dev_warn(xhci_pdev-dev,
+ USB 3.0 devices will work at USB 2.0
speeds.\n);
+ }
+#endif /* CONFIG_USB_XHCI_HCD || CONFIG_USB_XHCI_HCD_MODULE */
+
}
EXPORT_SYMBOL_GPL(usb_enable_xhci_ports);
--
1.7.9
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3.0-stable] xhci: Avoid dead ports when CONFIG_USB_XHCI_HCD=n
On Thu, Jun 07, 2012 at 03:49:11PM -0700, Sarah Sharp wrote: If the user chooses to say no to CONFIG_USB_XHCI_HCD on a system with an Intel Panther Point chipset, the PCI quirks code or the EHCI driver will switch the ports over to the xHCI host, but the xHCI driver will never load. The ports will be powered off and seem dead to the user. Fix this by only switching the ports over if CONFIG_USB_XHCI_HCD is either compiled in, or compiled as a module. This patch should be backported to the 3.0 stable kernel, since it contains the commit 69e848c2090aebba5698a1620604c7dccb448684 Intel xhci: Support EHCI/xHCI port switching. Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com Reported-by: Eric Anholt eric.anh...@intel.com Reported-by: David Bein d.b...@f5.com Cc: stable@vger.kernel.org --- Hi Greg, This patch should build against the 3.0-stable branch. Please queue it for 3.0. Hm, really? What patch is this in Linus's tree, 69e848c2090aebba5698a1620604c7dccb448684? If so, why not just use that one? Or is this a backported version of that commit? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: btree: fix tree corruption in btree_get_prev()
commit: cbf8ae32f66a9ceb8907ad9e16663c2a29e48990
From: Roland Dreier rol...@purestorage.com
Date: Thu, 7 Jun 2012 14:21:13 -0700
Subject: btree: fix tree corruption in btree_get_prev()
The memory the parameter __key points to is used as an iterator in
btree_get_prev(), so if we save off a bkey() pointer in retry_key and
then assign that to __key, we'll end up corrupting the btree internals
when we do eg
longcpy(__key, bkey(geo, node, i), geo-keylen);
to return the key value. What we should do instead is use longcpy() to
copy the key value that retry_key points to __key.
This can cause a btree to get corrupted by seemingly read-only
operations such as btree_for_each_safe.
[a...@linux-foundation.org: avoid the double longcpy()]
Signed-off-by: Roland Dreier rol...@purestorage.com
Acked-by: Joern Engel jo...@logfs.org
Cc: stable@vger.kernel.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
---
lib/btree.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/btree.c b/lib/btree.c
index e5ec1e9..5cf9e74 100644
--- a/lib/btree.c
+++ b/lib/btree.c
@@ -319,8 +319,8 @@ void *btree_get_prev(struct btree_head *head, struct
btree_geo *geo,
if (head-height == 0)
return NULL;
-retry:
longcpy(key, __key, geo-keylen);
+retry:
dec_key(geo, key);
node = head-node;
@@ -351,7 +351,7 @@ retry:
}
miss:
if (retry_key) {
- __key = retry_key;
+ longcpy(key, retry_key, geo-keylen);
retry_key = NULL;
goto retry;
}
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch Upstream: mm: correctly synchronize rss-counters at exit/exec
commit: 40af1bbdca47e5c8a2044039bb78ca8fd8b20f94
From: Konstantin Khlebnikov khlebni...@openvz.org
Date: Thu, 7 Jun 2012 14:21:14 -0700
Subject: mm: correctly synchronize rss-counters at exit/exec
mm-rss_stat counters have per-task delta: task-rss_stat. Before
changing task-mm pointer the kernel must flush this delta with
sync_mm_rss().
do_exit() already calls sync_mm_rss() to flush the rss-counters before
committing the rss statistics into task-signal-maxrss, taskstats,
audit and other stuff. Unfortunately the kernel does this before
calling mm_release(), which can call put_user() for processing
task-clear_child_tid. So at this point we can trigger page-faults and
task-rss_stat becomes non-zero again. As a result mm-rss_stat becomes
inconsistent and check_mm() will print something like this:
| BUG: Bad rss-counter state mm:88020813c380 idx:1 val:-1
| BUG: Bad rss-counter state mm:88020813c380 idx:2 val:1
This patch moves sync_mm_rss() into mm_release(), and moves mm_release()
out of do_exit() and calls it earlier. After mm_release() there should
be no pagefaults.
[a...@linux-foundation.org: tweak comment]
Signed-off-by: Konstantin Khlebnikov khlebni...@openvz.org
Reported-by: Markus Trippelsdorf mar...@trippelsdorf.de
Cc: Hugh Dickins hu...@google.com
Cc: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
Cc: Oleg Nesterov o...@redhat.com
Cc: stable@vger.kernel.org[3.4.x]
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
---
fs/exec.c |1 -
kernel/exit.c | 13 -
kernel/fork.c |8
3 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index a79786a..b926ed1 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -819,7 +819,6 @@ static int exec_mmap(struct mm_struct *mm)
/* Notify parent that we're no longer interested in the old VM */
tsk = current;
old_mm = current-mm;
- sync_mm_rss(old_mm);
mm_release(tsk, old_mm);
if (old_mm) {
diff --git a/kernel/exit.c b/kernel/exit.c
index 34867cc..804fb6b 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -423,6 +423,7 @@ void daemonize(const char *name, ...)
* user space pages. We don't need them, and if we didn't close them
* they would be locked into memory.
*/
+ mm_release(current, current-mm);
exit_mm(current);
/*
* We don't want to get frozen, in case system-wide hibernation
@@ -640,7 +641,6 @@ static void exit_mm(struct task_struct * tsk)
struct mm_struct *mm = tsk-mm;
struct core_state *core_state;
- mm_release(tsk, mm);
if (!mm)
return;
/*
@@ -960,9 +960,13 @@ void do_exit(long code)
preempt_count());
acct_update_integrals(tsk);
- /* sync mm's RSS info before statistics gathering */
- if (tsk-mm)
- sync_mm_rss(tsk-mm);
+
+ /* Set exit_code before complete_vfork_done() in mm_release() */
+ tsk-exit_code = code;
+
+ /* Release mm and sync mm's RSS info before statistics gathering */
+ mm_release(tsk, tsk-mm);
+
group_dead = atomic_dec_and_test(tsk-signal-live);
if (group_dead) {
hrtimer_cancel(tsk-signal-real_timer);
@@ -975,7 +979,6 @@ void do_exit(long code)
tty_audit_exit();
audit_free(tsk);
- tsk-exit_code = code;
taskstats_exit(tsk, group_dead);
exit_mm(tsk);
diff --git a/kernel/fork.c b/kernel/fork.c
index ab5211b..0560781 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -619,6 +619,14 @@ void mmput(struct mm_struct *mm)
module_put(mm-binfmt-module);
mmdrop(mm);
}
+
+ /*
+* Final rss-counter synchronization. After this point there must be
+* no pagefaults into this mm from the current context. Otherwise
+* mm-rss_stat will be inconsistent.
+*/
+ if (mm)
+ sync_mm_rss(mm);
}
EXPORT_SYMBOL_GPL(mmput);
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3.0-stable] xhci: Avoid dead ports when CONFIG_USB_XHCI_HCD=n
On Fri, Jun 08, 2012 at 07:55:21AM +0900, Greg Kroah-Hartman wrote: On Thu, Jun 07, 2012 at 03:49:11PM -0700, Sarah Sharp wrote: If the user chooses to say no to CONFIG_USB_XHCI_HCD on a system with an Intel Panther Point chipset, the PCI quirks code or the EHCI driver will switch the ports over to the xHCI host, but the xHCI driver will never load. The ports will be powered off and seem dead to the user. Fix this by only switching the ports over if CONFIG_USB_XHCI_HCD is either compiled in, or compiled as a module. This patch should be backported to the 3.0 stable kernel, since it contains the commit 69e848c2090aebba5698a1620604c7dccb448684 Intel xhci: Support EHCI/xHCI port switching. Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com Reported-by: Eric Anholt eric.anh...@intel.com Reported-by: David Bein d.b...@f5.com Cc: stable@vger.kernel.org --- Hi Greg, This patch should build against the 3.0-stable branch. Please queue it for 3.0. Hm, really? What patch is this in Linus's tree, 69e848c2090aebba5698a1620604c7dccb448684? This is a bug fix against the feature added in commit 69e848c. This bug fix is already in Linus' tree, see commit 51c9e6c7732b67769c0a514d31f505e49fa82dd4 xhci: Avoid dead ports when CONFIG_USB_XHCI_HCD=n If so, why not just use that one? Or is this a backported version of that commit? You sent me mail that commit 51c9e6c7732b67769c0a514d31f505e49fa82dd4 didn't compile against the 3.0 kernel, and you were dropping it from the 3.0 queue. So I tried to see why it didn't compile. The original commit doesn't compile against the 3.0 kernel sources because it uses the macro IS_ENABLED() from the header file linux/kconfig.h. That header file wasn't added until the 3.1 kernel, with commit 2a11c8ea20bf850b3a2c60db8c2e7497d28aba99 kconfig: Introduce IS_ENABLED(), IS_BUILTIN() and IS_MODULE(). This version of the patch reworks the code to use the old style of checking for kernel modules: +#if defined(CONFIG_USB_XHCI_HCD) || defined(CONFIG_USB_XHCI_HCD_MODULE) instead of the new style introduced in linux/kconfig.h: if (IS_ENABLED(CONFIG_USB_XHCI_HCD)) So please accept this patch in lieu of just adding commit 51c9e6c7732b67769c0a514d31f505e49fa82dd4 to the 3.0 stable tree. Sarah Sharp -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 12/12] mm: correctly synchronize rss-counters at exit/exec
This patch actually seems to have made the
BUG: Bad rss-counter state ..
problem *much* worse. It triggers all the time for me now - I've got
408 of those messages on my macbook air within a minute of booting it.
Not good. Especially not good when it's marked for stable too.
Linus
On Thu, Jun 7, 2012 at 2:21 PM, a...@linux-foundation.org wrote:
From: Konstantin Khlebnikov khlebni...@openvz.org
Subject: mm: correctly synchronize rss-counters at exit/exec
mm-rss_stat counters have per-task delta: task-rss_stat. Before
changing task-mm pointer the kernel must flush this delta with
sync_mm_rss().
do_exit() already calls sync_mm_rss() to flush the rss-counters before
committing the rss statistics into task-signal-maxrss, taskstats, audit
and other stuff. Unfortunately the kernel does this before calling
mm_release(), which can call put_user() for processing
task-clear_child_tid. So at this point we can trigger page-faults and
task-rss_stat becomes non-zero again. As a result mm-rss_stat becomes
inconsistent and check_mm() will print something like this:
| BUG: Bad rss-counter state mm:88020813c380 idx:1 val:-1
| BUG: Bad rss-counter state mm:88020813c380 idx:2 val:1
This patch moves sync_mm_rss() into mm_release(), and moves mm_release()
out of do_exit() and calls it earlier. After mm_release() there should be
no pagefaults.
[a...@linux-foundation.org: tweak comment]
Signed-off-by: Konstantin Khlebnikov khlebni...@openvz.org
Reported-by: Markus Trippelsdorf mar...@trippelsdorf.de
Cc: Hugh Dickins hu...@google.com
Cc: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
Cc: Oleg Nesterov o...@redhat.com
Cc: stable@vger.kernel.org [3.4.x]
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
fs/exec.c | 1 -
kernel/exit.c | 13 -
kernel/fork.c | 8
3 files changed, 16 insertions(+), 6 deletions(-)
diff -puN fs/exec.c~mm-correctly-synchronize-rss-counters-at-exit-exec
fs/exec.c
--- a/fs/exec.c~mm-correctly-synchronize-rss-counters-at-exit-exec
+++ a/fs/exec.c
@@ -819,7 +819,6 @@ static int exec_mmap(struct mm_struct *m
/* Notify parent that we're no longer interested in the old VM */
tsk = current;
old_mm = current-mm;
- sync_mm_rss(old_mm);
mm_release(tsk, old_mm);
if (old_mm) {
diff -puN kernel/exit.c~mm-correctly-synchronize-rss-counters-at-exit-exec
kernel/exit.c
--- a/kernel/exit.c~mm-correctly-synchronize-rss-counters-at-exit-exec
+++ a/kernel/exit.c
@@ -423,6 +423,7 @@ void daemonize(const char *name, ...)
* user space pages. We don't need them, and if we didn't close them
* they would be locked into memory.
*/
+ mm_release(current, current-mm);
exit_mm(current);
/*
* We don't want to get frozen, in case system-wide hibernation
@@ -640,7 +641,6 @@ static void exit_mm(struct task_struct *
struct mm_struct *mm = tsk-mm;
struct core_state *core_state;
- mm_release(tsk, mm);
if (!mm)
return;
/*
@@ -960,9 +960,13 @@ void do_exit(long code)
preempt_count());
acct_update_integrals(tsk);
- /* sync mm's RSS info before statistics gathering */
- if (tsk-mm)
- sync_mm_rss(tsk-mm);
+
+ /* Set exit_code before complete_vfork_done() in mm_release() */
+ tsk-exit_code = code;
+
+ /* Release mm and sync mm's RSS info before statistics gathering */
+ mm_release(tsk, tsk-mm);
+
group_dead = atomic_dec_and_test(tsk-signal-live);
if (group_dead) {
hrtimer_cancel(tsk-signal-real_timer);
@@ -975,7 +979,6 @@ void do_exit(long code)
tty_audit_exit();
audit_free(tsk);
- tsk-exit_code = code;
taskstats_exit(tsk, group_dead);
exit_mm(tsk);
diff -puN kernel/fork.c~mm-correctly-synchronize-rss-counters-at-exit-exec
kernel/fork.c
--- a/kernel/fork.c~mm-correctly-synchronize-rss-counters-at-exit-exec
+++ a/kernel/fork.c
@@ -619,6 +619,14 @@ void mmput(struct mm_struct *mm)
module_put(mm-binfmt-module);
mmdrop(mm);
}
+
+ /*
+ * Final rss-counter synchronization. After this point there must be
+ * no pagefaults into this mm from the current context. Otherwise
+ * mm-rss_stat will be inconsistent.
+ */
+ if (mm)
+ sync_mm_rss(mm);
}
EXPORT_SYMBOL_GPL(mmput);
_
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 12/12] mm: correctly synchronize rss-counters at exit/exec
Ugh, looking more at the patch, I'm getting more and more convinces that it is pure and utter garbage. It does sync_mm_rss(mm); in mmput(), _after_ it has done the possibly final mmdrop(). WTF? This is crap, guys. Seriously. Stop playing russian rulette with this code. I think we need to revert *all* of the crazy rss games, unless Konstantin can show us some truly obviously correct fix. Sadly, I merged and pushed out the crap before I had rebooted and noticed this problem, so now it's in the wild. Can somebody please take a look at this asap? Linus On Thu, Jun 7, 2012 at 5:17 PM, Linus Torvalds torva...@linux-foundation.org wrote: This patch actually seems to have made the BUG: Bad rss-counter state .. problem *much* worse. It triggers all the time for me now - I've got 408 of those messages on my macbook air within a minute of booting it. Not good. Especially not good when it's marked for stable too. -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 12/12] mm: correctly synchronize rss-counters at exit/exec
On 2012.06.07 at 17:25 -0700, Linus Torvalds wrote: Ugh, looking more at the patch, I'm getting more and more convinces that it is pure and utter garbage. It does sync_mm_rss(mm); in mmput(), _after_ it has done the possibly final mmdrop(). WTF? This is crap, guys. Seriously. Stop playing russian rulette with this code. I think we need to revert *all* of the crazy rss games, unless Konstantin can show us some truly obviously correct fix. Sadly, I merged and pushed out the crap before I had rebooted and noticed this problem, so now it's in the wild. Can somebody please take a look at this asap? You've somehow merged the wrong patch. The correct version can be found here: http://marc.info/?l=linux-kernelm=133848759505805 -- Markus -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 12/12] mm: correctly synchronize rss-counters at exit/exec
On Thu, 7 Jun 2012, Linus Torvalds wrote:
Ugh, looking more at the patch, I'm getting more and more convinces
that it is pure and utter garbage.
It does sync_mm_rss(mm); in mmput(), _after_ it has done the
possibly final mmdrop(). WTF?
This is crap, guys. Seriously. Stop playing russian rulette with this
code. I think we need to revert *all* of the crazy rss games, unless
Konstantin can show us some truly obviously correct fix.
Sadly, I merged and pushed out the crap before I had rebooted and
noticed this problem, so now it's in the wild. Can somebody please
take a look at this asap?
Linus
On Thu, Jun 7, 2012 at 5:17 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
This patch actually seems to have made the
BUG: Bad rss-counter state ..
problem *much* worse. It triggers all the time for me now - I've got
408 of those messages on my macbook air within a minute of booting it.
Not good. Especially not good when it's marked for stable too.
I'm on the Cc, but I've not been following closely, I've not been able
to reproduce the issue with Konstantin's commit in just now, and I've
not even tried Oleg's version: so, don't trust me an inch.
But I was surprised that that patch went to you, I thought Konstantin
and Oleg had just reached agreement that Oleg's version (reposted this
morning in the 3.4-rc7: BUG: Bad rss-counter state thread) was nicer.
And it looks like it does not do anything offensive in mmput().
Doing things after something called mm_release sounds equally
bad, but IIRC that's not so.
You probably want to revert Konstantin's, try out Oleg's on your Air,
and maybe wait for Konstantin and Oleg to confirm the below.
Offline for a few hours,
Hugh
[PATCH] correctly synchronize rss-counters at exit/exec
From: Oleg Nesterov o...@redhat.com
A simplified version of Konstantin Khlebnikov's patch.
do_exit() and exec_mmap() call sync_mm_rss() before mm_release()
does put_user(clear_child_tid) which can update task-rss_stat
and thus make mm-rss_stat inconsistent. This triggers the BUG:
printk in check_mm().
- Move the final sync_mm_rss() from do_exit() to exit_mm(), and
change exec_mmap() to call sync_mm_rss() after mm_release() to
make check_mm() happy.
Perhaps we should simply move it into mm_release() and call it
unconditionally to catch the task-rss_stat != 0 !task-mm
bugs.
- Since taskstats_exit() is called before exit_mm(), add another
sync_mm_rss() into xacct_add_tsk() who actually uses rss_stat.
Probably we should also shift acct_update_integrals().
Reported-by: Markus Trippelsdorf mar...@trippelsdorf.de
Tested-by: Martin Mokrejs mmokr...@fold.natur.cuni.cz
Signed-off-by: Oleg Nesterov o...@redhat.com
Acked-by: Konstantin Khlebnikov khlebni...@openvz.org
---
fs/exec.c |2 +-
kernel/exit.c |5 ++---
kernel/tsacct.c |1 +
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index 52c9e2f..e49e3c2 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -823,10 +823,10 @@ static int exec_mmap(struct mm_struct *mm)
/* Notify parent that we're no longer interested in the old VM */
tsk = current;
old_mm = current-mm;
- sync_mm_rss(old_mm);
mm_release(tsk, old_mm);
if (old_mm) {
+ sync_mm_rss(old_mm);
/*
* Make sure that if there is a core dump in progress
* for the old mm, we get out and die instead of going
diff --git a/kernel/exit.c b/kernel/exit.c
index ab972a7..b3a84b5 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -655,6 +655,8 @@ static void exit_mm(struct task_struct * tsk)
mm_release(tsk, mm);
if (!mm)
return;
+
+ sync_mm_rss(mm);
/*
* Serialize with any possible pending coredump.
* We must hold mmap_sem around checking core_state
@@ -965,9 +967,6 @@ void do_exit(long code)
preempt_count());
acct_update_integrals(tsk);
- /* sync mm's RSS info before statistics gathering */
- if (tsk-mm)
- sync_mm_rss(tsk-mm);
group_dead = atomic_dec_and_test(tsk-signal-live);
if (group_dead) {
hrtimer_cancel(tsk-signal-real_timer);
diff --git a/kernel/tsacct.c b/kernel/tsacct.c
index 23b4d78..a64ee90 100644
--- a/kernel/tsacct.c
+++ b/kernel/tsacct.c
@@ -91,6 +91,7 @@ void xacct_add_tsk(struct taskstats *stats, struct
task_struct *p)
stats-virtmem = p-acct_vm_mem1 * PAGE_SIZE / MB;
mm = get_task_mm(p);
if (mm) {
+ sync_mm_rss(mm);
/* adjust to KB unit */
stats-hiwater_rss = get_mm_hiwater_rss(mm) * PAGE_SIZE / KB;
stats-hiwater_vm= get_mm_hiwater_vm(mm) * PAGE_SIZE / KB;
--
1.5.5.1
Re: [patch 12/12] mm: correctly synchronize rss-counters at exit/exec
On Thu, Jun 7, 2012 at 6:05 PM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: You've somehow merged the wrong patch. The correct version can be found here: http://marc.info/?l=linux-kernelm=133848759505805 It looks like Andrew sent me a bad version. However, that patch you point at isn't good *either*. It does totally insane things in xacct_add_tsk(). You can't call sync_mm_rss(mm) on somebody elses mm, yet that is exactly what it does (and you can't pass in another thread pointer either, since the whole point of the per-thread counters is that they don't have locking and aren't atomic, so you can't read them from any other context than current). The thing is, the *only* point where it makes sense to sync the rss pointers is when you detach the mm from the current thread. And possibly at fork() time, *before* you duplicate the struct task_struct and pollute the new one with stale rss counter values from the old one. So doing sync_mm_rss() in xacct_add_tsk() is crazy. Doing it *anywhere* where mm is not clearly current-mm is wrong. If there is a get_task_mm() or similar nearby, it's wrong, it's crap, and it shouldn't be done. Oleg, please rescue me? Your patch looks much closer to sane, but it's not quite there.. Linus -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 12/12] mm: correctly synchronize rss-counters at exit/exec
No, this is apparently that same almost there patch from Oleg. I
guarantee that it's wrong.
Linus
---
[ This part, to be exact: ]
On Thu, Jun 7, 2012 at 6:16 PM, Hugh Dickins hu...@google.com wrote:
--- a/kernel/tsacct.c
+++ b/kernel/tsacct.c
@@ -91,6 +91,7 @@ void xacct_add_tsk(struct taskstats *stats, struct
task_struct *p)
stats-virtmem = p-acct_vm_mem1 * PAGE_SIZE / MB;
mm = get_task_mm(p);
if (mm) {
+ sync_mm_rss(mm);
/* adjust to KB unit */
stats-hiwater_rss = get_mm_hiwater_rss(mm) * PAGE_SIZE / KB;
stats-hiwater_vm = get_mm_hiwater_vm(mm) * PAGE_SIZE / KB;
--
1.5.5.1
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] xhci: Don't free endpoints in xhci_mem_cleanup()
On Fri, Jun 01, 2012 at 10:06:24AM +0200, Takashi Iwai wrote:
This patch fixes a few issues introduced in the recent fix
[f8a9e72d: USB: fix resource leak in xhci power loss path]
- The endpoints listed in bw table are just links and each entry is an
array member of dev-eps[]. But the commit above adds a kfree() call
to these instances, and thus it results in memory corruption.
I tested your patch, hoping it would fix some warnings I had seen when
the xHCI driver was unloaded, but it didn't help. I still think this
patch is correct, but we're still leaking some memory from the xHCI
driver.
When I plug in a multi-TT USB 2.0 hub, and then unload the xHCI driver,
I get the warning Slot 2 endpoint 2 not removed from BW list!:
Jun 7 17:31:08 maggie kernel: [ 218.431583] usb usb1: USB disconnect, device
number 1
Jun 7 17:31:08 maggie kernel: [ 218.431585] usb 1-2: USB disconnect, device
number 3
Jun 7 17:31:08 maggie kernel: [ 218.431587] usb 1-2: unregistering device
Jun 7 17:31:08 maggie kernel: [ 218.431588] usb 1-2: unregistering interface
1-2:1.0
Jun 7 17:31:08 maggie kernel: [ 218.432118] usb 1-2: usb_disable_device
nuking all URBs
Jun 7 17:31:08 maggie kernel: [ 218.433030] xhci_hcd :00:14.0: Slot 2
endpoint 2 not removed from BW list!
Jun 7 17:31:08 maggie kernel: [ 218.433106] usb usb1: unregistering device
Jun 7 17:31:08 maggie kernel: [ 218.433109] usb usb1: unregistering interface
1-0:1.0
Jun 7 17:31:08 maggie kernel: [ 218.433594] usb usb1: usb_disable_device
nuking all URBs
Jun 7 17:31:08 maggie kernel: [ 218.433598] xHCI xhci_drop_endpoint called
for root hub
Jun 7 17:31:08 maggie kernel: [ 218.433600] xHCI xhci_check_bandwidth called
for root hub
Jun 7 17:31:08 maggie kernel: [ 218.434216] xhci_hcd :00:14.0: // Halt
the HC
That warning comes from this code in xhci-mem.c:xhci_free_virt_device():
for (i = 0; i 31; ++i) {
if (dev-eps[i].ring)
xhci_ring_free(xhci, dev-eps[i].ring);
if (dev-eps[i].stream_info)
xhci_free_stream_info(xhci,
dev-eps[i].stream_info);
/* Endpoints on the TT/root port lists should have been removed
* when usb_disable_device() was called for the device.
* We can't drop them anyway, because the udev might have gone
* away by this point, and we can't tell what speed it was.
*/
if (!list_empty(dev-eps[i].bw_endpoint_list))
xhci_warn(xhci, Slot %u endpoint %u
not removed from BW list!\n,
slot_id, i);
Even though the endpoint bandwidth list head should be removed later in
xhci_mem_cleanup(), I wondered why it wouldn't have been removed by the
USB in usb_disable_device(). That's the way it's supposed to work:
when a USB device is disconnected, we free any resources associated with
its endpoints by calling xhci_drop_endpoint() and
xhci_check_bandwidth().
Long story short, all xHCI functions check whether the xHC is halted
before issuing any commands. When the xHCI driver is unloaded, the USB
core first disables the USB 3.0 roothub portion of the xHCI host, and
then disables the USB 2.0 roothub portion. When it's called with the
USB 3.0 roothub, xhci_stop() will halt the xHCI host controller and
return. The driver will get cleaned up when xhci_stop() is called with
the USB 2.0 roothub later.
After the SS roothub is disabled, but the HS roothub is still enabled,
the USB core comes and tries to clean up all connected USB 2.0 devices.
This includes calling usb_disable_device(). Howevrer,
xhci_check_bandwidth() will return immediately because the xHCI host is
halted, and we will leak memory resources.
That's why resources weren't being deallocated when the driver was
unloaded. This is sort of a separate issue, so I'll still accept your
patch, and send a second patch to fix the driver unload issue.
Sarah Sharp
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IA64: Export asm/cmpxchg.h to userland
On Thu, Jun 07, 2012 at 09:07:13PM +0100, Ben Hutchings wrote:
On Thu, Jun 07, 2012 at 04:54:56PM +, Luck, Tony wrote:
Parts of asm/intrinsics.h were moved to asm/cmpxchg.h, and the
former now includes the latter. The former is exported to userland
so the latter must be too.
Already received and applied a patch that does this (though it added
the cmpxchg.h a few lines earlier that you did).
See commit: 98e4cff73
It didn't get marked for stable though ... so if you need this to
get pulled into the stable branches you'll need to poke Greg etc.
manually.
Greg, please cherry-pick commit
85f8f7759e418c814ee2ceacf73eddb9bed39492 ('[IA64] Add cmpxchg.h to
exported userspace headers') for 3.4.y.
I tried, but it doesn't apply properly. Can someone backport it and
send it to me?
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IA64: Export asm/cmpxchg.h to userland
On Fri, 2012-06-08 at 10:43 +0900, Greg Kroah-Hartman wrote:
On Thu, Jun 07, 2012 at 09:07:13PM +0100, Ben Hutchings wrote:
On Thu, Jun 07, 2012 at 04:54:56PM +, Luck, Tony wrote:
Parts of asm/intrinsics.h were moved to asm/cmpxchg.h, and the
former now includes the latter. The former is exported to userland
so the latter must be too.
Already received and applied a patch that does this (though it added
the cmpxchg.h a few lines earlier that you did).
See commit: 98e4cff73
It didn't get marked for stable though ... so if you need this to
get pulled into the stable branches you'll need to poke Greg etc.
manually.
Greg, please cherry-pick commit
85f8f7759e418c814ee2ceacf73eddb9bed39492 ('[IA64] Add cmpxchg.h to
exported userspace headers') for 3.4.y.
I tried, but it doesn't apply properly. Can someone backport it and
send it to me?
Sorry, I mean 98e4cff73a18af27f0d40d0b0d37f105dfc1994a; the former
commit is already in 3.4 and resulted in this breakage.
Ben.
--
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] e1000: save skb counts in TX to avoid cache misses
On Thu, Jun 07, 2012 at 02:43:58PM -0700, David Miller wrote: From: Jeff Kirsher tar...@gmail.com Date: Thu, 07 Jun 2012 14:38:17 -0700 Thanks! I have applied the patch to my queue Why? My impression is that this is a patch already in the tree, and it's being submitted for -stable but such minor performance hacks are absolutely not appropriate for -stable submission. The patch description says it is fixing reported oopses, but the Subject: isn't all that helpful there. So which is this? Should I accept it for a stable release or not? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ 53/82] asix: allow full size 8021Q frames to be received
On Thu, 2012-06-07 at 13:04 +0900, Greg KH wrote:
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet eduma...@google.com
[ Upstream commit 9dae31009b1a00d926c6fe032d5a88099620adc3 ]
asix driver drops 8021Q full size frames because it doesn't take into
account VLAN header size.
Tested on AX88772 adapter.
[...]
This should presumably go into earlier stable versions as well
(specifically requested for 3.2 in http://bugs.debian.org/676545).
Does the attached backport look reasonable?
Ben.
--
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.
From: Eric Dumazet eduma...@google.com
Date: Mon, 28 May 2012 22:31:41 +
Subject: asix: allow full size 8021Q frames to be received
commit 9dae31009b1a00d926c6fe032d5a88099620adc3 upstream.
asix driver drops 8021Q full size frames because it doesn't take into
account VLAN header size.
Tested on AX88772 adapter.
Signed-off-by: Eric Dumazet eduma...@google.com
CC: Greg Kroah-Hartman gre...@linuxfoundation.org
CC: Allan Chou al...@asix.com.tw
CC: Trond Wuellner tr...@chromium.org
CC: Grant Grundler grund...@chromium.org
CC: Paul Stewart ps...@chromium.org
Signed-off-by: David S. Miller da...@davemloft.net
[bwh: Backported to 3.2: no offset used in asix_rx_fixup()]
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
--- a/drivers/net/usb/asix.c
+++ b/drivers/net/usb/asix.c
@@ -35,6 +35,7 @@
#include linux/crc32.h
#include linux/usb/usbnet.h
#include linux/slab.h
+#include linux/if_vlan.h
#define DRIVER_VERSION 08-Nov-2011
#define DRIVER_NAME asix
@@ -348,7 +349,7 @@
return 2;
}
- if (size dev-net-mtu + ETH_HLEN) {
+ if (size dev-net-mtu + ETH_HLEN + VLAN_HLEN) {
netdev_err(dev-net, asix_rx_fixup() Bad RX Length %d\n,
size);
return 0;
signature.asc
Description: This is a digitally signed message part
Re: [ 64/82] ext4: dont trash state flags in EXT4_IOC_SETFLAGS
On Thu, 2012-06-07 at 13:04 +0900, Greg KH wrote:
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Theodore Ts'o ty...@mit.edu
commit 79906964a187c405db72a3abc60eb9b50d804fbc upstream.
In commit 353eb83c we removed i_state_flags with 64-bit longs, But
when handling the EXT4_IOC_SETFLAGS ioctl, we replace i_flags
directly, which trashes the state flags which are stored in the high
32-bits of i_flags on 64-bit platforms. So use the the
ext4_{set,clear}_inode_flags() functions which use atomic bit
manipulation functions instead.
[...]
@@ -115,8 +115,14 @@ long ext4_ioctl(struct file *filp, unsig
if (err)
goto flags_err;
- flags = flags EXT4_FL_USER_MODIFIABLE;
- flags |= oldflags ~EXT4_FL_USER_MODIFIABLE;
+ for (i = 0, mask = 1; i 32; i++, mask = 1) {
+ if (!(mask EXT4_FL_USER_MODIFIABLE))
+ continue;
+ if (mask flags)
+ ext4_set_inode_flag(inode, i);
+ else
+ ext4_clear_inode_flag(inode, i);
+ }
ei-i_flags = flags;
[...]
Shouldn't this last assignment have been deleted?
Ben.
--
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.
signature.asc
Description: This is a digitally signed message part
Re: [ 64/82] ext4: dont trash state flags in EXT4_IOC_SETFLAGS
On Fri, Jun 08, 2012 at 04:03:09AM +0100, Ben Hutchings wrote:
ei-i_flags = flags;
[...]
Shouldn't this last assignment have been deleted?
Yes, I'm testing two patches to push to Linus. One of them deletes
the last assignment.
The testing cycle should be over by tomorrow morning; in the mean
time, this commit is harmless in its current form (although it won't
fix the problem it was intending to fix until we delete the last
line).
- Ted
commit b22b1f178f6799278d3178d894f37facb2085765
Author: Tao Ma boyu...@taobao.com
Date: Thu Jun 7 19:04:19 2012 -0400
ext4: don't set i_flags in EXT4_IOC_SETFLAGS
Commit 7990696 uses the ext4_{set,clear}_inode_flags() functions to
change the i_flags automatically but fails to remove the error setting
of i_flags. So we still have the problem of trashing state flags.
Fix this by removing the assignment.
Signed-off-by: Tao Ma boyu...@taobao.com
Signed-off-by: Theodore Ts'o ty...@mit.edu
Cc: sta...@kernel.org
diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
index 8ad112a..e34deac 100644
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -123,7 +123,6 @@ long ext4_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
else
ext4_clear_inode_flag(inode, i);
}
- ei-i_flags = flags;
ext4_set_inode_flags(inode);
inode-i_ctime = ext4_current_time(inode);
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ 64/82] ext4: dont trash state flags in EXT4_IOC_SETFLAGS
On Thu, 2012-06-07 at 23:11 -0400, Ted Ts'o wrote: On Fri, Jun 08, 2012 at 04:03:09AM +0100, Ben Hutchings wrote: ei-i_flags = flags; [...] Shouldn't this last assignment have been deleted? Yes, I'm testing two patches to push to Linus. One of them deletes the last assignment. The testing cycle should be over by tomorrow morning; in the mean time, this commit is harmless in its current form (although it won't fix the problem it was intending to fix until we delete the last line). [...] It's not harmless because the user is no longer restricted to changing EXT4_FL_USER_MODIFIABLE. Ben. -- Ben Hutchings I haven't lost my mind; it's backed up on tape somewhere. signature.asc Description: This is a digitally signed message part
Re: [ 53/82] asix: allow full size 8021Q frames to be received
From: Ben Hutchings b...@decadent.org.uk Date: Fri, 08 Jun 2012 03:27:52 +0100 On Thu, 2012-06-07 at 13:04 +0900, Greg KH wrote: 3.4-stable review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet eduma...@google.com [ Upstream commit 9dae31009b1a00d926c6fe032d5a88099620adc3 ] asix driver drops 8021Q full size frames because it doesn't take into account VLAN header size. Tested on AX88772 adapter. [...] This should presumably go into earlier stable versions as well (specifically requested for 3.2 in http://bugs.debian.org/676545). Does the attached backport look reasonable? Yes, thanks Ben. -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 00/82] 3.2.20-stable review
This is the start of the stable review cycle for the 3.2.20 release. There are 82 patches in this series, which will be posted as responses to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Jun 10 13:00:00 UTC 2012. Anything received after that time might be too late. A combined patch relative to 3.2.19 will be posted as an additional response to this, and the diffstat can be found below. Ben. - Makefile |4 +- arch/arm/Kconfig |2 +- arch/arm/mach-ixp4xx/common.c | 48 - arch/arm/mach-ixp4xx/include/mach/gpio.h | 79 + arch/microblaze/Kconfig |2 +- arch/mips/include/asm/mach-bcm63xx/bcm63xx_gpio.h |1 + arch/parisc/kernel/entry.S| 30 arch/parisc/kernel/vmlinux.lds.S |6 +- arch/x86/xen/enlighten.c |3 + drivers/acpi/battery.c| 10 ++- drivers/atm/solos-pci.c |4 +- drivers/bluetooth/ath3k.c | 10 +++ drivers/bluetooth/btusb.c | 14 +++- drivers/gpu/drm/i915/i915_reg.h |6 +- drivers/gpu/drm/i915/intel_display.c |4 +- drivers/gpu/drm/i915/intel_dp.c | 17 +++-- drivers/gpu/drm/i915/intel_lvds.c | 32 + drivers/gpu/drm/i915/intel_sdvo.c | 12 ++-- drivers/gpu/drm/i915/intel_sdvo_regs.h|5 ++ drivers/gpu/drm/i915/intel_tv.c |5 ++ drivers/gpu/drm/radeon/evergreen.c| 18 +++-- drivers/gpu/drm/radeon/evergreend.h |1 + drivers/gpu/drm/radeon/ni.c |6 +- drivers/gpu/drm/radeon/radeon_atombios.c |4 +- drivers/gpu/drm/radeon/rv770.c| 10 ++- drivers/gpu/drm/radeon/rv770d.h |1 + drivers/gpu/drm/ttm/ttm_bo.c |1 + drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c |2 +- drivers/iommu/amd_iommu.c | 29 ++-- drivers/iommu/amd_iommu_init.c| 13 ++-- drivers/iommu/amd_iommu_types.h |3 + drivers/mtd/Kconfig |2 +- drivers/mtd/nand/nand_bbt.c |1 + drivers/net/ethernet/freescale/fec_mpc52xx.c |2 +- drivers/net/ethernet/realtek/r8169.c | 39 +++--- drivers/net/macvlan.c |2 +- drivers/net/usb/asix.c|3 +- drivers/net/wireless/ath/ath9k/xmit.c | 16 +++-- drivers/net/wireless/iwlwifi/iwl-2000.c |4 +- drivers/net/wireless/iwlwifi/iwl-6000.c |6 +- drivers/net/wireless/iwlwifi/iwl-agn-rs.c |1 + drivers/net/wireless/wl1251/sdio.c|2 +- drivers/net/wireless/wl1251/spi.c |3 +- drivers/scsi/scsi_lib.c | 11 +-- drivers/scsi/scsi_wait_scan.c |2 +- drivers/target/target_core_file.c | 78 +--- drivers/target/target_core_file.h |1 - fs/attr.c |5 ++ fs/cifs/cifsglob.h|1 + fs/cifs/cifsproto.h |6 +- fs/cifs/cifssmb.c | 12 ++-- fs/cifs/file.c| 57 --- fs/cifs/readdir.c | 15 +++- fs/exofs/super.c |2 +- fs/ext4/mballoc.c |6 +- fs/ext4/namei.c |6 ++ fs/ext4/super.c |4 +- fs/namespace.c|3 +- fs/nfs/nfs4proc.c |2 + include/drm/drm_pciids.h |4 ++ include/linux/Kbuild |1 + include/linux/kernel-page-flags.h |4 ++ include/linux/netdevice.h |9 --- include/linux/netfilter_bridge.h |9 +++ include/linux/skbuff.h|2 - include/net/dst.h |2 + include/net/sctp/sctp.h | 13 kernel/fork.c |3 +- lib/btree.c |4 +- mm/hugetlb.c | 29 ++-- mm/slub.c |9 ++- mm/vmalloc.c | 11 +-- mm/vmscan.c
[ 41/82] vfs: umount_tree() might be called on subtree that had never made it
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Al Viro v...@zeniv.linux.org.uk
commit 63d37a84ab6004c235314ffd7a76c5eb28c2fae0 upstream.
__mnt_make_shortterm() in there undoes the effect of __mnt_make_longterm()
we'd done back when we set -mnt_ns non-NULL; it should not be done to
vfsmounts that had never gone through commit_tree() and friends. Kudos to
lczerner for catching that one...
Signed-off-by: Al Viro v...@zeniv.linux.org.uk
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
fs/namespace.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1244,8 +1244,9 @@
list_del_init(p-mnt_expire);
list_del_init(p-mnt_list);
__touch_mnt_namespace(p-mnt_ns);
+ if (p-mnt_ns)
+ __mnt_make_shortterm(p);
p-mnt_ns = NULL;
- __mnt_make_shortterm(p);
list_del_init(p-mnt_child);
if (p-mnt_parent != p) {
p-mnt_parent-mnt_ghosts++;
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 05/82] exofs: Fix CRASH on very early IO errors.
3.2-stable review patch. If anyone has any objections, please let me know. -- From: Boaz Harrosh bharr...@panasas.com commit 6abe4a87f7bc7978705c386dbba0ca0c7790b3ec upstream. If at exofs_fill_super() we had an early termination do to any error, like an IO error while reading the super-block. We would crash inside exofs_free_sbi(). This is because sbi-oc.numdevs was set to 1, before we actually have a device table at all. Fix it by moving the sbi-oc.numdevs = 1 to after the allocation of the device table. Reported-by: Johannes Schild jsch...@gmx.de Stable: This is a bug since v3.2.0 Signed-off-by: Boaz Harrosh bharr...@panasas.com Signed-off-by: Ben Hutchings b...@decadent.org.uk --- fs/exofs/super.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/exofs/super.c b/fs/exofs/super.c index 735ca06..59e0849 100644 --- a/fs/exofs/super.c +++ b/fs/exofs/super.c @@ -745,7 +745,6 @@ static int exofs_fill_super(struct super_block *sb, void *data, int silent) sbi-one_comp.obj.partition = opts-pid; sbi-one_comp.obj.id = 0; exofs_make_credential(sbi-one_comp.cred, sbi-one_comp.obj); - sbi-oc.numdevs = 1; sbi-oc.single_comp = EC_SINGLE_COMP; sbi-oc.comps = sbi-one_comp; @@ -804,6 +803,7 @@ static int exofs_fill_super(struct super_block *sb, void *data, int silent) goto free_sbi; ore_comp_set_dev(sbi-oc, 0, od); + sbi-oc.numdevs = 1; } __sbi_read_stats(sbi); -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 30/82] hugetlb: fix resv_map leak in error path
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Dave Hansen d...@linux.vnet.ibm.com
commit c50ac050811d6485616a193eb0f37bfbd191cc89 upstream.
When called for anonymous (non-shared) mappings, hugetlb_reserve_pages()
does a resv_map_alloc(). It depends on code in hugetlbfs's
vm_ops-close() to release that allocation.
However, in the mmap() failure path, we do a plain unmap_region() without
the remove_vma() which actually calls vm_ops-close().
This is a decent fix. This leak could get reintroduced if new code (say,
after hugetlb_reserve_pages() in hugetlbfs_file_mmap()) decides to return
an error. But, I think it would have to unroll the reservation anyway.
Christoph's test case:
http://marc.info/?l=linux-mmm=133728900729735
Signed-off-by: Dave Hansen d...@linux.vnet.ibm.com
[Christoph Lameter: I have rediffed the patch against 2.6.32 and 3.2.0.]
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
mm/hugetlb.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2068,6 +2068,15 @@
kref_get(reservations-refs);
}
+static void resv_map_put(struct vm_area_struct *vma)
+{
+ struct resv_map *reservations = vma_resv_map(vma);
+
+ if (!reservations)
+ return;
+ kref_put(reservations-refs, resv_map_release);
+}
+
static void hugetlb_vm_op_close(struct vm_area_struct *vma)
{
struct hstate *h = hstate_vma(vma);
@@ -2083,7 +2092,7 @@
reserve = (end - start) -
region_count(reservations-regions, start, end);
- kref_put(reservations-refs, resv_map_release);
+ resv_map_put(vma);
if (reserve) {
hugetlb_acct_memory(h, -reserve);
@@ -2884,12 +2893,16 @@
set_vma_resv_flags(vma, HPAGE_RESV_OWNER);
}
- if (chg 0)
- return chg;
+ if (chg 0) {
+ ret = chg;
+ goto out_err;
+ }
/* There must be enough filesystem quota for the mapping */
- if (hugetlb_get_quota(inode-i_mapping, chg))
- return -ENOSPC;
+ if (hugetlb_get_quota(inode-i_mapping, chg)) {
+ ret = -ENOSPC;
+ goto out_err;
+ }
/*
* Check enough hugepages are available for the reservation.
@@ -2898,7 +2911,7 @@
ret = hugetlb_acct_memory(h, chg);
if (ret 0) {
hugetlb_put_quota(inode-i_mapping, chg);
- return ret;
+ goto out_err;
}
/*
@@ -2915,6 +2928,9 @@
if (!vma || vma-vm_flags VM_MAYSHARE)
region_add(inode-i_mapping-private_list, from, to);
return 0;
+out_err:
+ resv_map_put(vma);
+ return ret;
}
void hugetlb_unreserve_pages(struct inode *inode, long offset, long freed)
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 03/82] cifs: Include backup intent search flags during searches {try #2)
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Shirish Pargaonkar shirishpargaon...@gmail.com
commit 2608bee744a92d60d15ff4e6e0b913d8b406aedd upstream.
As observed and suggested by Tushar Gosavi...
-
readdir calls these function to send TRANS2_FIND_FIRST and
TRANS2_FIND_NEXT command to the server. The current cifs module is
not specifying CIFS_SEARCH_BACKUP_SEARCH flag while sending these
command when backupuid/backupgid is specified. This can be resolved
by specifying CIFS_SEARCH_BACKUP_SEARCH flag.
-
Reported-and-Tested-by: Tushar Gosavi tugos...@in.ibm.com
Signed-off-by: Shirish Pargaonkar shirishpargaon...@gmail.com
Acked-by: Jeff Layton jlay...@redhat.com
Signed-off-by: Steve French sfre...@us.ibm.com
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
fs/cifs/cifsproto.h |6 --
fs/cifs/cifssmb.c | 12 +---
fs/cifs/readdir.c | 15 +--
3 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/fs/cifs/cifsproto.h b/fs/cifs/cifsproto.h
index eeb789d..0a3fa96 100644
--- a/fs/cifs/cifsproto.h
+++ b/fs/cifs/cifsproto.h
@@ -192,11 +192,13 @@ extern int CIFSTCon(unsigned int xid, struct cifs_ses
*ses,
extern int CIFSFindFirst(const int xid, struct cifs_tcon *tcon,
const char *searchName, const struct nls_table *nls_codepage,
- __u16 *searchHandle, struct cifs_search_info *psrch_inf,
+ __u16 *searchHandle, __u16 search_flags,
+ struct cifs_search_info *psrch_inf,
int map, const char dirsep);
extern int CIFSFindNext(const int xid, struct cifs_tcon *tcon,
- __u16 searchHandle, struct cifs_search_info *psrch_inf);
+ __u16 searchHandle, __u16 search_flags,
+ struct cifs_search_info *psrch_inf);
extern int CIFSFindClose(const int, struct cifs_tcon *tcon,
const __u16 search_handle);
diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c
index 45633da..3563c93 100644
--- a/fs/cifs/cifssmb.c
+++ b/fs/cifs/cifssmb.c
@@ -4238,7 +4238,7 @@ int
CIFSFindFirst(const int xid, struct cifs_tcon *tcon,
const char *searchName,
const struct nls_table *nls_codepage,
- __u16 *pnetfid,
+ __u16 *pnetfid, __u16 search_flags,
struct cifs_search_info *psrch_inf, int remap, const char dirsep)
{
/* level 257 SMB_ */
@@ -4310,8 +4310,7 @@ findFirstRetry:
cpu_to_le16(ATTR_READONLY | ATTR_HIDDEN | ATTR_SYSTEM |
ATTR_DIRECTORY);
pSMB-SearchCount = cpu_to_le16(CIFSMaxBufSize/sizeof(FILE_UNIX_INFO));
- pSMB-SearchFlags = cpu_to_le16(CIFS_SEARCH_CLOSE_AT_END |
- CIFS_SEARCH_RETURN_RESUME);
+ pSMB-SearchFlags = cpu_to_le16(search_flags);
pSMB-InformationLevel = cpu_to_le16(psrch_inf-info_level);
/* BB what should we set StorageType to? Does it matter? BB */
@@ -4381,8 +4380,8 @@ findFirstRetry:
return rc;
}
-int CIFSFindNext(const int xid, struct cifs_tcon *tcon,
-__u16 searchHandle, struct cifs_search_info *psrch_inf)
+int CIFSFindNext(const int xid, struct cifs_tcon *tcon, __u16 searchHandle,
+__u16 search_flags, struct cifs_search_info *psrch_inf)
{
TRANSACTION2_FNEXT_REQ *pSMB = NULL;
TRANSACTION2_FNEXT_RSP *pSMBr = NULL;
@@ -4425,8 +4424,7 @@ int CIFSFindNext(const int xid, struct cifs_tcon *tcon,
cpu_to_le16(CIFSMaxBufSize / sizeof(FILE_UNIX_INFO));
pSMB-InformationLevel = cpu_to_le16(psrch_inf-info_level);
pSMB-ResumeKey = psrch_inf-resume_key;
- pSMB-SearchFlags =
- cpu_to_le16(CIFS_SEARCH_CLOSE_AT_END | CIFS_SEARCH_RETURN_RESUME);
+ pSMB-SearchFlags = cpu_to_le16(search_flags);
name_len = psrch_inf-resume_name_len;
params += name_len;
diff --git a/fs/cifs/readdir.c b/fs/cifs/readdir.c
index e2bbc68..0a8224d 100644
--- a/fs/cifs/readdir.c
+++ b/fs/cifs/readdir.c
@@ -219,6 +219,7 @@ int get_symlink_reparse_path(char *full_path, struct
cifs_sb_info *cifs_sb,
static int initiate_cifs_search(const int xid, struct file *file)
{
+ __u16 search_flags;
int rc = 0;
char *full_path = NULL;
struct cifsFileInfo *cifsFile;
@@ -270,8 +271,12 @@ ffirst_retry:
cifsFile-srch_inf.info_level = SMB_FIND_FILE_DIRECTORY_INFO;
}
+ search_flags = CIFS_SEARCH_CLOSE_AT_END | CIFS_SEARCH_RETURN_RESUME;
+ if (backup_cred(cifs_sb))
+ search_flags |= CIFS_SEARCH_BACKUP_SEARCH;
+
rc = CIFSFindFirst(xid, pTcon, full_path, cifs_sb-local_nls,
- cifsFile-netfid, cifsFile-srch_inf,
+ cifsFile-netfid, search_flags, cifsFile-srch_inf,
cifs_sb-mnt_cifs_flags
CIFS_MOUNT_MAP_SPECIAL_CHR, CIFS_DIR_SEP(cifs_sb));
if (rc == 0)
@@ -502,11 +507,13 @@ static int
[ 61/82] Bluetooth: Add support for Foxconn/Hon Hai AR5BBU22 0489:E03C
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Michael Gruetzner mgrue...@gmx.de
commit 85d59726c5c66016a507f1f4a60db8e374dd284d upstream.
Add Foxconn/Hon Hai AR5BBU22 Bluetooth Module( 0x489:0xE03C) to
the blacklist of btusb module and add it to the ath3k module to properly
load the firmware in Kernel 3.3.4
The device is integrated in e.g. some Acer Aspire 7750G.
Output from /sys/kernel/debug/usb/devices:
T: Bus=01 Lev=02 Prnt=02 Port=05 Cnt=02 Dev#= 6 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e03c Rev= 0.02
S: Manufacturer=Atheros Communications
S: Product=Bluetooth USB Host Controller
S: SerialNumber=Alaska Day 2006
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
Signed-off-by: Michael Gruetzner mgrue...@gmx.de
Signed-off-by: Gustavo Padovan gust...@padovan.org
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
drivers/bluetooth/ath3k.c |6 ++
drivers/bluetooth/btusb.c |3 +++
2 files changed, 9 insertions(+)
diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index 57fd867..aba22b2 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -81,6 +81,9 @@ static struct usb_device_id ath3k_table[] = {
/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE02C) },
+ /* Atheros AR5BBU22 with sflash firmware */
+ { USB_DEVICE(0x0489, 0xE03C) },
+
{ } /* Terminating entry */
};
@@ -99,6 +102,9 @@ static struct usb_device_id ath3k_blist_tbl[] = {
{ USB_DEVICE(0x13d3, 0x3362), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
+ /* Atheros AR5BBU22 with sflash firmware */
+ { USB_DEVICE(0x0489, 0xE03C), .driver_info = BTUSB_ATH3012 },
+
{ } /* Terminating entry */
};
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index de17121..cb480f1 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -143,6 +143,9 @@ static struct usb_device_id blacklist_table[] = {
/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xe02c), .driver_info = BTUSB_IGNORE },
+ /* Atheros AR5BBU12 with sflash firmware */
+ { USB_DEVICE(0x0489, 0xe03c), .driver_info = BTUSB_ATH3012 },
+
/* Broadcom BCM2035 */
{ USB_DEVICE(0x0a5c, 0x2035), .driver_info = BTUSB_WRONG_SCO_MTU },
{ USB_DEVICE(0x0a5c, 0x200a), .driver_info = BTUSB_WRONG_SCO_MTU },
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 64/82] ipv4: fix the rcu race between free_fib_info and ip_route_output_slow
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Yanmin Zhang yanmin_zh...@linux.intel.com
[ Upstream commit e49cc0da7283088c5e03d475ffe2fdcb24a6d5b1 ]
We hit a kernel OOPS.
3[23898.789643] BUG: sleeping function called from invalid context at
/data/buildbot/workdir/ics/hardware/intel/linux-2.6/arch/x86/mm/fault.c:1103
3[23898.862215] in_atomic(): 0, irqs_disabled(): 0, pid: 10526, name:
Thread-6683
4[23898.967805] HSU serial :00:05.1: :00:05.2:HSU serial prevented me
to suspend...
4[23899.258526] Pid: 10526, comm: Thread-6683 Tainted: GW
3.0.8-137685-ge7742f9 #1
4[23899.357404] HSU serial :00:05.1: :00:05.2:HSU serial prevented me
to suspend...
4[23899.904225] Call Trace:
4[23899.989209] [c1227f50] ? pgtable_bad+0x130/0x130
4[23900.000416] [c1238c2a] __might_sleep+0x10a/0x110
4[23900.007357] [c1228021] do_page_fault+0xd1/0x3c0
4[23900.013764] [c18e9ba9] ? restore_all+0xf/0xf
4[23900.024024] [c17c007b] ? napi_complete+0x8b/0x690
4[23900.029297] [c1227f50] ? pgtable_bad+0x130/0x130
4[23900.123739] [c1227f50] ? pgtable_bad+0x130/0x130
4[23900.128955] [c18ea0c3] error_code+0x5f/0x64
4[23900.133466] [c1227f50] ? pgtable_bad+0x130/0x130
4[23900.138450] [c17f6298] ? __ip_route_output_key+0x698/0x7c0
4[23900.144312] [c17f5f8d] ? __ip_route_output_key+0x38d/0x7c0
4[23900.150730] [c17f63df] ip_route_output_flow+0x1f/0x60
4[23900.156261] [c181de58] ip4_datagram_connect+0x188/0x2b0
4[23900.161960] [c18e981f] ? _raw_spin_unlock_bh+0x1f/0x30
4[23900.167834] [c18298d6] inet_dgram_connect+0x36/0x80
4[23900.173224] [c14f9e88] ? _copy_from_user+0x48/0x140
4[23900.178817] [c17ab9da] sys_connect+0x9a/0xd0
4[23900.183538] [c132e93c] ? alloc_file+0xdc/0x240
4[23900.189111] [c123925d] ? sub_preempt_count+0x3d/0x50
Function free_fib_info resets nexthop_nh-nh_dev to NULL before releasing
fi. Other cpu might be accessing fi. Fixing it by delaying the releasing.
With the patch, we ran MTBF testing on Android mobile for 12 hours
and didn't trigger the issue.
Thank Eric for very detailed review/checking the issue.
Signed-off-by: Yanmin Zhang yanmin_zh...@linux.intel.com
Signed-off-by: Kun Jiang kunx.ji...@intel.com
Acked-by: Eric Dumazet eduma...@google.com
Signed-off-by: David S. Miller da...@davemloft.net
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
net/ipv4/fib_semantics.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index 80106d8..d01f9c6 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -146,6 +146,12 @@ static void free_fib_info_rcu(struct rcu_head *head)
{
struct fib_info *fi = container_of(head, struct fib_info, rcu);
+ change_nexthops(fi) {
+ if (nexthop_nh-nh_dev)
+ dev_put(nexthop_nh-nh_dev);
+ } endfor_nexthops(fi);
+
+ release_net(fi-fib_net);
if (fi-fib_metrics != (u32 *) dst_default_metrics)
kfree(fi-fib_metrics);
kfree(fi);
@@ -157,13 +163,7 @@ void free_fib_info(struct fib_info *fi)
pr_warning(Freeing alive fib_info %p\n, fi);
return;
}
- change_nexthops(fi) {
- if (nexthop_nh-nh_dev)
- dev_put(nexthop_nh-nh_dev);
- nexthop_nh-nh_dev = NULL;
- } endfor_nexthops(fi);
fib_info_cnt--;
- release_net(fi-fib_net);
call_rcu(fi-rcu, free_fib_info_rcu);
}
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 56/82] Bluetooth: btusb: typo in Broadcom SoftSailing id
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Don Zickus dzic...@redhat.com
commit 2e8b506310f6433d5558387fd568d4bfb1d6a799 upstream.
I was trying to backport the following commit to RHEL-6
From 0cea73465cd22373c5cd43a3edd25fbd4bb532ef Mon Sep 17 00:00:00 2001
From: Oliver Neukum oli...@neukum.org
Date: Wed, 21 Sep 2011 11:37:15 +0200
Subject: [PATCH] btusb: add device entry for Broadcom SoftSailing
and noticed it wasn't working on an HP Elitebook. Looking into the patch I
noticed a very subtle typo in the ids. The patch has '0x05ac' instead of
'0x0a5c'. A snippet of the lsusb -v output also shows this:
Bus 002 Device 003: ID 0a5c:21e1 Broadcom Corp.
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 1
bDeviceProtocol 1
bMaxPacketSize064
idVendor 0x0a5c Broadcom Corp.
idProduct 0x21e1
bcdDevice1.12
iManufacturer 1 Broadcom Corp
iProduct2 BCM20702A0
iSerial 3 60D819F0338C
bNumConfigurations 1
Looking at other Broadcom ids, the fix matches them whereas the original patch
matches Apple's ids.
Tested on an HP Elitebook 8760w. The btusb binds and the userspace stuff loads
correctly.
Cc: Oliver Neukum oli...@neukum.org
Signed-off-by: Don Zickus dzic...@redhat.com
Acked-by: Marcel Holtmann mar...@holtmann.org
Signed-off-by: Johan Hedberg johan.hedb...@intel.com
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
drivers/bluetooth/btusb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index ba89cd0..3311b81 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -61,7 +61,7 @@ static struct usb_device_id btusb_table[] = {
{ USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
/* Broadcom SoftSailing reporting vendor specific */
- { USB_DEVICE(0x05ac, 0x21e1) },
+ { USB_DEVICE(0x0a5c, 0x21e1) },
/* Apple MacBookPro 7,1 */
{ USB_DEVICE(0x05ac, 0x8213) },
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 79/82] drm/radeon/kms: add new BTC PCI ids
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher alexander.deuc...@amd.com
commit a2bef8ce826dd1e787fd8ad9b6e0566ba59dab43 upstream.
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Signed-off-by: Dave Airlie airl...@redhat.com
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
include/drm/drm_pciids.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index c5b0d8c..86c4cf9 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -181,6 +181,7 @@
{0x1002, 0x6747, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6748, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6749, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x674A, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6750, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6751, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6758, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_NEW_MEMMAP}, \
@@ -198,6 +199,7 @@
{0x1002, 0x6767, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CAICOS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6768, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CAICOS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6770, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CAICOS|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x6771, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CAICOS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6772, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CAICOS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6778, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CAICOS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6779, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CAICOS|RADEON_NEW_MEMMAP}, \
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 65/82] set fake_rtables dst to NULL to avoid kernel Oops
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Peter Huang (Peng) peter.huangp...@huawei.com
[ Upstream commit a881e963c7fe1f226e991ee9bbe8907acda93294 ]
bridge: set fake_rtable's dst to NULL to avoid kernel Oops
when bridge is deleted before tap/vif device's delete, kernel may
encounter an oops because of NULL reference to fake_rtable's dst.
Set fake_rtable's dst to NULL before sending packets out can solve
this problem.
v4 reformat, change br_drop_fake_rtable(skb) to {}
v3 enrich commit header
v2 introducing new flag DST_FAKE_RTABLE to dst_entry struct.
[ Use do { } while (0) for nop br_drop_fake_rtable()
implementation -DaveM ]
Acked-by: Eric Dumazet eric.duma...@gmail.com
Signed-off-by: Peter Huang peter.huangp...@huawei.com
Signed-off-by: David S. Miller da...@davemloft.net
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
include/linux/netfilter_bridge.h |9 +
include/net/dst.h|1 +
net/bridge/br_forward.c |1 +
net/bridge/br_netfilter.c|8 ++--
4 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/include/linux/netfilter_bridge.h b/include/linux/netfilter_bridge.h
index 0ddd161..31d2844 100644
--- a/include/linux/netfilter_bridge.h
+++ b/include/linux/netfilter_bridge.h
@@ -104,9 +104,18 @@ struct bridge_skb_cb {
} daddr;
};
+static inline void br_drop_fake_rtable(struct sk_buff *skb)
+{
+ struct dst_entry *dst = skb_dst(skb);
+
+ if (dst (dst-flags DST_FAKE_RTABLE))
+ skb_dst_drop(skb);
+}
+
#else
#define nf_bridge_maybe_copy_header(skb) (0)
#define nf_bridge_pad(skb) (0)
+#define br_drop_fake_rtable(skb) do { } while (0)
#endif /* CONFIG_BRIDGE_NETFILTER */
#endif /* __KERNEL__ */
diff --git a/include/net/dst.h b/include/net/dst.h
index 75766b4..65bca65 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -54,6 +54,7 @@ struct dst_entry {
#define DST_NOCACHE0x0010
#define DST_NOCOUNT0x0020
#define DST_NOPEER 0x0040
+#define DST_FAKE_RTABLE0x0080
short error;
short obsolete;
diff --git a/net/bridge/br_forward.c b/net/bridge/br_forward.c
index ee64287..e221f88 100644
--- a/net/bridge/br_forward.c
+++ b/net/bridge/br_forward.c
@@ -47,6 +47,7 @@ int br_dev_queue_push_xmit(struct sk_buff *skb)
kfree_skb(skb);
} else {
skb_push(skb, ETH_HLEN);
+ br_drop_fake_rtable(skb);
dev_queue_xmit(skb);
}
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index fa8b8f7..577ea5d 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -147,7 +147,7 @@ void br_netfilter_rtable_init(struct net_bridge *br)
rt-dst.dev = br-dev;
rt-dst.path = rt-dst;
dst_init_metrics(rt-dst, br_dst_default_metrics, true);
- rt-dst.flags = DST_NOXFRM | DST_NOPEER;
+ rt-dst.flags = DST_NOXFRM | DST_NOPEER | DST_FAKE_RTABLE;
rt-dst.ops = fake_dst_ops;
}
@@ -687,11 +687,7 @@ static unsigned int br_nf_local_in(unsigned int hook,
struct sk_buff *skb,
const struct net_device *out,
int (*okfn)(struct sk_buff *))
{
- struct rtable *rt = skb_rtable(skb);
-
- if (rt rt == bridge_parent_rtable(in))
- skb_dst_drop(skb);
-
+ br_drop_fake_rtable(skb);
return NF_ACCEPT;
}
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 52/82] fec_mpc52xx: fix timestamp filtering
3.2-stable review patch. If anyone has any objections, please let me know. -- From: Stephan Gatzka step...@gatzka.org commit 9ca3cc6f3026946ba655e863ca2096339e667639 upstream. skb_defer_rx_timestamp was called with a freshly allocated skb but must be called with rskb instead. Signed-off-by: Stephan Gatzka step...@gatzka.org Acked-by: Richard Cochran richardcoch...@gmail.com Signed-off-by: David S. Miller da...@davemloft.net Signed-off-by: Ben Hutchings b...@decadent.org.uk --- drivers/net/ethernet/freescale/fec_mpc52xx.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/freescale/fec_mpc52xx.c b/drivers/net/ethernet/freescale/fec_mpc52xx.c index 97f947b..2933d08 100644 --- a/drivers/net/ethernet/freescale/fec_mpc52xx.c +++ b/drivers/net/ethernet/freescale/fec_mpc52xx.c @@ -437,7 +437,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void *dev_id) length = status BCOM_FEC_RX_BD_LEN_MASK; skb_put(rskb, length - 4); /* length without CRC32 */ rskb-protocol = eth_type_trans(rskb, dev); - if (!skb_defer_rx_timestamp(skb)) + if (!skb_defer_rx_timestamp(rskb)) netif_rx(rskb); spin_lock(priv-lock); -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 12/82] drm/i915: Ignore LVDS on hp t5745 and hp st5747 thin client
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Marc Gariepy mgari...@ubuntu.com
commit f5b8a7ed0405d48fd096acce48fbefbed77fb055 upstream.
Add a no_lvds quirk for the HP t5745 and HP st5747 thin clients
dmidecode for those thin clients are attached in thoses bugs:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911916
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911920
Signed-off-by: Marc Gariepy mgari...@ubuntu.com
Acked-by: Adam Jackson a...@redhat.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
[bwh: Backported to 3.2: adjust context because these quirk entries aren't
consistently cc'd to stable and are now being applied out of order]
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
drivers/gpu/drm/i915/intel_lvds.c | 16
1 file changed, 16 insertions(+)
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -741,6 +741,22 @@
},
{
.callback = intel_no_lvds_dmi_callback,
+ .ident = Hewlett-Packard t5745,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, Hewlett-Packard),
+ DMI_MATCH(DMI_BOARD_NAME, hp t5745),
+ },
+ },
+ {
+ .callback = intel_no_lvds_dmi_callback,
+ .ident = Hewlett-Packard st5747,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, Hewlett-Packard),
+ DMI_MATCH(DMI_BOARD_NAME, hp st5747),
+ },
+ },
+ {
+ .callback = intel_no_lvds_dmi_callback,
.ident = MSI Wind Box DC500,
.matches = {
DMI_MATCH(DMI_BOARD_VENDOR, MICRO-STAR INTERNATIONAL
CO., LTD),
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 10/82] drm/i915: enable vdd when switching off the eDP panel
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Daniel Vetter daniel.vet...@ffwll.ch
commit 6cb49835da0426f69a2931bc2a0a8156344b0e41 upstream.
We have one bug report from a validation team that we get the eDP
panel sequencing still somewhat wrong: We need to enable VDD while
switching off the panel and backlight. Unfortunately that reporter
seems to have fallen off the earth :(
For another reporter this actually fixes a black panel issue because
without this the backlight/panel gets confused and doesn't light up
again.
v2: I've forgotten to remove the vdd_off call in panel_off which is
now bogus. This essentially reverts
commit 17038de5f16569a25343cf68668f3b657eafb00e
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Mon Apr 16 22:43:42 2012 +0100
drm/i915/dp: Flush any outstanding work to turn the VDD off
v3: the current panel_off code forces off the vdd power, too. Which is
bogus and resulted in some funny warnings later on when we've tried to
do aux channel communications with just the vdd forced on. Fix this,
too.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46312
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43163
Tested-by: Vincent Frentzel zcec...@gmail.com
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
[bwh: Backported to 3.2: nothing to revert here]
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
drivers/gpu/drm/i915/intel_dp.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1149,10 +1149,10 @@
DRM_DEBUG_KMS(Turn eDP power off\n);
- WARN(intel_dp-want_panel_vdd, Cannot turn power off while VDD is
on\n);
+ WARN(!intel_dp-want_panel_vdd, Need VDD to turn off panel\n);
pp = ironlake_get_pp_control(dev_priv);
- pp = ~(POWER_TARGET_ON | EDP_FORCE_VDD | PANEL_POWER_RESET |
EDP_BLC_ENABLE);
+ pp = ~(POWER_TARGET_ON | PANEL_POWER_RESET | EDP_BLC_ENABLE);
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
@@ -1260,18 +1260,16 @@
{
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+ /* Make sure the panel is off before trying to change the mode. But also
+* ensure that we have vdd while we switch off the panel. */
+ ironlake_edp_panel_vdd_on(intel_dp);
ironlake_edp_backlight_off(intel_dp);
ironlake_edp_panel_off(intel_dp);
- /* Wake up the sink first */
- ironlake_edp_panel_vdd_on(intel_dp);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
intel_dp_link_down(intel_dp);
ironlake_edp_panel_vdd_off(intel_dp, false);
-
- /* Make sure the panel is off before trying to
-* change the mode
-*/
}
static void intel_dp_commit(struct drm_encoder *encoder)
@@ -1303,10 +1301,11 @@
uint32_t dp_reg = I915_READ(intel_dp-output_reg);
if (mode != DRM_MODE_DPMS_ON) {
+ /* Switching the panel off requires vdd. */
+ ironlake_edp_panel_vdd_on(intel_dp);
ironlake_edp_backlight_off(intel_dp);
ironlake_edp_panel_off(intel_dp);
- ironlake_edp_panel_vdd_on(intel_dp);
intel_dp_sink_dpms(intel_dp, mode);
intel_dp_link_down(intel_dp);
ironlake_edp_panel_vdd_off(intel_dp, false);
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 66/82] ipv6: fix incorrect ipsec fragment
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Gao feng gaof...@cn.fujitsu.com
[ Upstream commit 0c1833797a5a6ec23ea9261d979aa18078720b74 ]
Since commit ad0081e43a
ipv6: Fragment locally generated tunnel-mode IPSec6 packets as needed
the fragment of packets is incorrect.
because tunnel mode needs IPsec headers and trailer for all fragments,
while on transport mode it is sufficient to add the headers to the
first fragment and the trailer to the last.
so modify mtu and maxfraglen base on ipsec mode and if fragment is first
or last.
with my test,it work well(every fragment's size is the mtu)
and does not trigger slow fragment path.
Changes from v1:
though optimization, mtu_prev and maxfraglen_prev can be delete.
replace xfrm mode codes with dst_entry's new frag DST_XFRM_TUNNEL.
add fuction ip6_append_data_mtu to make codes clearer.
Signed-off-by: Gao feng gaof...@cn.fujitsu.com
Signed-off-by: David S. Miller da...@davemloft.net
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
include/net/dst.h |1 +
net/ipv6/ip6_output.c | 68 +++-
net/xfrm/xfrm_policy.c |3 +++
3 files changed, 54 insertions(+), 18 deletions(-)
diff --git a/include/net/dst.h b/include/net/dst.h
index 65bca65..16010d1 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -55,6 +55,7 @@ struct dst_entry {
#define DST_NOCOUNT0x0020
#define DST_NOPEER 0x0040
#define DST_FAKE_RTABLE0x0080
+#define DST_XFRM_TUNNEL0x0100
short error;
short obsolete;
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index f7f07e2..ae98e09 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1178,6 +1178,29 @@ static inline struct ipv6_rt_hdr *ip6_rthdr_dup(struct
ipv6_rt_hdr *src,
return src ? kmemdup(src, (src-hdrlen + 1) * 8, gfp) : NULL;
}
+static void ip6_append_data_mtu(int *mtu,
+ int *maxfraglen,
+ unsigned int fragheaderlen,
+ struct sk_buff *skb,
+ struct rt6_info *rt)
+{
+ if (!(rt-dst.flags DST_XFRM_TUNNEL)) {
+ if (skb == NULL) {
+ /* first fragment, reserve header_len */
+ *mtu = *mtu - rt-dst.header_len;
+
+ } else {
+ /*
+* this fragment is not first, the headers
+* space is regarded as data space.
+*/
+ *mtu = dst_mtu(rt-dst.path);
+ }
+ *maxfraglen = ((*mtu - fragheaderlen) ~7)
+ + fragheaderlen - sizeof(struct frag_hdr);
+ }
+}
+
int ip6_append_data(struct sock *sk, int getfrag(void *from, char *to,
int offset, int len, int odd, struct sk_buff *skb),
void *from, int length, int transhdrlen,
@@ -1187,7 +1210,7 @@ int ip6_append_data(struct sock *sk, int getfrag(void
*from, char *to,
struct inet_sock *inet = inet_sk(sk);
struct ipv6_pinfo *np = inet6_sk(sk);
struct inet_cork *cork;
- struct sk_buff *skb;
+ struct sk_buff *skb, *skb_prev = NULL;
unsigned int maxfraglen, fragheaderlen;
int exthdrlen;
int dst_exthdrlen;
@@ -1245,8 +1268,12 @@ int ip6_append_data(struct sock *sk, int getfrag(void
*from, char *to,
inet-cork.fl.u.ip6 = *fl6;
np-cork.hop_limit = hlimit;
np-cork.tclass = tclass;
- mtu = np-pmtudisc == IPV6_PMTUDISC_PROBE ?
- rt-dst.dev-mtu : dst_mtu(rt-dst);
+ if (rt-dst.flags DST_XFRM_TUNNEL)
+ mtu = np-pmtudisc == IPV6_PMTUDISC_PROBE ?
+ rt-dst.dev-mtu : dst_mtu(rt-dst);
+ else
+ mtu = np-pmtudisc == IPV6_PMTUDISC_PROBE ?
+ rt-dst.dev-mtu : dst_mtu(rt-dst.path);
if (np-frag_size mtu) {
if (np-frag_size)
mtu = np-frag_size;
@@ -1342,25 +1369,27 @@ int ip6_append_data(struct sock *sk, int getfrag(void
*from, char *to,
unsigned int fraglen;
unsigned int fraggap;
unsigned int alloclen;
- struct sk_buff *skb_prev;
alloc_new_skb:
- skb_prev = skb;
-
/* There's no room in the current skb */
- if (skb_prev)
- fraggap = skb_prev-len - maxfraglen;
+ if (skb)
+ fraggap = skb-len - maxfraglen;
else
fraggap = 0;
+
[ 06/82] cifs: fix oops while traversing open file list (try #4)
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Shirish Pargaonkar shirishpargaon...@gmail.com
commit 2c0c2a08bed7a3b791f88d09d16ace56acb3dd98 upstream.
While traversing the linked list of open file handles, if the identfied
file handle is invalid, a reopen is attempted and if it fails, we
resume traversing where we stopped and cifs can oops while accessing
invalid next element, for list might have changed.
So mark the invalid file handle and attempt reopen if no
valid file handle is found in rest of the list.
If reopen fails, move the invalid file handle to the end of the list
and start traversing the list again from the begining.
Repeat this four times before giving up and returning an error if
file reopen keeps failing.
Signed-off-by: Shirish Pargaonkar shirishpargaon...@gmail.com
Reviewed-by: Jeff Layton jlay...@redhat.com
Signed-off-by: Steve French sfre...@us.ibm.com
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
fs/cifs/cifsglob.h |1 +
fs/cifs/file.c | 57 ++--
2 files changed, 34 insertions(+), 24 deletions(-)
diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h
index c0a027e..20350a9 100644
--- a/fs/cifs/cifsglob.h
+++ b/fs/cifs/cifsglob.h
@@ -43,6 +43,7 @@
#define CIFS_MIN_RCV_POOL 4
+#define MAX_REOPEN_ATT 5 /* these many maximum attempts to reopen a file */
/*
* default attribute cache timeout (jiffies)
*/
diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index ed9b5a8..253170d 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -1565,10 +1565,11 @@ struct cifsFileInfo *find_readable_file(struct
cifsInodeInfo *cifs_inode,
struct cifsFileInfo *find_writable_file(struct cifsInodeInfo *cifs_inode,
bool fsuid_only)
{
- struct cifsFileInfo *open_file;
+ struct cifsFileInfo *open_file, *inv_file = NULL;
struct cifs_sb_info *cifs_sb;
bool any_available = false;
int rc;
+ unsigned int refind = 0;
/* Having a null inode here (because mapping-host was set to zero by
the VFS or MM) should not happen but we had reports of on oops (due to
@@ -1588,40 +1589,25 @@ struct cifsFileInfo *find_writable_file(struct
cifsInodeInfo *cifs_inode,
spin_lock(cifs_file_list_lock);
refind_writable:
+ if (refind MAX_REOPEN_ATT) {
+ spin_unlock(cifs_file_list_lock);
+ return NULL;
+ }
list_for_each_entry(open_file, cifs_inode-openFileList, flist) {
if (!any_available open_file-pid != current-tgid)
continue;
if (fsuid_only open_file-uid != current_fsuid())
continue;
if (OPEN_FMODE(open_file-f_flags) FMODE_WRITE) {
- cifsFileInfo_get(open_file);
-
if (!open_file-invalidHandle) {
/* found a good writable file */
+ cifsFileInfo_get(open_file);
spin_unlock(cifs_file_list_lock);
return open_file;
+ } else {
+ if (!inv_file)
+ inv_file = open_file;
}
-
- spin_unlock(cifs_file_list_lock);
-
- /* Had to unlock since following call can block */
- rc = cifs_reopen_file(open_file, false);
- if (!rc)
- return open_file;
-
- /* if it fails, try another handle if possible */
- cFYI(1, wp failed on reopen file);
- cifsFileInfo_put(open_file);
-
- spin_lock(cifs_file_list_lock);
-
- /* else we simply continue to the next entry. Thus
- we do not loop on reopen errors. If we
- can not reopen the file, for example if we
- reconnected to a server with another client
- racing to delete or lock the file we would not
- make progress if we restarted before the beginning
- of the loop here. */
}
}
/* couldn't find useable FH with same pid, try any available */
@@ -1629,7 +1615,30 @@ refind_writable:
any_available = true;
goto refind_writable;
}
+
+ if (inv_file) {
+ any_available = false;
+ cifsFileInfo_get(inv_file);
+ }
+
spin_unlock(cifs_file_list_lock);
+
+ if (inv_file) {
+ rc = cifs_reopen_file(inv_file, false);
+ if (!rc)
+ return inv_file;
+ else {
+ spin_lock(cifs_file_list_lock);
+
[ 71/82] Revert net: maintain namespace isolation between vlan and real device
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: David S. Miller da...@davemloft.net
[ Upstream commit 59b9997baba5242997ddc7bd96b1391f5275a5a4 ]
This reverts commit 8a83a00b0735190384a348156837918271034144.
It causes regressions for S390 devices, because it does an
unconditional DST drop on SKBs for vlans and the QETH device
needs the neighbour entry hung off the DST for certain things
on transmit.
Arnd can't remember exactly why he even needed this change.
Conflicts:
drivers/net/macvlan.c
net/8021q/vlan_dev.c
net/core/dev.c
Signed-off-by: David S. Miller da...@davemloft.net
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
drivers/net/macvlan.c |2 +-
include/linux/netdevice.h |9 -
net/8021q/vlan_dev.c |2 +-
net/core/dev.c| 36 +---
4 files changed, 7 insertions(+), 42 deletions(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 959d448..97f342e 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -258,7 +258,7 @@ static int macvlan_queue_xmit(struct sk_buff *skb, struct
net_device *dev)
xmit_world:
skb-ip_summed = ip_summed;
- skb_set_dev(skb, vlan-lowerdev);
+ skb-dev = vlan-lowerdev;
return dev_queue_xmit(skb);
}
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index cbeb586..cb52340 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1420,15 +1420,6 @@ static inline bool netdev_uses_dsa_tags(struct
net_device *dev)
return 0;
}
-#ifndef CONFIG_NET_NS
-static inline void skb_set_dev(struct sk_buff *skb, struct net_device *dev)
-{
- skb-dev = dev;
-}
-#else /* CONFIG_NET_NS */
-void skb_set_dev(struct sk_buff *skb, struct net_device *dev);
-#endif
-
static inline bool netdev_uses_trailer_tags(struct net_device *dev)
{
#ifdef CONFIG_NET_DSA_TAG_TRAILER
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index bc25286..0a8 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -156,7 +156,7 @@ static netdev_tx_t vlan_dev_hard_start_xmit(struct sk_buff
*skb,
skb = __vlan_hwaccel_put_tag(skb, vlan_tci);
}
- skb_set_dev(skb, vlan_dev_info(dev)-real_dev);
+ skb-dev = vlan_dev_info(dev)-real_dev;
len = skb-len;
ret = dev_queue_xmit(skb);
diff --git a/net/core/dev.c b/net/core/dev.c
index 61a7baa..1cbddc9 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1607,10 +1607,14 @@ int dev_forward_skb(struct net_device *dev, struct
sk_buff *skb)
kfree_skb(skb);
return NET_RX_DROP;
}
- skb_set_dev(skb, dev);
+ skb-dev = dev;
+ skb_dst_drop(skb);
skb-tstamp.tv64 = 0;
skb-pkt_type = PACKET_HOST;
skb-protocol = eth_type_trans(skb, dev);
+ skb-mark = 0;
+ secpath_reset(skb);
+ nf_reset(skb);
return netif_rx(skb);
}
EXPORT_SYMBOL_GPL(dev_forward_skb);
@@ -1865,36 +1869,6 @@ void netif_device_attach(struct net_device *dev)
}
EXPORT_SYMBOL(netif_device_attach);
-/**
- * skb_dev_set -- assign a new device to a buffer
- * @skb: buffer for the new device
- * @dev: network device
- *
- * If an skb is owned by a device already, we have to reset
- * all data private to the namespace a device belongs to
- * before assigning it a new device.
- */
-#ifdef CONFIG_NET_NS
-void skb_set_dev(struct sk_buff *skb, struct net_device *dev)
-{
- skb_dst_drop(skb);
- if (skb-dev !net_eq(dev_net(skb-dev), dev_net(dev))) {
- secpath_reset(skb);
- nf_reset(skb);
- skb_init_secmark(skb);
- skb-mark = 0;
- skb-priority = 0;
- skb-nf_trace = 0;
- skb-ipvs_property = 0;
-#ifdef CONFIG_NET_SCHED
- skb-tc_index = 0;
-#endif
- }
- skb-dev = dev;
-}
-EXPORT_SYMBOL(skb_set_dev);
-#endif /* CONFIG_NET_NS */
-
/*
* Invalidate hardware checksum when packet is to be mangled, and
* complete checksum manually on outgoing path.
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 53/82] Bluetooth: btusb: Add vendor specific ID (0a5c 21f3) for BCM20702A0
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Manoj Iyer manoj.i...@canonical.com
commit 37305cf649689a4d2341dd6fd89b091c6007f9ba upstream.
T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=03 Dev#= 5 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0a5c ProdID=21f3 Rev=01.12
S: Manufacturer=Broadcom Corp
S: Product=BCM20702A0
S: SerialNumber=74DE2B344A7B
C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
Signed-off-by: Manoj Iyer manoj.i...@canonical.com
Tested-by: Dennis Chua dennis.c...@canonical.com
Acked-by: Marcel Holtmann mar...@holtmann.org
Signed-off-by: Johan Hedberg johan.hedb...@intel.com
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
drivers/bluetooth/btusb.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index d7664ff..afcd281 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -102,6 +102,7 @@ static struct usb_device_id btusb_table[] = {
/* Broadcom BCM20702A0 */
{ USB_DEVICE(0x0a5c, 0x21e3) },
+ { USB_DEVICE(0x0a5c, 0x21f3) },
{ USB_DEVICE(0x413c, 0x8197) },
{ } /* Terminating entry */
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 74/82] xfrm: take net hdr len into account for esp payload size calculation
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Benjamin Poirier bpoir...@suse.de
[ Upstream commit 91657eafb64b4cb53ec3a2fbc4afc3497f735788 ]
Corrects the function that determines the esp payload size. The calculations
done in esp{4,6}_get_mtu() lead to overlength frames in transport mode for
certain mtu values and suboptimal frames for others.
According to what is done, mainly in esp{,6}_output() and tcp_mtu_to_mss(),
net_header_len must be taken into account before doing the alignment
calculation.
Signed-off-by: Benjamin Poirier bpoir...@suse.de
Signed-off-by: David S. Miller da...@davemloft.net
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
net/ipv4/esp4.c | 24 +---
net/ipv6/esp6.c | 18 +++---
2 files changed, 16 insertions(+), 26 deletions(-)
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index a5b4134..530787b 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -457,28 +457,22 @@ static u32 esp4_get_mtu(struct xfrm_state *x, int mtu)
struct esp_data *esp = x-data;
u32 blksize = ALIGN(crypto_aead_blocksize(esp-aead), 4);
u32 align = max_t(u32, blksize, esp-padlen);
- u32 rem;
-
- mtu -= x-props.header_len + crypto_aead_authsize(esp-aead);
- rem = mtu (align - 1);
- mtu = ~(align - 1);
+ unsigned int net_adj;
switch (x-props.mode) {
- case XFRM_MODE_TUNNEL:
- break;
- default:
case XFRM_MODE_TRANSPORT:
- /* The worst case */
- mtu -= blksize - 4;
- mtu += min_t(u32, blksize - 4, rem);
- break;
case XFRM_MODE_BEET:
- /* The worst case. */
- mtu += min_t(u32, IPV4_BEET_PHMAXLEN, rem);
+ net_adj = sizeof(struct iphdr);
break;
+ case XFRM_MODE_TUNNEL:
+ net_adj = 0;
+ break;
+ default:
+ BUG();
}
- return mtu - 2;
+ return ((mtu - x-props.header_len - crypto_aead_authsize(esp-aead) -
+net_adj) ~(align - 1)) + (net_adj - 2);
}
static void esp4_err(struct sk_buff *skb, u32 info)
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index 1ac7938..65dd543 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -411,19 +411,15 @@ static u32 esp6_get_mtu(struct xfrm_state *x, int mtu)
struct esp_data *esp = x-data;
u32 blksize = ALIGN(crypto_aead_blocksize(esp-aead), 4);
u32 align = max_t(u32, blksize, esp-padlen);
- u32 rem;
+ unsigned int net_adj;
- mtu -= x-props.header_len + crypto_aead_authsize(esp-aead);
- rem = mtu (align - 1);
- mtu = ~(align - 1);
-
- if (x-props.mode != XFRM_MODE_TUNNEL) {
- u32 padsize = ((blksize - 1) 7) + 1;
- mtu -= blksize - padsize;
- mtu += min_t(u32, blksize - padsize, rem);
- }
+ if (x-props.mode != XFRM_MODE_TUNNEL)
+ net_adj = sizeof(struct ipv6hdr);
+ else
+ net_adj = 0;
- return mtu - 2;
+ return ((mtu - x-props.header_len - crypto_aead_authsize(esp-aead) -
+net_adj) ~(align - 1)) + (net_adj - 2);
}
static void esp6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 82/82] asix: allow full size 8021Q frames to be received
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet eduma...@google.com
commit 9dae31009b1a00d926c6fe032d5a88099620adc3 upstream.
asix driver drops 8021Q full size frames because it doesn't take into
account VLAN header size.
Tested on AX88772 adapter.
Signed-off-by: Eric Dumazet eduma...@google.com
CC: Greg Kroah-Hartman gre...@linuxfoundation.org
CC: Allan Chou al...@asix.com.tw
CC: Trond Wuellner tr...@chromium.org
CC: Grant Grundler grund...@chromium.org
CC: Paul Stewart ps...@chromium.org
Signed-off-by: David S. Miller da...@davemloft.net
[bwh: Backported to 3.2: no offset used in asix_rx_fixup()]
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
--- a/drivers/net/usb/asix.c
+++ b/drivers/net/usb/asix.c
@@ -35,6 +35,7 @@
#include linux/crc32.h
#include linux/usb/usbnet.h
#include linux/slab.h
+#include linux/if_vlan.h
#define DRIVER_VERSION 08-Nov-2011
#define DRIVER_NAME asix
@@ -348,7 +349,7 @@
return 2;
}
- if (size dev-net-mtu + ETH_HLEN) {
+ if (size dev-net-mtu + ETH_HLEN + VLAN_HLEN) {
netdev_err(dev-net, asix_rx_fixup() Bad RX Length
%d\n,
size);
return 0;
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 81/82] kbuild: install kernel-page-flags.h
3.2-stable review patch. If anyone has any objections, please let me know. -- From: Ulrich Drepper drep...@akkadia.org commit 9295b7a07c859a42346221b5839be0ae612333b0 upstream. Programs using /proc/kpageflags need to know about the various flags. The linux/kernel-page-flags.h provides them and the comments in the file indicate that it is supposed to be used by user-level code. But the file is not installed. Install the headers and mark the unstable flags as out-of-bounds. The page-type tool is also adjusted to not duplicate the definitions Signed-off-by: Ulrich Drepper drep...@gmail.com Acked-by: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com Acked-by: Fengguang Wu fengguang...@intel.com Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Linus Torvalds torva...@linux-foundation.org [bwh: Backported to 3.2: adjust context; drop change to missing tools/vm/] Signed-off-by: Ben Hutchings b...@decadent.org.uk --- --- a/include/linux/Kbuild +++ b/include/linux/Kbuild @@ -224,6 +224,7 @@ header-y += kdev_t.h header-y += kernel.h header-y += kernelcapi.h +header-y += kernel-page-flags.h header-y += keyboard.h header-y += keyctl.h header-y += l2tp.h --- a/include/linux/kernel-page-flags.h +++ b/include/linux/kernel-page-flags.h @@ -31,6 +31,8 @@ #define KPF_KSM21 +#ifdef __KERNEL__ + /* kernel hacking assistances * WARNING: subject to change, never rely on them! */ @@ -43,4 +45,6 @@ #define KPF_ARCH 38 #define KPF_UNCACHED 39 +#endif /* __KERNEL__ */ + #endif /* LINUX_KERNEL_PAGE_FLAGS_H */ -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 76/82] target/file: Use O_DSYNC by default for FILEIO backends
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Nicholas Bellinger n...@linux-iscsi.org
commit a4dff3043c231d57f982af635c9d2192ee40e5ae upstream.
Convert to use O_DSYNC for all cases at FILEIO backend creation time to
avoid the extra syncing of pure timestamp updates with legacy O_SYNC during
default operation as recommended by hch. Continue to do this independently of
Write Cache Enable (WCE) bit, as WCE=0 is currently the default for all backend
devices and enabled by user on per device basis via attrib/emulate_write_cache.
This patch drops the now unnecessary fd_buffered_io= token usage that was
originally signalling when to explictly disable O_SYNC at backend creation
time for buffered I/O operation. This can end up being dangerous for a number
of reasons during physical node failure, so go ahead and drop this option
for now when O_DSYNC is used as the default.
Also allow explict FUA WRITEs - vfs_fsync_range() call to function in
fd_execute_cmd() independently of WCE bit setting.
Reported-by: Christoph Hellwig h...@lst.de
Cc: Linus Torvalds torva...@linux-foundation.org
Signed-off-by: Nicholas Bellinger n...@linux-iscsi.org
Signed-off-by: Ben Hutchings b...@decadent.org.uk
[bwh: Backported to 3.2:
- We have fd_do_task() and not fd_execute_cmd()
- Various fields are in struct se_task rather than struct se_cmd
- fd_create_virtdevice() flags initialisation hasn't been cleaned up]
---
--- a/drivers/target/target_core_file.c
+++ b/drivers/target/target_core_file.c
@@ -134,21 +134,11 @@
ret = PTR_ERR(dev_p);
goto fail;
}
-#if 0
- if (di-no_create_file)
- flags = O_RDWR | O_LARGEFILE;
- else
- flags = O_RDWR | O_CREAT | O_LARGEFILE;
-#else
- flags = O_RDWR | O_CREAT | O_LARGEFILE;
-#endif
-/* flags |= O_DIRECT; */
/*
-* If fd_buffered_io=1 has not been set explicitly (the default),
-* use O_SYNC to force FILEIO writes to disk.
+* Use O_DSYNC by default instead of O_SYNC to forgo syncing
+* of pure timestamp updates.
*/
- if (!(fd_dev-fbd_flags FDBD_USE_BUFFERED_IO))
- flags |= O_SYNC;
+ flags = O_RDWR | O_CREAT | O_LARGEFILE | O_DSYNC;
file = filp_open(dev_p, flags, 0600);
if (IS_ERR(file)) {
@@ -400,26 +390,6 @@
transport_complete_sync_cache(cmd, ret == 0);
}
-/*
- * WRITE Force Unit Access (FUA) emulation on a per struct se_task
- * LBA range basis..
- */
-static void fd_emulate_write_fua(struct se_cmd *cmd, struct se_task *task)
-{
- struct se_device *dev = cmd-se_dev;
- struct fd_dev *fd_dev = dev-dev_ptr;
- loff_t start = task-task_lba *
dev-se_sub_dev-se_dev_attrib.block_size;
- loff_t end = start + task-task_size;
- int ret;
-
- pr_debug(FILEIO: FUA WRITE LBA: %llu, bytes: %u\n,
- task-task_lba, task-task_size);
-
- ret = vfs_fsync_range(fd_dev-fd_file, start, end, 1);
- if (ret != 0)
- pr_err(FILEIO: vfs_fsync_range() failed: %d\n, ret);
-}
-
static int fd_do_task(struct se_task *task)
{
struct se_cmd *cmd = task-task_se_cmd;
@@ -434,19 +404,21 @@
ret = fd_do_readv(task);
} else {
ret = fd_do_writev(task);
-
+ /*
+* Perform implict vfs_fsync_range() for fd_do_writev() ops
+* for SCSI WRITEs with Forced Unit Access (FUA) set.
+* Allow this to happen independent of WCE=0 setting.
+*/
if (ret 0
- dev-se_sub_dev-se_dev_attrib.emulate_write_cache 0
dev-se_sub_dev-se_dev_attrib.emulate_fua_write 0
(cmd-se_cmd_flags SCF_FUA)) {
- /*
-* We might need to be a bit smarter here
-* and return some sense data to let the initiator
-* know the FUA WRITE cache sync failed..?
-*/
- fd_emulate_write_fua(cmd, task);
- }
+ struct fd_dev *fd_dev = dev-dev_ptr;
+ loff_t start = task-task_lba *
+ dev-se_sub_dev-se_dev_attrib.block_size;
+ loff_t end = start + task-task_size;
+ vfs_fsync_range(fd_dev-fd_file, start, end, 1);
+ }
}
if (ret 0) {
@@ -478,7 +450,6 @@
static match_table_t tokens = {
{Opt_fd_dev_name, fd_dev_name=%s},
{Opt_fd_dev_size, fd_dev_size=%s},
- {Opt_fd_buffered_io, fd_buffered_io=%d},
{Opt_err, NULL}
};
@@ -490,7 +461,7 @@
struct fd_dev *fd_dev = se_dev-se_dev_su_ptr;
char *orig, *ptr, *arg_p, *opts;
substring_t args[MAX_OPT_ARGS];
- int ret = 0, arg, token;
+ int ret = 0, token;
[ 69/82] r8169: fix early queue wake-up.
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Francois Romieu rom...@fr.zoreil.com
[ Upstream commit ae1f23fb433ac0aaff8aeaa5a7b14348e9aa8277 ]
With infinite gratitude to Eric Dumazet for allowing me to identify
the error.
Signed-off-by: Francois Romieu rom...@fr.zoreil.com
Acked-by: Eric Dumazet eric.duma...@gmail.com
Cc: Hayes Wang hayesw...@realtek.com
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
drivers/net/ethernet/realtek/r8169.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
index 5104d76..5f3fa32 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5561,7 +5561,18 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff
*skb,
RTL_W8(TxPoll, NPQ);
if (TX_BUFFS_AVAIL(tp) MAX_SKB_FRAGS) {
+ /* Avoid wrongly optimistic queue wake-up: rtl_tx thread must
+* not miss a ring update when it notices a stopped queue.
+*/
+ smp_wmb();
netif_stop_queue(dev);
+ /* Sync with rtl_tx:
+* - publish queue status and cur_tx ring index (write barrier)
+* - refresh dirty_tx ring index (read barrier).
+* May the current thread have a pessimistic view of the ring
+* status and forget to wake up queue, a racing rtl_tx thread
+* can't.
+*/
smp_mb();
if (TX_BUFFS_AVAIL(tp) = MAX_SKB_FRAGS)
netif_wake_queue(dev);
@@ -5663,6 +5674,13 @@ static void rtl8169_tx_interrupt(struct net_device *dev,
if (tp-dirty_tx != dirty_tx) {
tp-dirty_tx = dirty_tx;
+ /* Sync with rtl8169_start_xmit:
+* - publish dirty_tx ring index (write barrier)
+* - refresh cur_tx ring index and queue status (read barrier)
+* May the current thread miss the stopped queue condition,
+* a racing xmit thread can only have a right view of the
+* ring status.
+*/
smp_mb();
if (netif_queue_stopped(dev)
(TX_BUFFS_AVAIL(tp) = MAX_SKB_FRAGS)) {
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 70/82] r8169: fix unsigned int wraparound with TSO
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Julien Ducourthial jduco...@free.fr
[ Upstream commit 477206a018f902895bfcd069dd820bfe94c187b1 ]
The r8169 may get stuck or show bad behaviour after activating TSO :
the net_device is not stopped when it has no more TX descriptors.
This problem comes from TX_BUFS_AVAIL which may reach -1 when all
transmit descriptors are in use. The patch simply tries to keep positive
values.
Tested with 8111d(onboard) on a D510MO, and with 8111e(onboard) on a
Zotac 890GXITX.
Signed-off-by: Julien Ducourthial jduco...@free.fr
Acked-by: Francois Romieu rom...@fr.zoreil.com
Signed-off-by: David S. Miller da...@davemloft.net
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
drivers/net/ethernet/realtek/r8169.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
index 5f3fa32..cc2565c 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -62,8 +62,12 @@
#define R8169_MSG_DEFAULT \
(NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP | NETIF_MSG_IFDOWN)
-#define TX_BUFFS_AVAIL(tp) \
- (tp-dirty_tx + NUM_TX_DESC - tp-cur_tx - 1)
+#define TX_SLOTS_AVAIL(tp) \
+ (tp-dirty_tx + NUM_TX_DESC - tp-cur_tx)
+
+/* A skbuff with nr_frags needs nr_frags+1 entries in the tx queue */
+#define TX_FRAGS_READY_FOR(tp,nr_frags) \
+ (TX_SLOTS_AVAIL(tp) = (nr_frags + 1))
/* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
The RTL chips use a 64 element hash table based on the Ethernet CRC. */
@@ -5512,7 +5516,7 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
u32 opts[2];
int frags;
- if (unlikely(TX_BUFFS_AVAIL(tp) skb_shinfo(skb)-nr_frags)) {
+ if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)-nr_frags))) {
netif_err(tp, drv, dev, BUG! Tx Ring full when queue
awake!\n);
goto err_stop_0;
}
@@ -5560,7 +5564,7 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
RTL_W8(TxPoll, NPQ);
- if (TX_BUFFS_AVAIL(tp) MAX_SKB_FRAGS) {
+ if (!TX_FRAGS_READY_FOR(tp, MAX_SKB_FRAGS)) {
/* Avoid wrongly optimistic queue wake-up: rtl_tx thread must
* not miss a ring update when it notices a stopped queue.
*/
@@ -5574,7 +5578,7 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
* can't.
*/
smp_mb();
- if (TX_BUFFS_AVAIL(tp) = MAX_SKB_FRAGS)
+ if (TX_FRAGS_READY_FOR(tp, MAX_SKB_FRAGS))
netif_wake_queue(dev);
}
@@ -5683,7 +5687,7 @@ static void rtl8169_tx_interrupt(struct net_device *dev,
*/
smp_mb();
if (netif_queue_stopped(dev)
- (TX_BUFFS_AVAIL(tp) = MAX_SKB_FRAGS)) {
+ TX_FRAGS_READY_FOR(tp, MAX_SKB_FRAGS)) {
netif_wake_queue(dev);
}
/*
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 72/82] sctp: check cached dst before using it
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Nicolas Dichtel nicolas.dich...@6wind.com
[ Upstream commit e0268868ba064980488fc8c194db3d8e9fb2959c ]
dst_check() will take care of SA (and obsolete field), hence
IPsec rekeying scenario is taken into account.
Signed-off-by: Nicolas Dichtel nicolas.dich...@6wind.com
Acked-by: Vlad Yaseivch vyasev...@gmail.com
Signed-off-by: David S. Miller da...@davemloft.net
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
include/net/sctp/sctp.h | 13 +
net/sctp/output.c |4 +---
net/sctp/transport.c| 17 -
3 files changed, 14 insertions(+), 20 deletions(-)
diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index 6a72a58..ad03988 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -703,4 +703,17 @@ static inline void sctp_v4_map_v6(union sctp_addr *addr)
addr-v6.sin6_addr.s6_addr32[2] = htonl(0x);
}
+/* The cookie is always 0 since this is how it's used in the
+ * pmtu code.
+ */
+static inline struct dst_entry *sctp_transport_dst_check(struct sctp_transport
*t)
+{
+ if (t-dst !dst_check(t-dst, 0)) {
+ dst_release(t-dst);
+ t-dst = NULL;
+ }
+
+ return t-dst;
+}
+
#endif /* __net_sctp_h__ */
diff --git a/net/sctp/output.c b/net/sctp/output.c
index 817174e..8fc4dcd 100644
--- a/net/sctp/output.c
+++ b/net/sctp/output.c
@@ -377,9 +377,7 @@ int sctp_packet_transmit(struct sctp_packet *packet)
*/
skb_set_owner_w(nskb, sk);
- /* The 'obsolete' field of dst is set to 2 when a dst is freed. */
- if (!dst || (dst-obsolete 1)) {
- dst_release(dst);
+ if (!sctp_transport_dst_check(tp)) {
sctp_transport_route(tp, NULL, sctp_sk(sk));
if (asoc (asoc-param_flags SPP_PMTUD_ENABLE)) {
sctp_assoc_sync_pmtu(asoc);
diff --git a/net/sctp/transport.c b/net/sctp/transport.c
index 394c57c..8da4481 100644
--- a/net/sctp/transport.c
+++ b/net/sctp/transport.c
@@ -226,23 +226,6 @@ void sctp_transport_pmtu(struct sctp_transport *transport,
struct sock *sk)
transport-pathmtu = SCTP_DEFAULT_MAXSEGMENT;
}
-/* this is a complete rip-off from __sk_dst_check
- * the cookie is always 0 since this is how it's used in the
- * pmtu code
- */
-static struct dst_entry *sctp_transport_dst_check(struct sctp_transport *t)
-{
- struct dst_entry *dst = t-dst;
-
- if (dst dst-obsolete dst-ops-check(dst, 0) == NULL) {
- dst_release(t-dst);
- t-dst = NULL;
- return NULL;
- }
-
- return dst;
-}
-
void sctp_transport_update_pmtu(struct sctp_transport *t, u32 pmtu)
{
struct dst_entry *dst;
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 51/82] mtd: of_parts: fix breakage in Kconfig
3.2-stable review patch. If anyone has any objections, please let me know. -- From: Frank Svendsboe frank.svends...@gmail.com commit 2e929d001e85126d9267de373d4b76014789661d upstream. MTD_OF_PARTS and the default setting is not working due to using 'Y' instead of 'y', introduced in commit d6137badeff1ef64b4e0092ec249ebdeaeb3ff37. This made our board, and possibly other boards using DTS defined partitions and not having CONFIG_MTD_OF_PARTS=y defined in the defconfig, fail to mount root. Signed-off-by: Frank Svendsboe frank.svends...@gmail.com Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com Signed-off-by: David Woodhouse david.woodho...@intel.com Signed-off-by: Ben Hutchings b...@decadent.org.uk --- drivers/mtd/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig index 5760c1a..27143e0 100644 --- a/drivers/mtd/Kconfig +++ b/drivers/mtd/Kconfig @@ -128,7 +128,7 @@ config MTD_AFS_PARTS config MTD_OF_PARTS tristate OpenFirmware partitioning information support - default Y + default y depends on OF help This provides a partition parsing function which derives -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 29/82] mm: consider all swapped back pages in used-once logic
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Michal Hocko mho...@suse.cz
commit e48982734ea0500d1eba4f9d96195acc5406cad6 upstream.
Commit 645747462435 (vmscan: detect mapped file pages used only once)
made mapped pages have another round in inactive list because they might
be just short lived and so we could consider them again next time. This
heuristic helps to reduce pressure on the active list with a streaming
IO worklods.
This patch fixes a regression introduced by this commit for heavy shmem
based workloads because unlike Anon pages, which are excluded from this
heuristic because they are usually long lived, shmem pages are handled
as a regular page cache.
This doesn't work quite well, unfortunately, if the workload is mostly
backed by shmem (in memory database sitting on 80% of memory) with a
streaming IO in the background (backup - up to 20% of memory). Anon
inactive list is full of (dirty) shmem pages when watermarks are hit.
Shmem pages are kept in the inactive list (they are referenced) in the
first round and it is hard to reclaim anything else so we reach lower
scanning priorities very quickly which leads to an excessive swap out.
Let's fix this by excluding all swap backed pages (they tend to be long
lived wrt. the regular page cache anyway) from used-once heuristic and
rather activate them if they are referenced.
The customer's workload is shmem backed database (80% of RAM) and they
are measuring transactions/s with an IO in the background (20%).
Transactions touch more or less random rows in the table. The
transaction rate fell by a factor of 3 (in the worst case) because of
commit 64574746. This patch restores the previous numbers.
Signed-off-by: Michal Hocko mho...@suse.cz
Acked-by: Johannes Weiner han...@cmpxchg.org
Cc: Mel Gorman m...@csn.ul.ie
Cc: Minchan Kim minc...@kernel.org
Cc: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
Reviewed-by: Rik van Riel r...@redhat.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
mm/vmscan.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 44f0436..67a4fd4 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -657,7 +657,7 @@ static enum page_references page_check_references(struct
page *page,
return PAGEREF_RECLAIM;
if (referenced_ptes) {
- if (PageAnon(page))
+ if (PageSwapBacked(page))
return PAGEREF_ACTIVATE;
/*
* All mapped pages start out with page table
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 34/82] mm: fix vma_resv_map() NULL pointer
3.2-stable review patch. If anyone has any objections, please let me know. -- From: Dave Hansen d...@linux.vnet.ibm.com commit 4523e1458566a0e8ecfaff90f380dd23acc44d27 upstream. hugetlb_reserve_pages() can be used for either normal file-backed hugetlbfs mappings, or MAP_HUGETLB. In the MAP_HUGETLB, semi-anonymous mode, there is not a VMA around. The new call to resv_map_put() assumed that there was, and resulted in a NULL pointer dereference: BUG: unable to handle kernel NULL pointer dereference at 0030 IP: vma_resv_map+0x9/0x30 PGD 141453067 PUD 1421e1067 PMD 0 Oops: [#1] PREEMPT SMP ... Pid: 14006, comm: trinity-child6 Not tainted 3.4.0+ #36 RIP: vma_resv_map+0x9/0x30 ... Process trinity-child6 (pid: 14006, threadinfo 8801414e, task 8801414f26b0) Call Trace: resv_map_put+0xe/0x40 hugetlb_reserve_pages+0xa6/0x1d0 hugetlb_file_setup+0x102/0x2c0 newseg+0x115/0x360 ipcget+0x1ce/0x310 sys_shmget+0x5a/0x60 system_call_fastpath+0x16/0x1b This was reported by Dave Jones, but was reproducible with the libhugetlbfs test cases, so shame on me for not running them in the first place. With this, the oops is gone, and the output of libhugetlbfs's run_tests.py is identical to plain 3.4 again. [ Marked for stable, since this was introduced by commit c50ac050811d (hugetlb: fix resv_map leak in error path) which was also marked for stable ] Reported-by: Dave Jones da...@redhat.com Cc: Mel Gorman m...@csn.ul.ie Cc: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com Cc: Christoph Lameter c...@linux.com Cc: Andrea Arcangeli aarca...@redhat.com Cc: Andrew Morton a...@linux-foundation.org Signed-off-by: Linus Torvalds torva...@linux-foundation.org Signed-off-by: Ben Hutchings b...@decadent.org.uk --- mm/hugetlb.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 285a81e..e198831 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -3036,7 +3036,8 @@ int hugetlb_reserve_pages(struct inode *inode, region_add(inode-i_mapping-private_list, from, to); return 0; out_err: - resv_map_put(vma); + if (vma) + resv_map_put(vma); return ret; } -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 58/82] Bluetooth: Add support for Atheros [13d3:3362]
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: AceLan Kao acelan@canonical.com
commit 87522a433ba6886b5ccbb497e0a7cb8097def64e upstream.
Add another vendor specific ID for Atheros AR3012 device.
This chip is wrapped by IMC Networks.
output of usb-devices:
T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 5 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3362 Rev=00.02
S: Manufacturer=Atheros Communications
S: Product=Bluetooth USB Host Controller
S: SerialNumber=Alaska Day 2006
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
Signed-off-by: AceLan Kao acelan@canonical.com
Signed-off-by: Johan Hedberg johan.hedb...@intel.com
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
drivers/bluetooth/ath3k.c |2 ++
drivers/bluetooth/btusb.c |1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index ae9edca..639a161 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -75,6 +75,7 @@ static struct usb_device_id ath3k_table[] = {
{ USB_DEVICE(0x0CF3, 0x311D) },
{ USB_DEVICE(0x13d3, 0x3375) },
{ USB_DEVICE(0x04CA, 0x3005) },
+ { USB_DEVICE(0x13d3, 0x3362) },
/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE02C) },
@@ -94,6 +95,7 @@ static struct usb_device_id ath3k_blist_tbl[] = {
{ USB_DEVICE(0x0cf3, 0x311D), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x13d3, 0x3362), .driver_info = BTUSB_ATH3012 },
{ } /* Terminating entry */
};
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 9af450a..a497544 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -134,6 +134,7 @@ static struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x0cf3, 0x311d), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x13d3, 0x3362), .driver_info = BTUSB_ATH3012 },
/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xe02c), .driver_info = BTUSB_IGNORE },
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 45/82] ext4: remove mb_groups before tearing down the buddy_cache
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Salman Qazi sq...@google.com
commit 95599968d19db175829fb580baa6b68939b320fb upstream.
We can't have references held on pages in the s_buddy_cache while we are
trying to truncate its pages and put the inode. All the pages must be
gone before we reach clear_inode. This can only be gauranteed if we
can prevent new users from grabbing references to s_buddy_cache's pages.
The original bug can be reproduced and the bug fix can be verified by:
while true; do mount -t ext4 /dev/ram0 /export/hda3/ram0; \
umount /export/hda3/ram0; done
while true; do cat /proc/fs/ext4/ram0/mb_groups; done
Signed-off-by: Salman Qazi sq...@google.com
Signed-off-by: Theodore Ts'o ty...@mit.edu
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
fs/ext4/mballoc.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index 3d9277c..1cd6994 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -2517,6 +2517,9 @@ int ext4_mb_release(struct super_block *sb)
struct ext4_sb_info *sbi = EXT4_SB(sb);
struct kmem_cache *cachep = get_groupinfo_cache(sb-s_blocksize_bits);
+ if (sbi-s_proc)
+ remove_proc_entry(mb_groups, sbi-s_proc);
+
if (sbi-s_group_info) {
for (i = 0; i ngroups; i++) {
grinfo = ext4_get_group_info(sb, i);
@@ -2564,8 +2567,6 @@ int ext4_mb_release(struct super_block *sb)
}
free_percpu(sbi-s_locality_groups);
- if (sbi-s_proc)
- remove_proc_entry(mb_groups, sbi-s_proc);
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 75/82] ACPI battery: only refresh the sysfs files when pertinent information changes
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Andy Whitcroft a...@canonical.com
commit c5971456964290da7e98222892797b71ef793e62 upstream.
We only need to regenerate the sysfs files when the capacity units
change, avoid the update otherwise.
The origin of this issue is dates way back to 2.6.38:
da8aeb92d4853f37e281f11fddf61f9c7d84c3cd
(ACPI / Battery: Update information on info notification and resume)
Signed-off-by: Andy Whitcroft a...@canonical.com
Tested-by: Ralf Jung p...@ralfj.de
Signed-off-by: Len Brown len.br...@intel.com
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
drivers/acpi/battery.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 86933ca..7dd3f9f 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -643,11 +643,19 @@ static int acpi_battery_update(struct acpi_battery
*battery)
static void acpi_battery_refresh(struct acpi_battery *battery)
{
+ int power_unit;
+
if (!battery-bat.dev)
return;
+ power_unit = battery-power_unit;
+
acpi_battery_get_info(battery);
- /* The battery may have changed its reporting units. */
+
+ if (power_unit == battery-power_unit)
+ return;
+
+ /* The battery has changed its reporting units. */
sysfs_remove_battery(battery);
sysfs_add_battery(battery);
}
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 36/82] slub: fix a memory leak in get_partial_node()
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Joonsoo Kim js1...@gmail.com
commit 02d7633fa567be7bf55a993b79d2a31b95ce2227 upstream.
In the case which is below,
1. acquire slab for cpu partial list
2. free object to it by remote cpu
3. page-freelist = t
then memory leak is occurred.
Change acquire_slab() not to zap freelist when it works for cpu partial list.
I think it is a sufficient solution for fixing a memory leak.
Below is output of 'slabinfo -r kmalloc-256'
when './perf stat -r 30 hackbench 50 process 4000 /dev/null' is done.
***Vanilla***
Sizes (bytes) Slabs DebugMemory
Object : 256 Total : 468 Sanity Checks : Off Total: 3833856
SlabObj: 256 Full : 111 Redzoning : Off Used : 2004992
SlabSiz:8192 Partial: 302 Poisoning : Off Loss : 1828864
Loss : 0 CpuSlab: 55 Tracking : Off Lalig: 0
Align : 8 Objects: 32 Tracing : Off Lpadd: 0
***Patched***
Sizes (bytes) Slabs DebugMemory
Object : 256 Total : 300 Sanity Checks : Off Total: 2457600
SlabObj: 256 Full : 204 Redzoning : Off Used : 2348800
SlabSiz:8192 Partial: 33 Poisoning : Off Loss : 108800
Loss : 0 CpuSlab: 63 Tracking : Off Lalig: 0
Align : 8 Objects: 32 Tracing : Off Lpadd: 0
Total and loss number is the impact of this patch.
Acked-by: Christoph Lameter c...@linux.com
Signed-off-by: Joonsoo Kim js1...@gmail.com
Signed-off-by: Pekka Enberg penb...@kernel.org
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
mm/slub.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1506,15 +1506,19 @@
freelist = page-freelist;
counters = page-counters;
new.counters = counters;
- if (mode)
+ if (mode) {
new.inuse = page-objects;
+ new.freelist = NULL;
+ } else {
+ new.freelist = freelist;
+ }
VM_BUG_ON(new.frozen);
new.frozen = 1;
} while (!__cmpxchg_double_slab(s, page,
freelist, counters,
- NULL, new.counters,
+ new.freelist, new.counters,
lock and freeze));
remove_partial(n, page);
@@ -1556,7 +1560,6 @@
object = t;
available = page-objects - page-inuse;
} else {
- page-freelist = t;
available = put_cpu_partial(s, page, 0);
}
if (kmem_cache_debug(s) || available s-cpu_partial / 2)
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 49/82] drm/ttm: Fix spinlock imbalance
3.2-stable review patch. If anyone has any objections, please let me know. -- From: Thomas Hellstrom thellst...@vmware.com commit a8ff3ee211fccf708e1911bbc096625453ebf759 upstream. This imbalance may cause hangs when TTM is trying to swap out a buffer that is already on the delayed delete list. Signed-off-by: Thomas Hellstrom thellst...@vmware.com Reviewed-by: Jakob Bornecrantz ja...@vmware.com Signed-off-by: Dave Airlie airl...@redhat.com Signed-off-by: Ben Hutchings b...@decadent.org.uk --- drivers/gpu/drm/ttm/ttm_bo.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 36792bd..b67cfca 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -1834,6 +1834,7 @@ static int ttm_bo_swapout(struct ttm_mem_shrink *shrink) spin_unlock(glob-lru_lock); (void) ttm_bo_cleanup_refs(bo, false, false, false); kref_put(bo-list_kref, ttm_bo_release_list); + spin_lock(glob-lru_lock); continue; } -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 67/82] l2tp: fix oops in L2TP IP sockets for connect() AF_UNSPEC case
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: James Chapman jchap...@katalix.com
[ Upstream commit c51ce49735c183ef2592db70f918ee698716276b ]
An application may call connect() to disconnect a socket using an
address with family AF_UNSPEC. The L2TP IP sockets were not handling
this case when the socket is not bound and an attempt to connect()
using AF_UNSPEC in such cases would result in an oops. This patch
addresses the problem by protecting the sk_prot-disconnect() call
against trying to unhash the socket before it is bound.
The patch also adds more checks that the sockaddr supplied to bind()
and connect() calls is valid.
RIP: 0010:[82e133b0] [82e133b0] inet_unhash+0x50/0xd0
RSP: 0018:88001989be28 EFLAGS: 00010293
Stack:
8800407a8000 88001989be78 82e3a249
82e3a050 88001989bec8 88001989be88 8800407a8000
0010 88001989bec8 88001989bea8 82e42639
Call Trace:
[82e3a249] udp_disconnect+0x1f9/0x290
[82e42639] inet_dgram_connect+0x29/0x80
[82d012fc] sys_connect+0x9c/0x100
Reported-by: Sasha Levin levinsasha...@gmail.com
Signed-off-by: James Chapman jchap...@katalix.com
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
net/l2tp/l2tp_ip.c | 30 --
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/net/l2tp/l2tp_ip.c b/net/l2tp/l2tp_ip.c
index 2a2a3e7..2fbbe1f 100644
--- a/net/l2tp/l2tp_ip.c
+++ b/net/l2tp/l2tp_ip.c
@@ -251,9 +251,16 @@ static int l2tp_ip_bind(struct sock *sk, struct sockaddr
*uaddr, int addr_len)
{
struct inet_sock *inet = inet_sk(sk);
struct sockaddr_l2tpip *addr = (struct sockaddr_l2tpip *) uaddr;
- int ret = -EINVAL;
+ int ret;
int chk_addr_ret;
+ if (!sock_flag(sk, SOCK_ZAPPED))
+ return -EINVAL;
+ if (addr_len sizeof(struct sockaddr_l2tpip))
+ return -EINVAL;
+ if (addr-l2tp_family != AF_INET)
+ return -EINVAL;
+
ret = -EADDRINUSE;
read_lock_bh(l2tp_ip_lock);
if (__l2tp_ip_bind_lookup(init_net, addr-l2tp_addr.s_addr,
sk-sk_bound_dev_if, addr-l2tp_conn_id))
@@ -283,6 +290,8 @@ static int l2tp_ip_bind(struct sock *sk, struct sockaddr
*uaddr, int addr_len)
sk_del_node_init(sk);
write_unlock_bh(l2tp_ip_lock);
ret = 0;
+ sock_reset_flag(sk, SOCK_ZAPPED);
+
out:
release_sock(sk);
@@ -303,13 +312,14 @@ static int l2tp_ip_connect(struct sock *sk, struct
sockaddr *uaddr, int addr_len
__be32 saddr;
int oif, rc;
- rc = -EINVAL;
+ if (sock_flag(sk, SOCK_ZAPPED)) /* Must bind first - autobinding does
not work */
+ return -EINVAL;
+
if (addr_len sizeof(*lsa))
- goto out;
+ return -EINVAL;
- rc = -EAFNOSUPPORT;
if (lsa-l2tp_family != AF_INET)
- goto out;
+ return -EAFNOSUPPORT;
lock_sock(sk);
@@ -363,6 +373,14 @@ out:
return rc;
}
+static int l2tp_ip_disconnect(struct sock *sk, int flags)
+{
+ if (sock_flag(sk, SOCK_ZAPPED))
+ return 0;
+
+ return udp_disconnect(sk, flags);
+}
+
static int l2tp_ip_getname(struct socket *sock, struct sockaddr *uaddr,
int *uaddr_len, int peer)
{
@@ -598,7 +616,7 @@ static struct proto l2tp_ip_prot = {
.close = l2tp_ip_close,
.bind = l2tp_ip_bind,
.connect = l2tp_ip_connect,
- .disconnect= udp_disconnect,
+ .disconnect= l2tp_ip_disconnect,
.ioctl = udp_ioctl,
.destroy = l2tp_ip_destroy_sock,
.setsockopt= ip_setsockopt,
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 40/82] vfs: increment iversion when a file is truncated
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Dmitry Kasatkin dmitry.kasat...@intel.com
commit 799243a389bde0de10fa21ca1ca453d2fe538b85 upstream.
When a file is truncated with truncate()/ftruncate() and then closed,
iversion is not updated. This patch uses ATTR_SIZE flag as an indication
to increment iversion.
Mimi said:
On fput(), i_version is used to detect and flag files that have changed
and need to be re-measured in the IMA measurement policy. When a file
is truncated with truncate()/ftruncate() and then closed, i_version is
not updated. As a result, although the file has changed, it will not be
re-measured and added to the IMA measurement list on subsequent access.
Signed-off-by: Dmitry Kasatkin dmitry.kasat...@intel.com
Acked-by: Mimi Zohar zo...@us.ibm.com
Cc: Al Viro v...@zeniv.linux.org.uk
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Al Viro v...@zeniv.linux.org.uk
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
fs/attr.c |5 +
1 file changed, 5 insertions(+)
--- a/fs/attr.c
+++ b/fs/attr.c
@@ -176,6 +176,11 @@
return -EPERM;
}
+ if ((ia_valid ATTR_SIZE) IS_I_VERSION(inode)) {
+ if (attr-ia_size != inode-i_size)
+ inode_inc_iversion(inode);
+ }
+
if ((ia_valid ATTR_MODE)) {
mode_t amode = attr-ia_mode;
/* Flag setting protected by i_mutex */
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 26/82] ath9k: fix a use-after-free-bug when ath_tx_setup_buffer() fails
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Felix Fietkau n...@openwrt.org
commit 81357a281dcc454841532c46b30e6f2ba12b73ea upstream.
ath_tx_setup_buffer() can fail if there is no ath_buf left, or if mapping DMA
failed. In this case it frees the skb passed to it.
If ath_tx_setup_buffer is called from ath_tx_form_aggr, the skb is still
linked into the tid buffer list and must be dequeued before being released.
Signed-off-by: Felix Fietkau n...@openwrt.org
Signed-off-by: John W. Linville linvi...@tuxdriver.com
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
drivers/net/wireless/ath/ath9k/xmit.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -64,7 +64,8 @@
static struct ath_buf *ath_tx_setup_buffer(struct ath_softc *sc,
struct ath_txq *txq,
struct ath_atx_tid *tid,
- struct sk_buff *skb);
+ struct sk_buff *skb,
+ bool dequeue);
enum {
MCS_HT20,
@@ -761,7 +762,7 @@
fi = get_frame_info(skb);
bf = fi-bf;
if (!fi-bf)
- bf = ath_tx_setup_buffer(sc, txq, tid, skb);
+ bf = ath_tx_setup_buffer(sc, txq, tid, skb, true);
if (!bf)
continue;
@@ -1669,7 +1670,7 @@
return;
}
- bf = ath_tx_setup_buffer(sc, txctl-txq, tid, skb);
+ bf = ath_tx_setup_buffer(sc, txctl-txq, tid, skb, false);
if (!bf)
return;
@@ -1696,7 +1697,7 @@
bf = fi-bf;
if (!bf)
- bf = ath_tx_setup_buffer(sc, txq, tid, skb);
+ bf = ath_tx_setup_buffer(sc, txq, tid, skb, false);
if (!bf)
return;
@@ -1761,7 +1762,8 @@
static struct ath_buf *ath_tx_setup_buffer(struct ath_softc *sc,
struct ath_txq *txq,
struct ath_atx_tid *tid,
- struct sk_buff *skb)
+ struct sk_buff *skb,
+ bool dequeue)
{
struct ath_common *common = ath9k_hw_common(sc-sc_ah);
struct ath_frame_info *fi = get_frame_info(skb);
@@ -1802,6 +1804,8 @@
return bf;
error:
+ if (dequeue)
+ __skb_unlink(skb, tid-buf_q);
dev_kfree_skb_any(skb);
return NULL;
}
@@ -1833,7 +1837,7 @@
*/
ath_tx_send_ampdu(sc, tid, skb, txctl);
} else {
- bf = ath_tx_setup_buffer(sc, txctl-txq, tid, skb);
+ bf = ath_tx_setup_buffer(sc, txctl-txq, tid, skb, false);
if (!bf)
goto out;
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 20/82] [PARISC] fix TLB fault path on PA2.0 narrow systems
3.2-stable review patch. If anyone has any objections, please let me know. -- From: James Bottomley jbottom...@parallels.com commit 2f649c1f6f0fef445ce79a19b79e5ce8fe9d7f19 upstream. commit 5e185581d7c46ddd33cd9c01106d1fc86efb9376 Author: James Bottomley jbottom...@parallels.com [PARISC] fix PA1.1 oops on boot Didn't quite fix the crash on boot. It moved it from PA1.1 processors to PA2.0 narrow kernels. The final fix is to make sure the [id]tlb_miss_20 paths also work. Even on narrow systems, these paths require using the wide instructions becuase the tlb insertion format is wide. Fix this by conditioning the dep[wd],z on whether we're being called from _11 or _20[w] paths. Tested-by: Helge Deller del...@gmx.de Signed-off-by: James Bottomley jbottom...@parallels.com Signed-off-by: Ben Hutchings b...@decadent.org.uk --- arch/parisc/kernel/entry.S | 30 +- 1 file changed, 17 insertions(+), 13 deletions(-) diff --git a/arch/parisc/kernel/entry.S b/arch/parisc/kernel/entry.S index 5350342..07ef351 100644 --- a/arch/parisc/kernel/entry.S +++ b/arch/parisc/kernel/entry.S @@ -552,7 +552,7 @@ * entry (identifying the physical page) and %r23 up with * the from tlb entry (or nothing if only a to entry---for * clear_user_page_asm) */ - .macro do_aliasspc,tmp,tmp1,va,pte,prot,fault + .macro do_aliasspc,tmp,tmp1,va,pte,prot,fault,patype cmpib,COND(),n 0,\spc,\fault ldilL%(TMPALIAS_MAP_START),\tmp #if defined(CONFIG_64BIT) (TMPALIAS_MAP_START = 0x8000) @@ -581,11 +581,15 @@ */ cmpiclr,= 0x01,\tmp,%r0 ldi (_PAGE_DIRTY|_PAGE_READ|_PAGE_WRITE),\prot -#ifdef CONFIG_64BIT +.ifc \patype,20 depd,z \prot,8,7,\prot -#else +.else +.ifc \patype,11 depw,z \prot,8,7,\prot -#endif +.else + .error undefined PA type to do_alias +.endif +.endif /* * OK, it is in the temp alias region, check whether from or to. * Check subtle note in pacache.S re: r23/r26. @@ -1189,7 +1193,7 @@ dtlb_miss_20w: nop dtlb_check_alias_20w: - do_aliasspc,t0,t1,va,pte,prot,dtlb_fault + do_aliasspc,t0,t1,va,pte,prot,dtlb_fault,20 idtlbt pte,prot @@ -1213,7 +1217,7 @@ nadtlb_miss_20w: nop nadtlb_check_alias_20w: - do_aliasspc,t0,t1,va,pte,prot,nadtlb_emulate + do_aliasspc,t0,t1,va,pte,prot,nadtlb_emulate,20 idtlbt pte,prot @@ -1245,7 +1249,7 @@ dtlb_miss_11: nop dtlb_check_alias_11: - do_aliasspc,t0,t1,va,pte,prot,dtlb_fault + do_aliasspc,t0,t1,va,pte,prot,dtlb_fault,11 idtlba pte,(va) idtlbp prot,(va) @@ -1277,7 +1281,7 @@ nadtlb_miss_11: nop nadtlb_check_alias_11: - do_aliasspc,t0,t1,va,pte,prot,nadtlb_emulate + do_aliasspc,t0,t1,va,pte,prot,nadtlb_emulate,11 idtlba pte,(va) idtlbp prot,(va) @@ -1304,7 +1308,7 @@ dtlb_miss_20: nop dtlb_check_alias_20: - do_aliasspc,t0,t1,va,pte,prot,dtlb_fault + do_aliasspc,t0,t1,va,pte,prot,dtlb_fault,20 idtlbt pte,prot @@ -1330,7 +1334,7 @@ nadtlb_miss_20: nop nadtlb_check_alias_20: - do_aliasspc,t0,t1,va,pte,prot,nadtlb_emulate + do_aliasspc,t0,t1,va,pte,prot,nadtlb_emulate,20 idtlbt pte,prot @@ -1457,7 +1461,7 @@ naitlb_miss_20w: nop naitlb_check_alias_20w: - do_aliasspc,t0,t1,va,pte,prot,naitlb_fault + do_aliasspc,t0,t1,va,pte,prot,naitlb_fault,20 iitlbt pte,prot @@ -1511,7 +1515,7 @@ naitlb_miss_11: nop naitlb_check_alias_11: - do_aliasspc,t0,t1,va,pte,prot,itlb_fault + do_aliasspc,t0,t1,va,pte,prot,itlb_fault,11 iitlba pte,(%sr0, va) iitlbp prot,(%sr0, va) @@ -1557,7 +1561,7 @@ naitlb_miss_20: nop naitlb_check_alias_20: - do_aliasspc,t0,t1,va,pte,prot,naitlb_fault + do_aliasspc,t0,t1,va,pte,prot,naitlb_fault,20 iitlbt pte,prot -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 16/82] drm/i915: always use RPNSWREQ for turbo change requests
3.2-stable review patch. If anyone has any objections, please let me know. -- From: Jesse Barnes jbar...@virtuousgeek.org commit 89ba829e38bd500f438bc08af4229204c8ed7f35 upstream. Media turbo requests can either use RPVSWREQ or RPNSWREQ to indicate what the interrupt handler should do. Since we only deal with the latter in our turbo code, make the media engine use that for turbo requests. Tested-by: Joe Bloggsian joebloggs...@gmail.com Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings b...@decadent.org.uk --- drivers/gpu/drm/i915/intel_display.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8005,7 +8005,7 @@ I915_WRITE(GEN6_RP_IDLE_HYSTERSIS, 10); I915_WRITE(GEN6_RP_CONTROL, GEN6_RP_MEDIA_TURBO | - GEN6_RP_MEDIA_HW_MODE | + GEN6_RP_MEDIA_HW_NORMAL_MODE | GEN6_RP_MEDIA_IS_GFX | GEN6_RP_ENABLE | GEN6_RP_UP_BUSY_AVG | -- To unsubscribe from this list: send the line unsubscribe stable in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 38/82] ext4: disallow hard-linked directory in ext4_lookup
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Andreas Dilger adil...@dilger.ca
commit 7e936b737211e6b54e34b71a827e56b872e958d8 upstream.
A hard-linked directory to its parent can cause the VFS to deadlock,
and is a sign of a corrupted file system. So detect this case in
ext4_lookup(), before the rmdir() lockup scenario can take place.
Signed-off-by: Andreas Dilger adil...@dilger.ca
Signed-off-by: Theodore Ts'o ty...@mit.edu
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
fs/ext4/namei.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index a9fd5f4..daf8260 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1330,6 +1330,12 @@ static struct dentry *ext4_lookup(struct inode *dir,
struct dentry *dentry, stru
EXT4_ERROR_INODE(dir, bad inode number: %u, ino);
return ERR_PTR(-EIO);
}
+ if (unlikely(ino == dir-i_ino)) {
+ EXT4_ERROR_INODE(dir, '%.*s' linked to parent dir,
+dentry-d_name.len,
+dentry-d_name.name);
+ return ERR_PTR(-EIO);
+ }
inode = ext4_iget(dir-i_sb, ino);
if (inode == ERR_PTR(-ESTALE)) {
EXT4_ERROR_INODE(dir,
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ 59/82] Bluetooth: Add support for AR3012 [0cf3:e004]
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: AceLan Kao acelan@canonical.com
commit ac71311e65e2c4c2dbac76db698fecbee755b016 upstream.
Add another vendor specific ID for Atheros AR3012
output of usb-devices:
T: Bus=02 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0cf3 ProdID=e004 Rev=00.02
S: Manufacturer=Atheros Communications
S: Product=Bluetooth USB Host Controller
S: SerialNumber=Alaska Day 2006
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
BugLink: https://bugs.launchpad.net/bugs/922715
Signed-off-by: AceLan Kao acelan@canonical.com
Signed-off-by: Marcel Holtmann mar...@holtmann.org
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
drivers/bluetooth/ath3k.c |2 ++
drivers/bluetooth/btusb.c |1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index 639a161..57fd867 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -76,6 +76,7 @@ static struct usb_device_id ath3k_table[] = {
{ USB_DEVICE(0x13d3, 0x3375) },
{ USB_DEVICE(0x04CA, 0x3005) },
{ USB_DEVICE(0x13d3, 0x3362) },
+ { USB_DEVICE(0x0CF3, 0xE004) },
/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE02C) },
@@ -96,6 +97,7 @@ static struct usb_device_id ath3k_blist_tbl[] = {
{ USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3362), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
{ } /* Terminating entry */
};
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index a497544..93cc828 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -135,6 +135,7 @@ static struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3362), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xe02c), .driver_info = BTUSB_IGNORE },
--
To unsubscribe from this list: send the line unsubscribe stable in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
