The topology_##name() macro does not use its argument when CONFIG_SMP is not
set, as it ultimately calls the cpu_data() macro.
So we avoid maintaining a possibly unused `cpu' variable, to avoid the
following compilation warning:
drivers/base/topology.c: In function ‘show_physical_package_id’:
On Thu, Apr 03, 2014 at 06:18:40PM +0200, David Sterba wrote:
> On Thu, Apr 03, 2014 at 01:34:23PM +0800, Liu Bo wrote:
> > On Wed, Apr 02, 2014 at 07:13:00PM +0200, David Sterba wrote:
> > > Commit fae7f21cece9a4c181 ("btrfs: Use WARN_ON()'s return value in place
> > > of
> > > WARN_ON(1)") clean
Use the NULL legacy PIC when on Hyper-V. With this change we can support kexec
even when booting on EFI firmware. This patch has been tested on both EFI as
well as non-EFI firmware stacks on Hyper-V.
This patch is required to support kexec on EFI firmware on Hyper-V. Please
apply.
Signed-off-by:
Only ws2012r2 hosts support the ability to reconnect to the host on VMBUS. This
functionality
is needed by kexec in Linux. To use this functionality we need to negotiate
version 3.0 of the
VMBUS protocol.
Signed-off-by: K. Y. Srinivasan
Cc: [3.9+]
---
drivers/hv/connection.c |5 +++
On Mon, 2014-03-31 at 14:23 +0100, Luis Henriques wrote:
> 3.5.7.33 -stable review patch. If anyone has any objections, please let me
> know.
>
> --
>
> From: Ben Hutchings
[...]
Should be From: Dan Williams
I think you must have got my name by applying the 3.2 review mail..
It works over here, tested on 3.14-rc8 which was previously failing. You
have my
Tested-by: Alexandre Demers
Alexandre Demers
On 04/03/2014 03:49 PM, Thomas Bächler wrote:
Commit 9e30cc9595303b27b48 removed an internal mount. This
has the side-effect that rootfs now has FSID 0. Many
userspace
I'm announcing the release of the 3.10.36 kernel.
All users of the 3.10 kernel series must upgrade.
The updated 3.10.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-3.10.y
and can be browsed at the normal kernel.org git web browser:
I'm announcing the release of the 3.13.9 kernel.
All users of the 3.13 kernel series must upgrade.
The updated 3.13.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-3.13.y
and can be browsed at the normal kernel.org git web browser:
diff --git a/Makefile b/Makefile
index 4cab13b605c1..652f97296a40 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 13
-SUBLEVEL = 8
+SUBLEVEL = 9
EXTRAVERSION =
NAME = One Giant Leap for Frogkind
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/p
diff --git a/Makefile b/Makefile
index 06b31fce1ff5..b5f4ef30f6e6 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 10
-SUBLEVEL = 35
+SUBLEVEL = 36
EXTRAVERSION =
NAME = TOSSUG Baby Fish
diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.
I'm announcing the release of the 3.4.86 kernel.
All users of the 3.4 kernel series must upgrade.
The updated 3.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-3.4.y
and can be browsed at the normal kernel.org git web browser:
On Tue, Apr 01, 2014 at 03:07:20PM -0600, Shuah Khan wrote:
> On 03/31/2014 10:08 PM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.10.36 release.
> >There are 9 patches in this series, all will be posted as a response
> >to this one. If anyone has any issues
On Tue, Apr 01, 2014 at 05:03:34PM -0700, Guenter Roeck wrote:
> On 03/31/2014 09:08 PM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.13.9 release.
> >There are 22 patches in this series, all will be posted as a response
> >to this one. If anyone has any issu
From: Jan Kara
Subject: bdi: avoid oops on device removal
After 839a8e8660b67 ("writeback: replace custom worker pool implementation
with unbound workqueue") when device is removed while we are writing to it
we crash in bdi_writeback_workfn() -> set_worker_desc() because bdi->dev
is NULL. This c
From: Derek Basehore
Subject: backing_dev: fix hung task on sync
bdi_wakeup_thread_delayed() used the mod_delayed_work() function to
schedule work to writeback dirty inodes. The problem with this is that it
can delay work that is scheduled for immediate execution, such as the work
from sync_inod
From: Matt Fleming
Subject: sh: fix format string bug in stack tracer
Kees reported the following error,
arch/sh/kernel/dumpstack.c: In function 'print_trace_address':
>> arch/sh/kernel/dumpstack.c:118:2: error: format not a string literal and no
>> format arguments [-Werror=format-security]
From: Junxiao Bi
Subject: ocfs2: dlm: fix lock migration crash
This issue was introduced by 800deef3 ("ocfs2: use list_for_each_entry
where benefical") in 2007 where it replaced list_for_each with
list_for_each_entry. The variable "lock" will point to invalid data if
"tmpq" list is empty and a p
From: Serge Hallyn
Subject: xattr: guard against simultaneous glibc header inclusion
If the glibc xattr.h header is included after the uapi header, compilation
fails due to an enum re-using a #define from the uapi header. Protect
against this by guarding the define and enum inclusions against ea
From: Junxiao Bi
Subject: ocfs2: dlm: fix recovery hung
There is a race window in dlm_do_recovery() between dlm_remaster_locks()
and dlm_reset_recovery() when the recovery master nearly finish the
recovery process for a dead node. After the master sends FINALIZE_RECO
message in dlm_remaster_lock
From: Tetsuo Handa
Subject: ocfs2: fix panic on kfree(xattr->name)
Commit 9548906b 'xattr: Constify ->name member of "struct xattr".' missed that
ocfs2 is calling kfree(xattr->name). As a result, kernel panic occurs upon
calling kfree(xattr->name) because xattr->name refers static constant names.
From: alex chen
Subject: ocfs2: do not put bh when buffer_uptodate failed
Do not put bh when buffer_uptodate failed in ocfs2_write_block and
ocfs2_write_super_or_backup, because it will put bh in b_end_io.
Otherwise it will hit a warning "VFS: brelse: Trying to free free buffer".
Signed-off-by:
On Thu, Apr 03, 2014 at 09:55:37PM +0200, Thomas Bächler wrote:
> Commit 9e30cc9595303b27b48 removed an internal mount. This
> has the side-effect that rootfs now has FSID 0. Many
> userspace utilities assume that st_dev in struct stat
> is never 0, so this change breaks a number of tools in
> earl
On 04/03/2014 12:49 PM, Thomas Bächler wrote:
> Commit 9e30cc9595303b27b48 removed an internal mount. This
> has the side-effect that rootfs now has FSID 0. Many
> userspace utilities assume that st_dev in struct stat
> is never 0, so this change breaks a number of tools in
> early userspace.
>
>
Commit 9e30cc9595303b27b48 removed an internal mount. This
has the side-effect that rootfs now has FSID 0. Many
userspace utilities assume that st_dev in struct stat
is never 0, so this change breaks a number of tools in
early userspace.
Since we don't know how many userspace programs are affected
Commit 9e30cc9595303b27b48 removed an internal mount. This
has the side-effect that rootfs now has FSID 0. Many
userspace utilities assume that st_dev in struct stat
is never 0, so this change breaks a number of tools in
early userspace.
Since we don't know how many userspace programs are affected
On Thu, Apr 03, 2014 at 09:49:55PM +0200, Thomas Bächler wrote:
> Commit 9e30cc9595303b27b48 removed an internal mount. This
> has the side-effect that rootfs now has FSID 0. Many
> userspace utilities assume that st_dev in struct stat
> is never 0, so this change breaks a number of tools in
> earl
Loongson2 has been using (incorrectly) kHz for cpu_clk rate. This has
been unnoticed, as loongson2_cpufreq was the only place where the rate
was set/get. After commit 652ed95d5fa6074b3c4ea245deb0691f1acb6656
(cpufreq: introduce cpufreq_generic_get() routine) things however broke,
and now loops_per_
Hi,
On Thu, Apr 03, 2014 at 09:51:41AM +0530, Viresh Kumar wrote:
> On 3 April 2014 00:37, Aaro Koskinen wrote:
> > Loongson2 has been using (incorrectly) kHz for cpu_clk rate. This has
> > been unnoticed, as loongson2_cpufreq was the only place where the rate
> > was set/get. After commit 652ed9
Am 03.04.2014 19:44, schrieb Sebastian Hesselbarth:
I tried to reproduce the regression on Dockstar with 3.14.0 and
3.14.0-07247-gcd6362be, netconsole enabled, DHCP (dhclient).
Try using dhcpcd, that's why I mentioned it. DHCP-clients do work
differently.
I can neither reproduce any issues
Subject: [merged]
pid_namespace-pidns_get-should-check-task_active_pid_ns-=-null.patch removed
from -mm tree
To:
o...@redhat.com,ebied...@xmission.com,jan.kratoch...@redhat.com,j...@chromium.org,keesc...@chromium.org,mcgra...@chromium.org,mdemp...@chromium.org,stable@vger.kernel.org,mm-comm...@v
On 04/03/2014 05:06 PM, Alexander Holler wrote:
> Am 03.04.2014 10:49, schrieb Sebastian Hesselbarth:
>> On 04/03/2014 09:17 AM, Alexander Holler wrote:
>>> Am 03.04.2014 00:27, schrieb Sebastian Hesselbarth:
On 04/03/2014 12:12 AM, Alexander Holler wrote:
>> I am curious, how you determin
On Thu, Apr 03, 2014 at 01:34:23PM +0800, Liu Bo wrote:
> On Wed, Apr 02, 2014 at 07:13:00PM +0200, David Sterba wrote:
> > Commit fae7f21cece9a4c181 ("btrfs: Use WARN_ON()'s return value in place of
> > WARN_ON(1)") cleaned up WARN_ON usage and in one place reversed the
> > condition
> > that led
Am 03.04.2014 17:45, schrieb Sebastian Hesselbarth:
I will try to reproduce it and if I hit it, will do a bisect to find
(and fix) the offending patch.
I have better ways to waste my time.
Like writing workarounds instead of fixing bugs?
Sure. If I would try to fix (or even describe) ever
On Tue, 2014-04-01 at 09:08 -0700, Kamal Mostafa wrote:
> 3.8.13.21 -stable review patch. If anyone has any objections, please let me
> know.
>
> --
>
> From: Patrick Lai
>
> commit e4ad1accb28d0ed8cea6f12395d58686ad344ca7 upstream.
I am dropping this patch from 3.8-stable,
On 04/02/2014 02:12 PM, Jiri Slaby wrote:
This is the start of the stable review cycle for the 3.12.17 release.
There are 40 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.
Responses should be made by F
Am 03.04.2014 17:14, schrieb David Miller:
From: Alexander Holler
Date: Thu, 03 Apr 2014 17:06:52 +0200
But don't suggest me (or insist on) a time consuming
Bisects are not time consuming, and help developers analyze your
issue tremendously.
Hmm, compiling and booting several dozen kernels
On 04/03/2014 05:06 PM, Alexander Holler wrote:
Am 03.04.2014 10:49, schrieb Sebastian Hesselbarth:
On 04/03/2014 09:17 AM, Alexander Holler wrote:
Am 03.04.2014 00:27, schrieb Sebastian Hesselbarth:
On 04/03/2014 12:12 AM, Alexander Holler wrote:
I am curious, how you determined above commit
2014-04-03 13:06 GMT+02:00 Johan Hovold :
> Fix regression introduced by commit 8e493ca1767d ("USB: usb_wwan: fix
> bulk-urb allocation") by making sure to require both bulk-in and out
> endpoints during port probe.
Tested-by: Rafał Miłecki
--
To unsubscribe from this list: send the line "unsubsc
From: Mike Rapoport
Date: Tue, 1 Apr 2014 09:23:01 +0300
> If the vxlan interface is created without explicit group definition,
> there are corner cases which may cause kernel panic.
>
> For instance, in the following scenario:
...
> When vxlan interface is created without explicit group defin
From: Alexander Holler
Date: Thu, 03 Apr 2014 17:06:52 +0200
> But don't suggest me (or insist on) a time consuming
Bisects are not time consuming, and help developers analyze your
issue tremendously.
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message t
Am 03.04.2014 10:49, schrieb Sebastian Hesselbarth:
On 04/03/2014 09:17 AM, Alexander Holler wrote:
Am 03.04.2014 00:27, schrieb Sebastian Hesselbarth:
On 04/03/2014 12:12 AM, Alexander Holler wrote:
I am curious, how you determined above commit to be the cause of the
regression you are seeing
On Thu, Apr 03, 2014 at 01:32:19PM +0200, Rafał Miłecki wrote:
> 2014-04-03 13:06 GMT+02:00 Johan Hovold :
> > Fix regression introduced by commit 8e493ca1767d ("USB: usb_wwan: fix
> > bulk-urb allocation") by making sure to require both bulk-in and out
> > endpoints during port probe.
>
> Ohh, th
2014-04-03 13:06 GMT+02:00 Johan Hovold :
> Fix regression introduced by commit 8e493ca1767d ("USB: usb_wwan: fix
> bulk-urb allocation") by making sure to require both bulk-in and out
> endpoints during port probe.
Ohh, that was quick! :)
This patch works for me:
[33050.103575] option 1-1.2:1.0:
Fix regression introduced by commit 8e493ca1767d ("USB: usb_wwan: fix
bulk-urb allocation") by making sure to require both bulk-in and out
endpoints during port probe.
The original option driver (which usb_wwan is based on) was written
under the assumption that either endpoint could be missing, bu
Special pte mappings are not intended to be executable and do not even
have an associated struct page. This patch ensures that we do not call
__sync_icache_dcache() on such ptes.
Signed-off-by: Catalin Marinas
Reported-by: Steve Capper
Tested-by: Laura Abbott
Tested-by: Bharat Bhushan
Cc:
---
From: Catalin Marinas
pgprot_{dmacoherent,writecombine,noncached} don't need to generate
executable mappings with side-effects like __sync_icache_dcache() being
called when the mapping is in user space.
Signed-off-by: Catalin Marinas
Reported-by: Bharat Bhushan
Tested-by: Laura Abbott
Tested-
On Wed, Apr 02, 2014 at 04:19:36PM +0200, Krzysztof Kozlowski wrote:
> Hi,
>
> These two patches are good candidates for backporting to stable 3.10. They fix
> a CPU0 stall due to timer list corruption after hotplugging CPU1.
>
> 1. Commit: 95731ebb114c
>cpufreq: Fix governor start/stop race
Dear Gregory CLEMENT,
On Wed, 02 Apr 2014 16:15:17 +0200, Gregory CLEMENT wrote:
> > This commit was successfully tested with mvneta compiled as a module,
> > on both the OpenBlocks AX3 (SGMII configuration) and the Armada XP GP
> > (RGMII configuration).
>
> Unfortunately with this patch, mvnet
From: Bockholdt Arne
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 22e580d07f6529a395c129575127ea6d860aed3a upstream.
Corrected the MWAIT flag for C-State C6 on Intel Avoton/Rangeley processors.
Signed-off-by: Arne Bockholdt
Acked-by: Len
On 04/03/2014 09:17 AM, Alexander Holler wrote:
> Am 03.04.2014 00:27, schrieb Sebastian Hesselbarth:
>> On 04/03/2014 12:12 AM, Alexander Holler wrote:
I am curious, how you determined above commit to be the cause of the
regression you are seeing. Can you bisect, if you didn't already?
>
The query buffers were reserved while holding the binding mutex, which
caused a circular locking dependency.
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
---
drivers/gpu/drm/vmwgfx/vmwgfx_context.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
Am 03.04.2014 00:27, schrieb Sebastian Hesselbarth:
On 04/03/2014 12:12 AM, Alexander Holler wrote:
I am curious, how you determined above commit to be the cause of the
regression you are seeing. Can you bisect, if you didn't already?
There was no bisecting necessary. I've just looked at wha
52 matches
Mail list logo
