This is a note to let you know that I've just added the patch titled
md: free unused memory after bitmap resize
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
md-free-unused-memory-after-bitmap-resize.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 12 10:32:42 CET 2017
From: Zdenek Kabelac <zkabelac(a)redhat.com>
Date: Wed, 8 Nov 2017 13:44:56 +0100
Subject: md: free unused memory after bitmap resize
From: Zdenek Kabelac <zkabelac(a)redhat.com>
[ Upstream commit 0868b99c214a3d55486c700de7c3f770b7243e7c ]
When bitmap is resized, the old kalloced chunks just are not released
once the resized bitmap starts to use new space.
This fixes in particular kmemleak reports like this one:
unreferenced object 0xffff8f4311e9c000 (size 4096):
comm "lvm", pid 19333, jiffies 4295263268 (age 528.265s)
hex dump (first 32 bytes):
02 80 02 80 02 80 02 80 02 80 02 80 02 80 02 80 ................
02 80 02 80 02 80 02 80 02 80 02 80 02 80 02 80 ................
backtrace:
[<ffffffffa69471ca>] kmemleak_alloc+0x4a/0xa0
[<ffffffffa628c10e>] kmem_cache_alloc_trace+0x14e/0x2e0
[<ffffffffa676cfec>] bitmap_checkpage+0x7c/0x110
[<ffffffffa676d0c5>] bitmap_get_counter+0x45/0xd0
[<ffffffffa676d6b3>] bitmap_set_memory_bits+0x43/0xe0
[<ffffffffa676e41c>] bitmap_init_from_disk+0x23c/0x530
[<ffffffffa676f1ae>] bitmap_load+0xbe/0x160
[<ffffffffc04c47d3>] raid_preresume+0x203/0x2f0 [dm_raid]
[<ffffffffa677762f>] dm_table_resume_targets+0x4f/0xe0
[<ffffffffa6774b52>] dm_resume+0x122/0x140
[<ffffffffa6779b9f>] dev_suspend+0x18f/0x290
[<ffffffffa677a3a7>] ctl_ioctl+0x287/0x560
[<ffffffffa677a693>] dm_ctl_ioctl+0x13/0x20
[<ffffffffa62d6b46>] do_vfs_ioctl+0xa6/0x750
[<ffffffffa62d7269>] SyS_ioctl+0x79/0x90
[<ffffffffa6956d41>] entry_SYSCALL_64_fastpath+0x1f/0xc2
Signed-off-by: Zdenek Kabelac <zkabelac(a)redhat.com>
Signed-off-by: Shaohua Li <shli(a)fb.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/bitmap.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/drivers/md/bitmap.c
+++ b/drivers/md/bitmap.c
@@ -2158,6 +2158,7 @@ int bitmap_resize(struct bitmap *bitmap,
for (k = 0; k < page; k++) {
kfree(new_bp[k].map);
}
+ kfree(new_bp);
/* restore some fields from old_counts */
bitmap->counts.bp = old_counts.bp;
@@ -2208,6 +2209,14 @@ int bitmap_resize(struct bitmap *bitmap,
block += old_blocks;
}
+ if (bitmap->counts.bp != old_counts.bp) {
+ unsigned long k;
+ for (k = 0; k < old_counts.pages; k++)
+ if (!old_counts.bp[k].hijacked)
+ kfree(old_counts.bp[k].map);
+ kfree(old_counts.bp);
+ }
+
if (!init) {
int i;
while (block < (chunks << chunkshift)) {
Patches currently in stable-queue which might be from zkabelac(a)redhat.com are
queue-4.14/md-free-unused-memory-after-bitmap-resize.patch
This is a note to let you know that I've just added the patch titled
net/smc: use sk_rcvbuf as start for rmb creation
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-smc-use-sk_rcvbuf-as-start-for-rmb-creation.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 12 10:32:42 CET 2017
From: Ursula Braun <ursula.braun(a)de.ibm.com>
Date: Tue, 21 Nov 2017 13:23:53 +0100
Subject: net/smc: use sk_rcvbuf as start for rmb creation
From: Ursula Braun <ursula.braun(a)de.ibm.com>
[ Upstream commit 4e1061f4a2bba1669c7297455c73ddafbebf2b12 ]
Commit 3e034725c0d8 ("net/smc: common functions for RMBs and send buffers")
merged handling of SMC receive and send buffers. It introduced sk_buf_size
as merged start value for size determination. But since sk_buf_size is not
used at all, sk_sndbuf is erroneously used as start for rmb creation.
This patch makes sure, sk_buf_size is really used as intended, and
sk_rcvbuf is used as start value for rmb creation.
Fixes: 3e034725c0d8 ("net/smc: common functions for RMBs and send buffers")
Signed-off-by: Ursula Braun <ubraun(a)linux.vnet.ibm.com>
Reviewed-by: Hans Wippel <hwippel(a)linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/smc/smc_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/smc/smc_core.c
+++ b/net/smc/smc_core.c
@@ -571,7 +571,7 @@ static int __smc_buf_create(struct smc_s
/* use socket send buffer size (w/o overhead) as start value */
sk_buf_size = smc->sk.sk_sndbuf / 2;
- for (bufsize_short = smc_compress_bufsize(smc->sk.sk_sndbuf / 2);
+ for (bufsize_short = smc_compress_bufsize(sk_buf_size);
bufsize_short >= 0; bufsize_short--) {
if (is_rmb) {
Patches currently in stable-queue which might be from ursula.braun(a)de.ibm.com are
queue-4.14/net-smc-use-sk_rcvbuf-as-start-for-rmb-creation.patch
This is a note to let you know that I've just added the patch titled
mailbox: mailbox-test: don't rely on rx_buffer content to signal data ready
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mailbox-mailbox-test-don-t-rely-on-rx_buffer-content-to-signal-data-ready.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 12 10:32:42 CET 2017
From: Sudeep Holla <sudeep.holla(a)arm.com>
Date: Thu, 28 Sep 2017 11:18:53 +0100
Subject: mailbox: mailbox-test: don't rely on rx_buffer content to signal data ready
From: Sudeep Holla <sudeep.holla(a)arm.com>
[ Upstream commit e339c80af95e14de3712d69ddea09a3868fa14cd ]
Currently we rely on the first byte of the Rx buffer to check if there's
any data available to be read. If the first byte of the received buffer
is zero (i.e. null character), then we fail to signal that data is
available even when it's available.
Instead introduce a boolean variable to track the data availability and
update it in the channel receive callback as ready and clear it when the
data is read.
Signed-off-by: Sudeep Holla <sudeep.holla(a)arm.com>
Signed-off-by: Jassi Brar <jaswinder.singh(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mailbox/mailbox-test.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/drivers/mailbox/mailbox-test.c
+++ b/drivers/mailbox/mailbox-test.c
@@ -30,6 +30,7 @@
#define MBOX_HEXDUMP_MAX_LEN (MBOX_HEXDUMP_LINE_LEN * \
(MBOX_MAX_MSG_LEN / MBOX_BYTES_PER_LINE))
+static bool mbox_data_ready;
static struct dentry *root_debugfs_dir;
struct mbox_test_device {
@@ -152,16 +153,14 @@ out:
static bool mbox_test_message_data_ready(struct mbox_test_device *tdev)
{
- unsigned char data;
+ bool data_ready;
unsigned long flags;
spin_lock_irqsave(&tdev->lock, flags);
- data = tdev->rx_buffer[0];
+ data_ready = mbox_data_ready;
spin_unlock_irqrestore(&tdev->lock, flags);
- if (data != '\0')
- return true;
- return false;
+ return data_ready;
}
static ssize_t mbox_test_message_read(struct file *filp, char __user *userbuf,
@@ -223,6 +222,7 @@ static ssize_t mbox_test_message_read(st
*(touser + l) = '\0';
memset(tdev->rx_buffer, 0, MBOX_MAX_MSG_LEN);
+ mbox_data_ready = false;
spin_unlock_irqrestore(&tdev->lock, flags);
@@ -292,6 +292,7 @@ static void mbox_test_receive_message(st
message, MBOX_MAX_MSG_LEN);
memcpy(tdev->rx_buffer, message, MBOX_MAX_MSG_LEN);
}
+ mbox_data_ready = true;
spin_unlock_irqrestore(&tdev->lock, flags);
wake_up_interruptible(&tdev->waitq);
Patches currently in stable-queue which might be from sudeep.holla(a)arm.com are
queue-4.14/mailbox-mailbox-test-don-t-rely-on-rx_buffer-content-to-signal-data-ready.patch
This is a note to let you know that I've just added the patch titled
lib/genalloc.c: make the avail variable an atomic_long_t
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
lib-genalloc.c-make-the-avail-variable-an-atomic_long_t.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 12 10:32:42 CET 2017
From: Stephen Bates <sbates(a)raithlin.com>
Date: Fri, 17 Nov 2017 15:28:16 -0800
Subject: lib/genalloc.c: make the avail variable an atomic_long_t
From: Stephen Bates <sbates(a)raithlin.com>
[ Upstream commit 36a3d1dd4e16bcd0d2ddfb4a2ec7092f0ae0d931 ]
If the amount of resources allocated to a gen_pool exceeds 2^32 then the
avail atomic overflows and this causes problems when clients try and
borrow resources from the pool. This is only expected to be an issue on
64 bit systems.
Add the <linux/atomic.h> header to pull in atomic_long* operations. So
that 32 bit systems continue to use atomic32_t but 64 bit systems can
use atomic64_t.
Link: http://lkml.kernel.org/r/1509033843-25667-1-git-send-email-sbates@raithlin.…
Signed-off-by: Stephen Bates <sbates(a)raithlin.com>
Reviewed-by: Logan Gunthorpe <logang(a)deltatee.com>
Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com>
Reviewed-by: Daniel Mentz <danielmentz(a)google.com>
Cc: Jonathan Corbet <corbet(a)lwn.net>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/genalloc.h | 3 ++-
lib/genalloc.c | 10 +++++-----
2 files changed, 7 insertions(+), 6 deletions(-)
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -32,6 +32,7 @@
#include <linux/types.h>
#include <linux/spinlock_types.h>
+#include <linux/atomic.h>
struct device;
struct device_node;
@@ -71,7 +72,7 @@ struct gen_pool {
*/
struct gen_pool_chunk {
struct list_head next_chunk; /* next chunk in pool */
- atomic_t avail;
+ atomic_long_t avail;
phys_addr_t phys_addr; /* physical starting address of memory chunk */
unsigned long start_addr; /* start address of memory chunk */
unsigned long end_addr; /* end address of memory chunk (inclusive) */
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -194,7 +194,7 @@ int gen_pool_add_virt(struct gen_pool *p
chunk->phys_addr = phys;
chunk->start_addr = virt;
chunk->end_addr = virt + size - 1;
- atomic_set(&chunk->avail, size);
+ atomic_long_set(&chunk->avail, size);
spin_lock(&pool->lock);
list_add_rcu(&chunk->next_chunk, &pool->chunks);
@@ -304,7 +304,7 @@ unsigned long gen_pool_alloc_algo(struct
nbits = (size + (1UL << order) - 1) >> order;
rcu_read_lock();
list_for_each_entry_rcu(chunk, &pool->chunks, next_chunk) {
- if (size > atomic_read(&chunk->avail))
+ if (size > atomic_long_read(&chunk->avail))
continue;
start_bit = 0;
@@ -324,7 +324,7 @@ retry:
addr = chunk->start_addr + ((unsigned long)start_bit << order);
size = nbits << order;
- atomic_sub(size, &chunk->avail);
+ atomic_long_sub(size, &chunk->avail);
break;
}
rcu_read_unlock();
@@ -390,7 +390,7 @@ void gen_pool_free(struct gen_pool *pool
remain = bitmap_clear_ll(chunk->bits, start_bit, nbits);
BUG_ON(remain);
size = nbits << order;
- atomic_add(size, &chunk->avail);
+ atomic_long_add(size, &chunk->avail);
rcu_read_unlock();
return;
}
@@ -464,7 +464,7 @@ size_t gen_pool_avail(struct gen_pool *p
rcu_read_lock();
list_for_each_entry_rcu(chunk, &pool->chunks, next_chunk)
- avail += atomic_read(&chunk->avail);
+ avail += atomic_long_read(&chunk->avail);
rcu_read_unlock();
return avail;
}
Patches currently in stable-queue which might be from sbates(a)raithlin.com are
queue-4.14/lib-genalloc.c-make-the-avail-variable-an-atomic_long_t.patch
This is a note to let you know that I've just added the patch titled
mac80211_hwsim: Fix memory leak in hwsim_new_radio_nl()
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mac80211_hwsim-fix-memory-leak-in-hwsim_new_radio_nl.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 12 10:32:42 CET 2017
From: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Date: Fri, 10 Nov 2017 18:48:50 +0000
Subject: mac80211_hwsim: Fix memory leak in hwsim_new_radio_nl()
From: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
[ Upstream commit 67bd52386125ce1159c0581cbcd2740addf33cd4 ]
hwsim_new_radio_nl() now copies the name attribute in order to add a
null-terminator. mac80211_hwsim_new_radio() (indirectly) copies it
again into the net_device structure, so the first copy is not used or
freed later. Free the first copy before returning.
Fixes: ff4dd73dd2b4 ("mac80211_hwsim: check HWSIM_ATTR_RADIO_NAME length")
Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/mac80211_hwsim.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3108,6 +3108,7 @@ static int hwsim_new_radio_nl(struct sk_
{
struct hwsim_new_radio_params param = { 0 };
const char *hwname = NULL;
+ int ret;
param.reg_strict = info->attrs[HWSIM_ATTR_REG_STRICT_REG];
param.p2p_device = info->attrs[HWSIM_ATTR_SUPPORT_P2P_DEVICE];
@@ -3147,7 +3148,9 @@ static int hwsim_new_radio_nl(struct sk_
param.regd = hwsim_world_regdom_custom[idx];
}
- return mac80211_hwsim_new_radio(info, ¶m);
+ ret = mac80211_hwsim_new_radio(info, ¶m);
+ kfree(hwname);
+ return ret;
}
static int hwsim_del_radio_nl(struct sk_buff *msg, struct genl_info *info)
Patches currently in stable-queue which might be from ben.hutchings(a)codethink.co.uk are
queue-4.14/mac80211_hwsim-fix-memory-leak-in-hwsim_new_radio_nl.patch
This is a note to let you know that I've just added the patch titled
kbuild: rpm-pkg: fix jobserver unavailable warning
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kbuild-rpm-pkg-fix-jobserver-unavailable-warning.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 12 10:32:42 CET 2017
From: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Date: Sat, 30 Sep 2017 10:10:09 +0900
Subject: kbuild: rpm-pkg: fix jobserver unavailable warning
From: Masahiro Yamada <yamada.masahiro(a)socionext.com>
[ Upstream commit 606625be47bc87b6fab0af10cd57aaa675cb9e42 ]
If "make rpm-pkg" or "make binrpm-pkg" is run with -j[jobs] option,
the following warning message is displayed.
warning: jobserver unavailable: using -j1. Add '+' to parent make rule.
Follow the suggestion.
Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
scripts/package/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/scripts/package/Makefile
+++ b/scripts/package/Makefile
@@ -49,7 +49,7 @@ rpm-pkg rpm: FORCE
$(MAKE) clean
$(CONFIG_SHELL) $(MKSPEC) >$(objtree)/kernel.spec
$(call cmd,src_tar,$(KERNELPATH),kernel.spec)
- rpmbuild $(RPMOPTS) --target $(UTS_MACHINE) -ta $(KERNELPATH).tar.gz
+ +rpmbuild $(RPMOPTS) --target $(UTS_MACHINE) -ta $(KERNELPATH).tar.gz
rm $(KERNELPATH).tar.gz kernel.spec
# binrpm-pkg
@@ -57,7 +57,7 @@ rpm-pkg rpm: FORCE
binrpm-pkg: FORCE
$(MAKE) KBUILD_SRC=
$(CONFIG_SHELL) $(MKSPEC) prebuilt > $(objtree)/binkernel.spec
- rpmbuild $(RPMOPTS) --define "_builddir $(objtree)" --target \
+ +rpmbuild $(RPMOPTS) --define "_builddir $(objtree)" --target \
$(UTS_MACHINE) -bb $(objtree)/binkernel.spec
rm binkernel.spec
Patches currently in stable-queue which might be from yamada.masahiro(a)socionext.com are
queue-4.14/kbuild-rpm-pkg-fix-jobserver-unavailable-warning.patch
queue-4.14/firmware-cleanup-firmware_in_kernel-message.patch
queue-4.14/clk-uniphier-fix-dapll2-clock-rate-of-pro5.patch
queue-4.14/kbuild-do-not-call-cc-option-before-kbuild_cflags-initialization.patch
queue-4.14/coccinelle-fix-parallel-build-with-check-scripts-coccicheck.patch
queue-4.14/kbuild-pkg-use-transform-option-to-prefix-paths-in-tar.patch
This is a note to let you know that I've just added the patch titled
kbuild: pkg: use --transform option to prefix paths in tar
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kbuild-pkg-use-transform-option-to-prefix-paths-in-tar.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 12 10:32:42 CET 2017
From: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Date: Wed, 15 Nov 2017 18:17:07 +0900
Subject: kbuild: pkg: use --transform option to prefix paths in tar
From: Masahiro Yamada <yamada.masahiro(a)socionext.com>
[ Upstream commit 2dbc644ac62bbcb9ee78e84719953f611be0413d ]
For rpm-pkg and deb-pkg, a source tar file is created. All paths in
the archive must be prefixed with the base name of the tar so that
everything is contained in the directory when you extract it.
Currently, scripts/package/Makefile uses a symlink for that, and
removes it after the tar is created.
If you terminate the build during the tar creation, the symlink is
left over. Then, at the next package build, you will see a warning
like follows:
ln: '.' and 'kernel-4.14.0+/.' are the same file
It is possible to fix it by adding -n (--no-dereference) option to
the "ln" command, but a cleaner way is to use --transform option
of "tar" command. This option is GNU extension, but it should not
hurt to use it in the Linux build system.
The 'S' flag is needed to exclude symlinks from the path fixup.
Without it, symlinks in the kernel are broken.
Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
scripts/package/Makefile | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/scripts/package/Makefile
+++ b/scripts/package/Makefile
@@ -39,10 +39,9 @@ if test "$(objtree)" != "$(srctree)"; th
false; \
fi ; \
$(srctree)/scripts/setlocalversion --save-scmversion; \
-ln -sf $(srctree) $(2); \
tar -cz $(RCS_TAR_IGNORE) -f $(2).tar.gz \
- $(addprefix $(2)/,$(TAR_CONTENT) $(3)); \
-rm -f $(2) $(objtree)/.scmversion
+ --transform 's:^:$(2)/:S' $(TAR_CONTENT) $(3); \
+rm -f $(objtree)/.scmversion
# rpm-pkg
# ---------------------------------------------------------------------------
Patches currently in stable-queue which might be from yamada.masahiro(a)socionext.com are
queue-4.14/kbuild-rpm-pkg-fix-jobserver-unavailable-warning.patch
queue-4.14/firmware-cleanup-firmware_in_kernel-message.patch
queue-4.14/clk-uniphier-fix-dapll2-clock-rate-of-pro5.patch
queue-4.14/kbuild-do-not-call-cc-option-before-kbuild_cflags-initialization.patch
queue-4.14/coccinelle-fix-parallel-build-with-check-scripts-coccicheck.patch
queue-4.14/kbuild-pkg-use-transform-option-to-prefix-paths-in-tar.patch
This is a note to let you know that I've just added the patch titled
kbuild: do not call cc-option before KBUILD_CFLAGS initialization
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kbuild-do-not-call-cc-option-before-kbuild_cflags-initialization.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 12 10:32:42 CET 2017
From: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Date: Thu, 12 Oct 2017 18:22:25 +0900
Subject: kbuild: do not call cc-option before KBUILD_CFLAGS initialization
From: Masahiro Yamada <yamada.masahiro(a)socionext.com>
[ Upstream commit 433dc2ebe7d17dd21cba7ad5c362d37323592236 ]
Some $(call cc-option,...) are invoked very early, even before
KBUILD_CFLAGS, etc. are initialized.
The returned string from $(call cc-option,...) depends on
KBUILD_CPPFLAGS, KBUILD_CFLAGS, and GCC_PLUGINS_CFLAGS.
Since they are exported, they are not empty when the top Makefile
is recursively invoked.
The recursion occurs in several places. For example, the top
Makefile invokes itself for silentoldconfig. "make tinyconfig",
"make rpm-pkg" are the cases, too.
In those cases, the second call of cc-option from the same line
runs a different shell command due to non-pristine KBUILD_CFLAGS.
To get the same result all the time, KBUILD_* and GCC_PLUGINS_CFLAGS
must be initialized before any call of cc-option. This avoids
garbage data in the .cache.mk file.
Move all calls of cc-option below the config targets because target
compiler flags are unnecessary for Kconfig.
Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Reviewed-by: Douglas Anderson <dianders(a)chromium.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
Makefile | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
--- a/Makefile
+++ b/Makefile
@@ -373,9 +373,6 @@ LDFLAGS_MODULE =
CFLAGS_KERNEL =
AFLAGS_KERNEL =
LDFLAGS_vmlinux =
-CFLAGS_GCOV := -fprofile-arcs -ftest-coverage -fno-tree-loop-im $(call cc-disable-warning,maybe-uninitialized,)
-CFLAGS_KCOV := $(call cc-option,-fsanitize-coverage=trace-pc,)
-
# Use USERINCLUDE when you must reference the UAPI directories only.
USERINCLUDE := \
@@ -394,21 +391,19 @@ LINUXINCLUDE := \
-I$(objtree)/include \
$(USERINCLUDE)
-KBUILD_CPPFLAGS := -D__KERNEL__
-
+KBUILD_AFLAGS := -D__ASSEMBLY__
KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-fno-strict-aliasing -fno-common -fshort-wchar \
-Werror-implicit-function-declaration \
-Wno-format-security \
- -std=gnu89 $(call cc-option,-fno-PIE)
-
-
+ -std=gnu89
+KBUILD_CPPFLAGS := -D__KERNEL__
KBUILD_AFLAGS_KERNEL :=
KBUILD_CFLAGS_KERNEL :=
-KBUILD_AFLAGS := -D__ASSEMBLY__ $(call cc-option,-fno-PIE)
KBUILD_AFLAGS_MODULE := -DMODULE
KBUILD_CFLAGS_MODULE := -DMODULE
KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds
+GCC_PLUGINS_CFLAGS :=
# Read KERNELRELEASE from include/config/kernel.release (if it exists)
KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null)
@@ -421,7 +416,7 @@ export MAKE AWK GENKSYMS INSTALLKERNEL P
export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
-export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_GCOV CFLAGS_KCOV CFLAGS_KASAN CFLAGS_UBSAN
+export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_KASAN CFLAGS_UBSAN
export KBUILD_AFLAGS AFLAGS_KERNEL AFLAGS_MODULE
export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE KBUILD_LDFLAGS_MODULE
export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
@@ -622,6 +617,12 @@ endif
# Defaults to vmlinux, but the arch makefile usually adds further targets
all: vmlinux
+KBUILD_CFLAGS += $(call cc-option,-fno-PIE)
+KBUILD_AFLAGS += $(call cc-option,-fno-PIE)
+CFLAGS_GCOV := -fprofile-arcs -ftest-coverage -fno-tree-loop-im $(call cc-disable-warning,maybe-uninitialized,)
+CFLAGS_KCOV := $(call cc-option,-fsanitize-coverage=trace-pc,)
+export CFLAGS_GCOV CFLAGS_KCOV
+
# The arch Makefile can set ARCH_{CPP,A,C}FLAGS to override the default
# values of the respective KBUILD_* variables
ARCH_CPPFLAGS :=
Patches currently in stable-queue which might be from yamada.masahiro(a)socionext.com are
queue-4.14/kbuild-rpm-pkg-fix-jobserver-unavailable-warning.patch
queue-4.14/firmware-cleanup-firmware_in_kernel-message.patch
queue-4.14/clk-uniphier-fix-dapll2-clock-rate-of-pro5.patch
queue-4.14/kbuild-do-not-call-cc-option-before-kbuild_cflags-initialization.patch
queue-4.14/coccinelle-fix-parallel-build-with-check-scripts-coccicheck.patch
queue-4.14/kbuild-pkg-use-transform-option-to-prefix-paths-in-tar.patch
This is a note to let you know that I've just added the patch titled
irqchip/qcom: Fix u32 comparison with value less than zero
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
irqchip-qcom-fix-u32-comparison-with-value-less-than-zero.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 12 10:32:42 CET 2017
From: Colin Ian King <colin.king(a)canonical.com>
Date: Fri, 17 Nov 2017 18:35:53 +0000
Subject: irqchip/qcom: Fix u32 comparison with value less than zero
From: Colin Ian King <colin.king(a)canonical.com>
[ Upstream commit e9990d70e8a063a7b894c5cbb99f630a0f41200d ]
The comparison of u32 nregs being less than zero is never true since
nregs is unsigned. Fix this by making nregs a signed integer.
Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver")
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Marc Zyngier <marc.zyngier(a)arm.com>
Cc: kernel-janitors(a)vger.kernel.org
Cc: Jason Cooper <jason(a)lakedaemon.net>
Link: https://lkml.kernel.org/r/20171117183553.2739-1-colin.king@canonical.com
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/irqchip/qcom-irq-combiner.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/irqchip/qcom-irq-combiner.c
+++ b/drivers/irqchip/qcom-irq-combiner.c
@@ -238,7 +238,7 @@ static int __init combiner_probe(struct
{
struct combiner *combiner;
size_t alloc_sz;
- u32 nregs;
+ int nregs;
int err;
nregs = count_registers(pdev);
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-4.14/rsi-fix-memory-leak-on-buf-and-usb_reg_buf.patch
queue-4.14/irqchip-qcom-fix-u32-comparison-with-value-less-than-zero.patch
This is a note to let you know that I've just added the patch titled
jump_label: Invoke jump_label_test() via early_initcall()
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
jump_label-invoke-jump_label_test-via-early_initcall.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 12 10:32:42 CET 2017
From: Jason Baron <jbaron(a)akamai.com>
Date: Mon, 13 Nov 2017 16:48:47 -0500
Subject: jump_label: Invoke jump_label_test() via early_initcall()
From: Jason Baron <jbaron(a)akamai.com>
[ Upstream commit 92ee46efeb505ead3ab06d3c5ce695637ed5f152 ]
Fengguang Wu reported that running the rcuperf test during boot can cause
the jump_label_test() to hit a WARN_ON(). The issue is that the core jump
label code relies on kernel_text_address() to detect when it can no longer
update branches that may be contained in __init sections. The
kernel_text_address() in turn assumes that if the system_state variable is
greter than or equal to SYSTEM_RUNNING then __init sections are no longer
valid (since the assumption is that they have been freed). However, when
rcuperf is setup to run in early boot it can call kernel_power_off() which
sets the system_state to SYSTEM_POWER_OFF.
Since rcuperf initialization is invoked via a module_init(), we can make
the dependency of jump_label_test() needing to complete before rcuperf
explicit by calling it via early_initcall().
Reported-by: Fengguang Wu <fengguang.wu(a)intel.com>
Signed-off-by: Jason Baron <jbaron(a)akamai.com>
Acked-by: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Steven Rostedt <rostedt(a)goodmis.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/1510609727-2238-1-git-send-email-jbaron@akamai.com
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/jump_label.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -769,7 +769,7 @@ static __init int jump_label_test(void)
return 0;
}
-late_initcall(jump_label_test);
+early_initcall(jump_label_test);
#endif /* STATIC_KEYS_SELFTEST */
#endif /* HAVE_JUMP_LABEL */
Patches currently in stable-queue which might be from jbaron(a)akamai.com are
queue-4.14/jump_label-invoke-jump_label_test-via-early_initcall.patch
queue-4.14/dynamic-debug-howto-fix-optional-omitted-ending-line-number-to-be-large-instead-of-0.patch