Re: [PATCH] time: Revert ALWAYS_USE_PERSISTENT_CLOCK compile time optimizaitons

2013-04-24 Thread Feng Tang
On Wed, Apr 24, 2013 at 11:32:56AM -0700, John Stultz wrote: > Kay Sievers noted that the ALWAYS_USE_PERSISTENT_CLOCK config, > which enables some minor compile time optimization to avoid > uncessary code in mostly the suspend/resume path could cause > problems for userland. > > In particular, the

Re: [PATCH net] gianfar: do not advertise any alarm capability.

2013-04-24 Thread David Miller
From: Richard Cochran Date: Tue, 23 Apr 2013 07:42:16 +0200 > An early draft of the PHC patch series included an alarm in the > gianfar driver. During the review process, the alarm code was dropped, > but the capability removal was overlooked. This patch fixes the issue > by advertising zero alar

Re: [PATCH] hrtimer, add expiry time overflow check in hrtimer_interrupt

2013-04-24 Thread Guenter Roeck
On Thu, Apr 25, 2013 at 09:38:22AM +0800, Li Zefan wrote: > On 2013/4/25 6:42, Guenter Roeck wrote: > > On Mon, Apr 08, 2013 at 04:34:26PM -0400, Prarit Bhargava wrote: > >> > >> > >> On 04/08/2013 04:19 PM, John Stultz wrote: > >>> On 04/08/2013 05:47 AM, Prarit Bhargava wrote: > >> > >

Re: bonjour

2013-04-24 Thread michelemariesuzanne
JE SOUHAITE SOLLICITER VOTRE ACCORD POUR RÉALISER DES ŒŒUVRES HUMANITAIRE, POUR VENIR EN AIDE AUX ENFANTS DÉMUNIES AUX FAMILLES PAUVRES, D'OUVRIR DES ORPHELINATS ET CERTAINES ŒŒUVRES SOCIALES, DANS LE SOUCIS D'AIDER DES PERSONNES EN BESOIN, RENDRE HEUREUX LES FAMILLES PAUVRES, LES ORPHELINS, AID

Re: [PATCH] hrtimer, add expiry time overflow check in hrtimer_interrupt

2013-04-24 Thread Li Zefan
On 2013/4/25 6:42, Guenter Roeck wrote: > On Mon, Apr 08, 2013 at 04:34:26PM -0400, Prarit Bhargava wrote: >> >> >> On 04/08/2013 04:19 PM, John Stultz wrote: >>> On 04/08/2013 05:47 AM, Prarit Bhargava wrote: >> A simple check for an overflow can resolve this problem. Using KTIME_MAX >>

Re: [PATCH] hrtimer, add expiry time overflow check in hrtimer_interrupt

2013-04-24 Thread John Stultz
On 04/24/2013 05:35 PM, Guenter Roeck wrote: On Wed, Apr 24, 2013 at 05:05:03PM -0700, John Stultz wrote: On 04/24/2013 03:42 PM, Guenter Roeck wrote: On Mon, Apr 08, 2013 at 04:34:26PM -0400, Prarit Bhargava wrote: On 04/08/2013 04:19 PM, John Stultz wrote: On 04/08/2013 05:47 AM, Prarit Bha

Re: [PATCH] hrtimer, add expiry time overflow check in hrtimer_interrupt

2013-04-24 Thread Guenter Roeck
On Wed, Apr 24, 2013 at 05:05:03PM -0700, John Stultz wrote: > On 04/24/2013 03:42 PM, Guenter Roeck wrote: > >On Mon, Apr 08, 2013 at 04:34:26PM -0400, Prarit Bhargava wrote: > >> > >>On 04/08/2013 04:19 PM, John Stultz wrote: > >>>On 04/08/2013 05:47 AM, Prarit Bhargava wrote: > A simple chec

Re: [PATCH 3.8-stable] ARM: 7699/1: sched_clock: Add more notrace to prevent

2013-04-24 Thread Stephen Boyd
On 04/24/13 17:16, Jonghwan Choi wrote: > This patch looks like it should be in the 3.8-stable tree, should we apply > it? Sure. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe stab

[PATCH 3.8-stable] ARM: 7699/1: sched_clock: Add more notrace to prevent

2013-04-24 Thread Jonghwan Choi
This patch looks like it should be in the 3.8-stable tree, should we apply it? -- From: "Stephen Boyd " commit cea15092f098b7018e89f64a5a14bb71955965d5 upstream cyc_to_sched_clock() is called by sched_clock() and cyc_to_ns() is called by cyc_to_sched_clock(). I suspect that some

Re: [PATCH] hrtimer, add expiry time overflow check in hrtimer_interrupt

2013-04-24 Thread John Stultz
On 04/24/2013 03:42 PM, Guenter Roeck wrote: On Mon, Apr 08, 2013 at 04:34:26PM -0400, Prarit Bhargava wrote: On 04/08/2013 04:19 PM, John Stultz wrote: On 04/08/2013 05:47 AM, Prarit Bhargava wrote: A simple check for an overflow can resolve this problem. Using KTIME_MAX instead of the over

[PATCH 3.8-stable] ARM: 7692/1: iop3xx: move IOP3XX_PERIPHERAL_VIRT_BASE

2013-04-24 Thread Jonghwan Choi
This patch looks like it should be in the 3.8-stable tree, should we apply it? -- From: "Aaro Koskinen " commit f5d6a1441a5045824f36ff7c6b6bbae0373472a6 upstream Currently IOP3XX_PERIPHERAL_VIRT_BASE conflicts with PCI_IO_VIRT_BASE: addre

Re: [PATCH v2] kmsg: Honor dmesg_restrict sysctl on /dev/kmsg

2013-04-24 Thread Kay Sievers
On Wed, Apr 24, 2013 at 11:51 PM, Josh Boyer wrote: >> In the daemon case, it's nice to be able to drop privileges after >> setting up resources. The past was open /proc/kmsg with CAP_SYS_ADMIN, >> then drop CAP_SYS_ADMIN and keep reading. Then later CAP_SYS_LOG was >> introduced. So if a daemon

Re: [PATCH 1/2] Fix perf LBR filtering

2013-04-24 Thread Greg KH
On Wed, Apr 24, 2013 at 04:04:53PM -0700, Andi Kleen wrote: > From: Andi Kleen > > The perf LBR code has special code to filter specific > instructions in software. > > The LBR logs any instruction address, even if IP just faulted. > This means user space can control any address by just branchin

Re: [ 04/26] hugetlbfs: add swap entry check in follow_hugetlb_page()

2013-04-24 Thread Greg Kroah-Hartman
On Thu, Apr 25, 2013 at 12:04:10AM +0100, Ben Hutchings wrote: > On Tue, Apr 23, 2013 at 02:53:44PM -0700, Greg Kroah-Hartman wrote: > > 3.4-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Naoya Horiguchi > > > > commit 9cc3a5bd40

Re: [PATCH 1/2] Fix perf LBR filtering

2013-04-24 Thread Ben Hutchings
On Wed, Apr 24, 2013 at 04:04:53PM -0700, Andi Kleen wrote: [] > Should be applied to applicable stable branches too. The problem > goes back a long time. > > Signed-off-by: Andi Kleen > --- [...] This is not the correct way to submit a change to stable. See Documentation/stable_kernel_rules

[PATCH 2/2] perf, x86: Don't allow unusual PEBS raw flags

2013-04-24 Thread Andi Kleen
From: Andi Kleen The PEBS documentation in the Intel SDM 18.6.1.1 states: """ PEBS events are only valid when the following fields of IA32_PERFEVTSELx are all zero: AnyThread, Edge, Invert, CMask. """ Since we had problems with this earlier, don't allow cmask, any, edge, invert as raw events, e

[PATCH 1/2] Fix perf LBR filtering

2013-04-24 Thread Andi Kleen
From: Andi Kleen The perf LBR code has special code to filter specific instructions in software. The LBR logs any instruction address, even if IP just faulted. This means user space can control any address by just branching to a bad address. On a modern Intel system the only software filtering

Re: [ 04/26] hugetlbfs: add swap entry check in follow_hugetlb_page()

2013-04-24 Thread Ben Hutchings
On Tue, Apr 23, 2013 at 02:53:44PM -0700, Greg Kroah-Hartman wrote: > 3.4-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Naoya Horiguchi > > commit 9cc3a5bd40067b9a0fbd49199d0780463fc2140f upstream. > > With applying the previous patch

Re: [ 03/23] can: sja1000: fix handling on dt properties on little endian systems

2013-04-24 Thread Ben Hutchings
On Tue, Apr 23, 2013 at 02:56:10PM -0700, Greg Kroah-Hartman wrote: > 3.0-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Christoph Fritz > > commit 0443de5fbf224abf41f688d8487b0c307dc5a4b4 upstream. > > To get correct endianes on little

Re: [PATCH] hrtimer, add expiry time overflow check in hrtimer_interrupt

2013-04-24 Thread Guenter Roeck
On Mon, Apr 08, 2013 at 04:34:26PM -0400, Prarit Bhargava wrote: > > > On 04/08/2013 04:19 PM, John Stultz wrote: > > On 04/08/2013 05:47 AM, Prarit Bhargava wrote: > > >> > >> A simple check for an overflow can resolve this problem. Using KTIME_MAX > >> instead of the overflow value will resul

[PATCH 1/8] menuconfig: Fix memory leak introduced by jump keys feature

2013-04-24 Thread Yann E. MORIN
From: Benjamin Poirier Fixes the memory leak of struct jump_key allocated in get_prompt_str() Signed-off-by: Benjamin Poirier Tested-by: "Yann E. MORIN" Reviewed-by: "Yann E. MORIN" Signed-off-by: "Yann E. MORIN" Cc: stable@vger.kernel.org --- scripts/kconfig/list.h | 13 + s

[to-be-updated] kernel-sysc-migrate-shutdown-reboot-to-boot-cpu.patch removed from -mm tree

2013-04-24 Thread akpm
The patch titled Subject: kernel/sys.c: migrate shutdown/reboot to boot cpu. has been removed from the -mm tree. Its filename was kernel-sysc-migrate-shutdown-reboot-to-boot-cpu.patch This patch was dropped because an updated version will be merged

[to-be-updated] cpu-hotplug-provide-a-generic-helper-to-disable-enable-cpu-hotplug.patch removed from -mm tree

2013-04-24 Thread akpm
The patch titled Subject: CPU hotplug: provide a generic helper to disable/enable CPU hotplug has been removed from the -mm tree. Its filename was cpu-hotplug-provide-a-generic-helper-to-disable-enable-cpu-hotplug.patch This patch was dropped because an updated version will be merged

+ kernel-sysc-migrate-shutdown-reboot-to-boot-cpu.patch added to -mm tree

2013-04-24 Thread akpm
The patch titled Subject: kernel/sys.c: migrate shutdown/reboot to boot cpu. has been added to the -mm tree. Its filename is kernel-sysc-migrate-shutdown-reboot-to-boot-cpu.patch Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a su

+ cpu-hotplug-provide-a-generic-helper-to-disable-enable-cpu-hotplug.patch added to -mm tree

2013-04-24 Thread akpm
The patch titled Subject: CPU hotplug: provide a generic helper to disable/enable CPU hotplug has been added to the -mm tree. Its filename is cpu-hotplug-provide-a-generic-helper-to-disable-enable-cpu-hotplug.patch Before you just go and hit "reply", please: a) Consider who else sh

Re: [PATCH v2] kmsg: Honor dmesg_restrict sysctl on /dev/kmsg

2013-04-24 Thread Josh Boyer
On Wed, Apr 24, 2013 at 02:30:53PM -0700, Linus Torvalds wrote: > On Wed, Apr 24, 2013 at 1:35 PM, Kees Cook wrote: > > > > That said, I much prefer doing the privilege test at read time since > > that means passing a file descriptor to another process doesn't mean > > the new process can just con

Re: [PATCH v2] kmsg: Honor dmesg_restrict sysctl on /dev/kmsg

2013-04-24 Thread Josh Boyer
On Wed, Apr 24, 2013 at 02:36:39PM -0700, Kees Cook wrote: > >> > >> So, the problem here is the expectation of privileges. The /proc/kmsg > >> usage pattern was: > >> > >> open /proc/kmsg with CAP_SYSLOG > >> drop CAP_SYSLOG > >> read /proc/kmsg forever > > > > This doesn't change the /proc interf

Re: [PATCH v2] kmsg: Honor dmesg_restrict sysctl on /dev/kmsg

2013-04-24 Thread Kees Cook
On Wed, Apr 24, 2013 at 2:30 PM, Linus Torvalds wrote: > On Wed, Apr 24, 2013 at 1:35 PM, Kees Cook wrote: >> >> That said, I much prefer doing the privilege test at read time since >> that means passing a file descriptor to another process doesn't mean >> the new process can just continue readin

Re: [PATCH v2] kmsg: Honor dmesg_restrict sysctl on /dev/kmsg

2013-04-24 Thread Kees Cook
On Wed, Apr 24, 2013 at 2:21 PM, Josh Boyer wrote: > On Wed, Apr 24, 2013 at 01:35:17PM -0700, Kees Cook wrote: >> On Wed, Apr 24, 2013 at 10:58 AM, Josh Boyer wrote: >> > On Wed, Apr 24, 2013 at 07:44:33PM +0200, Kay Sievers wrote: >> >> On Tue, Apr 9, 2013 at 6:33 PM, Kees Cook wrote: >> >> >

Re: [PATCH v2] kmsg: Honor dmesg_restrict sysctl on /dev/kmsg

2013-04-24 Thread Linus Torvalds
On Wed, Apr 24, 2013 at 1:35 PM, Kees Cook wrote: > > That said, I much prefer doing the privilege test at read time since > that means passing a file descriptor to another process doesn't mean > the new process can just continue reading. Bullshit. That's exactly the wrong kind of thinking. If y

Re: [PATCH] time: Revert ALWAYS_USE_PERSISTENT_CLOCK compile time optimizaitons

2013-04-24 Thread John Stultz
On 04/24/2013 12:44 PM, Kay Sievers wrote: On Wed, Apr 24, 2013 at 8:32 PM, John Stultz wrote: Kay Sievers noted that the ALWAYS_USE_PERSISTENT_CLOCK config, which enables some minor compile time optimization to avoid uncessary code in mostly the suspend/resume path could cause problems for use

Re: [PATCH] time: Revert ALWAYS_USE_PERSISTENT_CLOCK compile time optimizaitons

2013-04-24 Thread John Stultz
On 04/24/2013 12:18 PM, Kay Sievers wrote: On Wed, Apr 24, 2013 at 8:55 PM, John Stultz wrote: On 04/24/2013 11:41 AM, Kay Sievers wrote: On Wed, Apr 24, 2013 at 8:32 PM, John Stultz wrote: Kay Sievers noted that the ALWAYS_USE_PERSISTENT_CLOCK config, which enables some minor compile time o

Re: [PATCH v2] kmsg: Honor dmesg_restrict sysctl on /dev/kmsg

2013-04-24 Thread Josh Boyer
On Wed, Apr 24, 2013 at 01:35:17PM -0700, Kees Cook wrote: > On Wed, Apr 24, 2013 at 10:58 AM, Josh Boyer wrote: > > On Wed, Apr 24, 2013 at 07:44:33PM +0200, Kay Sievers wrote: > >> On Tue, Apr 9, 2013 at 6:33 PM, Kees Cook wrote: > >> > On Tue, Apr 9, 2013 at 8:48 AM, Josh Boyer wrote: > >> >>

Re: [PATCH v2] kmsg: Honor dmesg_restrict sysctl on /dev/kmsg

2013-04-24 Thread Kees Cook
On Wed, Apr 24, 2013 at 10:58 AM, Josh Boyer wrote: > On Wed, Apr 24, 2013 at 07:44:33PM +0200, Kay Sievers wrote: >> On Tue, Apr 9, 2013 at 6:33 PM, Kees Cook wrote: >> > On Tue, Apr 9, 2013 at 8:48 AM, Josh Boyer wrote: >> >> The dmesg_restrict sysctl currently covers the syslog method for acc

Re: [PATCH v2] kmsg: Honor dmesg_restrict sysctl on /dev/kmsg

2013-04-24 Thread Josh Boyer
On Wed, Apr 24, 2013 at 01:58:35PM -0400, Josh Boyer wrote: > On Wed, Apr 24, 2013 at 07:44:33PM +0200, Kay Sievers wrote: > > On Tue, Apr 9, 2013 at 6:33 PM, Kees Cook wrote: > > > On Tue, Apr 9, 2013 at 8:48 AM, Josh Boyer wrote: > > >> The dmesg_restrict sysctl currently covers the syslog meth

[PATCH v4 1/7] xen/arm: actually pass a non-NULL percpu pointer to request_percpu_irq

2013-04-24 Thread Stefano Stabellini
Signed-off-by: Stefano Stabellini CC: stable@vger.kernel.org --- arch/arm/xen/enlighten.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c index 8dc0605..99ce189 100644 --- a/arch/arm/xen/enlighten.c +++ b/arch/arm/xen/e

Re: [PATCH] time: Revert ALWAYS_USE_PERSISTENT_CLOCK compile time optimizaitons

2013-04-24 Thread Kay Sievers
On Wed, Apr 24, 2013 at 8:32 PM, John Stultz wrote: > Kay Sievers noted that the ALWAYS_USE_PERSISTENT_CLOCK config, > which enables some minor compile time optimization to avoid > uncessary code in mostly the suspend/resume path could cause > problems for userland. > > In particular, the dependen

Re: [PATCH] time: Revert ALWAYS_USE_PERSISTENT_CLOCK compile time optimizaitons

2013-04-24 Thread Kay Sievers
On Wed, Apr 24, 2013 at 8:55 PM, John Stultz wrote: > On 04/24/2013 11:41 AM, Kay Sievers wrote: >> >> On Wed, Apr 24, 2013 at 8:32 PM, John Stultz >> wrote: >>> >>> Kay Sievers noted that the ALWAYS_USE_PERSISTENT_CLOCK config, >>> which enables some minor compile time optimization to avoid >>>

Re: [PATCH] drm/i915: Use the correct size of the GTT for placing the per-process entries

2013-04-24 Thread Jonathan Nieder
Hi Chris, Chris J Arges wrote: > This patch fixes the following bug: > http://bugs.launchpad.net/bugs/1107642 > > It has been tested against the Ubuntu Quantal 3.5 kernel. > I'd like to include it in the 3.5.y stable tree. Thanks. For future reference, it's easier to understand proposals like t

+ mm-swap-mark-swap-pages-writeback-before-queueing-for-direct-io.patch added to -mm tree

2013-04-24 Thread akpm
The patch titled Subject: mm: swap: Mark swap pages writeback before queueing for direct IO has been added to the -mm tree. Its filename is mm-swap-mark-swap-pages-writeback-before-queueing-for-direct-io.patch Before you just go and hit "reply", please: a) Consider who else should b

[PATCH] drm/i915: Use the correct size of the GTT for placing the per-process entries

2013-04-24 Thread Chris J Arges
From: Chris Wilson The current layout is to place the per-process tables at the end of the GTT. However, this is currently using a hardcoded maximum size for the GTT and not taking in account limitations imposed by the BIOS. Use the value for the total number of entries allocated in the table as

[PATCH] drm/i915: Use the correct size of the GTT for placing the per-process entries

2013-04-24 Thread Chris J Arges
This patch fixes the following bug: http://bugs.launchpad.net/bugs/1107642 It has been tested against the Ubuntu Quantal 3.5 kernel. I'd like to include it in the 3.5.y stable tree. The fix is present in v3.6-rc4 and beyond. Chris Wilson (1): drm/i915: Use the correct size of the GTT for placin

[PATCH] drm/i915: Use the correct size of the GTT for placing the per-process entries

2013-04-24 Thread Chris J Arges
From: Chris Wilson The current layout is to place the per-process tables at the end of the GTT. However, this is currently using a hardcoded maximum size for the GTT and not taking in account limitations imposed by the BIOS. Use the value for the total number of entries allocated in the table as

Re: [PATCH] time: Revert ALWAYS_USE_PERSISTENT_CLOCK compile time optimizaitons

2013-04-24 Thread John Stultz
On 04/24/2013 11:41 AM, Kay Sievers wrote: On Wed, Apr 24, 2013 at 8:32 PM, John Stultz wrote: Kay Sievers noted that the ALWAYS_USE_PERSISTENT_CLOCK config, which enables some minor compile time optimization to avoid uncessary code in mostly the suspend/resume path could cause problems for use

Re: [PATCH] time: Revert ALWAYS_USE_PERSISTENT_CLOCK compile time optimizaitons

2013-04-24 Thread Kay Sievers
On Wed, Apr 24, 2013 at 8:32 PM, John Stultz wrote: > Kay Sievers noted that the ALWAYS_USE_PERSISTENT_CLOCK config, > which enables some minor compile time optimization to avoid > uncessary code in mostly the suspend/resume path could cause > problems for userland. > > In particular, the dependen

[PATCH] drm/radeon: fix endian bugs in atom_allocate_fb_scratch()

2013-04-24 Thread alexdeucher
From: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org --- drivers/gpu/drm/radeon/atom.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c index 46a9c37..fb441a7 100644 --- a/drivers/gpu

[PATCH] time: Revert ALWAYS_USE_PERSISTENT_CLOCK compile time optimizaitons

2013-04-24 Thread John Stultz
Kay Sievers noted that the ALWAYS_USE_PERSISTENT_CLOCK config, which enables some minor compile time optimization to avoid uncessary code in mostly the suspend/resume path could cause problems for userland. In particular, the dependency for RTC_HCTOSYS on !ALWAYS_USE_PERSISTENT_CLOCK, which avoids

Re: [PATCH v2] kmsg: Honor dmesg_restrict sysctl on /dev/kmsg

2013-04-24 Thread Josh Boyer
On Wed, Apr 24, 2013 at 07:44:33PM +0200, Kay Sievers wrote: > On Tue, Apr 9, 2013 at 6:33 PM, Kees Cook wrote: > > On Tue, Apr 9, 2013 at 8:48 AM, Josh Boyer wrote: > >> The dmesg_restrict sysctl currently covers the syslog method for access > >> dmesg, however /dev/kmsg isn't covered by the sam

Re: [PATCH v2] kmsg: Honor dmesg_restrict sysctl on /dev/kmsg

2013-04-24 Thread Kay Sievers
On Tue, Apr 9, 2013 at 6:33 PM, Kees Cook wrote: > On Tue, Apr 9, 2013 at 8:48 AM, Josh Boyer wrote: >> The dmesg_restrict sysctl currently covers the syslog method for access >> dmesg, however /dev/kmsg isn't covered by the same protections. Most >> people haven't noticed because util-linux dme

Re: [PATCH v2] kmsg: Honor dmesg_restrict sysctl on /dev/kmsg

2013-04-24 Thread Josh Boyer
On Tue, Apr 09, 2013 at 11:48:20AM -0400, Josh Boyer wrote: > The dmesg_restrict sysctl currently covers the syslog method for access > dmesg, however /dev/kmsg isn't covered by the same protections. Most > people haven't noticed because util-linux dmesg(1) defaults to using the > syslog method fo

Re: [ 00/42] 3.8.9-stable review

2013-04-24 Thread Shuah Khan
On Tue, 2013-04-23 at 14:51 -0700, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.8.9 release. > There are 42 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. > > Re

Re: [ 00/26] 3.4.42-stable review

2013-04-24 Thread Shuah Khan
On Tue, 2013-04-23 at 14:53 -0700, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.4.42 release. > There are 26 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. > > R

Re: [ 00/23] 3.0.75-stable review

2013-04-24 Thread Shuah Khan
On Tue, 2013-04-23 at 14:56 -0700, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.0.75 release. > There are 23 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. > > R

Re: [ 00/42] 3.8.9-stable review

2013-04-24 Thread Greg Kroah-Hartman
On Wed, Apr 24, 2013 at 04:23:32PM +, Shuah Khan wrote: > On Tue, 2013-04-23 at 14:51 -0700, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.8.9 release. > > There are 42 patches in this series, all will be posted as a response > > to this one. If anyone ha

patch "USB: ftdi_sio: enable two UART ports on ST Microconnect Lite" added to usb tree

2013-04-24 Thread gregkh
This is a note to let you know that I've just added the patch titled USB: ftdi_sio: enable two UART ports on ST Microconnect Lite to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-next branch. The patch will show up in the n

[PATCH 3.0-stable] sparc32: support atomic64_t

2013-04-24 Thread Andreas Larsson
Commit aea1181b0bd0a09c54546399768f359d1e198e45 upstream [Backport to 3.0.y. Needed to compile ext4 for sparc32 since commit 503f4bdcc078e7abee273a85ce322de81b18a224] There is no-one that really require atomic64_t support on sparc32. But several drivers fails to build without proper atomic64 supp

Re: [PATCH] block: fix max discard sectors limit

2013-04-24 Thread Jens Axboe
On Wed, Apr 24 2013, James Bottomley wrote: > On Wed, 2013-04-24 at 22:55 +0900, Namjae Jeon wrote: > > From: James Bottomley > > > > linux-v3.8-rc1 and later support for plug for blkdev_issue_discard with > > commit 0cfbcafcae8b7364b5fa96c2b26ccde7a3a296a9 > > (block: add plug for blkdev_issue_d

Re: [PATCH] block: fix max discard sectors limit

2013-04-24 Thread James Bottomley
On Wed, 2013-04-24 at 08:23 -0600, Jens Axboe wrote: > On Wed, Apr 24 2013, Namjae Jeon wrote: > > From: James Bottomley > > > > linux-v3.8-rc1 and later support for plug for blkdev_issue_discard with > > commit 0cfbcafcae8b7364b5fa96c2b26ccde7a3a296a9 > > (block: add plug for blkdev_issue_discar

Re: [PATCH] block: fix max discard sectors limit

2013-04-24 Thread Jens Axboe
On Wed, Apr 24 2013, Namjae Jeon wrote: > From: James Bottomley > > linux-v3.8-rc1 and later support for plug for blkdev_issue_discard with > commit 0cfbcafcae8b7364b5fa96c2b26ccde7a3a296a9 > (block: add plug for blkdev_issue_discard ) > > For example, > 1) DISCARD rq-1 with size size 4GB > 2) D

Re: [PATCH] block: fix max discard sectors limit

2013-04-24 Thread James Bottomley
On Wed, 2013-04-24 at 22:55 +0900, Namjae Jeon wrote: > From: James Bottomley > > linux-v3.8-rc1 and later support for plug for blkdev_issue_discard with > commit 0cfbcafcae8b7364b5fa96c2b26ccde7a3a296a9 > (block: add plug for blkdev_issue_discard ) > > For example, > 1) DISCARD rq-1 with size s

[PATCH] block: fix max discard sectors limit

2013-04-24 Thread Namjae Jeon
From: James Bottomley linux-v3.8-rc1 and later support for plug for blkdev_issue_discard with commit 0cfbcafcae8b7364b5fa96c2b26ccde7a3a296a9 (block: add plug for blkdev_issue_discard ) For example, 1) DISCARD rq-1 with size size 4GB 2) DISCARD rq-2 with size size 1GB If these 2 discard request

Re: patch "USB: ftdi_sio: correct ST Micro Connect Lite PIDs" added to usb tree

2013-04-24 Thread Adrian THOMASSET
Hi Greg, Thank you very much for that. I am terribly sorry about the checkpatch warnings. I realise PATCH1/2 has a white space which you have kindly overlooked and I resubmitted PATCH2/2 with the indents. In fact PATCH2/2 with the two UARTs enabled is what our customers are asking for: USB

[PATCH] fix source operand decoding for 8bit mov[zs]x instructions

2013-04-24 Thread Gleb Natapov
Source operand for one byte mov[zs]x is decoded incorrectly if it is in high byte register. Fix that. Cc: stable@vger.kernel.org Signed-off-by: Gleb Natapov diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c index 46f63b8..8e517bb 100644 --- a/arch/x86/kvm/emulate.c +++ b/arch/x86/kvm