2019-07-02 08:16:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.1 00/55] 5.1.16-stable review

This is the start of the stable review cycle for the 5.1.16 release.
There are 55 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.

Responses should be made by Thu 04 Jul 2019 07:59:45 AM UTC.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.16-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.1.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>
Linux 5.1.16-rc1

Xin Long <[email protected]>
tipc: pass tunnel dev as NULL to udp_tunnel(6)_xmit_skb

Amir Goldstein <[email protected]>
fanotify: update connector fsid cache on add mark

Jason Gunthorpe <[email protected]>
RDMA: Directly cast the sockaddr union to sockaddr

Will Deacon <[email protected]>
futex: Update comments and docs about return values of arch futex code

Daniel Borkmann <[email protected]>
bpf, arm64: use more scalable stadd over ldxr / stxr loop in xadd

Will Deacon <[email protected]>
arm64: futex: Avoid copying out uninitialised stack in failed cmpxchg()

Martin KaFai Lau <[email protected]>
bpf: udp: ipv6: Avoid running reuseport's bpf_prog from __udp6_lib_err

Martin KaFai Lau <[email protected]>
bpf: udp: Avoid calling reuseport's bpf_prog from udp_gro

Daniel Borkmann <[email protected]>
bpf: fix unconnected udp hooks

Matt Mullins <[email protected]>
bpf: fix nested bpf tracepoints with per-cpu data

Jonathan Lemon <[email protected]>
bpf: lpm_trie: check left child of last leftmost node for NULL

Martynas Pumputis <[email protected]>
bpf: simplify definition of BPF_FIB_LOOKUP related flags

Dmitry Bogdanov <[email protected]>
net: aquantia: fix vlans not working over bridged network

Fei Li <[email protected]>
tun: wake up waitqueues after IFF_UP is set

Xin Long <[email protected]>
tipc: check msg->req data len in tipc_nl_compat_bearer_disable

Xin Long <[email protected]>
tipc: change to use register_pernet_device

YueHaibing <[email protected]>
team: Always enable vlan tx offload

Xin Long <[email protected]>
sctp: change to hold sk after auth shkey is created successfully

Dirk van der Merwe <[email protected]>
net/tls: fix page double free on TX cleanup

Roland Hii <[email protected]>
net: stmmac: set IC bit when transmitting frames with HW timestamp

Roland Hii <[email protected]>
net: stmmac: fixed new system time seconds value calculation

JingYi Hou <[email protected]>
net: remove duplicate fetch in sock_getsockopt

Eric Dumazet <[email protected]>
net/packet: fix memory leak in packet_set_ring()

Stephen Suryaputra <[email protected]>
ipv4: Use return value of inet_iif() for __raw_v4_lookup in the while loop

YueHaibing <[email protected]>
bonding: Always enable vlan tx offload

Neil Horman <[email protected]>
af_packet: Block execution of tasks waiting for transmit to complete in AF_PACKET

Paul Burton <[email protected]>
irqchip/mips-gic: Use the correct local interrupt map registers

Trond Myklebust <[email protected]>
SUNRPC: Fix up calculation of client message length

Geert Uytterhoeven <[email protected]>
cpu/speculation: Warn on unsupported mitigations= parameter

Trond Myklebust <[email protected]>
NFS/flexfiles: Use the correct TCP timeout for flexfiles I/O

Ard Biesheuvel <[email protected]>
efi/memreserve: deal with memreserve entries in unmapped memory

Johannes Weiner <[email protected]>
mm: fix page cache convergence regression

Reinette Chatre <[email protected]>
x86/resctrl: Prevent possible overrun during bitmap operations

Thomas Gleixner <[email protected]>
x86/microcode: Fix the microcode load on CPU hotplug for real

Alejandro Jimenez <[email protected]>
x86/speculation: Allow guests to use SSBD even if host does not

Jan Kara <[email protected]>
scsi: vmw_pscsi: Fix use-after-free in pvscsi_queue_lck()

Jens Axboe <[email protected]>
io_uring: ensure req->file is cleared on allocation

zhangyi (F) <[email protected]>
dm log writes: make sure super sector log updates are written in order

Gen Zhang <[email protected]>
dm init: fix incorrect uses of kstrndup()

Huang Ying <[email protected]>
mm, swap: fix THP swap out

Colin Ian King <[email protected]>
mm/page_idle.c: fix oops because end_pfn is larger than max_pfn

Naoya Horiguchi <[email protected]>
mm: hugetlb: soft-offline: dissolve_free_huge_page() return zero on !PageHuge

Naoya Horiguchi <[email protected]>
mm: soft-offline: return -EBUSY if set_hwpoison_free_buddy_page() fails

Ville Syrjälä <[email protected]>
drm/i915: Skip modeset for cdclk changes if possible

Imre Deak <[email protected]>
drm/i915: Remove redundant store of logical CDCLK state

Imre Deak <[email protected]>
drm/i915: Save the old CDCLK atomic state

Ville Syrjälä <[email protected]>
drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled

Dinh Nguyen <[email protected]>
clk: socfpga: stratix10: fix divider entry for the emac clocks

Jon Hunter <[email protected]>
clk: tegra210: Fix default rates for HDA clocks

Jann Horn <[email protected]>
fs/binfmt_flat.c: make load_flat_shared_library() work

zhong jiang <[email protected]>
mm/mempolicy.c: fix an incorrect rebind node in mpol_rebind_nodemask

John Ogness <[email protected]>
fs/proc/array.c: allow reporting eip/esp for all coredumping threads

Bjørn Mork <[email protected]>
qmi_wwan: Fix out-of-bounds read

Sasha Levin <[email protected]>
Revert "x86/uaccess, ftrace: Fix ftrace_likely_update() vs. SMAP"

Nathan Chancellor <[email protected]>
arm64: Don't unconditionally add -Wno-psabi to KBUILD_CFLAGS


-------------

Diffstat:

Documentation/robust-futexes.txt | 3 +-
Makefile | 4 +-
arch/arm64/Makefile | 2 +-
arch/arm64/include/asm/futex.h | 4 +-
arch/arm64/include/asm/insn.h | 8 +
arch/arm64/kernel/insn.c | 40 +++++
arch/arm64/net/bpf_jit.h | 4 +
arch/arm64/net/bpf_jit_comp.c | 28 +++-
arch/mips/include/asm/mips-gic.h | 30 ++++
arch/x86/kernel/cpu/bugs.c | 11 +-
arch/x86/kernel/cpu/microcode/core.c | 15 +-
arch/x86/kernel/cpu/resctrl/rdtgroup.c | 35 ++--
drivers/clk/socfpga/clk-s10.c | 4 +-
drivers/clk/tegra/clk-tegra210.c | 2 +
drivers/firmware/efi/efi.c | 12 +-
drivers/gpu/drm/i915/i915_drv.h | 6 +-
drivers/gpu/drm/i915/intel_audio.c | 62 ++++++-
drivers/gpu/drm/i915/intel_cdclk.c | 185 +++++++++++++++------
drivers/gpu/drm/i915/intel_display.c | 57 ++++++-
drivers/gpu/drm/i915/intel_drv.h | 21 ++-
drivers/infiniband/core/addr.c | 16 +-
drivers/infiniband/hw/ocrdma/ocrdma_ah.c | 5 +-
drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 5 +-
drivers/irqchip/irq-mips-gic.c | 4 +-
drivers/md/dm-init.c | 6 +-
drivers/md/dm-log-writes.c | 23 ++-
drivers/net/bonding/bond_main.c | 2 +-
.../net/ethernet/aquantia/atlantic/aq_filters.c | 10 +-
drivers/net/ethernet/aquantia/atlantic/aq_nic.c | 1 +
drivers/net/ethernet/aquantia/atlantic/aq_nic.h | 1 +
.../ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c | 19 ++-
.../net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 22 ++-
drivers/net/team/team.c | 2 +-
drivers/net/tun.c | 19 +--
drivers/net/usb/qmi_wwan.c | 2 +-
drivers/scsi/vmw_pvscsi.c | 6 +-
fs/binfmt_flat.c | 23 +--
fs/inode.c | 2 +-
fs/io_uring.c | 5 +-
fs/nfs/flexfilelayout/flexfilelayoutdev.c | 2 +-
fs/notify/fanotify/fanotify.c | 4 +
fs/notify/mark.c | 14 +-
fs/proc/array.c | 2 +-
include/asm-generic/futex.h | 8 +-
include/linux/bpf-cgroup.h | 8 +
include/linux/fsnotify_backend.h | 4 +-
include/linux/xarray.h | 1 +
include/net/tls.h | 15 --
include/uapi/linux/bpf.h | 6 +-
kernel/bpf/lpm_trie.c | 9 +-
kernel/bpf/syscall.c | 8 +
kernel/bpf/verifier.c | 12 +-
kernel/cpu.c | 3 +
kernel/trace/bpf_trace.c | 100 +++++++++--
kernel/trace/trace_branch.c | 4 -
lib/xarray.c | 12 +-
mm/hugetlb.c | 29 +++-
mm/memory-failure.c | 7 +-
mm/mempolicy.c | 2 +-
mm/page_idle.c | 4 +-
mm/page_io.c | 7 +-
net/core/filter.c | 2 +
net/core/sock.c | 3 -
net/ipv4/raw.c | 2 +-
net/ipv4/udp.c | 10 +-
net/ipv6/udp.c | 8 +-
net/packet/af_packet.c | 23 ++-
net/packet/internal.h | 1 +
net/sctp/endpointola.c | 8 +-
net/sunrpc/xprtsock.c | 16 +-
net/tipc/core.c | 12 +-
net/tipc/netlink_compat.c | 18 +-
net/tipc/udp_media.c | 8 +-
net/tls/tls_main.c | 3 +-
tools/testing/selftests/bpf/test_lpm_map.c | 41 ++++-
76 files changed, 830 insertions(+), 294 deletions(-)



2019-07-02 08:17:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.1 04/55] fs/proc/array.c: allow reporting eip/esp for all coredumping threads

From: John Ogness <[email protected]>

commit cb8f381f1613cafe3aec30809991cd56e7135d92 upstream.

0a1eb2d474ed ("fs/proc: Stop reporting eip and esp in /proc/PID/stat")
stopped reporting eip/esp and fd7d56270b52 ("fs/proc: Report eip/esp in
/prod/PID/stat for coredumping") reintroduced the feature to fix a
regression with userspace core dump handlers (such as minicoredumper).

Because PF_DUMPCORE is only set for the primary thread, this didn't fix
the original problem for secondary threads. Allow reporting the eip/esp
for all threads by checking for PF_EXITING as well. This is set for all
the other threads when they are killed. coredump_wait() waits for all the
tasks to become inactive before proceeding to invoke a core dumper.

Link: http://lkml.kernel.org/r/[email protected]
Link: http://lkml.kernel.org/r/[email protected]
Fixes: fd7d56270b526ca3 ("fs/proc: Report eip/esp in /prod/PID/stat for coredumping")
Signed-off-by: John Ogness <[email protected]>
Reported-by: Jan Luebbe <[email protected]>
Tested-by: Jan Luebbe <[email protected]>
Cc: Alexey Dobriyan <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/proc/array.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -462,7 +462,7 @@ static int do_task_stat(struct seq_file
* a program is not able to use ptrace(2) in that case. It is
* safe because the task has stopped executing permanently.
*/
- if (permitted && (task->flags & PF_DUMPCORE)) {
+ if (permitted && (task->flags & (PF_EXITING|PF_DUMPCORE))) {
if (try_get_task_stack(task)) {
eip = KSTK_EIP(task);
esp = KSTK_ESP(task);


2019-07-02 08:17:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.1 07/55] clk: tegra210: Fix default rates for HDA clocks

From: Jon Hunter <[email protected]>

commit 9caec6620f25b6d15646bbdb93062c872ba3b56f upstream.

Currently the default clock rates for the HDA and HDA2CODEC_2X clocks
are both 19.2MHz. However, the default rates for these clocks should
actually be 51MHz and 48MHz, respectively. The current clock settings
results in a distorted output during audio playback. Correct the default
clock rates for these clocks by specifying them in the clock init table
for Tegra210.

Cc: [email protected]
Signed-off-by: Jon Hunter <[email protected]>
Acked-by: Thierry Reding <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/clk/tegra/clk-tegra210.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/clk/tegra/clk-tegra210.c
+++ b/drivers/clk/tegra/clk-tegra210.c
@@ -3377,6 +3377,8 @@ static struct tegra_clk_init_table init_
{ TEGRA210_CLK_I2S3_SYNC, TEGRA210_CLK_CLK_MAX, 24576000, 0 },
{ TEGRA210_CLK_I2S4_SYNC, TEGRA210_CLK_CLK_MAX, 24576000, 0 },
{ TEGRA210_CLK_VIMCLK_SYNC, TEGRA210_CLK_CLK_MAX, 24576000, 0 },
+ { TEGRA210_CLK_HDA, TEGRA210_CLK_PLL_P, 51000000, 0 },
+ { TEGRA210_CLK_HDA2CODEC_2X, TEGRA210_CLK_PLL_P, 48000000, 0 },
/* This MUST be the last entry. */
{ TEGRA210_CLK_CLK_MAX, TEGRA210_CLK_CLK_MAX, 0, 0 },
};


2019-07-02 08:17:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.1 19/55] io_uring: ensure req->file is cleared on allocation

From: Jens Axboe <[email protected]>

commit 60c112b0ada09826cc4ae6a4e55df677f76f1313 upstream.

Stephen reports:

I hit the following General Protection Fault when testing io_uring via
the io_uring engine in fio. This was on a VM running 5.2-rc5 and the
latest version of fio. The issue occurs for both null_blk and fake NVMe
drives. I have not tested bare metal or real NVMe SSDs. The fio script
used is given below.

[io_uring]
time_based=1
runtime=60
filename=/dev/nvme2n1 (note /dev/nullb0 also fails)
ioengine=io_uring
bs=4k
rw=readwrite
direct=1
fixedbufs=1
sqthread_poll=1
sqthread_poll_cpu=0

general protection fault: 0000 [#1] SMP PTI
CPU: 0 PID: 872 Comm: io_uring-sq Not tainted 5.2.0-rc5-cpacket-io-uring #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
RIP: 0010:fput_many+0x7/0x90
Code: 01 48 85 ff 74 17 55 48 89 e5 53 48 8b 1f e8 a0 f9 ff ff 48 85 db 48 89 df 75 f0 5b 5d f3 c3 0f 1f 40 00 0f 1f 44 00 00 89 f6 <f0> 48 29 77 38 74 01 c3 55 48 89 e5 53 48 89 fb 65 48 \

RSP: 0018:ffffadeb817ebc50 EFLAGS: 00010246
RAX: 0000000000000004 RBX: ffff8f46ad477480 RCX: 0000000000001805
RDX: 0000000000000000 RSI: 0000000000000001 RDI: f18b51b9a39552b5
RBP: ffffadeb817ebc58 R08: ffff8f46b7a318c0 R09: 000000000000015d
R10: ffffadeb817ebce8 R11: 0000000000000020 R12: ffff8f46ad4cd000
R13: 00000000fffffff7 R14: ffffadeb817ebe30 R15: 0000000000000004
FS: 0000000000000000(0000) GS:ffff8f46b7a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055828f0bbbf0 CR3: 0000000232176004 CR4: 00000000003606f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
? fput+0x13/0x20
io_free_req+0x20/0x40
io_put_req+0x1b/0x20
io_submit_sqe+0x40a/0x680
? __switch_to_asm+0x34/0x70
? __switch_to_asm+0x40/0x70
io_submit_sqes+0xb9/0x160
? io_submit_sqes+0xb9/0x160
? __switch_to_asm+0x40/0x70
? __switch_to_asm+0x34/0x70
? __schedule+0x3f2/0x6a0
? __switch_to_asm+0x34/0x70
io_sq_thread+0x1af/0x470
? __switch_to_asm+0x34/0x70
? wait_woken+0x80/0x80
? __switch_to+0x85/0x410
? __switch_to_asm+0x40/0x70
? __switch_to_asm+0x34/0x70
? __schedule+0x3f2/0x6a0
kthread+0x105/0x140
? io_submit_sqes+0x160/0x160
? kthread+0x105/0x140
? io_submit_sqes+0x160/0x160
? kthread_destroy_worker+0x50/0x50
ret_from_fork+0x35/0x40

which occurs because using a kernel side submission thread isn't valid
without using fixed files (registered through io_uring_register()). This
causes io_uring to put the request after logging an error, but before
the file field is set in the request. If it happens to be non-zero, we
attempt to fput() garbage.

Fix this by ensuring that req->file is initialized when the request is
allocated.

Cc: [email protected] # 5.1+
Reported-by: Stephen Bates <[email protected]>
Tested-by: Stephen Bates <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/io_uring.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)

--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -533,6 +533,7 @@ static struct io_kiocb *io_get_req(struc
state->cur_req++;
}

+ req->file = NULL;
req->ctx = ctx;
req->flags = 0;
/* one is dropped after submission, the other at completion */
@@ -1684,10 +1685,8 @@ static int io_req_set_file(struct io_rin
flags = READ_ONCE(s->sqe->flags);
fd = READ_ONCE(s->sqe->fd);

- if (!io_op_needs_file(s->sqe)) {
- req->file = NULL;
+ if (!io_op_needs_file(s->sqe))
return 0;
- }

if (flags & IOSQE_FIXED_FILE) {
if (unlikely(!ctx->user_files ||


2019-07-02 08:17:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.1 02/55] Revert "x86/uaccess, ftrace: Fix ftrace_likely_update() vs. SMAP"

This reverts commit b65b70ba068b7cdbfeb65eee87cce84a74618603, which was
upstream commit 4a6c91fbdef846ec7250b82f2eeeb87ac5f18cf9.

On Tue, Jun 25, 2019 at 09:39:45AM +0200, Sebastian Andrzej Siewior wrote:
>Please backport commit e74deb11931ff682b59d5b9d387f7115f689698e to
>stable _or_ revert the backport of commit 4a6c91fbdef84 ("x86/uaccess,
>ftrace: Fix ftrace_likely_update() vs. SMAP"). It uses
>user_access_{save|restore}() which has been introduced in the following
>commit.

Signed-off-by: Sasha Levin <[email protected]>
---
kernel/trace/trace_branch.c | 4 ----
1 file changed, 4 deletions(-)

diff --git a/kernel/trace/trace_branch.c b/kernel/trace/trace_branch.c
index 3ea65cdff30d..4ad967453b6f 100644
--- a/kernel/trace/trace_branch.c
+++ b/kernel/trace/trace_branch.c
@@ -205,8 +205,6 @@ void trace_likely_condition(struct ftrace_likely_data *f, int val, int expect)
void ftrace_likely_update(struct ftrace_likely_data *f, int val,
int expect, int is_constant)
{
- unsigned long flags = user_access_save();
-
/* A constant is always correct */
if (is_constant) {
f->constant++;
@@ -225,8 +223,6 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
f->data.correct++;
else
f->data.incorrect++;
-
- user_access_restore(flags);
}
EXPORT_SYMBOL(ftrace_likely_update);

--
2.20.1



2019-07-02 08:17:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.1 13/55] mm: soft-offline: return -EBUSY if set_hwpoison_free_buddy_page() fails

From: Naoya Horiguchi <[email protected]>

commit b38e5962f8ed0d2a2b28a887fc2221f7f41db119 upstream.

The pass/fail of soft offline should be judged by checking whether the
raw error page was finally contained or not (i.e. the result of
set_hwpoison_free_buddy_page()), but current code do not work like
that. It might lead us to misjudge the test result when
set_hwpoison_free_buddy_page() fails.

Without this fix, there are cases where madvise(MADV_SOFT_OFFLINE) may
not offline the original page and will not return an error.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Naoya Horiguchi <[email protected]>
Fixes: 6bc9b56433b76 ("mm: fix race on soft-offlining")
Reviewed-by: Mike Kravetz <[email protected]>
Reviewed-by: Oscar Salvador <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Xishi Qiu <[email protected]>
Cc: "Chen, Jerry T" <[email protected]>
Cc: "Zhuo, Qiuxu" <[email protected]>
Cc: <[email protected]> [4.19+]
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
mm/memory-failure.c | 2 ++
1 file changed, 2 insertions(+)

--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1733,6 +1733,8 @@ static int soft_offline_huge_page(struct
if (!ret) {
if (set_hwpoison_free_buddy_page(page))
num_poisoned_pages_inc();
+ else
+ ret = -EBUSY;
}
}
return ret;


2019-07-02 08:18:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.1 47/55] bpf: fix unconnected udp hooks

From: Daniel Borkmann <[email protected]>

commit 983695fa676568fc0fe5ddd995c7267aabc24632 upstream.

Intention of cgroup bind/connect/sendmsg BPF hooks is to act transparently
to applications as also stated in original motivation in 7828f20e3779 ("Merge
branch 'bpf-cgroup-bind-connect'"). When recently integrating the latter
two hooks into Cilium to enable host based load-balancing with Kubernetes,
I ran into the issue that pods couldn't start up as DNS got broken. Kubernetes
typically sets up DNS as a service and is thus subject to load-balancing.

Upon further debugging, it turns out that the cgroupv2 sendmsg BPF hooks API
is currently insufficient and thus not usable as-is for standard applications
shipped with most distros. To break down the issue we ran into with a simple
example:

# cat /etc/resolv.conf
nameserver 147.75.207.207
nameserver 147.75.207.208

For the purpose of a simple test, we set up above IPs as service IPs and
transparently redirect traffic to a different DNS backend server for that
node:

# cilium service list
ID Frontend Backend
1 147.75.207.207:53 1 => 8.8.8.8:53
2 147.75.207.208:53 1 => 8.8.8.8:53

The attached BPF program is basically selecting one of the backends if the
service IP/port matches on the cgroup hook. DNS breaks here, because the
hooks are not transparent enough to applications which have built-in msg_name
address checks:

# nslookup 1.1.1.1
;; reply from unexpected source: 8.8.8.8#53, expected 147.75.207.207#53
;; reply from unexpected source: 8.8.8.8#53, expected 147.75.207.208#53
;; reply from unexpected source: 8.8.8.8#53, expected 147.75.207.207#53
[...]
;; connection timed out; no servers could be reached

# dig 1.1.1.1
;; reply from unexpected source: 8.8.8.8#53, expected 147.75.207.207#53
;; reply from unexpected source: 8.8.8.8#53, expected 147.75.207.208#53
;; reply from unexpected source: 8.8.8.8#53, expected 147.75.207.207#53
[...]

; <<>> DiG 9.11.3-1ubuntu1.7-Ubuntu <<>> 1.1.1.1
;; global options: +cmd
;; connection timed out; no servers could be reached

For comparison, if none of the service IPs is used, and we tell nslookup
to use 8.8.8.8 directly it works just fine, of course:

# nslookup 1.1.1.1 8.8.8.8
1.1.1.1.in-addr.arpa name = one.one.one.one.

In order to fix this and thus act more transparent to the application,
this needs reverse translation on recvmsg() side. A minimal fix for this
API is to add similar recvmsg() hooks behind the BPF cgroups static key
such that the program can track state and replace the current sockaddr_in{,6}
with the original service IP. From BPF side, this basically tracks the
service tuple plus socket cookie in an LRU map where the reverse NAT can
then be retrieved via map value as one example. Side-note: the BPF cgroups
static key should be converted to a per-hook static key in future.

Same example after this fix:

# cilium service list
ID Frontend Backend
1 147.75.207.207:53 1 => 8.8.8.8:53
2 147.75.207.208:53 1 => 8.8.8.8:53

Lookups work fine now:

# nslookup 1.1.1.1
1.1.1.1.in-addr.arpa name = one.one.one.one.

Authoritative answers can be found from:

# dig 1.1.1.1

; <<>> DiG 9.11.3-1ubuntu1.7-Ubuntu <<>> 1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51550
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;1.1.1.1. IN A

;; AUTHORITY SECTION:
. 23426 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2019052001 1800 900 604800 86400

;; Query time: 17 msec
;; SERVER: 147.75.207.207#53(147.75.207.207)
;; WHEN: Tue May 21 12:59:38 UTC 2019
;; MSG SIZE rcvd: 111

And from an actual packet level it shows that we're using the back end
server when talking via 147.75.207.20{7,8} front end:

# tcpdump -i any udp
[...]
12:59:52.698732 IP foo.42011 > google-public-dns-a.google.com.domain: 18803+ PTR? 1.1.1.1.in-addr.arpa. (38)
12:59:52.698735 IP foo.42011 > google-public-dns-a.google.com.domain: 18803+ PTR? 1.1.1.1.in-addr.arpa. (38)
12:59:52.701208 IP google-public-dns-a.google.com.domain > foo.42011: 18803 1/0/0 PTR one.one.one.one. (67)
12:59:52.701208 IP google-public-dns-a.google.com.domain > foo.42011: 18803 1/0/0 PTR one.one.one.one. (67)
[...]

In order to be flexible and to have same semantics as in sendmsg BPF
programs, we only allow return codes in [1,1] range. In the sendmsg case
the program is called if msg->msg_name is present which can be the case
in both, connected and unconnected UDP.

The former only relies on the sockaddr_in{,6} passed via connect(2) if
passed msg->msg_name was NULL. Therefore, on recvmsg side, we act in similar
way to call into the BPF program whenever a non-NULL msg->msg_name was
passed independent of sk->sk_state being TCP_ESTABLISHED or not. Note
that for TCP case, the msg->msg_name is ignored in the regular recvmsg
path and therefore not relevant.

For the case of ip{,v6}_recv_error() paths, picked up via MSG_ERRQUEUE,
the hook is not called. This is intentional as it aligns with the same
semantics as in case of TCP cgroup BPF hooks right now. This might be
better addressed in future through a different bpf_attach_type such
that this case can be distinguished from the regular recvmsg paths,
for example.

Fixes: 1cedee13d25a ("bpf: Hooks for sys_sendmsg")
Signed-off-by: Daniel Borkmann <[email protected]>
Acked-by: Andrey Ignatov <[email protected]>
Acked-by: Martin KaFai Lau <[email protected]>
Acked-by: Martynas Pumputis <[email protected]>
Signed-off-by: Alexei Starovoitov <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/linux/bpf-cgroup.h | 8 ++++++++
include/uapi/linux/bpf.h | 2 ++
kernel/bpf/syscall.c | 8 ++++++++
kernel/bpf/verifier.c | 12 ++++++++----
net/core/filter.c | 2 ++
net/ipv4/udp.c | 4 ++++
net/ipv6/udp.c | 4 ++++
7 files changed, 36 insertions(+), 4 deletions(-)

--- a/include/linux/bpf-cgroup.h
+++ b/include/linux/bpf-cgroup.h
@@ -230,6 +230,12 @@ int bpf_percpu_cgroup_storage_update(str
#define BPF_CGROUP_RUN_PROG_UDP6_SENDMSG_LOCK(sk, uaddr, t_ctx) \
BPF_CGROUP_RUN_SA_PROG_LOCK(sk, uaddr, BPF_CGROUP_UDP6_SENDMSG, t_ctx)

+#define BPF_CGROUP_RUN_PROG_UDP4_RECVMSG_LOCK(sk, uaddr) \
+ BPF_CGROUP_RUN_SA_PROG_LOCK(sk, uaddr, BPF_CGROUP_UDP4_RECVMSG, NULL)
+
+#define BPF_CGROUP_RUN_PROG_UDP6_RECVMSG_LOCK(sk, uaddr) \
+ BPF_CGROUP_RUN_SA_PROG_LOCK(sk, uaddr, BPF_CGROUP_UDP6_RECVMSG, NULL)
+
#define BPF_CGROUP_RUN_PROG_SOCK_OPS(sock_ops) \
({ \
int __ret = 0; \
@@ -319,6 +325,8 @@ static inline int bpf_percpu_cgroup_stor
#define BPF_CGROUP_RUN_PROG_INET6_CONNECT_LOCK(sk, uaddr) ({ 0; })
#define BPF_CGROUP_RUN_PROG_UDP4_SENDMSG_LOCK(sk, uaddr, t_ctx) ({ 0; })
#define BPF_CGROUP_RUN_PROG_UDP6_SENDMSG_LOCK(sk, uaddr, t_ctx) ({ 0; })
+#define BPF_CGROUP_RUN_PROG_UDP4_RECVMSG_LOCK(sk, uaddr) ({ 0; })
+#define BPF_CGROUP_RUN_PROG_UDP6_RECVMSG_LOCK(sk, uaddr) ({ 0; })
#define BPF_CGROUP_RUN_PROG_SOCK_OPS(sock_ops) ({ 0; })
#define BPF_CGROUP_RUN_PROG_DEVICE_CGROUP(type,major,minor,access) ({ 0; })

--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -187,6 +187,8 @@ enum bpf_attach_type {
BPF_CGROUP_UDP6_SENDMSG,
BPF_LIRC_MODE2,
BPF_FLOW_DISSECTOR,
+ BPF_CGROUP_UDP4_RECVMSG = 19,
+ BPF_CGROUP_UDP6_RECVMSG,
__MAX_BPF_ATTACH_TYPE
};

--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -1520,6 +1520,8 @@ bpf_prog_load_check_attach_type(enum bpf
case BPF_CGROUP_INET6_CONNECT:
case BPF_CGROUP_UDP4_SENDMSG:
case BPF_CGROUP_UDP6_SENDMSG:
+ case BPF_CGROUP_UDP4_RECVMSG:
+ case BPF_CGROUP_UDP6_RECVMSG:
return 0;
default:
return -EINVAL;
@@ -1809,6 +1811,8 @@ static int bpf_prog_attach(const union b
case BPF_CGROUP_INET6_CONNECT:
case BPF_CGROUP_UDP4_SENDMSG:
case BPF_CGROUP_UDP6_SENDMSG:
+ case BPF_CGROUP_UDP4_RECVMSG:
+ case BPF_CGROUP_UDP6_RECVMSG:
ptype = BPF_PROG_TYPE_CGROUP_SOCK_ADDR;
break;
case BPF_CGROUP_SOCK_OPS:
@@ -1891,6 +1895,8 @@ static int bpf_prog_detach(const union b
case BPF_CGROUP_INET6_CONNECT:
case BPF_CGROUP_UDP4_SENDMSG:
case BPF_CGROUP_UDP6_SENDMSG:
+ case BPF_CGROUP_UDP4_RECVMSG:
+ case BPF_CGROUP_UDP6_RECVMSG:
ptype = BPF_PROG_TYPE_CGROUP_SOCK_ADDR;
break;
case BPF_CGROUP_SOCK_OPS:
@@ -1939,6 +1945,8 @@ static int bpf_prog_query(const union bp
case BPF_CGROUP_INET6_CONNECT:
case BPF_CGROUP_UDP4_SENDMSG:
case BPF_CGROUP_UDP6_SENDMSG:
+ case BPF_CGROUP_UDP4_RECVMSG:
+ case BPF_CGROUP_UDP6_RECVMSG:
case BPF_CGROUP_SOCK_OPS:
case BPF_CGROUP_DEVICE:
break;
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -5145,9 +5145,12 @@ static int check_return_code(struct bpf_
struct tnum range = tnum_range(0, 1);

switch (env->prog->type) {
+ case BPF_PROG_TYPE_CGROUP_SOCK_ADDR:
+ if (env->prog->expected_attach_type == BPF_CGROUP_UDP4_RECVMSG ||
+ env->prog->expected_attach_type == BPF_CGROUP_UDP6_RECVMSG)
+ range = tnum_range(1, 1);
case BPF_PROG_TYPE_CGROUP_SKB:
case BPF_PROG_TYPE_CGROUP_SOCK:
- case BPF_PROG_TYPE_CGROUP_SOCK_ADDR:
case BPF_PROG_TYPE_SOCK_OPS:
case BPF_PROG_TYPE_CGROUP_DEVICE:
break;
@@ -5163,16 +5166,17 @@ static int check_return_code(struct bpf_
}

if (!tnum_in(range, reg->var_off)) {
+ char tn_buf[48];
+
verbose(env, "At program exit the register R0 ");
if (!tnum_is_unknown(reg->var_off)) {
- char tn_buf[48];
-
tnum_strn(tn_buf, sizeof(tn_buf), reg->var_off);
verbose(env, "has value %s", tn_buf);
} else {
verbose(env, "has unknown scalar value");
}
- verbose(env, " should have been 0 or 1\n");
+ tnum_strn(tn_buf, sizeof(tn_buf), range);
+ verbose(env, " should have been in %s\n", tn_buf);
return -EINVAL;
}
return 0;
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -6420,6 +6420,7 @@ static bool sock_addr_is_valid_access(in
case BPF_CGROUP_INET4_BIND:
case BPF_CGROUP_INET4_CONNECT:
case BPF_CGROUP_UDP4_SENDMSG:
+ case BPF_CGROUP_UDP4_RECVMSG:
break;
default:
return false;
@@ -6430,6 +6431,7 @@ static bool sock_addr_is_valid_access(in
case BPF_CGROUP_INET6_BIND:
case BPF_CGROUP_INET6_CONNECT:
case BPF_CGROUP_UDP6_SENDMSG:
+ case BPF_CGROUP_UDP6_RECVMSG:
break;
default:
return false;
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1783,6 +1783,10 @@ try_again:
sin->sin_addr.s_addr = ip_hdr(skb)->saddr;
memset(sin->sin_zero, 0, sizeof(sin->sin_zero));
*addr_len = sizeof(*sin);
+
+ if (cgroup_bpf_enabled)
+ BPF_CGROUP_RUN_PROG_UDP4_RECVMSG_LOCK(sk,
+ (struct sockaddr *)sin);
}

if (udp_sk(sk)->gro_enabled)
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -370,6 +370,10 @@ try_again:
inet6_iif(skb));
}
*addr_len = sizeof(*sin6);
+
+ if (cgroup_bpf_enabled)
+ BPF_CGROUP_RUN_PROG_UDP6_RECVMSG_LOCK(sk,
+ (struct sockaddr *)sin6);
}

if (udp_sk(sk)->gro_enabled)


2019-07-02 08:18:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.1 05/55] mm/mempolicy.c: fix an incorrect rebind node in mpol_rebind_nodemask

From: zhong jiang <[email protected]>

commit 29b190fa774dd1b72a1a6f19687d55dc72ea83be upstream.

mpol_rebind_nodemask() is called for MPOL_BIND and MPOL_INTERLEAVE
mempoclicies when the tasks's cpuset's mems_allowed changes. For
policies created without MPOL_F_STATIC_NODES or MPOL_F_RELATIVE_NODES,
it works by remapping the policy's allowed nodes (stored in v.nodes)
using the previous value of mems_allowed (stored in
w.cpuset_mems_allowed) as the domain of map and the new mems_allowed
(passed as nodes) as the range of the map (see the comment of
bitmap_remap() for details).

The result of remapping is stored back as policy's nodemask in v.nodes,
and the new value of mems_allowed should be stored in
w.cpuset_mems_allowed to facilitate the next rebind, if it happens.

However, 213980c0f23b ("mm, mempolicy: simplify rebinding mempolicies
when updating cpusets") introduced a bug where the result of remapping
is stored in w.cpuset_mems_allowed instead. Thus, a mempolicy's
allowed nodes can evolve in an unexpected way after a series of
rebinding due to cpuset mems_allowed changes, possibly binding to a
wrong node or a smaller number of nodes which may e.g. overload them.
This patch fixes the bug so rebinding again works as intended.

[[email protected]: new changlog]
Link: http://lkml.kernel.org/r/[email protected]
Link: http://lkml.kernel.org/r/[email protected]
Fixes: 213980c0f23b ("mm, mempolicy: simplify rebinding mempolicies when updating cpusets")
Signed-off-by: zhong jiang <[email protected]>
Reviewed-by: Vlastimil Babka <[email protected]>
Cc: Oscar Salvador <[email protected]>
Cc: Anshuman Khandual <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Mel Gorman <[email protected]>
Cc: Andrea Arcangeli <[email protected]>
Cc: Ralph Campbell <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
mm/mempolicy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -306,7 +306,7 @@ static void mpol_rebind_nodemask(struct
else {
nodes_remap(tmp, pol->v.nodes,pol->w.cpuset_mems_allowed,
*nodes);
- pol->w.cpuset_mems_allowed = tmp;
+ pol->w.cpuset_mems_allowed = *nodes;
}

if (nodes_empty(tmp))


2019-07-02 08:18:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.1 31/55] bonding: Always enable vlan tx offload

From: YueHaibing <[email protected]>

[ Upstream commit 30d8177e8ac776d89d387fad547af6a0f599210e ]

We build vlan on top of bonding interface, which vlan offload
is off, bond mode is 802.3ad (LACP) and xmit_hash_policy is
BOND_XMIT_POLICY_ENCAP34.

Because vlan tx offload is off, vlan tci is cleared and skb push
the vlan header in validate_xmit_vlan() while sending from vlan
devices. Then in bond_xmit_hash, __skb_flow_dissect() fails to
get information from protocol headers encapsulated within vlan,
because 'nhoff' is points to IP header, so bond hashing is based
on layer 2 info, which fails to distribute packets across slaves.

This patch always enable bonding's vlan tx offload, pass the vlan
packets to the slave devices with vlan tci, let them to handle
vlan implementation.

Fixes: 278339a42a1b ("bonding: propogate vlan_features to bonding master")
Suggested-by: Jiri Pirko <[email protected]>
Signed-off-by: YueHaibing <[email protected]>
Acked-by: Jiri Pirko <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/bonding/bond_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4321,12 +4321,12 @@ void bond_setup(struct net_device *bond_
bond_dev->features |= NETIF_F_NETNS_LOCAL;

bond_dev->hw_features = BOND_VLAN_FEATURES |
- NETIF_F_HW_VLAN_CTAG_TX |
NETIF_F_HW_VLAN_CTAG_RX |
NETIF_F_HW_VLAN_CTAG_FILTER;

bond_dev->hw_features |= NETIF_F_GSO_ENCAP_ALL | NETIF_F_GSO_UDP_L4;
bond_dev->features |= bond_dev->hw_features;
+ bond_dev->features |= NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_STAG_TX;
}

/* Destroy a bonding device.


2019-07-02 08:18:28

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.1 03/55] qmi_wwan: Fix out-of-bounds read

[ Upstream commit 904d88d743b0c94092c5117955eab695df8109e8 ]

The syzbot reported

Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xca/0x13e lib/dump_stack.c:113
print_address_description+0x67/0x231 mm/kasan/report.c:188
__kasan_report.cold+0x1a/0x32 mm/kasan/report.c:317
kasan_report+0xe/0x20 mm/kasan/common.c:614
qmi_wwan_probe+0x342/0x360 drivers/net/usb/qmi_wwan.c:1417
usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361
really_probe+0x281/0x660 drivers/base/dd.c:509
driver_probe_device+0x104/0x210 drivers/base/dd.c:670
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777
bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454

Caused by too many confusing indirections and casts.
id->driver_info is a pointer stored in a long. We want the
pointer here, not the address of it.

Thanks-to: Hillf Danton <[email protected]>
Reported-by: [email protected]
Cc: Kristian Evensen <[email protected]>
Fixes: e4bf63482c30 ("qmi_wwan: Add quirk for Quectel dynamic config")
Signed-off-by: Bjørn Mork <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/usb/qmi_wwan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index d9a6699abe59..e657d8947125 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1412,7 +1412,7 @@ static int qmi_wwan_probe(struct usb_interface *intf,
* different. Ignore the current interface if the number of endpoints
* equals the number for the diag interface (two).
*/
- info = (void *)&id->driver_info;
+ info = (void *)id->driver_info;

if (info->data & QMI_WWAN_QUIRK_QUECTEL_DYNCFG) {
if (desc->bNumEndpoints == 2)
--
2.20.1



2019-07-02 08:18:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.1 27/55] cpu/speculation: Warn on unsupported mitigations= parameter

From: Geert Uytterhoeven <[email protected]>

commit 1bf72720281770162c87990697eae1ba2f1d917a upstream.

Currently, if the user specifies an unsupported mitigation strategy on the
kernel command line, it will be ignored silently. The code will fall back
to the default strategy, possibly leaving the system more vulnerable than
expected.

This may happen due to e.g. a simple typo, or, for a stable kernel release,
because not all mitigation strategies have been backported.

Inform the user by printing a message.

Fixes: 98af8452945c5565 ("cpu/speculation: Add 'mitigations=' cmdline option")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Acked-by: Josh Poimboeuf <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Jiri Kosina <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Ben Hutchings <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/cpu.c | 3 +++
1 file changed, 3 insertions(+)

--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -2315,6 +2315,9 @@ static int __init mitigations_parse_cmdl
cpu_mitigations = CPU_MITIGATIONS_AUTO;
else if (!strcmp(arg, "auto,nosmt"))
cpu_mitigations = CPU_MITIGATIONS_AUTO_NOSMT;
+ else
+ pr_crit("Unsupported mitigations=%s, system may still be vulnerable\n",
+ arg);

return 0;
}


2019-07-02 08:18:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.1 24/55] mm: fix page cache convergence regression

From: Johannes Weiner <[email protected]>

commit 7b785645e8f13e17cbce492708cf6e7039d32e46 upstream.

Since a28334862993 ("page cache: Finish XArray conversion"), on most
major Linux distributions, the page cache doesn't correctly transition
when the hot data set is changing, and leaves the new pages thrashing
indefinitely instead of kicking out the cold ones.

On a freshly booted, freshly ssh'd into virtual machine with 1G RAM
running stock Arch Linux:

[root@ham ~]# ./reclaimtest.sh
+ dd of=workingset-a bs=1M count=0 seek=600
+ cat workingset-a
+ cat workingset-a
+ cat workingset-a
+ cat workingset-a
+ cat workingset-a
+ cat workingset-a
+ cat workingset-a
+ cat workingset-a
+ ./mincore workingset-a
153600/153600 workingset-a
+ dd of=workingset-b bs=1M count=0 seek=600
+ cat workingset-b
+ cat workingset-b
+ cat workingset-b
+ cat workingset-b
+ ./mincore workingset-a workingset-b
104029/153600 workingset-a
120086/153600 workingset-b
+ cat workingset-b
+ cat workingset-b
+ cat workingset-b
+ cat workingset-b
+ ./mincore workingset-a workingset-b
104029/153600 workingset-a
120268/153600 workingset-b

workingset-b is a 600M file on a 1G host that is otherwise entirely
idle. No matter how often it's being accessed, it won't get cached.

While investigating, I noticed that the non-resident information gets
aggressively reclaimed - /proc/vmstat::workingset_nodereclaim. This is
a problem because a workingset transition like this relies on the
non-resident information tracked in the page cache tree of evicted
file ranges: when the cache faults are refaults of recently evicted
cache, we challenge the existing active set, and that allows a new
workingset to establish itself.

Tracing the shrinker that maintains this memory revealed that all page
cache tree nodes were allocated to the root cgroup. This is a problem,
because 1) the shrinker sizes the amount of non-resident information
it keeps to the size of the cgroup's other memory and 2) on most major
Linux distributions, only kernel threads live in the root cgroup and
everything else gets put into services or session groups:

[root@ham ~]# cat /proc/self/cgroup
0::/user.slice/user-0.slice/session-c1.scope

As a result, we basically maintain no non-resident information for the
workloads running on the system, thus breaking the caching algorithm.

Looking through the code, I found the culprit in the above-mentioned
patch: when switching from the radix tree to xarray, it dropped the
__GFP_ACCOUNT flag from the tree node allocations - the flag that
makes sure the allocated memory gets charged to and tracked by the
cgroup of the calling process - in this case, the one doing the fault.

To fix this, allow xarray users to specify per-tree flag that makes
xarray allocate nodes using __GFP_ACCOUNT. Then restore the page cache
tree annotation to request such cgroup tracking for the cache nodes.

With this patch applied, the page cache correctly converges on new
workingsets again after just a few iterations:

[root@ham ~]# ./reclaimtest.sh
+ dd of=workingset-a bs=1M count=0 seek=600
+ cat workingset-a
+ cat workingset-a
+ cat workingset-a
+ cat workingset-a
+ cat workingset-a
+ cat workingset-a
+ cat workingset-a
+ cat workingset-a
+ ./mincore workingset-a
153600/153600 workingset-a
+ dd of=workingset-b bs=1M count=0 seek=600
+ cat workingset-b
+ ./mincore workingset-a workingset-b
124607/153600 workingset-a
87876/153600 workingset-b
+ cat workingset-b
+ ./mincore workingset-a workingset-b
81313/153600 workingset-a
133321/153600 workingset-b
+ cat workingset-b
+ ./mincore workingset-a workingset-b
63036/153600 workingset-a
153600/153600 workingset-b

Cc: [email protected] # 4.20+
Signed-off-by: Johannes Weiner <[email protected]>
Reviewed-by: Shakeel Butt <[email protected]>
Signed-off-by: Matthew Wilcox (Oracle) <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/inode.c | 2 +-
include/linux/xarray.h | 1 +
lib/xarray.c | 12 ++++++++++--
3 files changed, 12 insertions(+), 3 deletions(-)

--- a/fs/inode.c
+++ b/fs/inode.c
@@ -349,7 +349,7 @@ EXPORT_SYMBOL(inc_nlink);

static void __address_space_init_once(struct address_space *mapping)
{
- xa_init_flags(&mapping->i_pages, XA_FLAGS_LOCK_IRQ);
+ xa_init_flags(&mapping->i_pages, XA_FLAGS_LOCK_IRQ | XA_FLAGS_ACCOUNT);
init_rwsem(&mapping->i_mmap_rwsem);
INIT_LIST_HEAD(&mapping->private_list);
spin_lock_init(&mapping->private_lock);
--- a/include/linux/xarray.h
+++ b/include/linux/xarray.h
@@ -265,6 +265,7 @@ enum xa_lock_type {
#define XA_FLAGS_TRACK_FREE ((__force gfp_t)4U)
#define XA_FLAGS_ZERO_BUSY ((__force gfp_t)8U)
#define XA_FLAGS_ALLOC_WRAPPED ((__force gfp_t)16U)
+#define XA_FLAGS_ACCOUNT ((__force gfp_t)32U)
#define XA_FLAGS_MARK(mark) ((__force gfp_t)((1U << __GFP_BITS_SHIFT) << \
(__force unsigned)(mark)))

--- a/lib/xarray.c
+++ b/lib/xarray.c
@@ -298,6 +298,8 @@ bool xas_nomem(struct xa_state *xas, gfp
xas_destroy(xas);
return false;
}
+ if (xas->xa->xa_flags & XA_FLAGS_ACCOUNT)
+ gfp |= __GFP_ACCOUNT;
xas->xa_alloc = kmem_cache_alloc(radix_tree_node_cachep, gfp);
if (!xas->xa_alloc)
return false;
@@ -325,6 +327,8 @@ static bool __xas_nomem(struct xa_state
xas_destroy(xas);
return false;
}
+ if (xas->xa->xa_flags & XA_FLAGS_ACCOUNT)
+ gfp |= __GFP_ACCOUNT;
if (gfpflags_allow_blocking(gfp)) {
xas_unlock_type(xas, lock_type);
xas->xa_alloc = kmem_cache_alloc(radix_tree_node_cachep, gfp);
@@ -358,8 +362,12 @@ static void *xas_alloc(struct xa_state *
if (node) {
xas->xa_alloc = NULL;
} else {
- node = kmem_cache_alloc(radix_tree_node_cachep,
- GFP_NOWAIT | __GFP_NOWARN);
+ gfp_t gfp = GFP_NOWAIT | __GFP_NOWARN;
+
+ if (xas->xa->xa_flags & XA_FLAGS_ACCOUNT)
+ gfp |= __GFP_ACCOUNT;
+
+ node = kmem_cache_alloc(radix_tree_node_cachep, gfp);
if (!node) {
xas_set_err(xas, -ENOMEM);
return NULL;


2019-07-02 08:18:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.1 16/55] mm, swap: fix THP swap out

From: Huang Ying <[email protected]>

commit 1a5f439c7c02837d943e528d46501564d4226757 upstream.

0-Day test system reported some OOM regressions for several THP
(Transparent Huge Page) swap test cases. These regressions are bisected
to 6861428921b5 ("block: always define BIO_MAX_PAGES as 256"). In the
commit, BIO_MAX_PAGES is set to 256 even when THP swap is enabled. So the
bio_alloc(gfp_flags, 512) in get_swap_bio() may fail when swapping out
THP. That causes the OOM.

As in the patch description of 6861428921b5 ("block: always define
BIO_MAX_PAGES as 256"), THP swap should use multi-page bvec to write THP
to swap space. So the issue is fixed via doing that in get_swap_bio().

BTW: I remember I have checked the THP swap code when 6861428921b5
("block: always define BIO_MAX_PAGES as 256") was merged, and thought the
THP swap code needn't to be changed. But apparently, I was wrong. I
should have done this at that time.

Link: http://lkml.kernel.org/r/[email protected]
Fixes: 6861428921b5 ("block: always define BIO_MAX_PAGES as 256")
Signed-off-by: "Huang, Ying" <[email protected]>
Reviewed-by: Ming Lei <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Johannes Weiner <[email protected]>
Cc: Hugh Dickins <[email protected]>
Cc: Minchan Kim <[email protected]>
Cc: Rik van Riel <[email protected]>
Cc: Daniel Jordan <[email protected]>
Cc: Jens Axboe <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
mm/page_io.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)

--- a/mm/page_io.c
+++ b/mm/page_io.c
@@ -29,10 +29,9 @@
static struct bio *get_swap_bio(gfp_t gfp_flags,
struct page *page, bio_end_io_t end_io)
{
- int i, nr = hpage_nr_pages(page);
struct bio *bio;

- bio = bio_alloc(gfp_flags, nr);
+ bio = bio_alloc(gfp_flags, 1);
if (bio) {
struct block_device *bdev;

@@ -41,9 +40,7 @@ static struct bio *get_swap_bio(gfp_t gf
bio->bi_iter.bi_sector <<= PAGE_SHIFT - 9;
bio->bi_end_io = end_io;

- for (i = 0; i < nr; i++)
- bio_add_page(bio, page + i, PAGE_SIZE, 0);
- VM_BUG_ON(bio->bi_iter.bi_size != PAGE_SIZE * nr);
+ bio_add_page(bio, page, PAGE_SIZE * hpage_nr_pages(page), 0);
}
return bio;
}


2019-07-02 08:19:02

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 5.1 10/55] drm/i915: Save the old CDCLK atomic state

From: Imre Deak <[email protected]>

commit 48d9f87ddd2108663fd866b254e05d422243cc56 upstream.

The old state will be needed by an upcoming patch to determine if the
commit increases or decreases CDCLK, so move the old state to the atomic
state (while keeping the new one in dev_priv). cdclk.logical and
cdclk.actual in the atomic state isn't used atm anywhere after the
atomic check phase, so this should be safe.

v2:
- Use swap() instead of opencoding it. (Ville)

Suggested-by: Ville Syrjälä <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Jian-Hong Pan <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/i915/intel_cdclk.c | 20 ++++++++++++++++++++
drivers/gpu/drm/i915/intel_display.c | 4 ++--
drivers/gpu/drm/i915/intel_drv.h | 1 +
3 files changed, 23 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -2100,6 +2100,26 @@ bool intel_cdclk_changed(const struct in
a->voltage_level != b->voltage_level;
}

+/**
+ * intel_cdclk_swap_state - make atomic CDCLK configuration effective
+ * @state: atomic state
+ *
+ * This is the CDCLK version of drm_atomic_helper_swap_state() since the
+ * helper does not handle driver-specific global state.
+ *
+ * Similarly to the atomic helpers this function does a complete swap,
+ * i.e. it also puts the old state into @state. This is used by the commit
+ * code to determine how CDCLK has changed (for instance did it increase or
+ * decrease).
+ */
+void intel_cdclk_swap_state(struct intel_atomic_state *state)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+
+ swap(state->cdclk.logical, dev_priv->cdclk.logical);
+ swap(state->cdclk.actual, dev_priv->cdclk.actual);
+}
+
void intel_dump_cdclk_state(const struct intel_cdclk_state *cdclk_state,
const char *context)
{
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13483,10 +13483,10 @@ static int intel_atomic_commit(struct dr
intel_state->min_voltage_level,
sizeof(intel_state->min_voltage_level));
dev_priv->active_crtcs = intel_state->active_crtcs;
- dev_priv->cdclk.logical = intel_state->cdclk.logical;
- dev_priv->cdclk.actual = intel_state->cdclk.actual;
dev_priv->cdclk.force_min_cdclk =
intel_state->cdclk.force_min_cdclk;
+
+ intel_cdclk_swap_state(intel_state);
}

drm_atomic_state_get(state);
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1597,6 +1597,7 @@ bool intel_cdclk_needs_modeset(const str
const struct intel_cdclk_state *b);
bool intel_cdclk_changed(const struct intel_cdclk_state *a,
const struct intel_cdclk_state *b);
+void intel_cdclk_swap_state(struct intel_atomic_state *state);
void intel_set_cdclk(struct drm_i915_private *dev_priv,
const struct intel_cdclk_state *cdclk_state);
void intel_dump_cdclk_state(const struct intel_cdclk_state *cdclk_state,


2019-07-02 14:34:04

by kernelci.org bot

[permalink] [raw]
Subject: Re: [PATCH 5.1 00/55] 5.1.16-stable review

stable-rc/linux-5.1.y boot: 135 boots: 4 failed, 131 passed (v5.1.15-56-gbe6a5acaf4fb)

Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.1.y/kernel/v5.1.15-56-gbe6a5acaf4fb/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.1.y/kernel/v5.1.15-56-gbe6a5acaf4fb/

Tree: stable-rc
Branch: linux-5.1.y
Git Describe: v5.1.15-56-gbe6a5acaf4fb
Git Commit: be6a5acaf4fb84829cc456c77af78ef981fb6db2
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 77 unique boards, 26 SoC families, 16 builds out of 209

Boot Failures Detected:

arm:
sunxi_defconfig:
gcc-8:
sun7i-a20-bananapi: 1 failed lab

multi_v7_defconfig:
gcc-8:
bcm4708-smartrg-sr400ac: 1 failed lab
stih410-b2120: 1 failed lab
sun7i-a20-bananapi: 1 failed lab

---
For more info write to <[email protected]>

2019-07-02 17:41:01

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 5.1 00/55] 5.1.16-stable review

On Tue, 2 Jul 2019 at 13:34, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.1.16 release.
> There are 55 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu 04 Jul 2019 07:59:45 AM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.16-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.1.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary
------------------------------------------------------------------------

kernel: 5.1.16-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.1.y
git commit: be6a5acaf4fb84829cc456c77af78ef981fb6db2
git describe: v5.1.15-56-gbe6a5acaf4fb
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.1-oe/build/v5.1.15-56-gbe6a5acaf4fb


No regressions (compared to build v5.1.15)


No fixes (compared to build v5.1.15)

Ran 22032 total tests in the following environments and test suites.

Environments
--------------
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86

Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest
* libgpiod
* libhugetlbfs
* ltp-containers-tests
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-timers-tests
* network-basic-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* ltp-open-posix-tests
* ltp-syscalls-tests
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

--
Linaro LKFT
https://lkft.linaro.org

2019-07-02 18:08:17

by Jiunn Chang

[permalink] [raw]
Subject: Re: [PATCH 5.1 00/55] 5.1.16-stable review

On Tue, Jul 02, 2019 at 10:01:08AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.1.16 release.
> There are 55 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu 04 Jul 2019 07:59:45 AM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.16-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.1.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -------------

Hello,

Compiled and booted. No regressions on x86_64.

THX,

Jiunn

2019-07-03 01:23:43

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 5.1 00/55] 5.1.16-stable review

On 7/2/19 2:01 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.1.16 release.
> There are 55 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu 04 Jul 2019 07:59:45 AM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.16-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.1.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

2019-07-03 01:28:06

by Kelsey

[permalink] [raw]
Subject: Re: [PATCH 5.1 00/55] 5.1.16-stable review

On Tue, Jul 02, 2019 at 10:01:08AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.1.16 release.
> There are 55 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu 04 Jul 2019 07:59:45 AM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.16-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.1.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Compiled, booted, and no regressions on my system.

Cheers,
Kelsey

2019-07-03 06:27:43

by Shreeya Patel

[permalink] [raw]
Subject: Re: [PATCH 5.1 00/55] 5.1.16-stable review

On Tue, 2019-07-02 at 10:01 +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.1.16 release.
> There are 55 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied,
> please
> let me know.
>
> Responses should be made by Thu 04 Jul 2019 07:59:45 AM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
>
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.16-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-
> stable-rc.git linux-5.1.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Compiled, booted, and no regressions.

Thanks

>
> -------------
> Pseudo-Shortlog of commits:
>
> Greg Kroah-Hartman <[email protected]>
> Linux 5.1.16-rc1
>
> Xin Long <[email protected]>
> tipc: pass tunnel dev as NULL to udp_tunnel(6)_xmit_skb
>
> Amir Goldstein <[email protected]>
> fanotify: update connector fsid cache on add mark
>
> Jason Gunthorpe <[email protected]>
> RDMA: Directly cast the sockaddr union to sockaddr
>
> Will Deacon <[email protected]>
> futex: Update comments and docs about return values of arch futex
> code
>
> Daniel Borkmann <[email protected]>
> bpf, arm64: use more scalable stadd over ldxr / stxr loop in xadd
>
> Will Deacon <[email protected]>
> arm64: futex: Avoid copying out uninitialised stack in failed
> cmpxchg()
>
> Martin KaFai Lau <[email protected]>
> bpf: udp: ipv6: Avoid running reuseport's bpf_prog from
> __udp6_lib_err
>
> Martin KaFai Lau <[email protected]>
> bpf: udp: Avoid calling reuseport's bpf_prog from udp_gro
>
> Daniel Borkmann <[email protected]>
> bpf: fix unconnected udp hooks
>
> Matt Mullins <[email protected]>
> bpf: fix nested bpf tracepoints with per-cpu data
>
> Jonathan Lemon <[email protected]>
> bpf: lpm_trie: check left child of last leftmost node for NULL
>
> Martynas Pumputis <[email protected]>
> bpf: simplify definition of BPF_FIB_LOOKUP related flags
>
> Dmitry Bogdanov <[email protected]>
> net: aquantia: fix vlans not working over bridged network
>
> Fei Li <[email protected]>
> tun: wake up waitqueues after IFF_UP is set
>
> Xin Long <[email protected]>
> tipc: check msg->req data len in tipc_nl_compat_bearer_disable
>
> Xin Long <[email protected]>
> tipc: change to use register_pernet_device
>
> YueHaibing <[email protected]>
> team: Always enable vlan tx offload
>
> Xin Long <[email protected]>
> sctp: change to hold sk after auth shkey is created successfully
>
> Dirk van der Merwe <[email protected]>
> net/tls: fix page double free on TX cleanup
>
> Roland Hii <[email protected]>
> net: stmmac: set IC bit when transmitting frames with HW
> timestamp
>
> Roland Hii <[email protected]>
> net: stmmac: fixed new system time seconds value calculation
>
> JingYi Hou <[email protected]>
> net: remove duplicate fetch in sock_getsockopt
>
> Eric Dumazet <[email protected]>
> net/packet: fix memory leak in packet_set_ring()
>
> Stephen Suryaputra <[email protected]>
> ipv4: Use return value of inet_iif() for __raw_v4_lookup in the
> while loop
>
> YueHaibing <[email protected]>
> bonding: Always enable vlan tx offload
>
> Neil Horman <[email protected]>
> af_packet: Block execution of tasks waiting for transmit to
> complete in AF_PACKET
>
> Paul Burton <[email protected]>
> irqchip/mips-gic: Use the correct local interrupt map registers
>
> Trond Myklebust <[email protected]>
> SUNRPC: Fix up calculation of client message length
>
> Geert Uytterhoeven <[email protected]>
> cpu/speculation: Warn on unsupported mitigations= parameter
>
> Trond Myklebust <[email protected]>
> NFS/flexfiles: Use the correct TCP timeout for flexfiles I/O
>
> Ard Biesheuvel <[email protected]>
> efi/memreserve: deal with memreserve entries in unmapped memory
>
> Johannes Weiner <[email protected]>
> mm: fix page cache convergence regression
>
> Reinette Chatre <[email protected]>
> x86/resctrl: Prevent possible overrun during bitmap operations
>
> Thomas Gleixner <[email protected]>
> x86/microcode: Fix the microcode load on CPU hotplug for real
>
> Alejandro Jimenez <[email protected]>
> x86/speculation: Allow guests to use SSBD even if host does not
>
> Jan Kara <[email protected]>
> scsi: vmw_pscsi: Fix use-after-free in pvscsi_queue_lck()
>
> Jens Axboe <[email protected]>
> io_uring: ensure req->file is cleared on allocation
>
> zhangyi (F) <[email protected]>
> dm log writes: make sure super sector log updates are written in
> order
>
> Gen Zhang <[email protected]>
> dm init: fix incorrect uses of kstrndup()
>
> Huang Ying <[email protected]>
> mm, swap: fix THP swap out
>
> Colin Ian King <[email protected]>
> mm/page_idle.c: fix oops because end_pfn is larger than max_pfn
>
> Naoya Horiguchi <[email protected]>
> mm: hugetlb: soft-offline: dissolve_free_huge_page() return zero
> on !PageHuge
>
> Naoya Horiguchi <[email protected]>
> mm: soft-offline: return -EBUSY if set_hwpoison_free_buddy_page()
> fails
>
> Ville Syrjälä <[email protected]>
> drm/i915: Skip modeset for cdclk changes if possible
>
> Imre Deak <[email protected]>
> drm/i915: Remove redundant store of logical CDCLK state
>
> Imre Deak <[email protected]>
> drm/i915: Save the old CDCLK atomic state
>
> Ville Syrjälä <[email protected]>
> drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is
> enabled
>
> Dinh Nguyen <[email protected]>
> clk: socfpga: stratix10: fix divider entry for the emac clocks
>
> Jon Hunter <[email protected]>
> clk: tegra210: Fix default rates for HDA clocks
>
> Jann Horn <[email protected]>
> fs/binfmt_flat.c: make load_flat_shared_library() work
>
> zhong jiang <[email protected]>
> mm/mempolicy.c: fix an incorrect rebind node in
> mpol_rebind_nodemask
>
> John Ogness <[email protected]>
> fs/proc/array.c: allow reporting eip/esp for all coredumping
> threads
>
> Bjørn Mork <[email protected]>
> qmi_wwan: Fix out-of-bounds read
>
> Sasha Levin <[email protected]>
> Revert "x86/uaccess, ftrace: Fix ftrace_likely_update() vs. SMAP"
>
> Nathan Chancellor <[email protected]>
> arm64: Don't unconditionally add -Wno-psabi to KBUILD_CFLAGS
>
>
> -------------
>
> Diffstat:
>
> Documentation/robust-futexes.txt | 3 +-
> Makefile | 4 +-
> arch/arm64/Makefile | 2 +-
> arch/arm64/include/asm/futex.h | 4 +-
> arch/arm64/include/asm/insn.h | 8 +
> arch/arm64/kernel/insn.c | 40 +++++
> arch/arm64/net/bpf_jit.h | 4 +
> arch/arm64/net/bpf_jit_comp.c | 28 +++-
> arch/mips/include/asm/mips-gic.h | 30 ++++
> arch/x86/kernel/cpu/bugs.c | 11 +-
> arch/x86/kernel/cpu/microcode/core.c | 15 +-
> arch/x86/kernel/cpu/resctrl/rdtgroup.c | 35 ++--
> drivers/clk/socfpga/clk-s10.c | 4 +-
> drivers/clk/tegra/clk-tegra210.c | 2 +
> drivers/firmware/efi/efi.c | 12 +-
> drivers/gpu/drm/i915/i915_drv.h | 6 +-
> drivers/gpu/drm/i915/intel_audio.c | 62 ++++++-
> drivers/gpu/drm/i915/intel_cdclk.c | 185
> +++++++++++++++------
> drivers/gpu/drm/i915/intel_display.c | 57 ++++++-
> drivers/gpu/drm/i915/intel_drv.h | 21 ++-
> drivers/infiniband/core/addr.c | 16 +-
> drivers/infiniband/hw/ocrdma/ocrdma_ah.c | 5 +-
> drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 5 +-
> drivers/irqchip/irq-mips-gic.c | 4 +-
> drivers/md/dm-init.c | 6 +-
> drivers/md/dm-log-writes.c | 23 ++-
> drivers/net/bonding/bond_main.c | 2 +-
> .../net/ethernet/aquantia/atlantic/aq_filters.c | 10 +-
> drivers/net/ethernet/aquantia/atlantic/aq_nic.c | 1 +
> drivers/net/ethernet/aquantia/atlantic/aq_nic.h | 1 +
> .../ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c | 19 ++-
> .../net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 2 +-
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 22 ++-
> drivers/net/team/team.c | 2 +-
> drivers/net/tun.c | 19 +--
> drivers/net/usb/qmi_wwan.c | 2 +-
> drivers/scsi/vmw_pvscsi.c | 6 +-
> fs/binfmt_flat.c | 23 +--
> fs/inode.c | 2 +-
> fs/io_uring.c | 5 +-
> fs/nfs/flexfilelayout/flexfilelayoutdev.c | 2 +-
> fs/notify/fanotify/fanotify.c | 4 +
> fs/notify/mark.c | 14 +-
> fs/proc/array.c | 2 +-
> include/asm-generic/futex.h | 8 +-
> include/linux/bpf-cgroup.h | 8 +
> include/linux/fsnotify_backend.h | 4 +-
> include/linux/xarray.h | 1 +
> include/net/tls.h | 15 --
> include/uapi/linux/bpf.h | 6 +-
> kernel/bpf/lpm_trie.c | 9 +-
> kernel/bpf/syscall.c | 8 +
> kernel/bpf/verifier.c | 12 +-
> kernel/cpu.c | 3 +
> kernel/trace/bpf_trace.c | 100 +++++++++--
> kernel/trace/trace_branch.c | 4 -
> lib/xarray.c | 12 +-
> mm/hugetlb.c | 29 +++-
> mm/memory-failure.c | 7 +-
> mm/mempolicy.c | 2 +-
> mm/page_idle.c | 4 +-
> mm/page_io.c | 7 +-
> net/core/filter.c | 2 +
> net/core/sock.c | 3 -
> net/ipv4/raw.c | 2 +-
> net/ipv4/udp.c | 10 +-
> net/ipv6/udp.c | 8 +-
> net/packet/af_packet.c | 23 ++-
> net/packet/internal.h | 1 +
> net/sctp/endpointola.c | 8 +-
> net/sunrpc/xprtsock.c | 16 +-
> net/tipc/core.c | 12 +-
> net/tipc/netlink_compat.c | 18 +-
> net/tipc/udp_media.c | 8 +-
> net/tls/tls_main.c | 3 +-
> tools/testing/selftests/bpf/test_lpm_map.c | 41 ++++-
> 76 files changed, 830 insertions(+), 294 deletions(-)
>
>

2019-07-03 09:12:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.1 00/55] 5.1.16-stable review

On Tue, Jul 02, 2019 at 11:09:47PM +0530, Naresh Kamboju wrote:
> On Tue, 2 Jul 2019 at 13:34, Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > This is the start of the stable review cycle for the 5.1.16 release.
> > There are 55 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu 04 Jul 2019 07:59:45 AM UTC.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.16-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.1.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.

Great, thanks for testing and letting me know.

greg k-h

2019-07-03 09:13:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.1 00/55] 5.1.16-stable review

On Tue, Jul 02, 2019 at 04:56:24PM -0600, shuah wrote:
> On 7/2/19 2:01 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.1.16 release.
> > There are 55 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu 04 Jul 2019 07:59:45 AM UTC.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.16-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.1.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Compiled and booted on my test system. No dmesg regressions.

thanks for testing all of these and letting me know.

greg k-h

2019-07-03 10:22:19

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH 5.1 00/55] 5.1.16-stable review


On 02/07/2019 09:01, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.1.16 release.
> There are 55 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu 04 Jul 2019 07:59:45 AM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.16-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.1.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

All tests are passing for Tegra ...

Test results for stable-v5.1:
12 builds: 12 pass, 0 fail
22 boots: 22 pass, 0 fail
32 tests: 32 pass, 0 fail

Linux version: 5.1.16-rc1-gbe6a5acaf4fb
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04

Cheers
Jon

--
nvpublic

2019-07-03 10:50:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 5.1 00/55] 5.1.16-stable review

On Wed, Jul 03, 2019 at 11:21:35AM +0100, Jon Hunter wrote:
>
> On 02/07/2019 09:01, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.1.16 release.
> > There are 55 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu 04 Jul 2019 07:59:45 AM UTC.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.16-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.1.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> All tests are passing for Tegra ...
>
> Test results for stable-v5.1:
> 12 builds: 12 pass, 0 fail
> 22 boots: 22 pass, 0 fail
> 32 tests: 32 pass, 0 fail
>
> Linux version: 5.1.16-rc1-gbe6a5acaf4fb
> Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
> tegra194-p2972-0000, tegra20-ventana,
> tegra210-p2371-2180, tegra30-cardhu-a04

Wonderful, thanks for testing all of these and letting me know.

greg k-h

2019-07-04 05:30:54

by Bharath Vedartham

[permalink] [raw]
Subject: Re: [PATCH 5.1 00/55] 5.1.16-stable review

Tested and booted on my x86 system. No regressions.