On Sun, Apr 14, 2013 at 07:17:22PM -0700, Greg KH wrote:
> On Mon, Apr 15, 2013 at 03:12:24AM +0100, Ben Hutchings wrote:
> > Brad Spengler pointed out that some KVM security fixes are missing from
> > the 3.2 branches. Three recent commits were marked as such:
> >
> > c300aa64ddf5 KVM: x86: fix
On Mon, 2013-04-15 at 15:05 -0700, Andrew Honig wrote:
> As they are these patches will cause issues for some guests
> (particular RHEL5) which uses non 32-byte aligned addresses. The
> documentation specified the alignment requirement, but guests got away
> with ignoring that requirement and thro
On 2013/4/15 22:15, Jonghwan Choi wrote:
> From: libin
>
> This patch looks like it should be in the 3.8-stable tree, should we apply
> it?
>
yes, I think this patch should be applied to the 3.8-stable tree. Thanks.
Libin
> --
>
> From: "libin "
>
> commit fd9b86d37a600488dbd
Greg KH twisted the bytes to say:
>> http://o.cs.uvic.ca:20810/perl/next.pl
Greg> Yes, that's a great thing. Maybe the ability to see the subject: line
Greg> of the commit somewhere easier than having to click through to the patch
Greg> would be nice, so we can just glance at the report a
On Mon, Apr 15, 2013 at 02:49:34PM -0700, D M German wrote:
>
>
> Greg KH twisted the bytes to say:
>
> Greg> But, for the linux-next stuff, that could be very interesting. We
> Greg> always like seeing what commits in a -rc1 release did NOT previously
> Greg> show up in linux-next. Stephen
This is a note to let you know that I've just added the patch titled
mtd: Disable mtdchar mmap on MMU systems
to the 3.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
mtd-disable-mtd
This is a note to let you know that I've just added the patch titled
mtd: Disable mtdchar mmap on MMU systems
to the 3.0-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
mtd-disable-mtd
On Mon, Apr 15, 2013 at 09:55:20PM +0100, David Woodhouse wrote:
> On Sun, 2013-04-14 at 19:17 -0700, Greg Kroah-Hartman wrote:
> > 3.0-stable review patch. If anyone has any objections, please let me know.
>
> Please use f5cf8f07423b2677cebebcebc863af77223a4972 instead (for 3.4
> too).
Really?
As they are these patches will cause issues for some guests
(particular RHEL5) which uses non 32-byte aligned addresses. The
documentation specified the alignment requirement, but guests got away
with ignoring that requirement and through random luck it never caused
an issue before.
https://git.k
Greg KH twisted the bytes to say:
Greg> But, for the linux-next stuff, that could be very interesting. We
Greg> always like seeing what commits in a -rc1 release did NOT previously
Greg> show up in linux-next. Stephen has some tools on how to do this, it
Greg> would be interesting to see i
On Sun, 2013-04-14 at 19:17 -0700, Greg Kroah-Hartman wrote:
> 3.0-stable review patch. If anyone has any objections, please let me know.
Please use f5cf8f07423b2677cebebcebc863af77223a4972 instead (for 3.4
too).
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
On Fri, Apr 12, 2013 at 06:16:53PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We may have DDI_BUF_CTL(PORT_A) configured with 2 lanes and still not
> have CRT, so just check for !IS_ULT. This problem happened on a real
> machine and resulted in a very ugly dmesg.
>
> Cc: stable@vger.ker
On Mon, Apr 15, 2013 at 03:37:36PM -0400, Peter Hurley wrote:
> [ -cc Alan Cox ]
>
> On Sun, 2013-04-14 at 19:43 -0700, Greg Kroah-Hartman wrote:
> > 3.8-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Sebastian Andrzej Siewior
>
[ -cc Alan Cox ]
On Sun, 2013-04-14 at 19:43 -0700, Greg Kroah-Hartman wrote:
> 3.8-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Sebastian Andrzej Siewior
>
> commit 852e4a8152b427c3f318bb0e1b5e938d64dcdc32 upstream.
Greg,
So many o
On Mon, Apr 15, 2013 at 11:21:32AM -0700, dmg wrote:
> Hi Ben,
>
> On 4/13/13, Ben Hutchings wrote:
[...]
> > It should be possible to find such backported commits based on a simple
> > regex search over the commit message:
>
> I took a more aggressive approach. I decided to look for 40 length
>
From: Ben Hutchings
Date: Mon, 15 Apr 2013 01:03:00 +0100
> Brad Spengler pointed out there was one missing, which seems to be this
> one:
>
> commit 586c31f3bf04c290dc0a0de7fc91d20aa9a5ee53
> Author: Daniel Borkmann
> Date: Thu Feb 7 00:55:37 2013 +
>
> net: sctp: sctp_auth_key_put:
Hi Ben,
On 4/13/13, Ben Hutchings wrote:
> I notice that where a commit is cherry-picked cleanly on a stable
> branch, like 6b90466cfec2a2fe027187d675d8d14217c12d82, your script finds
> the corresponding commit on the stable branch. This is useful.
>
> But where some backporting changes are need
This is a note to let you know that I've just added the patch titled
serial_core.c: add put_device() after device_find_child()
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-next branch.
The patch will show up in the next
minimum...@rambler.ru writes:
> From: "Alex A. Mihaylov"
>
> Some cards on Ralink RT30xx chipset not have correctly TX_MIXER_GAIN
> value in them EEPROM/EFUSE. In this case, we must use default value,
> but always used EEPROM/EFUSE value. As result we have tranmitt power
> range from -10dBm to +6
commit: 84cc8fd2fe65866e49d70b38b3fdf7219dd92fe0
From: Michael Bohan
Date: Tue, 19 Mar 2013 19:19:25 -0700
Subject: hrtimer: Don't reinitialize a cpu_base lock on CPU_UP
The current code makes the assumption that a cpu_base lock won't be
held if the CPU corresponding to that cpu_base is offline,
commit: f2530dc71cf0822f90bb63ea4600caaef33a66bb
From: Thomas Gleixner
Date: Tue, 9 Apr 2013 09:33:34 +0200
Subject: kthread: Prevent unpark race which puts threads on the wrong cpu
The smpboot threads rely on the park/unpark mechanism which binds per
cpu threads on a particular core. Though the
On Mon, Apr 15, 2013 at 08:05:24AM -0600, Shuah Khan wrote:
> On Sun, Apr 14, 2013 at 8:42 PM, Greg Kroah-Hartman
> wrote:
> > This is the start of the stable review cycle for the 3.8.8 release.
> > There are 27 patches in this series, all will be posted as a response
> > to this one. If anyone h
On Mon, Apr 15, 2013 at 5:29 AM, wrote:
> From: "Alex A. Mihaylov"
>
> Some cards on Ralink RT30xx chipset not have correctly TX_MIXER_GAIN
> value in them EEPROM/EFUSE. In this case, we must use default value,
> but always used EEPROM/EFUSE value. As result we have tranmitt power
> range from -
On Mon, Apr 15, 2013 at 10:18 AM, Alex Mihaylov wrote:
>
> Good day!
>
>> > From: "Alex A. Mihaylov"
>> > Some cards on Ralink RT30xx chipset not have correctly TX_MIXER_GAIN
>> > value in them EEPROM/EFUSE. In this case, we must use default value,
>> > but always used EEPROM/EFUSE value. As resu
From: libin
This patch looks like it should be in the 3.8-stable tree, should we apply
it?
--
From: "libin "
commit fd9b86d37a600488dbd80fe60cca46b822bff1cd upstream
Commit 201c373e8e ("sched/debug: Limit sd->*_idx range on
sysctl") was an incomplete bug fix.
This patch fixes
Hello,
Chris Dunlop has discovered that a few block layer changes have made it
into stable without a corresponding MD RAID change:
http://thread.gmane.org/gmane.linux.raid/42416
WRITE SAME was broken in MD RAID 1/10 up until:
c8dc9c6 md: raid1,10: Handle REQ_WRITE_SAME flag in write bios
a
On Sun, Apr 14, 2013 at 8:42 PM, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 3.8.8 release.
> There are 27 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Resp
On Sun, Apr 14, 2013 at 8:25 PM, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 3.4.41 release.
> There are 17 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Res
On Sun, Apr 14, 2013 at 8:17 PM, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 3.0.74 release.
> There are 11 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Res
On Sat, Apr 13, 2013 at 12:26:32PM +0200, Francois Romieu wrote:
> From: Hayes Wang
>
> commit e2409d83434d77874b461b78af6a19cd6e6a1280 upstream.
Thanks, I'm queuing it for 3.5 kernel as well.
Cheers,
--
Luis
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a
On Mon, Apr 15, 2013 at 01:27:10AM +0100, Ben Hutchings wrote:
> Brad Spengler pointed out this fix from 3.6 was missing from the earlier
> stable branches:
>
> commit 9c603e53d380459fb62fec7cd085acb0b74ac18f
> Author: Linus Torvalds
> Date: Sat Sep 8 12:57:30 2012 -0700
>
> mtdchar: fix o
Good day!
> From: "Alex A. Mihaylov"
> Some cards on Ralink RT30xx chipset not have correctly TX_MIXER_GAIN
> value in them EEPROM/EFUSE. In this case, we must use default value,
> but always used EEPROM/EFUSE value. As result we have tranmitt power
> range from -10dBm to +6dBm instead 0dBm to
On Mon, Apr 15, 2013 at 5:29 AM, wrote:
> From: "Alex A. Mihaylov"
>
> Some cards on Ralink RT30xx chipset not have correctly TX_MIXER_GAIN
> value in them EEPROM/EFUSE. In this case, we must use default value,
> but always used EEPROM/EFUSE value. As result we have tranmitt power
> range from -
33 matches
Mail list logo
