On Tue, Nov 19, 2013 at 02:35:37PM -0700, Bjorn Helgaas wrote:
> The following patches fix issues reported by Yuval Mintz
> and Myron Stowe .
>
> These fix pcie_capability_read_dword() and related accessors, which first
> appeared in v3.7. I backported these to v3.10.19 because that appears to
>
On 11/19/2013 03:09 PM, Greg Kroah-Hartman wrote:
On Tue, Nov 19, 2013 at 10:50:00AM +, Luis Henriques wrote:
Hi Greg,
On Mon, Nov 18, 2013 at 10:41:34AM -0800, Greg Kroah-Hartman wrote:
3.4-stable review patch. If anyone has any objections, please let me know.
I guess you can drop thi
Jonghwan Choi writes:
> This patch looks like it should be in the 3.11-stable tree, should we apply
> it?
Well, do you think a kmemleak false positive which has been around for
years, and was only just noticed now, is suddenly important?
If so, I need to send a lot more patches to stable. In fa
Jonghwan Choi writes:
> This patch looks like it should be in the 3.11-stable tree, should we apply
> it?
No. We've had the issue that broken devices can do bad things since
2008. But we've not hit any reports in the field, that I am aware of.
Cheers,
Rusty.
>
> --
>
> From: "H
Jonghwan Choi writes:
> This patch looks like it should be in the 3.11-stable tree, should we apply
> it?
No. Supporting BE on virtio_mmio is in fact a new feature. And this
doesn't make it work anyway.
Grumble,
Rusty.
> --
>
> From: "Marc Zyngier "
>
> commit 4ae8537072015602
On Tue, Nov 19, 2013 at 10:50:00AM +, Luis Henriques wrote:
> Hi Greg,
>
> On Mon, Nov 18, 2013 at 10:41:34AM -0800, Greg Kroah-Hartman wrote:
> > 3.4-stable review patch. If anyone has any objections, please let me know.
> >
>
> I guess you can drop this commit because, as Ben has already
Subject: + ipcshm-fix-shm_file-deletion-races.patch added to -mm tree
To:
gthe...@google.com,davidl...@hp.com,manf...@colorfullife.com,r...@redhat.com,stable@vger.kernel.org
From: a...@linux-foundation.org
Date: Tue, 19 Nov 2013 14:43:04 -0800
The patch titled
Subject: ipc,shm: fix shm_file
On Tue, Nov 19, 2013 at 2:35 PM, Bjorn Helgaas wrote:
> Commit 6d3a1741f1e648cfbd5a0cc94477a0d5004c6f5e upstream. This is part
> of the fix for https://bugzilla.kernel.org/show_bug.cgi?id=65211
>
> Previously we allowed callers to access Slot Capabilities, Status, and
> Control for Root Ports eve
On Tue, Nov 19, 2013 at 2:35 PM, Bjorn Helgaas wrote:
> Commit c8b303d0206b28c4ff3aecada47108d1655ae00f upstream. This is part
> of the fix for https://bugzilla.kernel.org/show_bug.cgi?id=65211
>
> Previously we relied on the PCIe r3.0, sec 7.8, spec language that says
> "For Functions that do no
Убежденный путь оказаться наихорошим партнером http://goo.gl/f7iMRd
--
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
Commit d3694d4fa3f44f6a295f8ab064937c8a1549d174 upstream.
Every PCIe device has a link, except Root Complex Integrated Endpoints
and Root Complex Event Collectors. Previously we didn't give access
to PCIe capability link-related registers for Upstream Ports, Downstream
Ports, and Bridges, so atte
Commit c8b303d0206b28c4ff3aecada47108d1655ae00f upstream. This is part
of the fix for https://bugzilla.kernel.org/show_bug.cgi?id=65211
Previously we relied on the PCIe r3.0, sec 7.8, spec language that says
"For Functions that do not implement the [Link, Slot, Root] registers,
these spaces must
Commit 6d3a1741f1e648cfbd5a0cc94477a0d5004c6f5e upstream. This is part
of the fix for https://bugzilla.kernel.org/show_bug.cgi?id=65211
Previously we allowed callers to access Slot Capabilities, Status, and
Control for Root Ports even if the Root Port did not implement a slot.
This seems dubious
The following patches fix issues reported by Yuval Mintz
and Myron Stowe .
These fix pcie_capability_read_dword() and related accessors, which first
appeared in v3.7. I backported these to v3.10.19 because that appears to
be the oldest maintained stable kernel that is affected.
These patches re
From: Johannes Berg
The station ID must be valid, if it's out of range then
the array access may crash. Validate the station ID to
the array length, and also validate the drain value even
if that doesn't matter all that much.
Cc: stable@vger.kernel.org
Fixes: 8ca151b568b6 ("iwlwifi: add the MVM
On 19.11.2013 19:48, Greg KH wrote:
> On Tue, Nov 19, 2013 at 05:59:13PM +0100, Christoph Rudorff wrote:
>> Current code disables fbcon acceleration before fbcon is suspended,
>> leading to corrupted console after resume from s2disk. In a similar
>> fashion we must make sure that fbcon acceleration
On Mon, Nov 18, 2013 at 07:07:29PM -0800, Guenter Roeck wrote:
> On Mon, Nov 18, 2013 at 10:41:33AM -0800, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.4.70 release.
> > There are 12 patches in this series, all will be posted as a response
> > to this one. I
On Tue, Nov 19, 2013 at 05:59:13PM +0100, Christoph Rudorff wrote:
> Current code disables fbcon acceleration before fbcon is suspended,
> leading to corrupted console after resume from s2disk. In a similar
> fashion we must make sure that fbcon acceleration is enabled before we
> revive the consol
On Mon, Nov 18, 2013 at 12:17 PM, Bjorn Helgaas wrote:
> The following two patches fix issues reported by Yuval Mintz
> and Adam Lee .
>
> These backports are for 3.10.x and 3.11.x.
>
> 3.4.x and earlier stable kernels do not need these fixes because they
> do not have the pcie_capability_*() acc
Current code disables fbcon acceleration before fbcon is suspended,
leading to corrupted console after resume from s2disk. In a similar
fashion we must make sure that fbcon acceleration is enabled before we
revive the console.
With this patch s2disk works correctly on my MacBookPro6,2 with GT216
[
> From: Eric Dumazet [mailto:eric.duma...@gmail.com]
> On Tue, 2013-11-19 at 14:43 +, David Laight wrote:
>
> > It isn't directly a TSO problem.
> > There has always been a bug in the xhci driver for fragmented buffers.
> > TSO just means it is given a lot of fragmented buffers.
> >
> > As wel
On Tue, 2013-11-19 at 14:43 +, David Laight wrote:
> It isn't directly a TSO problem.
> There has always been a bug in the xhci driver for fragmented buffers.
> TSO just means it is given a lot of fragmented buffers.
>
> As well as user-supplied fragmented buffers, the bug affects
> internal
On Tue, Nov 19, 2013 at 05:51:54PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 18, 2013 at 07:38:16AM +0100, Daniel Vetter wrote:
> > Haswell's DDI encoders have their own ->get_config callback and in
> >
> > commit c6cd2ee2d59111a07cd9199564c9bdcb2d11e5cf
> > Author: Jani Nikula
> > Date: Mon Oc
On Mon, Nov 18, 2013 at 07:38:16AM +0100, Daniel Vetter wrote:
> Haswell's DDI encoders have their own ->get_config callback and in
>
> commit c6cd2ee2d59111a07cd9199564c9bdcb2d11e5cf
> Author: Jani Nikula
> Date: Mon Oct 21 10:52:07 2013 +0300
>
> drm/i915/dp: workaround BIOS eDP bpp clam
> From: Eric Dumazet [mailto:eric.duma...@gmail.com]
> On Tue, 2013-11-19 at 09:02 -0500, Mark Lord wrote:
> > On 13-11-19 05:04 AM, David Laight wrote:
> > >> From: Mark Lord
> > ..
> > >> except the ax88179_178a driver still does not work in linux-3.12,
> > >> whereas it works fine in all earlier
On 13-11-19 09:15 AM, Eric Dumazet wrote:
> On Tue, 2013-11-19 at 09:02 -0500, Mark Lord wrote:
>> On 13-11-19 05:04 AM, David Laight wrote:
From: Mark Lord
>> ..
except the ax88179_178a driver still does not work in linux-3.12,
whereas it works fine in all earlier kernels.
On 13-11-19 05:04 AM, David Laight wrote:
>> From: Mark Lord
..
>> except the ax88179_178a driver still does not work in linux-3.12,
>> whereas it works fine in all earlier kernels.
>>
>> That's a regression.
>> And a simple revert (earlier in this thread) fixes it.
>> So.. let's revert it for now,
On Tue, 2013-11-19 at 09:02 -0500, Mark Lord wrote:
> On 13-11-19 05:04 AM, David Laight wrote:
> >> From: Mark Lord
> ..
> >> except the ax88179_178a driver still does not work in linux-3.12,
> >> whereas it works fine in all earlier kernels.
> >>
> >> That's a regression.
> >> And a simple revert
On Tue, Nov 19, 2013 at 01:24:44PM +0100, Mike Galbraith wrote:
> On Tue, 2013-11-19 at 12:01 +0100, Peter Zijlstra wrote:
>
> > What idle function does the core2 use? Something like:
> >
> > perf record -a sleep 1; perf report
> >
> > Should show you the idle function on top if ran on a mostl
On Tue, 2013-11-19 at 12:01 +0100, Peter Zijlstra wrote:
> What idle function does the core2 use? Something like:
>
> perf record -a sleep 1; perf report
>
> Should show you the idle function on top if ran on a mostly idle system.
> I would be expecting mwait_idle_with_hints() for core2. And I
On Tue, Nov 19, 2013 at 08:13:35AM +0100, Mike Galbraith wrote:
> Hi Peter,
>
> 3.12 escaped without this regression being fixed, nor does the fix have
> a stable tag. Suspecting it may have just fallen through a crack...
Indeed, looks like a stable candidate, thanks for keeping track.
> core2
On Thu, Nov 07, 2013 at 12:09:59PM +0100, Eric Bénard wrote:
> From: Nicolas Pitre
>
> Commit 455bd4c430b0 ("ARM: 7668/1: fix memset-related crashes caused by
> recent GCC (4.7.2) optimizations") attempted to fix a compliance issue
> with the memset return value. However the memset itself became
Hi Greg,
On Mon, Nov 18, 2013 at 10:41:34AM -0800, Greg Kroah-Hartman wrote:
> 3.4-stable review patch. If anyone has any objections, please let me know.
>
I guess you can drop this commit because, as Ben has already pointed
out, it is required for kernels >= 3.11.
Cheers,
--
Luis
>
33 matches
Mail list logo
