This is a note to let you know that I've just added the patch titled
powerpc/perf: Fix pmu_count to count only nest imc pmus
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:
powerpc-perf-fix-pmu_count-to-count-only-nest-imc-pmus.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: Madhavan Srinivasan <maddy(a)linux.vnet.ibm.com>
Date: Wed, 22 Nov 2017 10:45:38 +0530
Subject: powerpc/perf: Fix pmu_count to count only nest imc pmus
From: Madhavan Srinivasan <maddy(a)linux.vnet.ibm.com>
[ Upstream commit de34787f1096cce38e2590be0013b44418d14546 ]
"pmu_count" in opal_imc_counters_probe() is intended to hold
the number of successful nest imc pmu registerations. But
current code also counts other imc units like core_imc and
thread_imc. Patch add a check to count only nest imc pmus.
Signed-off-by: Madhavan Srinivasan <maddy(a)linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/platforms/powernv/opal-imc.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/arch/powerpc/platforms/powernv/opal-imc.c
+++ b/arch/powerpc/platforms/powernv/opal-imc.c
@@ -191,8 +191,10 @@ static int opal_imc_counters_probe(struc
break;
}
- if (!imc_pmu_create(imc_dev, pmu_count, domain))
- pmu_count++;
+ if (!imc_pmu_create(imc_dev, pmu_count, domain)) {
+ if (domain == IMC_DOMAIN_NEST)
+ pmu_count++;
+ }
}
return 0;
Patches currently in stable-queue which might be from maddy(a)linux.vnet.ibm.com are
queue-4.14/powerpc-perf-fix-pmu_count-to-count-only-nest-imc-pmus.patch
This is a note to let you know that I've just added the patch titled
pipe: match pipe_max_size data type with procfs
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:
pipe-match-pipe_max_size-data-type-with-procfs.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: Joe Lawrence <joe.lawrence(a)redhat.com>
Date: Fri, 17 Nov 2017 15:29:17 -0800
Subject: pipe: match pipe_max_size data type with procfs
From: Joe Lawrence <joe.lawrence(a)redhat.com>
[ Upstream commit 98159d977f71c3b3dee898d1c34e56f520b094e7 ]
Patch series "A few round_pipe_size() and pipe-max-size fixups", v3.
While backporting Michael's "pipe: fix limit handling" patchset to a
distro-kernel, Mikulas noticed that current upstream pipe limit handling
contains a few problems:
1 - procfs signed wrap: echo'ing a large number into
/proc/sys/fs/pipe-max-size and then cat'ing it back out shows a
negative value.
2 - round_pipe_size() nr_pages overflow on 32bit: this would
subsequently try roundup_pow_of_two(0), which is undefined.
3 - visible non-rounded pipe-max-size value: there is no mutual
exclusion or protection between the time pipe_max_size is assigned
a raw value from proc_dointvec_minmax() and when it is rounded.
4 - unsigned long -> unsigned int conversion makes for potential odd
return errors from do_proc_douintvec_minmax_conv() and
do_proc_dopipe_max_size_conv().
This version underwent the same testing as v1:
https://marc.info/?l=linux-kernel&m=150643571406022&w=2
This patch (of 4):
pipe_max_size is defined as an unsigned int:
unsigned int pipe_max_size = 1048576;
but its procfs/sysctl representation is an integer:
static struct ctl_table fs_table[] = {
...
{
.procname = "pipe-max-size",
.data = &pipe_max_size,
.maxlen = sizeof(int),
.mode = 0644,
.proc_handler = &pipe_proc_fn,
.extra1 = &pipe_min_size,
},
...
that is signed:
int pipe_proc_fn(struct ctl_table *table, int write, void __user *buf,
size_t *lenp, loff_t *ppos)
{
...
ret = proc_dointvec_minmax(table, write, buf, lenp, ppos)
This leads to signed results via procfs for large values of pipe_max_size:
% echo 2147483647 >/proc/sys/fs/pipe-max-size
% cat /proc/sys/fs/pipe-max-size
-2147483648
Use unsigned operations on this variable to avoid such negative values.
Link: http://lkml.kernel.org/r/1507658689-11669-2-git-send-email-joe.lawrence@red…
Signed-off-by: Joe Lawrence <joe.lawrence(a)redhat.com>
Reported-by: Mikulas Patocka <mpatocka(a)redhat.com>
Reviewed-by: Mikulas Patocka <mpatocka(a)redhat.com>
Cc: Michael Kerrisk <mtk.manpages(a)gmail.com>
Cc: Randy Dunlap <rdunlap(a)infradead.org>
Cc: Al Viro <viro(a)zeniv.linux.org.uk>
Cc: Jens Axboe <axboe(a)kernel.dk>
Cc: Josh Poimboeuf <jpoimboe(a)redhat.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>
---
fs/pipe.c | 2 +-
kernel/sysctl.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -1125,7 +1125,7 @@ int pipe_proc_fn(struct ctl_table *table
{
int ret;
- ret = proc_dointvec_minmax(table, write, buf, lenp, ppos);
+ ret = proc_douintvec_minmax(table, write, buf, lenp, ppos);
if (ret < 0 || !write)
return ret;
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1822,7 +1822,7 @@ static struct ctl_table fs_table[] = {
{
.procname = "pipe-max-size",
.data = &pipe_max_size,
- .maxlen = sizeof(int),
+ .maxlen = sizeof(pipe_max_size),
.mode = 0644,
.proc_handler = &pipe_proc_fn,
.extra1 = &pipe_min_size,
Patches currently in stable-queue which might be from joe.lawrence(a)redhat.com are
queue-4.14/pipe-match-pipe_max_size-data-type-with-procfs.patch
This is a note to let you know that I've just added the patch titled
nvmet-rdma: update queue list during ib_device removal
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:
nvmet-rdma-update-queue-list-during-ib_device-removal.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: Israel Rukshin <israelr(a)mellanox.com>
Date: Sun, 5 Nov 2017 08:43:01 +0000
Subject: nvmet-rdma: update queue list during ib_device removal
From: Israel Rukshin <israelr(a)mellanox.com>
[ Upstream commit 43b92fd27aaef0f529c9321cfebbaec1d7b8f503 ]
A NULL deref happens when nvmet_rdma_remove_one() is called more than once
(e.g. while connected via 2 ports).
The first call frees the queues related to the first ib_device but
doesn't remove them from the queue list.
While calling nvmet_rdma_remove_one() for the second ib_device it goes over
the full queue list again and we get the NULL deref.
Fixes: f1d4ef7d ("nvmet-rdma: register ib_client to not deadlock in device removal")
Signed-off-by: Israel Rukshin <israelr(a)mellanox.com>
Reviewed-by: Max Gurtovoy <maxg(a)mellanox.com>
Reviewed-by: Sagi Grimberg <sagi(a)grmberg.me>
Signed-off-by: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/nvme/target/rdma.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/nvme/target/rdma.c
+++ b/drivers/nvme/target/rdma.c
@@ -1512,15 +1512,17 @@ static struct nvmet_fabrics_ops nvmet_rd
static void nvmet_rdma_remove_one(struct ib_device *ib_device, void *client_data)
{
- struct nvmet_rdma_queue *queue;
+ struct nvmet_rdma_queue *queue, *tmp;
/* Device is being removed, delete all queues using this device */
mutex_lock(&nvmet_rdma_queue_mutex);
- list_for_each_entry(queue, &nvmet_rdma_queue_list, queue_list) {
+ list_for_each_entry_safe(queue, tmp, &nvmet_rdma_queue_list,
+ queue_list) {
if (queue->dev->device != ib_device)
continue;
pr_info("Removing queue %d\n", queue->idx);
+ list_del_init(&queue->queue_list);
__nvmet_rdma_queue_disconnect(queue);
}
mutex_unlock(&nvmet_rdma_queue_mutex);
Patches currently in stable-queue which might be from israelr(a)mellanox.com are
queue-4.14/nvmet-rdma-update-queue-list-during-ib_device-removal.patch
This is a note to let you know that I've just added the patch titled
NFS: Fix a typo in nfs_rename()
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:
nfs-fix-a-typo-in-nfs_rename.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: Trond Myklebust <trond.myklebust(a)primarydata.com>
Date: Mon, 6 Nov 2017 15:28:04 -0500
Subject: NFS: Fix a typo in nfs_rename()
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
[ Upstream commit d803224c84be067754db7fa58a93f36f61566493 ]
On successful rename, the "old_dentry" is retained and is attached to
the "new_dir", so we need to call nfs_set_verifier() accordingly.
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/dir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -2064,7 +2064,7 @@ out:
* should mark the directories for revalidation.
*/
d_move(old_dentry, new_dentry);
- nfs_set_verifier(new_dentry,
+ nfs_set_verifier(old_dentry,
nfs_save_change_attribute(new_dir));
} else if (error == -ENOENT)
nfs_dentry_handle_enoent(old_dentry);
Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are
queue-4.14/nfs-fix-a-typo-in-nfs_rename.patch
This is a note to let you know that I've just added the patch titled
nfp: inherit the max_mtu from the PF netdev
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:
nfp-inherit-the-max_mtu-from-the-pf-netdev.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: Dirk van der Merwe <dirk.vandermerwe(a)netronome.com>
Date: Thu, 16 Nov 2017 17:06:41 -0800
Subject: nfp: inherit the max_mtu from the PF netdev
From: Dirk van der Merwe <dirk.vandermerwe(a)netronome.com>
[ Upstream commit 743ba5b47f7961fb29f2e06bb694fb4f068ac58f ]
The PF netdev is used for data transfer for reprs, so reprs inherit the
maximum MTU settings of the PF netdev.
Fixes: 5de73ee46704 ("nfp: general representor implementation")
Signed-off-by: Dirk van der Merwe <dirk.vandermerwe(a)netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski(a)netronome.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>
---
drivers/net/ethernet/netronome/nfp/nfp_net_repr.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_repr.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_repr.c
@@ -297,6 +297,8 @@ int nfp_repr_init(struct nfp_app *app, s
netdev->netdev_ops = &nfp_repr_netdev_ops;
netdev->ethtool_ops = &nfp_port_ethtool_ops;
+ netdev->max_mtu = pf_netdev->max_mtu;
+
SWITCHDEV_SET_OPS(netdev, &nfp_port_switchdev_ops);
if (nfp_app_has_tc(app)) {
Patches currently in stable-queue which might be from dirk.vandermerwe(a)netronome.com are
queue-4.14/nfp-inherit-the-max_mtu-from-the-pf-netdev.patch
This is a note to let you know that I've just added the patch titled
nfp: fix flower offload metadata flag usage
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:
nfp-fix-flower-offload-metadata-flag-usage.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: Pieter Jansen van Vuuren <pieter.jansenvanvuuren(a)netronome.com>
Date: Thu, 16 Nov 2017 17:06:39 -0800
Subject: nfp: fix flower offload metadata flag usage
From: Pieter Jansen van Vuuren <pieter.jansenvanvuuren(a)netronome.com>
[ Upstream commit 6c3ab204f4ca00374a374bc0fc9a275b64d1bcbb ]
Hardware has no notion of new or last mask id, instead it makes use of the
message type (i.e. add flow or del flow) in combination with a single bit
in metadata flags to determine when to add or delete a mask id. Previously
we made use of the new or last flags to indicate that a new mask should be
allocated or deallocated, respectively. This incorrect behaviour is fixed
by making use single bit in metadata flags to indicate mask allocation or
deallocation.
Fixes: 43f84b72c50d ("nfp: add metadata to each flow offload")
Signed-off-by: Pieter Jansen van Vuuren <pieter.jansenvanvuuren(a)netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski(a)netronome.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>
---
drivers/net/ethernet/netronome/nfp/flower/main.h | 3 +--
drivers/net/ethernet/netronome/nfp/flower/metadata.c | 7 +++++--
2 files changed, 6 insertions(+), 4 deletions(-)
--- a/drivers/net/ethernet/netronome/nfp/flower/main.h
+++ b/drivers/net/ethernet/netronome/nfp/flower/main.h
@@ -52,8 +52,7 @@ struct nfp_app;
#define NFP_FLOWER_MASK_ELEMENT_RS 1
#define NFP_FLOWER_MASK_HASH_BITS 10
-#define NFP_FL_META_FLAG_NEW_MASK 128
-#define NFP_FL_META_FLAG_LAST_MASK 1
+#define NFP_FL_META_FLAG_MANAGE_MASK BIT(7)
#define NFP_FL_MASK_REUSE_TIME_NS 40000
#define NFP_FL_MASK_ID_LOCATION 1
--- a/drivers/net/ethernet/netronome/nfp/flower/metadata.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/metadata.c
@@ -282,7 +282,7 @@ nfp_check_mask_add(struct nfp_app *app,
id = nfp_add_mask_table(app, mask_data, mask_len);
if (id < 0)
return false;
- *meta_flags |= NFP_FL_META_FLAG_NEW_MASK;
+ *meta_flags |= NFP_FL_META_FLAG_MANAGE_MASK;
}
*mask_id = id;
@@ -299,6 +299,9 @@ nfp_check_mask_remove(struct nfp_app *ap
if (!mask_entry)
return false;
+ if (meta_flags)
+ *meta_flags &= ~NFP_FL_META_FLAG_MANAGE_MASK;
+
*mask_id = mask_entry->mask_id;
mask_entry->ref_cnt--;
if (!mask_entry->ref_cnt) {
@@ -306,7 +309,7 @@ nfp_check_mask_remove(struct nfp_app *ap
nfp_release_mask_id(app, *mask_id);
kfree(mask_entry);
if (meta_flags)
- *meta_flags |= NFP_FL_META_FLAG_LAST_MASK;
+ *meta_flags |= NFP_FL_META_FLAG_MANAGE_MASK;
}
return true;
Patches currently in stable-queue which might be from pieter.jansenvanvuuren(a)netronome.com are
queue-4.14/nfp-fix-flower-offload-metadata-flag-usage.patch
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
This is a note to let you know that I've just added the patch titled
ipvlan: fix ipv6 outbound device
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:
ipvlan-fix-ipv6-outbound-device.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: Keefe Liu <liuqifa(a)huawei.com>
Date: Thu, 9 Nov 2017 20:09:31 +0800
Subject: ipvlan: fix ipv6 outbound device
From: Keefe Liu <liuqifa(a)huawei.com>
[ Upstream commit ca29fd7cce5a6444d57fb86517589a1a31c759e1 ]
When process the outbound packet of ipv6, we should assign the master
device to output device other than input device.
Signed-off-by: Keefe Liu <liuqifa(a)huawei.com>
Acked-by: Mahesh Bandewar <maheshb(a)google.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>
---
drivers/net/ipvlan/ipvlan_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ipvlan/ipvlan_core.c
+++ b/drivers/net/ipvlan/ipvlan_core.c
@@ -409,7 +409,7 @@ static int ipvlan_process_v6_outbound(st
struct dst_entry *dst;
int err, ret = NET_XMIT_DROP;
struct flowi6 fl6 = {
- .flowi6_iif = dev->ifindex,
+ .flowi6_oif = dev->ifindex,
.daddr = ip6h->daddr,
.saddr = ip6h->saddr,
.flowi6_flags = FLOWI_FLAG_ANYSRC,
Patches currently in stable-queue which might be from liuqifa(a)huawei.com are
queue-4.14/ipvlan-fix-ipv6-outbound-device.patch
This is a note to let you know that I've just added the patch titled
ide: ide-atapi: fix compile error with defining macro DEBUG
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:
ide-ide-atapi-fix-compile-error-with-defining-macro-debug.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: Hongxu Jia <hongxu.jia(a)windriver.com>
Date: Fri, 10 Nov 2017 15:59:17 +0800
Subject: ide: ide-atapi: fix compile error with defining macro DEBUG
From: Hongxu Jia <hongxu.jia(a)windriver.com>
[ Upstream commit 8dc7a31fbce5e2dbbacd83d910da37105181b054 ]
Compile ide-atapi failed with defining macro "DEBUG"
...
|drivers/ide/ide-atapi.c:285:52: error: 'struct request' has
no member named 'cmd'; did you mean 'csd'?
| debug_log("%s: rq->cmd[0]: 0x%x\n", __func__, rq->cmd[0]);
...
Since we split the scsi_request out of struct request, it missed
do the same thing on debug_log
Fixes: 82ed4db499b8 ("block: split scsi_request out of struct request")
Signed-off-by: Hongxu Jia <hongxu.jia(a)windriver.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/ide/ide-atapi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/ide/ide-atapi.c
+++ b/drivers/ide/ide-atapi.c
@@ -282,7 +282,7 @@ int ide_cd_expiry(ide_drive_t *drive)
struct request *rq = drive->hwif->rq;
unsigned long wait = 0;
- debug_log("%s: rq->cmd[0]: 0x%x\n", __func__, rq->cmd[0]);
+ debug_log("%s: scsi_req(rq)->cmd[0]: 0x%x\n", __func__, scsi_req(rq)->cmd[0]);
/*
* Some commands are *slow* and normally take a long time to complete.
@@ -463,7 +463,7 @@ static ide_startstop_t ide_pc_intr(ide_d
return ide_do_reset(drive);
}
- debug_log("[cmd %x]: check condition\n", rq->cmd[0]);
+ debug_log("[cmd %x]: check condition\n", scsi_req(rq)->cmd[0]);
/* Retry operation */
ide_retry_pc(drive);
@@ -531,7 +531,7 @@ static ide_startstop_t ide_pc_intr(ide_d
ide_pad_transfer(drive, write, bcount);
debug_log("[cmd %x] transferred %d bytes, padded %d bytes, resid: %u\n",
- rq->cmd[0], done, bcount, scsi_req(rq)->resid_len);
+ scsi_req(rq)->cmd[0], done, bcount, scsi_req(rq)->resid_len);
/* And set the interrupt handler again */
ide_set_handler(drive, ide_pc_intr, timeout);
Patches currently in stable-queue which might be from hongxu.jia(a)windriver.com are
queue-4.14/ide-ide-atapi-fix-compile-error-with-defining-macro-debug.patch
This is a note to let you know that I've just added the patch titled
IB/mlx4: Increase maximal message size under UD QP
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:
ib-mlx4-increase-maximal-message-size-under-ud-qp.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: Mark Bloch <markb(a)mellanox.com>
Date: Thu, 2 Nov 2017 15:22:26 +0200
Subject: IB/mlx4: Increase maximal message size under UD QP
From: Mark Bloch <markb(a)mellanox.com>
[ Upstream commit 5f22a1d87c5315a98981ecf93cd8de226cffe6ca ]
Maximal message should be used as a limit to the max message payload allowed,
without the headers. The ConnectX-3 check is done against this value includes
the headers. When the payload is 4K this will cause the NIC to drop packets.
Increase maximal message to 8K as workaround, this shouldn't change current
behaviour because we continue to set the MTU to 4k.
To reproduce;
set MTU to 4296 on the corresponding interface, for example:
ifconfig eth0 mtu 4296 (both server and client)
On server:
ib_send_bw -c UD -d mlx4_0 -s 4096 -n 1000000 -i1 -m 4096
On client:
ib_send_bw -d mlx4_0 -c UD <server_ip> -s 4096 -n 1000000 -i 1 -m 4096
Fixes: 6e0d733d9215 ("IB/mlx4: Allow 4K messages for UD QPs")
Signed-off-by: Mark Bloch <markb(a)mellanox.com>
Reviewed-by: Majd Dibbiny <majd(a)mellanox.com>
Signed-off-by: Leon Romanovsky <leon(a)kernel.org>
Signed-off-by: Doug Ledford <dledford(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/mlx4/qp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/hw/mlx4/qp.c
+++ b/drivers/infiniband/hw/mlx4/qp.c
@@ -2216,7 +2216,7 @@ static int __mlx4_ib_modify_qp(void *src
context->mtu_msgmax = (IB_MTU_4096 << 5) |
ilog2(dev->dev->caps.max_gso_sz);
else
- context->mtu_msgmax = (IB_MTU_4096 << 5) | 12;
+ context->mtu_msgmax = (IB_MTU_4096 << 5) | 13;
} else if (attr_mask & IB_QP_PATH_MTU) {
if (attr->path_mtu < IB_MTU_256 || attr->path_mtu > IB_MTU_4096) {
pr_err("path MTU (%u) is invalid\n",
Patches currently in stable-queue which might be from markb(a)mellanox.com are
queue-4.14/ib-mlx4-increase-maximal-message-size-under-ud-qp.patch
This is a note to let you know that I've just added the patch titled
IB/mlx5: Assign send CQ and recv CQ of UMR QP
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:
ib-mlx5-assign-send-cq-and-recv-cq-of-umr-qp.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: Majd Dibbiny <majd(a)mellanox.com>
Date: Mon, 30 Oct 2017 14:23:13 +0200
Subject: IB/mlx5: Assign send CQ and recv CQ of UMR QP
From: Majd Dibbiny <majd(a)mellanox.com>
[ Upstream commit 31fde034a8bd964a5c7c1a5663fc87a913158db2 ]
The UMR's QP is created by calling mlx5_ib_create_qp directly, and
therefore the send CQ and the recv CQ on the ibqp weren't assigned.
Assign them right after calling the mlx5_ib_create_qp to assure
that any access to those pointers will work as expected and won't
crash the system as might happen as part of reset flow.
Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters")
Signed-off-by: Majd Dibbiny <majd(a)mellanox.com>
Reviewed-by: Yishai Hadas <yishaih(a)mellanox.com>
Signed-off-by: Leon Romanovsky <leon(a)kernel.org>
Signed-off-by: Doug Ledford <dledford(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/mlx5/main.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -3097,6 +3097,8 @@ static int create_umr_res(struct mlx5_ib
qp->real_qp = qp;
qp->uobject = NULL;
qp->qp_type = MLX5_IB_QPT_REG_UMR;
+ qp->send_cq = init_attr->send_cq;
+ qp->recv_cq = init_attr->recv_cq;
attr->qp_state = IB_QPS_INIT;
attr->port_num = 1;
Patches currently in stable-queue which might be from majd(a)mellanox.com are
queue-4.14/ib-mlx5-assign-send-cq-and-recv-cq-of-umr-qp.patch
queue-4.14/ib-mlx4-increase-maximal-message-size-under-ud-qp.patch
This is a note to let you know that I've just added the patch titled
geneve: fix fill_info when link down
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:
geneve-fix-fill_info-when-link-down.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: Hangbin Liu <liuhangbin(a)gmail.com>
Date: Wed, 15 Nov 2017 09:43:09 +0800
Subject: geneve: fix fill_info when link down
From: Hangbin Liu <liuhangbin(a)gmail.com>
[ Upstream commit fd7eafd02121d6ef501ef1a4a891e6061366c952 ]
geneve->sock4/6 were added with geneve_open and released with geneve_stop.
So when geneve link down, we will not able to show remote address and
checksum info after commit 11387fe4a98 ("geneve: fix fill_info when using
collect_metadata").
Fix this by avoid passing *_REMOTE{,6} for COLLECT_METADATA since they are
mutually exclusive, and always show UDP_ZERO_CSUM6_RX info.
Fixes: 11387fe4a98 ("geneve: fix fill_info when using collect_metadata")
Signed-off-by: Hangbin Liu <liuhangbin(a)gmail.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>
---
drivers/net/geneve.c | 24 ++++++++++--------------
1 file changed, 10 insertions(+), 14 deletions(-)
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -1503,6 +1503,7 @@ static int geneve_fill_info(struct sk_bu
{
struct geneve_dev *geneve = netdev_priv(dev);
struct ip_tunnel_info *info = &geneve->info;
+ bool metadata = geneve->collect_md;
__u8 tmp_vni[3];
__u32 vni;
@@ -1511,32 +1512,24 @@ static int geneve_fill_info(struct sk_bu
if (nla_put_u32(skb, IFLA_GENEVE_ID, vni))
goto nla_put_failure;
- if (rtnl_dereference(geneve->sock4)) {
+ if (!metadata && ip_tunnel_info_af(info) == AF_INET) {
if (nla_put_in_addr(skb, IFLA_GENEVE_REMOTE,
info->key.u.ipv4.dst))
goto nla_put_failure;
-
if (nla_put_u8(skb, IFLA_GENEVE_UDP_CSUM,
!!(info->key.tun_flags & TUNNEL_CSUM)))
goto nla_put_failure;
- }
-
#if IS_ENABLED(CONFIG_IPV6)
- if (rtnl_dereference(geneve->sock6)) {
+ } else if (!metadata) {
if (nla_put_in6_addr(skb, IFLA_GENEVE_REMOTE6,
&info->key.u.ipv6.dst))
goto nla_put_failure;
-
if (nla_put_u8(skb, IFLA_GENEVE_UDP_ZERO_CSUM6_TX,
!(info->key.tun_flags & TUNNEL_CSUM)))
goto nla_put_failure;
-
- if (nla_put_u8(skb, IFLA_GENEVE_UDP_ZERO_CSUM6_RX,
- !geneve->use_udp6_rx_checksums))
- goto nla_put_failure;
- }
#endif
+ }
if (nla_put_u8(skb, IFLA_GENEVE_TTL, info->key.ttl) ||
nla_put_u8(skb, IFLA_GENEVE_TOS, info->key.tos) ||
@@ -1546,10 +1539,13 @@ static int geneve_fill_info(struct sk_bu
if (nla_put_be16(skb, IFLA_GENEVE_PORT, info->key.tp_dst))
goto nla_put_failure;
- if (geneve->collect_md) {
- if (nla_put_flag(skb, IFLA_GENEVE_COLLECT_METADATA))
+ if (metadata && nla_put_flag(skb, IFLA_GENEVE_COLLECT_METADATA))
goto nla_put_failure;
- }
+
+ if (nla_put_u8(skb, IFLA_GENEVE_UDP_ZERO_CSUM6_RX,
+ !geneve->use_udp6_rx_checksums))
+ goto nla_put_failure;
+
return 0;
nla_put_failure:
Patches currently in stable-queue which might be from liuhangbin(a)gmail.com are
queue-4.14/geneve-fix-fill_info-when-link-down.patch
This is a note to let you know that I've just added the patch titled
gre6: use log_ecn_error module parameter in ip6_tnl_rcv()
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:
gre6-use-log_ecn_error-module-parameter-in-ip6_tnl_rcv.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: Alexey Kodanev <alexey.kodanev(a)oracle.com>
Date: Fri, 17 Nov 2017 19:16:17 +0300
Subject: gre6: use log_ecn_error module parameter in ip6_tnl_rcv()
From: Alexey Kodanev <alexey.kodanev(a)oracle.com>
[ Upstream commit 981542c526ecd846920bc500e9989da906ee9fb9 ]
After commit 308edfdf1563 ("gre6: Cleanup GREv6 receive path, call
common GRE functions") it's not used anywhere in the module, but
previously was used in ip6gre_rcv().
Fixes: 308edfdf1563 ("gre6: Cleanup GREv6 receive path, call common GRE functions")
Signed-off-by: Alexey Kodanev <alexey.kodanev(a)oracle.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/ipv6/ip6_gre.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -461,7 +461,7 @@ static int ip6gre_rcv(struct sk_buff *sk
&ipv6h->saddr, &ipv6h->daddr, tpi->key,
tpi->proto);
if (tunnel) {
- ip6_tnl_rcv(tunnel, skb, tpi, NULL, false);
+ ip6_tnl_rcv(tunnel, skb, tpi, NULL, log_ecn_error);
return PACKET_RCVD;
}
Patches currently in stable-queue which might be from alexey.kodanev(a)oracle.com are
queue-4.14/gre6-use-log_ecn_error-module-parameter-in-ip6_tnl_rcv.patch
This is a note to let you know that I've just added the patch titled
f2fs: fix to clear FI_NO_PREALLOC
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:
f2fs-fix-to-clear-fi_no_prealloc.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: Chao Yu <yuchao0(a)huawei.com>
Date: Mon, 13 Nov 2017 17:32:39 +0800
Subject: f2fs: fix to clear FI_NO_PREALLOC
From: Chao Yu <yuchao0(a)huawei.com>
[ Upstream commit 28cfafb73853f0494b06649716687a3ea07681d5 ]
We need to clear FI_NO_PREALLOC flag in error path of f2fs_file_write_iter,
otherwise we will lose the chance to preallocate blocks in latter write()
at one time.
Fixes: dc91de78e5e1 ("f2fs: do not preallocate blocks which has wrong buffer")
Signed-off-by: Chao Yu <yuchao0(a)huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/f2fs/file.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -2697,6 +2697,7 @@ static ssize_t f2fs_file_write_iter(stru
err = f2fs_preallocate_blocks(iocb, from);
if (err) {
+ clear_inode_flag(inode, FI_NO_PREALLOC);
inode_unlock(inode);
return err;
}
Patches currently in stable-queue which might be from yuchao0(a)huawei.com are
queue-4.14/f2fs-fix-to-clear-fi_no_prealloc.patch
This is a note to let you know that I've just added the patch titled
fcntl: don't leak fd reference when fixup_compat_flock fails
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:
fcntl-don-t-leak-fd-reference-when-fixup_compat_flock-fails.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: Jeff Layton <jlayton(a)redhat.com>
Date: Tue, 14 Nov 2017 14:43:56 -0500
Subject: fcntl: don't leak fd reference when fixup_compat_flock fails
From: Jeff Layton <jlayton(a)redhat.com>
[ Upstream commit 9280a601e6080c9ff658468c1c775ff6514099a6 ]
Currently we just return err here, but we need to put the fd reference
first.
Fixes: 94073ad77fff (fs/locks: don't mess with the address limit in compat_fcntl64)
Signed-off-by: Jeff Layton <jlayton(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/fcntl.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -632,9 +632,8 @@ COMPAT_SYSCALL_DEFINE3(fcntl64, unsigned
if (err)
break;
err = fixup_compat_flock(&flock);
- if (err)
- return err;
- err = put_compat_flock(&flock, compat_ptr(arg));
+ if (!err)
+ err = put_compat_flock(&flock, compat_ptr(arg));
break;
case F_GETLK64:
case F_OFD_GETLK:
Patches currently in stable-queue which might be from jlayton(a)redhat.com are
queue-4.14/fcntl-don-t-leak-fd-reference-when-fixup_compat_flock-fails.patch
This is a note to let you know that I've just added the patch titled
dynamic-debug-howto: fix optional/omitted ending line number to be LARGE instead of 0
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:
dynamic-debug-howto-fix-optional-omitted-ending-line-number-to-be-large-instead-of-0.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: Randy Dunlap <rdunlap(a)infradead.org>
Date: Fri, 17 Nov 2017 15:27:35 -0800
Subject: dynamic-debug-howto: fix optional/omitted ending line number to be LARGE instead of 0
From: Randy Dunlap <rdunlap(a)infradead.org>
[ Upstream commit 1f3c790bd5989fcfec9e53ad8fa09f5b740c958f ]
line-range is supposed to treat "1-" as "1-endoffile", so
handle the special case by setting last_lineno to UINT_MAX.
Fixes this error:
dynamic_debug:ddebug_parse_query: last-line:0 < 1st-line:1
dynamic_debug:ddebug_exec_query: query parse failed
Link: http://lkml.kernel.org/r/10a6a101-e2be-209f-1f41-54637824788e@infradead.org
Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org>
Acked-by: Jason Baron <jbaron(a)akamai.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>
---
lib/dynamic_debug.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -360,6 +360,10 @@ static int ddebug_parse_query(char *word
if (parse_lineno(last, &query->last_lineno) < 0)
return -EINVAL;
+ /* special case for last lineno not specified */
+ if (query->last_lineno == 0)
+ query->last_lineno = UINT_MAX;
+
if (query->last_lineno < query->first_lineno) {
pr_err("last-line:%d < 1st-line:%d\n",
query->last_lineno,
Patches currently in stable-queue which might be from rdunlap(a)infradead.org are
queue-4.14/firmware-vpd-fix-platform-driver-and-device-registration-unregistration.patch
queue-4.14/firmware-vpd-destroy-vpd-sections-in-remove-function.patch
queue-4.14/pipe-match-pipe_max_size-data-type-with-procfs.patch
queue-4.14/firmware-vpd-tie-firmware-kobject-to-device-lifetime.patch
queue-4.14/dynamic-debug-howto-fix-optional-omitted-ending-line-number-to-be-large-instead-of-0.patch