The compat_elf_prpsinfo structure does not match the arch/arm struct
elf_pspsinfo definition. As result NT_PRPSINFO note in core file
created by arm64 kernel for aarch32 (compat) process has wrong size.
So gdb cannot display command that caused process crash.
Fix is to change size of
On 10/14/2014 5:57 PM, Martin K. Petersen wrote:
Petr == Petr Vandrovec p...@vmware.com writes:
Petr,
Petr Logic (from 2011, commit 8af1954d172a46a63e5e79dae523a6d74715e458)
Petr says that EOPNOTSUPP is returned when DISCARD request failed, as
Petr discarding is optional, and failures can be
This is for 3.17 stable.
According to Nish:
I think they occur every boot, unconditionally, on pseries. Doesn't
prevent boot, just really noisy. I think it'd be good to get them into
-stable.
From 70ad237515d99595ed03848bd8e549e50e83c4f2 Mon Sep 17 00:00:00 2001
From: Li Zhong
This is for 3.17 stable.
According to Nish:
I think they occur every boot, unconditionally, on pseries. Doesn't
prevent boot, just really noisy. I think it'd be good to get them into
-stable.
From bc3c4327c92b9ceb9a6356ec64d1b2ab2dc851f9 Mon Sep 17 00:00:00 2001
From: Li Zhong
Hi Krzysztof,
On Tue, Oct 14, 2014 at 10:32:53AM +0200, Krzysztof Kozlowski wrote:
The power_supply_get_by_phandle() on error returns ENODEV or NULL.
The driver later expects obtained pointer to power supply to be
valid or NULL. If it is not NULL then it dereferences it in
Hi,
Can you please apply the following mainline commits to 3.14 stable (in the
order below)
c3441edd2dea ARC: [SMP] General Fixes
d75386363ee6 ARC: fix mmuv2 warning
ef680cdc2437 ARC: Disable caches in early boot if so configured
Build/run tested on 3.14
Thx,
-Vineet
--
To unsubscribe from
I'm announcing the release of the 3.17.1 kernel.
All users of the 3.17 kernel series must upgrade.
The updated 3.17.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-3.17.y
and can be browsed at the normal kernel.org git web browser:
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 10d51c2f10d7..1edd5fdc629d 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3522,6 +3522,8 @@ bytes respectively. Such letter suffixes can also be
entirely
I'm announcing the release of the 3.16.6 kernel.
All users of the 3.16 kernel series must upgrade.
The updated 3.16.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-3.16.y
and can be browsed at the normal kernel.org git web browser:
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index f896f68a3ba3..c4da64b525b2 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3459,6 +3459,8 @@ bytes respectively. Such letter suffixes can also be
entirely
diff --git a/Makefile b/Makefile
index 9df630a513b7..c27454b8ca3e 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 10
-SUBLEVEL = 57
+SUBLEVEL = 58
EXTRAVERSION =
NAME = TOSSUG Baby Fish
diff --git a/drivers/net/ethernet/broadcom/tg3.c
diff --git a/Makefile b/Makefile
index 41e6e19fe2e9..a59980eb4557 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 14
-SUBLEVEL = 21
+SUBLEVEL = 22
EXTRAVERSION =
NAME = Remembering Coco
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
I'm announcing the release of the 3.10.58 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
I'm announcing the release of the 3.14.22 kernel.
All users of the 3.14 kernel series must upgrade.
The updated 3.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-3.14.y
and can be browsed at the normal kernel.org git web
On śro, 2014-10-15 at 11:05 +0200, Sebastian Reichel wrote:
Hi Krzysztof,
On Tue, Oct 14, 2014 at 10:32:53AM +0200, Krzysztof Kozlowski wrote:
The power_supply_get_by_phandle() on error returns ENODEV or NULL.
The driver later expects obtained pointer to power supply to be
valid or NULL.
Hi,
On Wed, Oct 15, 2014 at 01:11:31PM +0200, Krzysztof Kozlowski wrote:
[...] I guess something as the following is needed:
if (IS_ERR_OR_NULL(bq-notify_psy)) {
if (bq-notify_psy)
dev_err(client-dev, no 'ti,usb-charger-detection' property\n);
ret =
On śro, 2014-10-15 at 15:58 +0200, Sebastian Reichel wrote:
Hi,
On Wed, Oct 15, 2014 at 01:11:31PM +0200, Krzysztof Kozlowski wrote:
[...] I guess something as the following is needed:
if (IS_ERR_OR_NULL(bq-notify_psy)) {
if (bq-notify_psy)
dev_err(client-dev, no
Memory allocated for 'name' was leaking if required binding properties
were not present.
The memory for 'name' was allocated early at probe with kasprintf(). It
was freed in error paths executed before and after parsing DTS but not
in that error path.
Fix the error path for parsing device tree
The power_supply_get_by_phandle() on error returns ENODEV or NULL.
The driver later expects obtained pointer to power supply to be
valid or NULL. If it is not NULL then it dereferences it in
bq2415x_notifier_call() which would lead to dereferencing ENODEV-value
pointer.
Properly handle the
On Wed, Oct 15, 2014 at 07:11:36AM +0100, Victor Kamensky wrote:
The compat_elf_prpsinfo structure does not match the arch/arm struct
elf_pspsinfo definition. As result NT_PRPSINFO note in core file
created by arm64 kernel for aarch32 (compat) process has wrong size.
So gdb cannot display
Backport of commit f9865f06f7f18c6661c88d0511f05c48612319cc for 3.10.
Commit f363e45fd118 (net/ceph: make ceph_msgr_wq non-reentrant)
effectively removed WQ_MEM_RECLAIM flag from ceph_msgr_wq. This is
wrong - libceph is very much a memory reclaim path, so restore it.
Cc: stable@vger.kernel.org
Backport of commit 792c3a914910bd34302c5345578f85cfcb5e2c01 for 3.16.
Need to use WQ_MEM_RECLAIM for our workqueues to prevent I/O lockups
under memory pressure - we sit on the memory reclaim path.
Cc: stable@vger.kernel.org # 3.17, needs backporting for 3.16
Signed-off-by: Ilya Dryomov
From: Ezequiel Garcia ezequ...@vanguardiasur.com.ar
commit b478e336b3e75505707a11e78ef8b964ef0a03af upstream
The current error path calls tilcdc_unload() in case of an error to release
the resources. However, this is wrong because not all resources have been
allocated by the time an error occurs
If the TSC is unusable or disabled, then this patch fixes:
- Confusion while trying to clear old APIC interrupts.
- Division by zero and incorrect programming of the TSC deadline
timer.
This fixes boot if the CPU has a TSC deadline timer but a missing or
broken TSC. The failure to boot can
This reverts commit 9c3b306e1c9e6be4be09e99a8fe2227d1005effc.
Switching only one commit root during a transaction is wrong because it leads
the fs into an inconsistent state. All commit roots should be switched at once,
at transaction commit time, otherwise backref walking can often miss
Hi Pali,
On Fri, Oct 03, 2014 at 03:51:12PM +0200, Pali Rohár wrote:
Sometimes laptops with closed lid receive invalid ALPS protocol V3 packets
with
last bit7 set.
This happens on Dell Latitude laptops and it looks like it is BIOS bug.
Probably
EC does not correctly split keyboard and
On Wednesday 15 October 2014 19:55:24 Dmitry Torokhov wrote:
Hi Pali,
On Fri, Oct 03, 2014 at 03:51:12PM +0200, Pali Rohár wrote:
Sometimes laptops with closed lid receive invalid ALPS
protocol V3 packets with last bit7 set.
This happens on Dell Latitude laptops and it looks like it
On Wed, Oct 15, 2014 at 08:06:45PM +0200, Pali Rohár wrote:
On Wednesday 15 October 2014 19:55:24 Dmitry Torokhov wrote:
Hi Pali,
On Fri, Oct 03, 2014 at 03:51:12PM +0200, Pali Rohár wrote:
Sometimes laptops with closed lid receive invalid ALPS
protocol V3 packets with last bit7 set.
On Wednesday 15 October 2014 20:17:40 Dmitry Torokhov wrote:
On Wed, Oct 15, 2014 at 08:06:45PM +0200, Pali Rohár wrote:
On Wednesday 15 October 2014 19:55:24 Dmitry Torokhov wrote:
Hi Pali,
On Fri, Oct 03, 2014 at 03:51:12PM +0200, Pali Rohár wrote:
Sometimes laptops with closed
On Wed, Oct 15, 2014 at 08:28:59PM +0200, Pali Rohár wrote:
On Wednesday 15 October 2014 20:17:40 Dmitry Torokhov wrote:
On Wed, Oct 15, 2014 at 08:06:45PM +0200, Pali Rohár wrote:
On Wednesday 15 October 2014 19:55:24 Dmitry Torokhov wrote:
Hi Pali,
On Fri, Oct 03, 2014 at
Without this patch driver dell-wmi is trying to access elements of dynamically
allocated array without checking array size. This can lead to memory corruption
or kernel panic. This patch adds missing checks for array size.
Upstream commit id: a666b6ffbc9b6705a3ced704f52c3fe9ea8bf959
Compound page should be freed by put_page() or free_pages() with
correct order. Not doing so will cause tail pages leaked.
The compound order can be obtained by compound_order() or use
HPAGE_PMD_ORDER in our case. Some people would argue the latter
is faster but I prefer the former which is more
This allows us to catch the bug fixed in the previous patch
(mm: free compound page with correct order).
Here we also verify whether a page is tail page or not -- tail
pages are supposed to be freed along with their head, not by
themselves.
Reviewed-by: Kirill A. Shutemov
On Wed, 15 Oct 2014 12:20:04 -0700 Yu Zhao yuz...@google.com wrote:
Compound page should be freed by put_page() or free_pages() with
correct order. Not doing so will cause tail pages leaked.
The compound order can be obtained by compound_order() or use
HPAGE_PMD_ORDER in our case. Some
The patch titled
Subject: mm: free compound page with correct order
has been added to the -mm tree. Its filename is
mm-free-compound-page-with-correct-order.patch
This patch should soon appear at
On Wed, Oct 15, 2014 at 12:30:44PM -0700, Andrew Morton wrote:
@@ -232,7 +232,7 @@ static unsigned long shrink_huge_zero_page_scan(struct
shrinker *shrink,
if (atomic_cmpxchg(huge_zero_refcount, 1, 0) == 1) {
struct page *zero_page = xchg(huge_zero_page, NULL);
On Wed, Oct 15, 2014 at 12:20:05PM -0700, Yu Zhao wrote:
This allows us to catch the bug fixed in the previous patch
(mm: free compound page with correct order).
Here we also verify whether a page is tail page or not -- tail
pages are supposed to be freed along with their head, not by
On Wed, Oct 15, 2014 at 11:37:01AM +0800, Baoquan He wrote:
On 10/14/14 at 08:49am, Vivek Goyal wrote:
On Mon, Oct 13, 2014 at 01:22:42PM -0400, Vivek Goyal wrote:
On Mon, Oct 13, 2014 at 08:43:00AM -0700, H. Peter Anvin wrote:
On 10/13/2014 08:19 AM, Vivek Goyal wrote:
This
I don't see why we can't randomize anywhere in physical space. We already
handle the kernel above 4 GB and it wouldn't be hard to do the equivalent for
the decompress/relocation code, using a #PF handler. Not all CPUs support 1 GB
pages.
On October 14, 2014 8:37:01 PM PDT, Baoquan He
On Wed, Oct 15, 2014 at 2:37 PM, Filipe Manana fdman...@gmail.com
wrote:
This reverts commit 9c3b306e1c9e6be4be09e99a8fe2227d1005effc.
Switching only one commit root during a transaction is wrong because
it leads
the fs into an inconsistent state. All commit roots should be
switched at
If an anonymous mapping is not allowed to fault thp memory and then
madvise(MADV_HUGEPAGE) is used after fault, khugepaged will never
collapse this memory into thp memory.
This occurs because the madvise(2) handler for thp, hugepage_madvise(),
clears VM_NOHUGEPAGE on the stack and it isn't stored
The patch titled
Subject: mm, thp: fix collapsing of hugepages on madvise
has been added to the -mm tree. Its filename is
mm-thp-fix-collapsing-of-hugepages-on-madvise.patch
This patch should soon appear at
Hi.
I applied the patch to 3.17.1 but although I haven't seen any
corrupted ro snapshot yet it's still impossible to do btrfs send. As
soon as I start btrfs send I still get
ERROR: send ioctl failed with -12: Cannot allocate memory
even if I redirect btrfs send's output to a file (instead of
On Wed, Oct 15, 2014 at 11:42 PM, john terragon jterra...@gmail.com wrote:
Hi.
I applied the patch to 3.17.1 but although I haven't seen any
corrupted ro snapshot yet it's still impossible to do btrfs send. As
soon as I start btrfs send I still get
ERROR: send ioctl failed with -12: Cannot
On 10/15/14 at 01:32pm, H. Peter Anvin wrote:
I don't see why we can't randomize anywhere in physical space. We already
handle the kernel above 4 GB and it wouldn't be hard to do the equivalent for
the decompress/relocation code, using a #PF handler. Not all CPUs support 1
GB pages.
On 10/16/14 at 07:55am, Baoquan He wrote:
On 10/15/14 at 01:32pm, H. Peter Anvin wrote:
I don't see why we can't randomize anywhere in physical space. We already
handle the kernel above 4 GB and it wouldn't be hard to do the equivalent
for the decompress/relocation code, using a #PF
46 matches
Mail list logo
