--- /dev/null
+From fab827dbee8c2e06ca4ba000fa6c48bcf9054aba Mon Sep 17 00:00:00 2001
+From: Vasily Averin <vvs@virtuozzo.com>
+Date: Thu, 2 Sep 2021 14:54:57 -0700
+Subject: memcg: enable accounting for pids in nested pid namespaces
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Vasily Averin <vvs@virtuozzo.com>
+
+commit fab827dbee8c2e06ca4ba000fa6c48bcf9054aba upstream.
+
+Commit 5d097056c9a0 ("kmemcg: account certain kmem allocations to memcg")
+enabled memcg accounting for pids allocated from init_pid_ns.pid_cachep,
+but forgot to adjust the setting for nested pid namespaces. As a result,
+pid memory is not accounted exactly where it is really needed, inside
+memcg-limited containers with their own pid namespaces.
+
+Pid was one the first kernel objects enabled for memcg accounting.
+init_pid_ns.pid_cachep marked by SLAB_ACCOUNT and we can expect that any
+new pids in the system are memcg-accounted.
+
+Though recently I've noticed that it is wrong. nested pid namespaces
+creates own slab caches for pid objects, nested pids have increased size
+because contain id both for all parent and for own pid namespaces. The
+problem is that these slab caches are _NOT_ marked by SLAB_ACCOUNT, as a
+result any pids allocated in nested pid namespaces are not
+memcg-accounted.
+
+Pid struct in nested pid namespace consumes up to 500 bytes memory, 100000
+such objects gives us up to ~50Mb unaccounted memory, this allow container
+to exceed assigned memcg limits.
+
+Link: https://lkml.kernel.org/r/8b6de616-fd1a-02c6-cbdb-976ecdcfa604@virtuozzo.com
+Fixes: 5d097056c9a0 ("kmemcg: account certain kmem allocations to memcg")
+Cc: stable@vger.kernel.org
+Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
+Reviewed-by: Michal Koutný <mkoutny@suse.com>
+Reviewed-by: Shakeel Butt <shakeelb@google.com>
+Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
+Acked-by: Roman Gushchin <guro@fb.com>
+Cc: Michal Hocko <mhocko@suse.com>
+Cc: Johannes Weiner <hannes@cmpxchg.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/pid_namespace.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/pid_namespace.c
++++ b/kernel/pid_namespace.c
+@@ -52,7 +52,7 @@ static struct kmem_cache *create_pid_cac
+ snprintf(pcache->name, sizeof(pcache->name), "pid_%d", nr_ids);
+ cachep = kmem_cache_create(pcache->name,
+ sizeof(struct pid) + (nr_ids - 1) * sizeof(struct upid),
+- 0, SLAB_HWCACHE_ALIGN, NULL);
++ 0, SLAB_HWCACHE_ALIGN | SLAB_ACCOUNT, NULL);
+ if (cachep == NULL)
+ goto err_cachep;
+
--- /dev/null
+From 13db8c50477d83ad3e3b9b0ae247e5cd833a7ae4 Mon Sep 17 00:00:00 2001
+From: Liu Zixian <liuzixian4@huawei.com>
+Date: Wed, 8 Sep 2021 18:10:05 -0700
+Subject: mm/hugetlb: initialize hugetlb_usage in mm_init
+
+From: Liu Zixian <liuzixian4@huawei.com>
+
+commit 13db8c50477d83ad3e3b9b0ae247e5cd833a7ae4 upstream.
+
+After fork, the child process will get incorrect (2x) hugetlb_usage. If
+a process uses 5 2MB hugetlb pages in an anonymous mapping,
+
+ HugetlbPages: 10240 kB
+
+and then forks, the child will show,
+
+ HugetlbPages: 20480 kB
+
+The reason for double the amount is because hugetlb_usage will be copied
+from the parent and then increased when we copy page tables from parent
+to child. Child will have 2x actual usage.
+
+Fix this by adding hugetlb_count_init in mm_init.
+
+Link: https://lkml.kernel.org/r/20210826071742.877-1-liuzixian4@huawei.com
+Fixes: 5d317b2b6536 ("mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status")
+Signed-off-by: Liu Zixian <liuzixian4@huawei.com>
+Reviewed-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
+Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/hugetlb.h | 9 +++++++++
+ kernel/fork.c | 1 +
+ 2 files changed, 10 insertions(+)
+
+--- a/include/linux/hugetlb.h
++++ b/include/linux/hugetlb.h
+@@ -482,6 +482,11 @@ static inline spinlock_t *huge_pte_lockp
+
+ void hugetlb_report_usage(struct seq_file *m, struct mm_struct *mm);
+
++static inline void hugetlb_count_init(struct mm_struct *mm)
++{
++ atomic_long_set(&mm->hugetlb_usage, 0);
++}
++
+ static inline void hugetlb_count_add(long l, struct mm_struct *mm)
+ {
+ atomic_long_add(l, &mm->hugetlb_usage);
+@@ -527,6 +532,10 @@ static inline spinlock_t *huge_pte_lockp
+ return &mm->page_table_lock;
+ }
+
++static inline void hugetlb_count_init(struct mm_struct *mm)
++{
++}
++
+ static inline void hugetlb_report_usage(struct seq_file *f, struct mm_struct *m)
+ {
+ }
+--- a/kernel/fork.c
++++ b/kernel/fork.c
+@@ -789,6 +789,7 @@ static struct mm_struct *mm_init(struct
+ mm->pmd_huge_pte = NULL;
+ #endif
+ mm_init_uprobes_state(mm);
++ hugetlb_count_init(mm);
+
+ if (current->mm) {
+ mm->flags = current->mm->flags & MMF_INIT_MASK;
--- /dev/null
+From 030f653078316a9cc9ca6bd1b0234dcf858be35d Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Mon, 30 Aug 2021 05:42:27 -0400
+Subject: parisc: fix crash with signals and alloca
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit 030f653078316a9cc9ca6bd1b0234dcf858be35d upstream.
+
+I was debugging some crashes on parisc and I found out that there is a
+crash possibility if a function using alloca is interrupted by a signal.
+The reason for the crash is that the gcc alloca implementation leaves
+garbage in the upper 32 bits of the sp register. This normally doesn't
+matter (the upper bits are ignored because the PSW W-bit is clear),
+however the signal delivery routine in the kernel uses full 64 bits of sp
+and it fails with -EFAULT if the upper 32 bits are not zero.
+
+I created this program that demonstrates the problem:
+
+#include <stdlib.h>
+#include <unistd.h>
+#include <signal.h>
+#include <alloca.h>
+
+static __attribute__((noinline,noclone)) void aa(int *size)
+{
+ void * volatile p = alloca(-*size);
+ while (1) ;
+}
+
+static void handler(int sig)
+{
+ write(1, "signal delivered\n", 17);
+ _exit(0);
+}
+
+int main(void)
+{
+ int size = -0x100;
+ signal(SIGALRM, handler);
+ alarm(1);
+ aa(&size);
+}
+
+If you compile it with optimizations, it will crash.
+The "aa" function has this disassembly:
+
+000106a0 <aa>:
+ 106a0: 08 03 02 41 copy r3,r1
+ 106a4: 08 1e 02 43 copy sp,r3
+ 106a8: 6f c1 00 80 stw,ma r1,40(sp)
+ 106ac: 37 dc 3f c1 ldo -20(sp),ret0
+ 106b0: 0c 7c 12 90 stw ret0,8(r3)
+ 106b4: 0f 40 10 9c ldw 0(r26),ret0 ; ret0 = 0x00000000FFFFFF00
+ 106b8: 97 9c 00 7e subi 3f,ret0,ret0 ; ret0 = 0xFFFFFFFF0000013F
+ 106bc: d7 80 1c 1a depwi 0,31,6,ret0 ; ret0 = 0xFFFFFFFF00000100
+ 106c0: 0b 9e 0a 1e add,l sp,ret0,sp ; sp = 0xFFFFFFFFxxxxxxxx
+ 106c4: e8 1f 1f f7 b,l,n 106c4 <aa+0x24>,r0
+
+This patch fixes the bug by truncating the "usp" variable to 32 bits.
+
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/parisc/kernel/signal.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/arch/parisc/kernel/signal.c
++++ b/arch/parisc/kernel/signal.c
+@@ -239,6 +239,12 @@ setup_rt_frame(struct ksignal *ksig, sig
+ #endif
+
+ usp = (regs->gr[30] & ~(0x01UL));
++#ifdef CONFIG_64BIT
++ if (is_compat_task()) {
++ /* The gcc alloca implementation leaves garbage in the upper 32 bits of sp */
++ usp = (compat_uint_t)usp;
++ }
++#endif
+ /*FIXME: frame_size parameter is unused, remove it. */
+ frame = get_sigframe(&ksig->ka, usp, sizeof(*frame));
+
--- /dev/null
+From 3abc16af57c9939724df92fcbda296b25cc95168 Mon Sep 17 00:00:00 2001
+From: Patryk Duda <pdk@semihalf.com>
+Date: Tue, 18 May 2021 16:07:58 +0200
+Subject: platform/chrome: cros_ec_proto: Send command again when timeout occurs
+
+From: Patryk Duda <pdk@semihalf.com>
+
+commit 3abc16af57c9939724df92fcbda296b25cc95168 upstream.
+
+Sometimes kernel is trying to probe Fingerprint MCU (FPMCU) when it
+hasn't initialized SPI yet. This can happen because FPMCU is restarted
+during system boot and kernel can send message in short window
+eg. between sysjump to RW and SPI initialization.
+
+Cc: <stable@vger.kernel.org> # 4.4+
+Signed-off-by: Patryk Duda <pdk@semihalf.com>
+Link: https://lore.kernel.org/r/20210518140758.29318-1-pdk@semihalf.com
+Signed-off-by: Benson Leung <bleung@chromium.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/chrome/cros_ec_proto.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/drivers/platform/chrome/cros_ec_proto.c
++++ b/drivers/platform/chrome/cros_ec_proto.c
+@@ -183,6 +183,15 @@ static int cros_ec_host_command_proto_qu
+ msg->insize = sizeof(struct ec_response_get_protocol_info);
+
+ ret = send_command(ec_dev, msg);
++ /*
++ * Send command once again when timeout occurred.
++ * Fingerprint MCU (FPMCU) is restarted during system boot which
++ * introduces small window in which FPMCU won't respond for any
++ * messages sent by kernel. There is no need to wait before next
++ * attempt because we waited at least EC_MSG_DEADLINE_MS.
++ */
++ if (ret == -ETIMEDOUT)
++ ret = send_command(ec_dev, msg);
+
+ if (ret < 0) {
+ dev_dbg(ec_dev->dev,
--- /dev/null
+From 44d01fc86d952f5a8b8b32bdb4841504d5833d95 Mon Sep 17 00:00:00 2001
+From: "Maciej W. Rozycki" <macro@orcam.me.uk>
+Date: Tue, 20 Apr 2021 20:01:47 +0200
+Subject: scsi: BusLogic: Fix missing pr_cont() use
+
+From: Maciej W. Rozycki <macro@orcam.me.uk>
+
+commit 44d01fc86d952f5a8b8b32bdb4841504d5833d95 upstream.
+
+Update BusLogic driver's messaging system to use pr_cont() for continuation
+lines, bringing messy output:
+
+pci 0000:00:13.0: PCI->APIC IRQ transform: INT A -> IRQ 17
+scsi: ***** BusLogic SCSI Driver Version 2.1.17 of 12 September 2013 *****
+scsi: Copyright 1995-1998 by Leonard N. Zubkoff <lnz@dandelion.com>
+scsi0: Configuring BusLogic Model BT-958 PCI Wide Ultra SCSI Host Adapter
+scsi0: Firmware Version: 5.07B, I/O Address: 0x7000, IRQ Channel: 17/Level
+scsi0: PCI Bus: 0, Device: 19, Address:
+0xE0012000,
+Host Adapter SCSI ID: 7
+scsi0: Parity Checking: Enabled, Extended Translation: Enabled
+scsi0: Synchronous Negotiation: Ultra, Wide Negotiation: Enabled
+scsi0: Disconnect/Reconnect: Enabled, Tagged Queuing: Enabled
+scsi0: Scatter/Gather Limit: 128 of 8192 segments, Mailboxes: 211
+scsi0: Driver Queue Depth: 211, Host Adapter Queue Depth: 192
+scsi0: Tagged Queue Depth:
+Automatic
+, Untagged Queue Depth: 3
+scsi0: SCSI Bus Termination: Both Enabled
+, SCAM: Disabled
+
+scsi0: *** BusLogic BT-958 Initialized Successfully ***
+scsi host0: BusLogic BT-958
+
+back to order:
+
+pci 0000:00:13.0: PCI->APIC IRQ transform: INT A -> IRQ 17
+scsi: ***** BusLogic SCSI Driver Version 2.1.17 of 12 September 2013 *****
+scsi: Copyright 1995-1998 by Leonard N. Zubkoff <lnz@dandelion.com>
+scsi0: Configuring BusLogic Model BT-958 PCI Wide Ultra SCSI Host Adapter
+scsi0: Firmware Version: 5.07B, I/O Address: 0x7000, IRQ Channel: 17/Level
+scsi0: PCI Bus: 0, Device: 19, Address: 0xE0012000, Host Adapter SCSI ID: 7
+scsi0: Parity Checking: Enabled, Extended Translation: Enabled
+scsi0: Synchronous Negotiation: Ultra, Wide Negotiation: Enabled
+scsi0: Disconnect/Reconnect: Enabled, Tagged Queuing: Enabled
+scsi0: Scatter/Gather Limit: 128 of 8192 segments, Mailboxes: 211
+scsi0: Driver Queue Depth: 211, Host Adapter Queue Depth: 192
+scsi0: Tagged Queue Depth: Automatic, Untagged Queue Depth: 3
+scsi0: SCSI Bus Termination: Both Enabled, SCAM: Disabled
+scsi0: *** BusLogic BT-958 Initialized Successfully ***
+scsi host0: BusLogic BT-958
+
+Also diagnostic output such as with the BusLogic=TraceConfiguration
+parameter is affected and becomes vertical and therefore hard to read.
+This has now been corrected, e.g.:
+
+pci 0000:00:13.0: PCI->APIC IRQ transform: INT A -> IRQ 17
+blogic_cmd(86) Status = 30: 4 ==> 4: FF 05 93 00
+blogic_cmd(95) Status = 28: (Modify I/O Address)
+blogic_cmd(91) Status = 30: 1 ==> 1: 01
+blogic_cmd(04) Status = 30: 4 ==> 4: 41 41 35 30
+blogic_cmd(8D) Status = 30: 14 ==> 14: 45 DC 00 20 00 00 00 00 00 40 30 37 42 1D
+scsi: ***** BusLogic SCSI Driver Version 2.1.17 of 12 September 2013 *****
+scsi: Copyright 1995-1998 by Leonard N. Zubkoff <lnz@dandelion.com>
+blogic_cmd(04) Status = 30: 4 ==> 4: 41 41 35 30
+blogic_cmd(0B) Status = 30: 3 ==> 3: 00 08 07
+blogic_cmd(0D) Status = 30: 34 ==> 34: 03 01 07 04 00 00 00 00 00 00 00 00 00 00 00 00 FF 42 44 46 FF 00 00 00 00 00 00 00 00 00 FF 00 FF 00
+blogic_cmd(8D) Status = 30: 14 ==> 14: 45 DC 00 20 00 00 00 00 00 40 30 37 42 1D
+blogic_cmd(84) Status = 30: 1 ==> 1: 37
+blogic_cmd(8B) Status = 30: 5 ==> 5: 39 35 38 20 20
+blogic_cmd(85) Status = 30: 1 ==> 1: 42
+blogic_cmd(86) Status = 30: 4 ==> 4: FF 05 93 00
+blogic_cmd(91) Status = 30: 64 ==> 64: 41 46 3E 20 39 35 38 20 20 00 C4 00 04 01 07 2F 07 04 35 FF FF FF FF FF FF FF FF FF FF 01 00 FE FF 08 FF FF 00 00 00 00 00 00 00 01 00 01 00 00 FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 FC
+scsi0: Configuring BusLogic Model BT-958 PCI Wide Ultra SCSI Host Adapter
+
+etc.
+
+Link: https://lore.kernel.org/r/alpine.DEB.2.21.2104201940430.44318@angie.orcam.me.uk
+Fixes: 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing continuation lines")
+Cc: stable@vger.kernel.org # v4.9+
+Acked-by: Khalid Aziz <khalid@gonehiking.org>
+Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/BusLogic.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/scsi/BusLogic.c
++++ b/drivers/scsi/BusLogic.c
+@@ -3597,7 +3597,7 @@ static void blogic_msg(enum blogic_msgle
+ if (buf[0] != '\n' || len > 1)
+ printk("%sscsi%d: %s", blogic_msglevelmap[msglevel], adapter->host_no, buf);
+ } else
+- printk("%s", buf);
++ pr_cont("%s", buf);
+ } else {
+ if (begin) {
+ if (adapter != NULL && adapter->adapter_initd)
+@@ -3605,7 +3605,7 @@ static void blogic_msg(enum blogic_msgle
+ else
+ printk("%s%s", blogic_msglevelmap[msglevel], buf);
+ } else
+- printk("%s", buf);
++ pr_cont("%s", buf);
+ }
+ begin = (buf[len - 1] == '\n');
+ }
ath9k-fix-sleeping-in-atomic-context.patch
net-fix-null-pointer-reference-in-cipso_v4_doi_free.patch
net-w5100-check-return-value-after-calling-platform_.patch
+parisc-fix-crash-with-signals-and-alloca.patch
+scsi-buslogic-fix-missing-pr_cont-use.patch
+mm-hugetlb-initialize-hugetlb_usage-in-mm_init.patch
+memcg-enable-accounting-for-pids-in-nested-pid-namespaces.patch
+platform-chrome-cros_ec_proto-send-command-again-when-timeout-occurs.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
