Skip to contentSkip to conversation

incoming

PATCH In review Andrew Morton 7 participants 80 messages Jun 26, 2020 – Jul 8, 2020 2 messages not in the archive

Subsystems (28)
lore
Share & tools
lore

Andrew Morton

author maintainer
#0 lore raw

32 patches, based on 908f7d12d3ba51dfe0449b9723199b423f97ca9a.

Subsystems affected by this patch series:

hotfixes
mm/pagealloc
kexec
ocfs2
lib
misc
mm/slab
mm/slab
mm/slub
mm/swap
mm/pagemap
mm/vmalloc
mm/memcg
mm/gup
mm/thp
mm/vmscan
x86
mm/memory-hotplug
MAINTAINERS

Subsystem: hotfixes

Stafford Horne <[email protected]>:
openrisc: fix boot oops when DEBUG_VM is enabled

Michal Hocko <[email protected]>:
mm: do_swap_page(): fix up the error code

Subsystem: mm/pagealloc

Vlastimil Babka <[email protected]>:
mm, compaction: make capture control handling safe wrt interrupts

Subsystem: kexec

Lianbo Jiang <[email protected]>:
kexec: do not verify the signature without the lockdown or mandatory signature

Subsystem: ocfs2

Junxiao Bi <[email protected]>:
Patch series "ocfs2: fix nfsd over ocfs2 issues", v2:
ocfs2: avoid inode removal while nfsd is accessing it
ocfs2: load global_inode_alloc
ocfs2: fix panic on nfs server over ocfs2
ocfs2: fix value of OCFS2_INVALID_SLOT

Subsystem: lib

Randy Dunlap <[email protected]>:
lib: fix test_hmm.c reference after free

Subsystem: misc

Rikard Falkeborn <[email protected]>:
linux/bits.h: fix unsigned less than zero warnings

Subsystem: mm/slab

Waiman Long <[email protected]>:
mm, slab: fix sign conversion problem in memcg_uncharge_slab()

Subsystem: mm/slab

Waiman Long <[email protected]>:
mm/slab: use memzero_explicit() in kzfree()

Subsystem: mm/slub

Sebastian Andrzej Siewior <[email protected]>:
slub: cure list_slab_objects() from double fix

Subsystem: mm/swap

Hugh Dickins <[email protected]>:
mm: fix swap cache node allocation mask

Subsystem: mm/pagemap

Arjun Roy <[email protected]>:
mm/memory.c: properly pte_offset_map_lock/unlock in vm_insert_pages()

Christophe Leroy <[email protected]>:
mm/debug_vm_pgtable: fix build failure with powerpc 8xx

Stephen Rothwell <[email protected]>:
make asm-generic/cacheflush.h more standalone

Nathan Chancellor <[email protected]>:
media: omap3isp: remove cacheflush.h

Subsystem: mm/vmalloc

Masanari Iida <[email protected]>:
mm/vmalloc.c: fix a warning while make xmldocs

Subsystem: mm/memcg

Johannes Weiner <[email protected]>:
mm: memcontrol: handle div0 crash race condition in memory.low

Muchun Song <[email protected]>:
mm/memcontrol.c: add missed css_put()

Chris Down <[email protected]>:
mm/memcontrol.c: prevent missed memory.low load tears

Subsystem: mm/gup

Souptick Joarder <[email protected]>:
docs: mm/gup: minor documentation update

Subsystem: mm/thp

Yang Shi <[email protected]>:
doc: THP CoW fault no longer allocate THP

Subsystem: mm/vmscan

Johannes Weiner <[email protected]>:
Patch series "fix for "mm: balance LRU lists based on relative thrashing" patchset":
mm: workingset: age nonresident information alongside anonymous pages

Joonsoo Kim <[email protected]>:
mm/swap: fix for "mm: workingset: age nonresident information alongside anonymous pages" mm/memory: fix IO cost for anonymous page

Subsystem: x86

Christoph Hellwig <[email protected]>:
Patch series "fix a hyperv W^X violation and remove vmalloc_exec":
x86/hyperv: allocate the hypercall page with only read and execute bits
arm64: use PAGE_KERNEL_ROX directly in alloc_insn_page
mm: remove vmalloc_exec

Subsystem: mm/memory-hotplug

Ben Widawsky <[email protected]>:
mm/memory_hotplug.c: fix false softlockup during pfn range removal

Subsystem: MAINTAINERS

Luc Van Oostenryck <[email protected]>:
MAINTAINERS: update info for sparse

 Documentation/admin-guide/cgroup-v2.rst    |    4 +-
 Documentation/admin-guide/mm/transhuge.rst |    3 -
 Documentation/core-api/pin_user_pages.rst  |    2 -
 MAINTAINERS                                |    4 +-
 arch/arm64/kernel/probes/kprobes.c         |   12 +------
 arch/openrisc/kernel/dma.c                 |    5 +++
 arch/x86/hyperv/hv_init.c                  |    4 +-
 arch/x86/include/asm/pgtable_types.h       |    2 +
 drivers/media/platform/omap3isp/isp.c      |    2 -
 drivers/media/platform/omap3isp/ispvideo.c |    1 
 fs/ocfs2/dlmglue.c                         |   17 ++++++++++
 fs/ocfs2/ocfs2.h                           |    1 
 fs/ocfs2/ocfs2_fs.h                        |    4 +-
 fs/ocfs2/suballoc.c                        |    9 +++--
 include/asm-generic/cacheflush.h           |    5 +++
 include/linux/bits.h                       |    3 +
 include/linux/mmzone.h                     |    4 +-
 include/linux/swap.h                       |    1 
 include/linux/vmalloc.h                    |    1 
 kernel/kexec_file.c                        |   36 ++++------------------
 kernel/module.c                            |    4 +-
 lib/test_hmm.c                             |    3 -
 mm/compaction.c                            |   17 ++++++++--
 mm/debug_vm_pgtable.c                      |    4 +-
 mm/memcontrol.c                            |   18 ++++++++---
 mm/memory.c                                |   33 +++++++++++++-------
 mm/memory_hotplug.c                        |   13 ++++++--
 mm/nommu.c                                 |   17 ----------
 mm/slab.h                                  |    4 +-
 mm/slab_common.c                           |    2 -
 mm/slub.c                                  |   19 ++---------
 mm/swap.c                                  |    3 -
 mm/swap_state.c                            |    4 +-
 mm/vmalloc.c                               |   21 -------------
 mm/vmscan.c                                |    3 +
 mm/workingset.c                            |   46 +++++++++++++++++------------
 36 files changed, 168 insertions(+), 163 deletions(-)
author maintainer
#1 lore raw

PATCH 1/32 openrisc: fix boot oops when DEBUG_VM is enabled

From: Stafford Horne <[email protected]>
Subject: openrisc: fix boot oops when DEBUG_VM is enabled

Since v5.8-rc1 OpenRISC Linux fails to boot when DEBUG_VM is enabled. This has been bisected to commit 42fc541404f2 ("mmap locking API: add mmap_assert_locked() and mmap_assert_write_locked()").

The added locking checks exposed the issue that OpenRISC was not taking this mmap lock when during page walks for DMA operations. This patch locks and unlocks the mmap lock for page walking.

Fixes 42fc541404f2 ("mmap locking API: add mmap_assert_locked() and mmap_assert_write_locked()"
Cc Jonas Bonn <[email protected]>
Cc Stefan Kristiansson <[email protected]>
Cc Jason Gunthorpe <[email protected]>
Cc Steven Price <[email protected]>
Cc Thomas Hellstrom <[email protected]>
Cc Robin Murphy <[email protected]>
Cc Vlastimil Babka <[email protected]>
Cc Daniel Jordan <[email protected]>

---

 arch/openrisc/kernel/dma.c |    5 +++++
 1 file changed, 5 insertions(+)
arch/openrisc/kernel/dma.c renamed from arch/openrisc/kernel/dma.c~openrisc-fix-boot-oops-when-debug_vm-is-enabled +5 -0
@@ -74,8 +74,11 @@ void *arch_dma_set_uncached(void *cpu_ad
 	 * We need to iterate through the pages, clearing the dcache for
 	 * them and setting the cache-inhibit bit.
 	 */
+	mmap_read_lock(&init_mm);
 	error = walk_page_range(&init_mm, va, va + size, &set_nocache_walk_ops,
 			NULL);
+	mmap_read_unlock(&init_mm);
+
 	if (error)
 		return ERR_PTR(error);
 	return cpu_addr;
@@ -85,9 +88,11 @@ void arch_dma_clear_uncached(void *cpu_a
 {
 	unsigned long va = (unsigned long)cpu_addr;
 
+	mmap_read_lock(&init_mm);
 	/* walk_page_range shouldn't be able to fail here */
 	WARN_ON(walk_page_range(&init_mm, va, va + size,
 			&clear_nocache_walk_ops, NULL));
+	mmap_read_unlock(&init_mm);
 }
 
 void arch_sync_dma_for_device(phys_addr_t addr, size_t size,

_

author maintainer
#2 lore raw

PATCH 2/32 mm: do_swap_page(): fix up the error code

In reply to Andrew Morton

From: Michal Hocko <[email protected]>
Subject: mm: do_swap_page(): fix up the error code

do_swap_page() returns error codes from the VM_FAULT* space. try_charge() might return -ENOMEM, though, and then do_swap_page() simply returns 0 which means a success.

We almost never return ENOMEM for GFP_KERNEL single page charge. Except for async OOM handling (oom_disabled v1). So this needs translation to VM_FAULT_OOM otherwise the the page fault path will not notify the userspace and wait for an action.

Fixes 4c6355b25e8b ("mm: memcontrol: charge swapin pages on instantiation")
Cc Alex Shi <[email protected]>
Cc Joonsoo Kim <[email protected]>
Cc Shakeel Butt <[email protected]>
Cc Hugh Dickins <[email protected]>
Cc "Kirill A. Shutemov" <[email protected]>
Cc Roman Gushchin <[email protected]>

---

 mm/memory.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
mm/memory.c renamed from mm/memory.c~mm-do_swap_page-fix-up-the-error-code-instantiation +3 -1
@@ -3140,8 +3140,10 @@ vm_fault_t do_swap_page(struct vm_fault
 				err = mem_cgroup_charge(page, vma->vm_mm,
 							GFP_KERNEL);
 				ClearPageSwapCache(page);
-				if (err)
+				if (err) {
+					ret = VM_FAULT_OOM;
 					goto out_page;
+				}
 
 				lru_cache_add(page);
 				swap_readpage(page, true);

_

author maintainer
#3 lore raw

PATCH 3/32 mm, compaction: make capture control handling safe wrt interrupts

In reply to Andrew Morton

From: Vlastimil Babka <[email protected]>
Subject: mm, compaction: make capture control handling safe wrt interrupts

Hugh reports:

: While stressing compaction, one run oopsed on NULL capc->cc in : __free_one_page()'s task_capc(zone): compact_zone_order() had been : interrupted, and a page was being freed in the return from interrupt. :
: Though you would not expect it from the source, both gccs I was using (a : 4.8.1 and a 7.5.0) had chosen to compile compact_zone_order() with the : ".cc = &cc" implemented by mov %rbx,-0xb0(%rbp) immediately before callq : compact_zone - long after the "current->capture_control = &capc". An : interrupt in between those finds capc->cc NULL (zeroed by an earlier rep : stos).
:
: This could presumably be fixed by a barrier() before setting
: current->capture_control in compact_zone_order(); but would also need more : care on return from compact_zone(), in order not to risk leaking a page : captured by interrupt just before capture_control is reset.
:
: Maybe that is the preferable fix, but I felt safer for task_capc() to : exclude the rather surprising possibility of capture at interrupt time.

I have checked that gcc10 also behaves the same.

The advantage of fix in compact_zone_order() is that we don't add another test in the page freeing hot path, and that it might prevent future problems if we stop exposing pointers to uninitialized structures in current task.

So this patch implements the suggestion for compact_zone_order() with barrier() (and WRITE_ONCE() to prevent store tearing) for setting current->capture_control, and prevents page leaking with WRITE_ONCE/READ_ONCE in the proper order.

Fixes 5e1f0f098b46 ("mm, compaction: capture a page under direct compaction")
Cc Alex Shi <[email protected]>
Cc Li Wang <[email protected]>
Cc Mel Gorman <[email protected]>
Cc <[email protected]> [5.1+]

---

 mm/compaction.c |   17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)
mm/compaction.c renamed from mm/compaction.c~mm-compaction-make-capture-control-handling-safe-wrt-interrupts +14 -3
@@ -2316,15 +2316,26 @@ static enum compact_result compact_zone_
 		.page = NULL,
 	};
 
-	current->capture_control = &capc;
+	/*
+	 * Make sure the structs are really initialized before we expose the
+	 * capture control, in case we are interrupted and the interrupt handler
+	 * frees a page.
+	 */
+	barrier();
+	WRITE_ONCE(current->capture_control, &capc);
 
 	ret = compact_zone(&cc, &capc);
 
 	VM_BUG_ON(!list_empty(&cc.freepages));
 	VM_BUG_ON(!list_empty(&cc.migratepages));
 
-	*capture = capc.page;
-	current->capture_control = NULL;
+	/*
+	 * Make sure we hide capture control first before we read the captured
+	 * page pointer, otherwise an interrupt could free and capture a page
+	 * and we would leak it.
+	 */
+	WRITE_ONCE(current->capture_control, NULL);
+	*capture = READ_ONCE(capc.page);
 
 	return ret;
 }

_

author maintainer
#4 lore raw

PATCH 4/32 kexec: do not verify the signature without the lockdown or mandatory signature

In reply to Andrew Morton

From: Lianbo Jiang <[email protected]>
Subject: kexec: do not verify the signature without the lockdown or mandatory signature

Signature verification is an important security feature, to protect system from being attacked with a kernel of unknown origin. Kexec rebooting is a way to replace the running kernel, hence need be secured carefully.

In the current code of handling signature verification of kexec kernel, the logic is very twisted. It mixes signature verification, IMA signature appraising and kexec lockdown.

If there is no KEXEC_SIG_FORCE, kexec kernel image doesn't have one of signature, the supported crypto, and key, we don't think this is wrong, Unless kexec lockdown is executed. IMA is considered as another kind of signature appraising method.

If kexec kernel image has signature/crypto/key, it has to go through the signature verification and pass. Otherwise it's seen as verification failure, and won't be loaded.

Seems kexec kernel image with an unqualified signature is even worse than those w/o signature at all, this sounds very unreasonable. E.g. If people get a unsigned kernel to load, or a kernel signed with expired key, which one is more dangerous?

So, here, let's simplify the logic to improve code readability. If the KEXEC_SIG_FORCE enabled or kexec lockdown enabled, signature verification is mandated. Otherwise, we lift the bar for any kernel image.

---

 kernel/kexec_file.c |   36 +++++++-----------------------------
 1 file changed, 7 insertions(+), 29 deletions(-)
kernel/kexec_file.c renamed from kernel/kexec_file.c~kexec-do-not-verify-the-signature-without-the-lockdown-or-mandatory-signature +5 -21
@@ -181,34 +181,19 @@ void kimage_file_post_load_cleanup(struc
 static int
 kimage_validate_signature(struct kimage *image)
 {
-	const char *reason;
 	int ret;
 
 	ret = arch_kexec_kernel_verify_sig(image, image->kernel_buf,
 					   image->kernel_buf_len);
-	switch (ret) {
-	case 0:
-		break;
-
-		/* Certain verification errors are non-fatal if we're not
-		 * checking errors, provided we aren't mandating that there
-		 * must be a valid signature.
-		 */
-	case -ENODATA:
-		reason = "kexec of unsigned image";
-		goto decide;
-	case -ENOPKG:
-		reason = "kexec of image with unsupported crypto";
-		goto decide;
-	case -ENOKEY:
-		reason = "kexec of image with unavailable key";
-	decide:
+	if (ret) {
+
 		if (IS_ENABLED(CONFIG_KEXEC_SIG_FORCE)) {
-			pr_notice("%s rejected\n", reason);
+			pr_notice("Enforced kernel signature verification failed (%d).\n", ret);
 			return ret;
 		}
 
-		/* If IMA is guaranteed to appraise a signature on the kexec
+		/*
+		 * If IMA is guaranteed to appraise a signature on the kexec
 		 * image, permit it even if the kernel is otherwise locked
 		 * down.
 		 */
@@ -216,17 +201,10 @@ kimage_validate_signature(struct kimage
 		    security_locked_down(LOCKDOWN_KEXEC))
 			return -EPERM;
 
-		return 0;
author maintainer
#5 lore raw

PATCH 5/32 ocfs2: avoid inode removal while nfsd is accessing it

In reply to Andrew Morton

From: Junxiao Bi <[email protected]>
Subject: ocfs2: avoid inode removal while nfsd is accessing it

Patch series "ocfs2: fix nfsd over ocfs2 issues", v2.

This is a series of patches to fix issues on nfsd over ocfs2. patch 1 is to avoid inode removed while nfsd access it patch 2 & 3 is to fix a panic issue.

This patch (of 4):

When nfsd is getting file dentry using handle or parent dentry of some dentry, one cluster lock is used to avoid inode removed from other node, but it still could be removed from local node, so use a rw lock to avoid this.

---

 fs/ocfs2/dlmglue.c |   17 ++++++++++++++++-
 fs/ocfs2/ocfs2.h   |    1 +
 2 files changed, 17 insertions(+), 1 deletion(-)
fs/ocfs2/dlmglue.c renamed from fs/ocfs2/dlmglue.c~ocfs2-avoid-inode-removed-while-nfsd-access-it +16 -1
@@ -689,6 +689,12 @@ static void ocfs2_nfs_sync_lock_res_init
 				   &ocfs2_nfs_sync_lops, osb);
 }
 
+static void ocfs2_nfs_sync_lock_init(struct ocfs2_super *osb)
+{
+	ocfs2_nfs_sync_lock_res_init(&osb->osb_nfs_sync_lockres, osb);
+	init_rwsem(&osb->nfs_sync_rwlock);
+}
+
 void ocfs2_trim_fs_lock_res_init(struct ocfs2_super *osb)
 {
 	struct ocfs2_lock_res *lockres = &osb->osb_trim_fs_lockres;
@@ -2855,6 +2861,11 @@ int ocfs2_nfs_sync_lock(struct ocfs2_sup
 	if (ocfs2_is_hard_readonly(osb))
 		return -EROFS;
 
+	if (ex)
+		down_write(&osb->nfs_sync_rwlock);
+	else
+		down_read(&osb->nfs_sync_rwlock);
+
 	if (ocfs2_mount_local(osb))
 		return 0;
 
@@ -2873,6 +2884,10 @@ void ocfs2_nfs_sync_unlock(struct ocfs2_
 	if (!ocfs2_mount_local(osb))
 		ocfs2_cluster_unlock(osb, lockres,
 				     ex ? LKM_EXMODE : LKM_PRMODE);
+	if (ex)
+		up_write(&osb->nfs_sync_rwlock);
+	else
+		up_read(&osb->nfs_sync_rwlock);
 }
 
 int ocfs2_trim_fs_lock(struct ocfs2_super *osb,
@@ -3340,7 +3355,7 @@ int ocfs2_dlm_init(struct ocfs2_super *o
 local:
 	ocfs2_super_lock_res_init(&osb->osb_super_lockres, osb);
 	ocfs2_rename_lock_res_init(&osb->osb_rename_lockres, osb);
-	ocfs2_nfs_sync_lock_res_init(&osb->osb_nfs_sync_lockres, osb);
+	ocfs2_nfs_sync_lock_init(osb);
 	ocfs2_orphan_scan_lock_res_init(&osb->osb_orphan_scan.os_lockres, osb);
 
 	osb->cconn = conn;
fs/ocfs2/ocfs2.h renamed from fs/ocfs2/ocfs2.h~ocfs2-avoid-inode-removed-while-nfsd-access-it +1 -0
@@ -395,6 +395,7 @@ struct ocfs2_super
 	struct ocfs2_lock_res osb_super_lockres;
 	struct ocfs2_lock_res osb_rename_lockres;
 	struct ocfs2_lock_res osb_nfs_sync_lockres;
+	struct rw_semaphore nfs_sync_rwlock;
 	struct ocfs2_lock_res osb_trim_fs_lockres;
 	struct mutex obs_trim_fs_mutex;
 	struct ocfs2_dlm_debug *osb_dlm_debug;

_

author maintainer
#6 lore raw

PATCH 6/32 ocfs2: load global_inode_alloc

In reply to Andrew Morton

From: Junxiao Bi <[email protected]>
Subject: ocfs2: load global_inode_alloc

Set global_inode_alloc as OCFS2_FIRST_ONLINE_SYSTEM_INODE, that will make it load during mount. It can be used to test whether some global/system inodes are valid. One use case is that nfsd will test whether root inode is valid.

---

 fs/ocfs2/ocfs2_fs.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/ocfs2/ocfs2_fs.h renamed from fs/ocfs2/ocfs2_fs.h~ocfs2-load-global_inode_alloc +1 -1
@@ -326,8 +326,8 @@ struct ocfs2_system_inode_info {
 enum {
 	BAD_BLOCK_SYSTEM_INODE = 0,
 	GLOBAL_INODE_ALLOC_SYSTEM_INODE,
+#define OCFS2_FIRST_ONLINE_SYSTEM_INODE GLOBAL_INODE_ALLOC_SYSTEM_INODE
 	SLOT_MAP_SYSTEM_INODE,
-#define OCFS2_FIRST_ONLINE_SYSTEM_INODE SLOT_MAP_SYSTEM_INODE
 	HEARTBEAT_SYSTEM_INODE,
 	GLOBAL_BITMAP_SYSTEM_INODE,
 	USER_QUOTA_SYSTEM_INODE,

_

author maintainer
#7 lore raw

PATCH 7/32 ocfs2: fix panic on nfs server over ocfs2

In reply to Andrew Morton

From: Junxiao Bi <[email protected]>
Subject: ocfs2: fix panic on nfs server over ocfs2

The following kernel panic was captured when running nfs server over ocfs2, at that time ocfs2_test_inode_bit() was checking whether one inode locating at "blkno" 5 was valid, that is ocfs2 root inode, its "suballoc_slot" was OCFS2_INVALID_SLOT(65535) and it was allocted from //global_inode_alloc, but here it wrongly assumed that it was got from per slot inode alloctor which would cause array overflow and trigger kernel panic.

[430033.469151] BUG: unable to handle kernel paging request at
0000000000001088
[430033.469367] IP: [<ffffffff816f6898>] _raw_spin_lock+0x18/0xf0
[430033.469567] PGD 1e06ba067 PUD 1e9e7d067 PMD 0
[430033.469769] Oops: 0002 [#1] SMP
[430033.469975] Modules linked in: tun nfsd lockd grace nfs_acl auth_rpcgss

ocfs2 xen_netback xen_blkback xen_gntalloc xen_gntdev xen_evtchn xenfs xen_privcmd ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bnx2fc fcoe libfcoe libfc sunrpc bridge 8021q mrp garp stp llc bonding dm_round_robin scsi_dh_emc dm_multipath iTCO_wdt iTCO_vendor_support pcspkr sb_edac edac_core i2c_i801 i2c_core lpc_ich mfd_core sg ext4 jbd2 mbcache2 sd_mod ahci libahci lpfc scsi_transport_fc be2net vxlan udp_tunnel ip6_udp_tunnel mpt3sas scsi_transport_sas raid_class crc32c_intel be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdio libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi dm_mirror dm_region_hash dm_log dm_mod

[430033.472350] CPU: 6 PID: 24873 Comm: nfsd Not tainted
4.1.12-124.36.1.el6uek.x86_64 #2
[430033.472719] Hardware name: Huawei CH121 V3/IT11SGCA1, BIOS 3.87
02/02/2018
[430033.472910] task: ffff88005ae98000 ti: ffff88005ae94000 task.ti:
ffff88005ae94000
[430033.473277] RIP: e030:[<ffffffff816f6898>]  [<ffffffff816f6898>]
_raw_spin_lock+0x18/0xf0
[430033.473655] RSP: e02b:ffff88005ae97908  EFLAGS: 00010206
[430033.473850] RAX: ffff88005ae98000 RBX: 0000000000001088 RCX:
0000000000000000
[430033.474205] RDX: 0000000000020000 RSI: 0000000000000009 RDI:
0000000000001088
[430033.474574] RBP: ffff88005ae97928 R08: 0000000000000000 R09:
ffff880212878e00
[430033.474938] R10: 0000000000007ff0 R11: 0000000000000000 R12:
0000000000001088
[430033.475324] R13: ffff8800063c0aa8 R14: ffff8800650c27d0 R15:
000000000000ffff
[430033.475721] FS:  0000000000000000(0000) GS:ffff880218180000(0000)
knlGS:ffff880218180000
[430033.476199] CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033
[430033.476390] CR2: 0000000000001088 CR3: 00000002033d0000 CR4:
0000000000042660
[430033.476760] Stack:
[430033.476942]  0000000000001000 0000000000001088 ffff8800063c0aa8
ffff8800650c27d0
[430033.477329]  ffff88005ae97948 ffffffff8122a3de 0000000000000009
ffff8800063c0000
[430033.477718]  ffff88005ae979e8 ffffffffc0714e43 ffff88005ae97968
ffff88019de8f958
[430033.478104] Call Trace:
[430033.478286]  [<ffffffff8122a3de>] igrab+0x1e/0x60
[430033.478494]  [<ffffffffc0714e43>] ocfs2_get_system_file_inode+0x63/0x3a0
[ocfs2]
[430033.478870]  [<ffffffffc06a87df>] ? ocfs2_read_blocks_sync+0x13f/0x3c0
[ocfs2]
[430033.479267]  [<ffffffffc06ff2d8>] ocfs2_test_inode_bit+0x328/0xa00
[ocfs2]
[430033.479498]  [<ffffffffc06bef5a>] ocfs2_get_parent+0xba/0x3e0 [ocfs2]
[430033.479730]  [<ffffffff8129b305>] reconnect_path+0xb5/0x300
[430033.479933]  [<ffffffff8129b646>] exportfs_decode_fh+0xf6/0x2b0
[430033.480124]  [<ffffffffc0814af0>] ? nfsd_proc_getattr+0xa0/0xa0 [nfsd]
[430033.480294]  [<ffffffffc081a682>] ? exp_find+0xe2/0x190 [nfsd]
[430033.480461]  [<ffffffff810e5a7e>] ? irq_get_irq_data+0xe/0x10
[430033.480627]  [<ffffffff810ea1a7>] ? __call_rcu_nocb_enqueue+0xd7/0xe0
[430033.480794]  [<ffffffff810eb9e8>] ? __call_rcu+0xe8/0x360
[430033.480959]  [<ffffffffc0815860>] fh_verify+0x350/0x660 [nfsd]
[430033.481134]  [<ffffffffc0535076>] ? cache_check+0x56/0x3a0 [sunrpc]
[430033.481317]  [<ffffffffc0823a4d>] nfsd4_putfh+0x4d/0x60 [nfsd]
[430033.481505]  [<ffffffffc0826003>] nfsd4_proc_compound+0x3d3/0x6f0 [nfsd]
[430033.481730]  [<ffffffffc0811f60>] nfsd_dispatch+0xe0/0x290 [nfsd]
[430033.481950]  [<ffffffffc052b752>] ? svc_tcp_adjust_wspace+0x12/0x30
[sunrpc]
[430033.482152]  [<ffffffffc052a512>] svc_process_common+0x412/0x6a0 [sunrpc]
[430033.482351]  [<ffffffffc052a8c3>] svc_process+0x123/0x210 [sunrpc]
[430033.482550]  [<ffffffffc081190f>] nfsd+0xff/0x170 [nfsd]
[430033.482744]  [<ffffffffc0811810>] ? nfsd_destroy+0x80/0x80 [nfsd]
[430033.482943]  [<ffffffff810a7aeb>] kthread+0xcb/0xf0
[430033.483151]  [<ffffffff816f10ea>] ? __schedule+0x24a/0x810
[430033.483354]  [<ffffffff816f10ea>] ? __schedule+0x24a/0x810
[430033.483553]  [<ffffffff810a7a20>] ? kthread_create_on_node+0x180/0x180
[430033.483777]  [<ffffffff816f72a1>] ret_from_fork+0x61/0x90
[430033.483976]  [<ffffffff810a7a20>] ? kthread_create_on_node+0x180/0x180
[430033.484191] Code: 83 c2 02 0f b7 f2 e8 18 dc 91 ff 66 90 eb bf 0f 1f 40
00 55 48 89 e5 41 56 41 55 41 54 53 0f 1f 44 00 00 48 89 fb ba 00 00 02 00
<f0> 0f c1 17 89 d0 45 31 e4 45 31 ed c1 e8 10 66 39 d0 41 89 c6
[430033.485174] RIP  [<ffffffff816f6898>] _raw_spin_lock+0x18/0xf0
[430033.485370]  RSP <ffff88005ae97908>
[430033.485566] CR2: 0000000000001088
[430033.486223] ---[ end trace 7264463cd1aac8f9 ]---
[430033.666368] Kernel panic - not syncing: Fatal exception

---

 fs/ocfs2/suballoc.c |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)
fs/ocfs2/suballoc.c renamed from fs/ocfs2/suballoc.c~ocfs2-fix-panic-on-nfs-server-over-ocfs2 +6 -3
@@ -2825,9 +2825,12 @@ int ocfs2_test_inode_bit(struct ocfs2_su
 		goto bail;
 	}
 
-	inode_alloc_inode =
-		ocfs2_get_system_file_inode(osb, INODE_ALLOC_SYSTEM_INODE,
-					    suballoc_slot);
+	if (suballoc_slot == (u16)OCFS2_INVALID_SLOT)
+		inode_alloc_inode = ocfs2_get_system_file_inode(osb,
+			GLOBAL_INODE_ALLOC_SYSTEM_INODE, suballoc_slot);
+	else
+		inode_alloc_inode = ocfs2_get_system_file_inode(osb,
+			INODE_ALLOC_SYSTEM_INODE, suballoc_slot);
 	if (!inode_alloc_inode) {
 		/* the error code could be inaccurate, but we are not able to
 		 * get the correct one. */

_

author maintainer
#8 lore raw

PATCH 8/32 ocfs2: fix value of OCFS2_INVALID_SLOT

In reply to Andrew Morton

From: Junxiao Bi <[email protected]>
Subject: ocfs2: fix value of OCFS2_INVALID_SLOT

In the ocfs2 disk layout, slot number is 16 bits, but in ocfs2 implementation, slot number is 32 bits. Usually this will not cause any issue, because slot number is converted from u16 to u32, but OCFS2_INVALID_SLOT was defined as -1, when an invalid slot number from disk was obtained, its value was (u16)-1, and it was converted to u32. Then the following checking in get_local_system_inode will be always skipped:

static struct inode **get_local_system_inode(struct ocfs2_super *osb,

                                               int type,
                                               u32 slot)
 {
 	BUG_ON(slot == OCFS2_INVALID_SLOT);
	...

}

---

 fs/ocfs2/ocfs2_fs.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/ocfs2/ocfs2_fs.h renamed from fs/ocfs2/ocfs2_fs.h~ocfs2-fix-value-of-ocfs2_invalid_slot +1 -1
@@ -290,7 +290,7 @@
 #define OCFS2_MAX_SLOTS			255
 
 /* Slot map indicator for an empty slot */
-#define OCFS2_INVALID_SLOT		-1
+#define OCFS2_INVALID_SLOT		((u16)-1)
 
 #define OCFS2_VOL_UUID_LEN		16
 #define OCFS2_MAX_VOL_LABEL_LEN		64

_

author maintainer
#9 lore raw

PATCH 9/32 lib: fix test_hmm.c reference after free

In reply to Andrew Morton

From: Randy Dunlap <[email protected]>
Subject: lib: fix test_hmm.c reference after free

Coccinelle scripts report the following errors:

lib/test_hmm.c:523:20-26: ERROR: reference preceded by free on line 521 lib/test_hmm.c:524:21-27: ERROR: reference preceded by free on line 521 lib/test_hmm.c:523:28-35: ERROR: devmem is NULL but dereferenced. lib/test_hmm.c:524:29-36: ERROR: devmem is NULL but dereferenced.

Fix these by using the local variable 'res' instead of devmem.

---

 lib/test_hmm.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
lib/test_hmm.c renamed from lib/test_hmm.c~lib-fix-test_hmmc-reference-after-free +1 -2
@@ -520,8 +520,7 @@ static bool dmirror_allocate_chunk(struc
 err_free:
 	kfree(devmem);
 err_release:
-	release_mem_region(devmem->pagemap.res.start,
-			   resource_size(&devmem->pagemap.res));
+	release_mem_region(res->start, resource_size(res));
 err:
 	mutex_unlock(&mdevice->devmem_lock);
 	return false;

_

author maintainer
#10 lore raw

PATCH 10/32 linux/bits.h: fix unsigned less than zero warnings

In reply to Andrew Morton

From: Rikard Falkeborn <[email protected]>
Subject: linux/bits.h: fix unsigned less than zero warnings

When calling the GENMASK and GENMASK_ULL macros with zero lower bit and an unsigned unknown high bit, some gcc versions warn due to the comparisons of the high and low bit in GENMASK_INPUT_CHECK.

To silence the warnings, only perform the check if both inputs are known. This does not trigger any warnings, from the Wtype-limits help:

Warn if a comparison is always true or always false due to the limited range of the data type, but do not warn for constant expressions.

As an example of the warning, kindly reported by the kbuild test robot:

from drivers/mfd/atmel-smc.c:11:
drivers/mfd/atmel-smc.c: In function 'atmel_smc_cs_encode_ncycles':
include/linux/bits.h:26:28: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
26 | __builtin_constant_p((l) > (h)), (l) > (h), 0)))
| ^
include/linux/build_bug.h:16:62: note: in definition of macro 'BUILD_BUG_ON_ZERO'
16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
| ^
include/linux/bits.h:39:3: note: in expansion of macro 'GENMASK_INPUT_CHECK'
39 | (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
| ^~~~~~~~~~~~~~~~~~~

Quoted 1 line
Quoted 1 line

drivers/mfd/atmel-smc.c:49:25: note: in expansion of macro 'GENMASK'

49 | unsigned int lsbmask = GENMASK(msbpos - 1, 0);
| ^~~~~~~

Fixes 295bcca84916 ("linux/bits.h: add compile time sanity check of GENMASK inputs")
Cc Arnd Bergmann <[email protected]>
Cc Geert Uytterhoeven <[email protected]>
Cc Kees Cook <[email protected]>
Cc Linus Walleij <[email protected]>
Cc William Breathitt Gray <[email protected]>
Cc Masahiro Yamada <[email protected]>

---

 include/linux/bits.h |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
include/linux/bits.h renamed from include/linux/bits.h~linux-bitsh-fix-unsigned-less-than-zero-warnings +2 -1
@@ -23,7 +23,8 @@
 #include <linux/build_bug.h>
 #define GENMASK_INPUT_CHECK(h, l) \
 	(BUILD_BUG_ON_ZERO(__builtin_choose_expr( \
-		__builtin_constant_p((l) > (h)), (l) > (h), 0)))
+		__builtin_constant_p(l) && __builtin_constant_p(h), \
+		(l) > (h), 0)))
 #else
 /*
  * BUILD_BUG_ON_ZERO is not available in h files included from asm files,

_

A message that is not in the archive (sent off-list or not yet received): CAHk-=wiZrhVUq3N17=GVzMQNQUKi65x=-djTM2A+fz8UdQxgEg@mail.gmail.com

A message that is not in the archive (sent off-list or not yet received): CADRDgG6SXwngT5gS2EY1Y0xnPdYth-FicQyTnPyqiwpmw52eQg@mail.gmail.com

#13 lore raw

Re: [patch 10/32] linux/bits.h: fix unsigned less than zero warnings

Quoted 1 line · Rikard Falkeborn

Den fre 26 juni 2020 08:32Linus Torvalds <[email protected]> skrev:

...

Quoted 1 line

I'll just say no and point to this email next time someone complains instead.

"No" is not constructive here. People can be annoyed with warning messages, but the real issue here are the various CI systems which send a lot of spam because of that. As a maintainer I would need to drop CI in order to see a good patch. If Linus considers that warning useless, then probably you can change your patch to do what he proposed.

Signature · 2 lines
With Best Regards,
Andy Shevchenko
maintainer
#14 lore raw

Re: [patch 10/32] linux/bits.h: fix unsigned less than zero warnings

Quoted 7 lines · Andy Shevchenko
Quoted 1 line · Rikard Falkeborn

Den fre 26 juni 2020 08:32Linus Torvalds <[email protected]> skrev:

...

Quoted 8 lines
Quoted 1 line

I'll just say no and point to this email next time someone complains instead.

"No" is not constructive here. People can be annoyed with warning messages, but the real issue here are the various CI systems which send a lot of spam because of that. As a maintainer I would need to drop CI in order to see a good patch. If Linus considers that warning useless, then probably you can change your patch to do what he proposed.

How about moving that warning from W=1 to W=2? Generally speaking I'd expect W=1 warnings to be in a category of "it's generally better to address this in the code, but we can't turn it on by default because the output gets too noisy", as opposed to W=2 meaning "this sometimes finds a real problem, but fixing the warning often makes code worse."

Arnd

#15 lore raw

Re: [patch 10/32] linux/bits.h: fix unsigned less than zero warnings

Quoted 17 lines · Arnd Bergmann
Quoted 6 lines · Andy Shevchenko
Quoted 1 line · Rikard Falkeborn

Den fre 26 juni 2020 08:32Linus Torvalds <[email protected]> skrev:

...

Quoted 8 lines
Quoted 1 line

I'll just say no and point to this email next time someone complains instead.

"No" is not constructive here. People can be annoyed with warning messages, but the real issue here are the various CI systems which send a lot of spam because of that. As a maintainer I would need to drop CI in order to see a good patch. If Linus considers that warning useless, then probably you can change your patch to do what he proposed.

Quoted 5 lines

How about moving that warning from W=1 to W=2? Generally speaking I'd expect W=1 warnings to be in a category of "it's generally better to address this in the code, but we can't turn it on by default because the output gets too noisy", as opposed to W=2 meaning "this sometimes finds a real problem, but fixing the warning often makes code worse."

It would work for me if it had been
a) documented (I didn't check if it had been already done, though);
b) understood by all CIs in the same way (see a) as well :-).

That said, I like any compromise that will reduce unneeded spam for submitted patches from CIs and, as a bonus, get rid of warnings in my local compilations (yes, I usually do W=1).

Signature · 2 lines
With Best Regards,
Andy Shevchenko
maintainer
#16 lore raw

Re: [patch 10/32] linux/bits.h: fix unsigned less than zero warnings

Quoted 25 lines · Andy Shevchenko
Quoted 17 lines · Arnd Bergmann
Quoted 6 lines · Andy Shevchenko
Quoted 1 line · Rikard Falkeborn

Den fre 26 juni 2020 08:32Linus Torvalds <[email protected]> skrev:

...

Quoted 8 lines
Quoted 1 line

I'll just say no and point to this email next time someone complains instead.

"No" is not constructive here. People can be annoyed with warning messages, but the real issue here are the various CI systems which send a lot of spam because of that. As a maintainer I would need to drop CI in order to see a good patch. If Linus considers that warning useless, then probably you can change your patch to do what he proposed.

Quoted 5 lines

How about moving that warning from W=1 to W=2? Generally speaking I'd expect W=1 warnings to be in a category of "it's generally better to address this in the code, but we can't turn it on by default because the output gets too noisy", as opposed to W=2 meaning "this sometimes finds a real problem, but fixing the warning often makes code worse."

Quoted 3 lines

It would work for me if it had been
a) documented (I didn't check if it had been already done, though);
b) understood by all CIs in the same way (see a) as well :-).

I checked the 'make help' output, which describes them as

make W=n [targets] Enable extra build checks, n=1,2,3 where
1: warnings which may be relevant and do not occur too often 2: warnings which occur quite often but may still be relevant 3: more obscure warnings, can most likely be ignored Multiple levels can be combined with W=12 or W=123

which is less specific than the interpretation I had in mind but I think still fits a).

Arnd

#17 lore raw

Re: [patch 10/32] linux/bits.h: fix unsigned less than zero warnings

Quoted 10 lines · Arnd Bergmann
Quoted 5 lines · Andy Shevchenko

On Fri, Jun 26, 2020 at 5:03 PM Arnd Bergmann <[email protected]> wrote:
It would work for me if it had been
a) documented (I didn't check if it had been already done, though);
b) understood by all CIs in the same way (see a) as well :-).

I checked the 'make help' output, which describes them as

Quoted 8 lines

make W=n [targets] Enable extra build checks, n=1,2,3 where
1: warnings which may be relevant and do not occur too often 2: warnings which occur quite often but may still be relevant 3: more obscure warnings, can most likely be ignored Multiple levels can be combined with W=12 or W=123

which is less specific than the interpretation I had in mind but I think still fits a).

How about tweaking this as:

make W=n [targets] Enable extra build checks, n=1,2,3 where
1: warnings which may be relevant and do not occur too often
and can normally be fixed in code. (Reasonable for CIs to use without generating too much spam.)
2: warnings which occur quite often but may still be relevant
to developers looking for ways to improve compilers or looking for very special cases. (Not usually a good idea for automated systems.)
3: more obscure warnings, can most likely be ignored but have
value to some very narrow areas of code/compiler analysis. Very noisy!

Signature · 1 line
Kees Cook
#18 lore raw

Re: [patch 10/32] linux/bits.h: fix unsigned less than zero warnings

In reply to Arnd Bergmann
Quoted 2 lines · Arnd Bergmann

How about moving that warning from W=1 to W=2?

That sounds like the right thing to do, perhaps with some extra warnings about W=2 (and W=3) being things that you definitely shouldn't be running in automated environments (unless you are then very very careful to look very critically at the warnings).

Linus

#19 lore raw

PATCH 1/1 kbuild: Move -Wtype-limits to W=2

-Wtype-limits is included in -Wextra which is added at W=1. It warns (among other things) that 'comparison of an unsigned variable < 0 is always false. This causes noisy warnings, especially when used in macros, hence it is more suitable for W=2.

---
See also discussion at https://lore.kernel.org/lkml/CAHk-=wiKCXEWKJ9dWUimGbrVRo_N2RosESUw8E7m9AEtyZcu=w@mail.gmail.com/

 scripts/Makefile.extrawarn | 2 ++
 1 file changed, 2 insertions(+)
scripts/Makefile.extrawarn +2 -0
index 4aea7cf71d11..62c275685b75 100644
@@ -35,6 +35,7 @@ KBUILD_CFLAGS += $(call cc-option, -Wstringop-truncation)
 # The following turn off the warnings enabled by -Wextra
 KBUILD_CFLAGS += -Wno-missing-field-initializers
 KBUILD_CFLAGS += -Wno-sign-compare
+KBUILD_CFLAGS += -Wno-type-limits
 
 KBUILD_CPPFLAGS += -DKBUILD_EXTRA_WARN1
 
@@ -66,6 +67,7 @@ KBUILD_CFLAGS += -Wshadow
 KBUILD_CFLAGS += $(call cc-option, -Wlogical-op)
 KBUILD_CFLAGS += -Wmissing-field-initializers
 KBUILD_CFLAGS += -Wsign-compare
+KBUILD_CFLAGS += -Wtype-limits
 KBUILD_CFLAGS += $(call cc-option, -Wmaybe-uninitialized)
 KBUILD_CFLAGS += $(call cc-option, -Wunused-macros)
 
Signature · 1 line
2.27.0
#20 lore raw

Re: [PATCH] kbuild: Move -Wtype-limits to W=2

Quoted 6 lines · Rikard Falkeborn

-Wtype-limits is included in -Wextra which is added at W=1. It warns (among other things) that 'comparison of an unsigned variable < 0 is always false. This causes noisy warnings, especially when used in macros, hence it is more suitable for W=2.

Suggested-by Arnd ?

LGTM!

Quoted 30 lines

---
See also discussion at https://lore.kernel.org/lkml/CAHk-=wiKCXEWKJ9dWUimGbrVRo_N2RosESUw8E7m9AEtyZcu=w@mail.gmail.com/

 scripts/Makefile.extrawarn | 2 ++
 1 file changed, 2 insertions(+)
scripts/Makefile.extrawarn +2 -1
index 4aea7cf71d11..62c275685b75 100644
@@ -35,6 +35,7 @@ KBUILD_CFLAGS += $(call cc-option, -Wstringop-truncation)
 # The following turn off the warnings enabled by -Wextra
 KBUILD_CFLAGS += -Wno-missing-field-initializers
 KBUILD_CFLAGS += -Wno-sign-compare
+KBUILD_CFLAGS += -Wno-type-limits
 
 KBUILD_CPPFLAGS += -DKBUILD_EXTRA_WARN1
 
@@ -66,6 +67,7 @@ KBUILD_CFLAGS += -Wshadow
 KBUILD_CFLAGS += $(call cc-option, -Wlogical-op)
 KBUILD_CFLAGS += -Wmissing-field-initializers
 KBUILD_CFLAGS += -Wsign-compare
+KBUILD_CFLAGS += -Wtype-limits
 KBUILD_CFLAGS += $(call cc-option, -Wmaybe-uninitialized)
 KBUILD_CFLAGS += $(call cc-option, -Wunused-macros)
 
--

2.27.0

Signature · 2 lines
With Best Regards,
Andy Shevchenko
author maintainer
#21 lore raw

PATCH 11/32 mm, slab: fix sign conversion problem in memcg_uncharge_slab()

In reply to Andrew Morton

From: Waiman Long <[email protected]>
Subject: mm, slab: fix sign conversion problem in memcg_uncharge_slab()

It was found that running the LTP test on a PowerPC system could produce erroneous values in /proc/meminfo, like:

  MemTotal:       531915072 kB
  MemFree:        507962176 kB
  MemAvailable:   1100020596352 kB

Using bisection, the problem is tracked down to commit 9c315e4d7d8c ("mm:
memcg/slab: cache page number in memcg_(un)charge_slab()").

In memcg_uncharge_slab() with a "int order" argument:

  unsigned int nr_pages = 1 << order;
    :
  mod_lruvec_state(lruvec, cache_vmstat_idx(s), -nr_pages);

The mod_lruvec_state() function will eventually call the __mod_zone_page_state() which accepts a long argument. Depending on the compiler and how inlining is done, "-nr_pages" may be treated as a negative number or a very large positive number. Apparently, it was treated as a large positive number in that PowerPC system leading to incorrect stat counts. This problem hasn't been seen in x86-64 yet, perhaps the gcc compiler there has some slight difference in behavior.

It is fixed by making nr_pages a signed value. For consistency, a similar change is applied to memcg_charge_slab() as well.

Fixes 9c315e4d7d8c ("mm: memcg/slab: cache page number in memcg_(un)charge_slab()").
Cc Christoph Lameter <[email protected]>
Cc Pekka Enberg <[email protected]>
Cc David Rientjes <[email protected]>
Cc Joonsoo Kim <[email protected]>
Cc Shakeel Butt <[email protected]>
Cc Johannes Weiner <[email protected]>
Cc Michal Hocko <[email protected]>
Cc Vladimir Davydov <[email protected]>

---

 mm/slab.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
mm/slab.h renamed from mm/slab.h~mm-slab-fix-sign-conversion-problem-in-memcg_uncharge_slab +2 -2
@@ -348,7 +348,7 @@ static __always_inline int memcg_charge_
 					     gfp_t gfp, int order,
 					     struct kmem_cache *s)
 {
-	unsigned int nr_pages = 1 << order;
+	int nr_pages = 1 << order;
 	struct mem_cgroup *memcg;
 	struct lruvec *lruvec;
 	int ret;
@@ -388,7 +388,7 @@ out:
 static __always_inline void memcg_uncharge_slab(struct page *page, int order,
 						struct kmem_cache *s)
 {
-	unsigned int nr_pages = 1 << order;
+	int nr_pages = 1 << order;
 	struct mem_cgroup *memcg;
 	struct lruvec *lruvec;
 

_

author maintainer
#22 lore raw

PATCH 11/32 mm, slab: fix sign conversion problem in memcg_uncharge_slab()

In reply to Andrew Morton

From: Waiman Long <[email protected]>
Subject: mm, slab: fix sign conversion problem in memcg_uncharge_slab()

It was found that running the LTP test on a PowerPC system could produce erroneous values in /proc/meminfo, like:

  MemTotal:       531915072 kB
  MemFree:        507962176 kB
  MemAvailable:   1100020596352 kB

Using bisection, the problem is tracked down to commit 9c315e4d7d8c ("mm:
memcg/slab: cache page number in memcg_(un)charge_slab()").

In memcg_uncharge_slab() with a "int order" argument:

  unsigned int nr_pages = 1 << order;
    :
  mod_lruvec_state(lruvec, cache_vmstat_idx(s), -nr_pages);

The mod_lruvec_state() function will eventually call the __mod_zone_page_state() which accepts a long argument. Depending on the compiler and how inlining is done, "-nr_pages" may be treated as a negative number or a very large positive number. Apparently, it was treated as a large positive number in that PowerPC system leading to incorrect stat counts. This problem hasn't been seen in x86-64 yet, perhaps the gcc compiler there has some slight difference in behavior.

It is fixed by making nr_pages a signed value. For consistency, a similar change is applied to memcg_charge_slab() as well.

Fixes 9c315e4d7d8c ("mm: memcg/slab: cache page number in memcg_(un)charge_slab()").
Cc Christoph Lameter <[email protected]>
Cc Pekka Enberg <[email protected]>
Cc David Rientjes <[email protected]>
Cc Joonsoo Kim <[email protected]>
Cc Shakeel Butt <[email protected]>
Cc Johannes Weiner <[email protected]>
Cc Michal Hocko <[email protected]>
Cc Vladimir Davydov <[email protected]>

---

 mm/slab.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
mm/slab.h renamed from mm/slab.h~mm-slab-fix-sign-conversion-problem-in-memcg_uncharge_slab +2 -2
@@ -348,7 +348,7 @@ static __always_inline int memcg_charge_
 					     gfp_t gfp, int order,
 					     struct kmem_cache *s)
 {
-	unsigned int nr_pages = 1 << order;
+	int nr_pages = 1 << order;
 	struct mem_cgroup *memcg;
 	struct lruvec *lruvec;
 	int ret;
@@ -388,7 +388,7 @@ out:
 static __always_inline void memcg_uncharge_slab(struct page *page, int order,
 						struct kmem_cache *s)
 {
-	unsigned int nr_pages = 1 << order;
+	int nr_pages = 1 << order;
 	struct mem_cgroup *memcg;
 	struct lruvec *lruvec;
 

_

author maintainer
#23 lore raw

PATCH 12/32 mm/slab: use memzero_explicit() in kzfree()

In reply to Andrew Morton

From: Waiman Long <[email protected]>
Subject: mm/slab: use memzero_explicit() in kzfree()

The kzfree() function is normally used to clear some sensitive information, like encryption keys, in the buffer before freeing it back to the pool. Memset() is currently used for buffer clearing. However unlikely, there is still a non-zero probability that the compiler may choose to optimize away the memory clearing especially if LTO is being used in the future. To make sure that this optimization will never happen, memzero_explicit(), which is introduced in v3.18, is now used in kzfree() to future-proof it.

Fixes 3ef0e5ba4673 ("slab: introduce kzfree()")
Cc David Howells <[email protected]>
Cc Jarkko Sakkinen <[email protected]>
Cc James Morris <[email protected]>
Cc "Serge E. Hallyn" <[email protected]>
Cc Joe Perches <[email protected]>
Cc Matthew Wilcox <[email protected]>
Cc David Rientjes <[email protected]>
Cc Johannes Weiner <[email protected]>
Cc Dan Carpenter <[email protected]>
Cc "Jason A . Donenfeld" <[email protected]>

---

 mm/slab_common.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
mm/slab_common.c renamed from mm/slab_common.c~mm-slab-use-memzero_explicit-in-kzfree +1 -1
@@ -1726,7 +1726,7 @@ void kzfree(const void *p)
 	if (unlikely(ZERO_OR_NULL_PTR(mem)))
 		return;
 	ks = ksize(mem);
-	memset(mem, 0, ks);
+	memzero_explicit(mem, ks);
 	kfree(mem);
 }
 EXPORT_SYMBOL(kzfree);

_

author maintainer
#24 lore raw

PATCH 13/32 slub: cure list_slab_objects() from double fix

In reply to Andrew Morton

From: Sebastian Andrzej Siewior <[email protected]>
Subject: slub: cure list_slab_objects() from double fix

According to Christopher Lameter two fixes have been merged for the same problem. As far as I can tell, the code does not acquire the list_lock and invoke kmalloc(). list_slab_objects() misses an unlock (the counterpart to get_map()) and the memory allocated in free_partial() isn't used.

Revert the mentioned commit.

Fixes aa456c7aebb14 ("slub: remove kmalloc under list_lock from list_slab_objects() V2")
Cc Pekka Enberg <[email protected]>
Cc David Rientjes <[email protected]>
Cc Joonsoo Kim <[email protected]>
Cc Thomas Gleixner <[email protected]>
Cc Yu Zhao <[email protected]>

---

 mm/slub.c |   19 ++++---------------
 1 file changed, 4 insertions(+), 15 deletions(-)
mm/slub.c renamed from mm/slub.c~slub-cure-list_slab_objects-from-double-fix +4 -14
@@ -3766,15 +3766,13 @@ error:
 }
 
 static void list_slab_objects(struct kmem_cache *s, struct page *page,
-			      const char *text, unsigned long *map)
+			      const char *text)
 {
 #ifdef CONFIG_SLUB_DEBUG
 	void *addr = page_address(page);
+	unsigned long *map;
 	void *p;
 
-	if (!map)
-		return;
-
 	slab_err(s, page, text, s->name);
 	slab_lock(page);
 
@@ -3786,6 +3784,7 @@ static void list_slab_objects(struct kme
 			print_tracking(s, p);
 		}
 	}
+	put_map(map);
 	slab_unlock(page);
 #endif
 }
@@ -3799,11 +3798,6 @@ static void free_partial(struct kmem_cac
 {
 	LIST_HEAD(discard);
 	struct page *page, *h;
-	unsigned long *map = NULL;
-
-#ifdef CONFIG_SLUB_DEBUG
-	map = bitmap_alloc(oo_objects(s->max), GFP_KERNEL);
-#endif
 
 	BUG_ON(irqs_disabled());
 	spin_lock_irq(&n->list_lock);
@@ -3813,16 +3807,11 @@ static void free_partial(struct kmem_cac
 			list_add(&page->slab_list, &discard);
 		} else {
 			list_slab_objects(s, page,
-			  "Objects remaining in %s on __kmem_cache_shutdown()",
-			  map);
+			  "Objects remaining in %s on __kmem_cache_shutdown()");
 		}
 	}
 	spin_unlock_irq(&n->list_lock);
 
-#ifdef CONFIG_SLUB_DEBUG
-	bitmap_free(map);
-#endif
author maintainer
#25 lore raw

PATCH 14/32 mm: fix swap cache node allocation mask

In reply to Andrew Morton

From: Hugh Dickins <[email protected]>
Subject: mm: fix swap cache node allocation mask

https://bugzilla.kernel.org/show_bug.cgi?id=208085 reports that a slightly overcommitted load, testing swap and zram along with i915, splats and keeps on splatting, when it had better fail less noisily:

gnome-shell: page allocation failure: order:0, mode:0x400d0(__GFP_IO|__GFP_FS|__GFP_COMP|__GFP_RECLAIMABLE), nodemask=(null),cpuset=/,mems_allowed=0

CPU: 2 PID: 1155 Comm: gnome-shell Not tainted 5.7.0-1.fc33.x86_64 #1
Call Trace:
dump_stack+0x64/0x88
warn_alloc.cold+0x75/0xd9
__alloc_pages_slowpath.constprop.0+0xcfa/0xd30
__alloc_pages_nodemask+0x2df/0x320
alloc_slab_page+0x195/0x310
allocate_slab+0x3c5/0x440
___slab_alloc+0x40c/0x5f0
__slab_alloc+0x1c/0x30
kmem_cache_alloc+0x20e/0x220
xas_nomem+0x28/0x70
add_to_swap_cache+0x321/0x400
__read_swap_cache_async+0x105/0x240
swap_cluster_readahead+0x22c/0x2e0
shmem_swapin+0x8e/0xc0
shmem_swapin_page+0x196/0x740
shmem_getpage_gfp+0x3a2/0xa60
shmem_read_mapping_page_gfp+0x32/0x60
shmem_get_pages+0x155/0x5e0 [i915]
__i915_gem_object_get_pages+0x68/0xa0 [i915]
i915_vma_pin+0x3fe/0x6c0 [i915]
eb_add_vma+0x10b/0x2c0 [i915]
i915_gem_do_execbuffer+0x704/0x3430 [i915]
i915_gem_execbuffer2_ioctl+0x1ea/0x3e0 [i915]
drm_ioctl_kernel+0x86/0xd0 [drm]
drm_ioctl+0x206/0x390 [drm]
ksys_ioctl+0x82/0xc0
__x64_sys_ioctl+0x16/0x20
do_syscall_64+0x5b/0xf0
entry_SYSCALL_64_after_hwframe+0x44/0xa9

Reported on 5.7, but it goes back really to 3.1: when shmem_read_mapping_page_gfp() was implemented for use by i915, and allowed for __GFP_NORETRY and __GFP_NOWARN flags in most places, but missed swapin's "& GFP_KERNEL" mask for page tree node allocation in __read_swap_cache_async() - that was to mask off HIGHUSER_MOVABLE bits from what page cache uses, but GFP_RECLAIM_MASK is now what's needed.

---

 mm/swap_state.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
mm/swap_state.c renamed from mm/swap_state.c~mm-fix-swap-cache-node-allocation-mask +0 -0
@@ -21,7 +21,7 @@
 #include <linux/vmalloc.h>
 #include <linux/swap_slots.h>
 #include <linux/huge_mm.h>
author maintainer
#26 lore raw

PATCH 15/32 mm/memory.c: properly pte_offset_map_lock/unlock in vm_insert_pages()

In reply to Andrew Morton

From: Arjun Roy <[email protected]>
Subject: mm/memory.c: properly pte_offset_map_lock/unlock in vm_insert_pages()

Calls to pte_offset_map() in vm_insert_pages() are erroneously not matched with a call to pte_unmap(). This would cause problems on architectures where that is not a no-op.

This patch does away with the non-traditional locking in the existing code, and instead uses pte_offset_map_lock/unlock() as usual, incrementing PTE as necessary. The PTE pointer is kept within bounds since we clamp it with PTRS_PER_PTE.

Fixes 8cd3984d81d5 ("mm/memory.c: add vm_insert_pages()")
Cc Eric Dumazet <[email protected]>
Cc Hugh Dickins <[email protected]>
Cc Soheil Hassas Yeganeh <[email protected]>

---

 mm/memory.c |   21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)
mm/memory.c renamed from mm/memory.c~mm-memoryc-properly-pte_offset_map_lock-unlock-in-vm_insert_pages +11 -10
@@ -1498,7 +1498,7 @@ out:
 }
 
 #ifdef pte_index
-static int insert_page_in_batch_locked(struct mm_struct *mm, pmd_t *pmd,
+static int insert_page_in_batch_locked(struct mm_struct *mm, pte_t *pte,
 			unsigned long addr, struct page *page, pgprot_t prot)
 {
 	int err;
@@ -1506,8 +1506,9 @@ static int insert_page_in_batch_locked(s
 	if (!page_count(page))
 		return -EINVAL;
 	err = validate_page_before_insert(page);
-	return err ? err : insert_page_into_pte_locked(
-		mm, pte_offset_map(pmd, addr), addr, page, prot);
+	if (err)
+		return err;
+	return insert_page_into_pte_locked(mm, pte, addr, page, prot);
 }
 
 /* insert_pages() amortizes the cost of spinlock operations
@@ -1517,7 +1518,8 @@ static int insert_pages(struct vm_area_s
 			struct page **pages, unsigned long *num, pgprot_t prot)
 {
 	pmd_t *pmd = NULL;
-	spinlock_t *pte_lock = NULL;
+	pte_t *start_pte, *pte;
+	spinlock_t *pte_lock;
 	struct mm_struct *const mm = vma->vm_mm;
 	unsigned long curr_page_idx = 0;
 	unsigned long remaining_pages_total = *num;
@@ -1536,18 +1538,17 @@ more:
 	ret = -ENOMEM;
 	if (pte_alloc(mm, pmd))
 		goto out;
-	pte_lock = pte_lockptr(mm, pmd);
 
 	while (pages_to_write_in_pmd) {
 		int pte_idx = 0;
 		const int batch_size = min_t(int, pages_to_write_in_pmd, 8);
 
-		spin_lock(pte_lock);
-		for (; pte_idx < batch_size; ++pte_idx) {
-			int err = insert_page_in_batch_locked(mm, pmd,
+		start_pte = pte_offset_map_lock(mm, pmd, addr, &pte_lock);
+		for (pte = start_pte; pte_idx < batch_size; ++pte, ++pte_idx) {
+			int err = insert_page_in_batch_locked(mm, pte,
 				addr, pages[curr_page_idx], prot);
 			if (unlikely(err)) {
-				spin_unlock(pte_lock);
+				pte_unmap_unlock(start_pte, pte_lock);
 				ret = err;
 				remaining_pages_total -= pte_idx;
 				goto out;
@@ -1555,7 +1556,7 @@ more:
 			addr += PAGE_SIZE;
 			++curr_page_idx;
 		}
-		spin_unlock(pte_lock);
+		pte_unmap_unlock(start_pte, pte_lock);
 		pages_to_write_in_pmd -= batch_size;
 		remaining_pages_total -= batch_size;
 	}

_

author maintainer
#27 lore raw

PATCH 16/32 mm/debug_vm_pgtable: fix build failure with powerpc 8xx

In reply to Andrew Morton

From: Christophe Leroy <[email protected]>
Subject: mm/debug_vm_pgtable: fix build failure with powerpc 8xx

Since commit 9e343b467c70 ("READ_ONCE: Enforce atomicity for {READ,WRITE}_ONCE() memory accesses"), READ_ONCE() cannot be used anymore to read complex page table entries. This leads to:

CC mm/debug_vm_pgtable.o
In file included from ./include/asm-generic/bug.h:5,

                 from ./arch/powerpc/include/asm/bug.h:109,
                 from ./include/linux/bug.h:5,
                 from ./include/linux/mmdebug.h:5,
                 from ./include/linux/gfp.h:5,
                 from mm/debug_vm_pgtable.c:13:

In function 'pte_clear_tests',
inlined from 'debug_vm_pgtable' at mm/debug_vm_pgtable.c:363:2:
./include/linux/compiler.h:392:38: error: call to '__compiletime_assert_210' declared with attribute error: Unsupported access size for {READ,WRITE}_ONCE().
392 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^
./include/linux/compiler.h:373:4: note: in definition of macro '__compiletime_assert'

  373 |    prefix ## suffix();    \
      |    ^~~~~~
./include/linux/compiler.h:392:2: note: in expansion of macro '_compiletime_assert'
  392 |  _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
      |  ^~~~~~~~~~~~~~~~~~~
./include/linux/compiler.h:405:2: note: in expansion of macro 'compiletime_assert'
  405 |  compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long long), \
      |  ^~~~~~~~~~~~~~~~~~
./include/linux/compiler.h:291:2: note: in expansion of macro 'compiletime_assert_rwonce_type'
  291 |  compiletime_assert_rwonce_type(x);    \
      |  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mm/debug_vm_pgtable.c:249:14: note: in expansion of macro 'READ_ONCE'
  249 |  pte_t pte = READ_ONCE(*ptep);
      |              ^~~~~~~~~

make[2]: *** [mm/debug_vm_pgtable.o] Error 1

Fix it by using the recently added ptep_get() helper.

Fixes 9e343b467c70 ("READ_ONCE: Enforce atomicity for {READ,WRITE}_ONCE() memory accesses")
Cc Benjamin Herrenschmidt <[email protected]>
Cc Paul Mackerras <[email protected]>
Cc Michael Ellerman <[email protected]>
Cc "Peter Zijlstra (Intel)" <[email protected]>

---

 mm/debug_vm_pgtable.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
mm/debug_vm_pgtable.c renamed from mm/debug_vm_pgtable.c~mm-debug_vm_pgtable-fix-build-failure-with-powerpc-8xx +2 -2
@@ -246,13 +246,13 @@ static void __init pgd_populate_tests(st
 static void __init pte_clear_tests(struct mm_struct *mm, pte_t *ptep,
 				   unsigned long vaddr)
 {
-	pte_t pte = READ_ONCE(*ptep);
+	pte_t pte = ptep_get(ptep);
 
 	pte = __pte(pte_val(pte) | RANDOM_ORVALUE);
 	set_pte_at(mm, vaddr, ptep, pte);
 	barrier();
 	pte_clear(mm, vaddr, ptep);
-	pte = READ_ONCE(*ptep);
+	pte = ptep_get(ptep);
 	WARN_ON(!pte_none(pte));
 }
 

_

author maintainer
#28 lore raw

PATCH 17/32 make asm-generic/cacheflush.h more standalone

In reply to Andrew Morton

From: Stephen Rothwell <[email protected]>
Subject: make asm-generic/cacheflush.h more standalone

Some s390 builds get these warnings:

include/asm-generic/cacheflush.h:16:42: warning: 'struct mm_struct' declared inside parameter list will not be visible outside of this definition or declaration include/asm-generic/cacheflush.h:22:46: warning: 'struct mm_struct' declared inside parameter list will not be visible outside of this definition or declaration include/asm-generic/cacheflush.h:28:45: warning: 'struct vm_area_struct' declared inside parameter list will not be visible outside of this definition or declaration include/asm-generic/cacheflush.h:36:44: warning: 'struct vm_area_struct' declared inside parameter list will not be visible outside of this definition or declaration include/asm-generic/cacheflush.h:44:45: warning: 'struct page' declared inside parameter list will not be visible outside of this definition or declaration include/asm-generic/cacheflush.h:52:50: warning: 'struct address_space' declared inside parameter list will not be visible outside of this definition or declaration include/asm-generic/cacheflush.h:58:52: warning: 'struct address_space' declared inside parameter list will not be visible outside of this definition or declaration include/asm-generic/cacheflush.h:75:17: warning: 'struct page' declared inside parameter list will not be visible outside of this definition or declaration include/asm-generic/cacheflush.h:74:45: warning: 'struct vm_area_struct' declared inside parameter list will not be visible outside of this definition or declaration include/asm-generic/cacheflush.h:82:16: warning: 'struct page' declared inside parameter list will not be visible outside of this definition or declaration include/asm-generic/cacheflush.h:81:50: warning: 'struct vm_area_struct' declared inside parameter list will not be visible outside of this definition or declaration

Forward declare the named structs to get rid of these.

Fixes e0cf615d725c ("asm-generic: don't include <linux/mm.h> in cacheflush.h")
Cc Heiko Carstens <[email protected]>
Cc Vasily Gorbik <[email protected]>
Cc Christian Borntraeger <[email protected]>

---

 include/asm-generic/cacheflush.h |    5 +++++
 1 file changed, 5 insertions(+)
include/asm-generic/cacheflush.h renamed from include/asm-generic/cacheflush.h~make-asm-generic-cacheflushh-more-standalone +5 -0
@@ -2,6 +2,11 @@
 #ifndef _ASM_GENERIC_CACHEFLUSH_H
 #define _ASM_GENERIC_CACHEFLUSH_H
 
+struct mm_struct;
+struct vm_area_struct;
+struct page;
+struct address_space;
+
 /*
  * The cache doesn't need to be flushed when TLB entries change when
  * the cache is mapped to physical memory, not virtual memory

_

author maintainer
#29 lore raw

PATCH 18/32 media: omap3isp: remove cacheflush.h

In reply to Andrew Morton

From: Nathan Chancellor <[email protected]>
Subject: media: omap3isp: remove cacheflush.h

After mm.h was removed from the asm-generic version of cacheflush.h, s390 allyesconfig shows several warnings of the following nature:

In file included from ./arch/s390/include/generated/asm/cacheflush.h:1,
from drivers/media/platform/omap3isp/isp.c:42:
./include/asm-generic/cacheflush.h:16:42: warning: 'struct mm_struct' declared inside parameter list will not be visible outside of this definition or declaration

As Geert and Laurent point out, this driver does not need this header in the two files that include it. Remove it so there are no warnings.

---

 drivers/media/platform/omap3isp/isp.c      |    2 --
 drivers/media/platform/omap3isp/ispvideo.c |    1 -
 2 files changed, 3 deletions(-)
drivers/media/platform/omap3isp/isp.c renamed from drivers/media/platform/omap3isp/isp.c~media-omap3isp-remove-cacheflushh +0 -1
@@ -39,8 +39,6 @@
  *	Troy Laramy <[email protected]>
  */
 
-#include <asm/cacheflush.h>
author maintainer
#30 lore raw

PATCH 19/32 mm/vmalloc.c: fix a warning while make xmldocs

In reply to Andrew Morton

From: Masanari Iida <[email protected]>
Subject: mm/vmalloc.c: fix a warning while make xmldocs

This patch fixes following warning while "make xmldocs"

./mm/vmalloc.c:1877: warning: Excess function parameter 'prot' description in 'vm_map_ram'

This warning started since a patch was merged in 5.8-rc1.

Fixes d4efd79a81ab ("mm: remove the prot argument from vm_map_ram")

---

 mm/vmalloc.c |    1 -
 1 file changed, 1 deletion(-)
mm/vmalloc.c renamed from mm/vmalloc.c~mm-fix-a-warning-while-make-xmldocs +0 -1
@@ -1862,7 +1862,6 @@ EXPORT_SYMBOL(vm_unmap_ram);
  * @pages: an array of pointers to the pages to be mapped
  * @count: number of pages
  * @node: prefer to allocate data structures on this node
- * @prot: memory protection to use. PAGE_KERNEL for regular RAM
  *
  * If you use this function for less than VMAP_MAX_ALLOC pages, it could be
  * faster than vmap so it's good.  But if you mix long-life and short-life

_

author maintainer
#31 lore raw

PATCH 20/32 mm: memcontrol: handle div0 crash race condition in memory.low

In reply to Andrew Morton

From: Johannes Weiner <[email protected]>
Subject: mm: memcontrol: handle div0 crash race condition in memory.low

Tejun reports seeing rare div0 crashes in memory.low stress testing:

[37228.504582] RIP: 0010:mem_cgroup_calculate_protection+0xed/0x150
[37228.505059] Code: 0f 46 d1 4c 39 d8 72 57 f6 05 16 d6 42 01 40 74 1f 4c 39 d8 76 1a 4c 39 d1 76 15 4c 29 d1 4c 29 d8 4d 29 d9 31 d2 48 0f af c1 <49> f7 f1 49 01 c2 4c 89 96 38 01 00 00 5d c3 48 0f af c7 31 d2 49
[37228.506254] RSP: 0018:ffffa14e01d6fcd0 EFLAGS: 00010246
[37228.506769] RAX: 000000000243e384 RBX: 0000000000000000 RCX: 0000000000008f4b
[37228.507319] RDX: 0000000000000000 RSI: ffff8b89bee84000 RDI: 0000000000000000
[37228.507869] RBP: ffffa14e01d6fcd0 R08: ffff8b89ca7d40f8 R09: 0000000000000000
[37228.508376] R10: 0000000000000000 R11: 00000000006422f7 R12: 0000000000000000
[37228.508881] R13: ffff8b89d9617000 R14: ffff8b89bee84000 R15: ffffa14e01d6fdb8
[37228.509397] FS:  0000000000000000(0000) GS:ffff8b8a1f1c0000(0000) knlGS:0000000000000000
[37228.509917] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[37228.510442] CR2: 00007f93b1fc175b CR3: 000000016100a000 CR4: 0000000000340ea0
[37228.511076] Call Trace:
[37228.511561]  shrink_node+0x1e5/0x6c0
[37228.512044]  balance_pgdat+0x32d/0x5f0
[37228.512521]  kswapd+0x1d7/0x3d0
[37228.513346]  ? wait_woken+0x80/0x80
[37228.514170]  kthread+0x11c/0x160
[37228.514983]  ? balance_pgdat+0x5f0/0x5f0
[37228.515797]  ? kthread_park+0x90/0x90
[37228.516593]  ret_from_fork+0x1f/0x30

This happens when parent_usage == siblings_protected. We check that usage is bigger than protected, which should imply parent_usage being bigger than siblings_protected. However, we don't read (or even update) these values atomically, and they can be out of sync as the memory state changes under us. A bit of fluctuation around the target protection isn't a big deal, but we need to handle the div0 case.

Check the parent state explicitly to make sure we have a reasonable positive value for the divisor.

---

 mm/memcontrol.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)
mm/memcontrol.c renamed from mm/memcontrol.c~mm-memcontrol-handle-div0-crash-race-condition-in-memorylow +4 -0
@@ -6360,11 +6360,16 @@ static unsigned long effective_protectio
 	 * We're using unprotected memory for the weight so that if
 	 * some cgroups DO claim explicit protection, we don't protect
 	 * the same bytes twice.
+	 *
+	 * Check both usage and parent_usage against the respective
+	 * protected values. One should imply the other, but they
+	 * aren't read atomically - make sure the division is sane.
 	 */
 	if (!(cgrp_dfl_root.flags & CGRP_ROOT_MEMORY_RECURSIVE_PROT))
 		return ep;
author maintainer
#32 lore raw

PATCH 21/32 mm/memcontrol.c: add missed css_put()

In reply to Andrew Morton

From: Muchun Song <[email protected]>
Subject: mm/memcontrol.c: add missed css_put()

We should put the css reference when memory allocation failed.

Fixes f0a3a24b532d ("mm: memcg/slab: rework non-root kmem_cache lifecycle management")
Cc Johannes Weiner <[email protected]>
Cc Vladimir Davydov <[email protected]>
Cc Qian Cai <[email protected]>

---

 mm/memcontrol.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
mm/memcontrol.c renamed from mm/memcontrol.c~mm-memcontrol-fix-do-not-put-the-css-reference +3 -1
@@ -2772,8 +2772,10 @@ static void memcg_schedule_kmem_cache_cr
 		return;
 
 	cw = kmalloc(sizeof(*cw), GFP_NOWAIT | __GFP_NOWARN);
-	if (!cw)
+	if (!cw) {
+		css_put(&memcg->css);
 		return;
+	}
 
 	cw->memcg = memcg;
 	cw->cachep = cachep;

_

author maintainer
#33 lore raw

PATCH 22/32 mm/memcontrol.c: prevent missed memory.low load tears

In reply to Andrew Morton

From: Chris Down <[email protected]>
Subject: mm/memcontrol.c: prevent missed memory.low load tears

Looks like one of these got missed when massaging in f86b810c2610 ("mm,
memcg: prevent memory.low load/store tearing") with other linux-mm changes.

---

 mm/memcontrol.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
mm/memcontrol.c renamed from mm/memcontrol.c~mm-memcg-prevent-missed-memorylow-load-tears +3 -2
@@ -6423,7 +6423,7 @@ enum mem_cgroup_protection mem_cgroup_pr
 
 	if (parent == root) {
 		memcg->memory.emin = READ_ONCE(memcg->memory.min);
-		memcg->memory.elow = memcg->memory.low;
+		memcg->memory.elow = READ_ONCE(memcg->memory.low);
 		goto out;
 	}
 
@@ -6435,7 +6435,8 @@ enum mem_cgroup_protection mem_cgroup_pr
 			atomic_long_read(&parent->memory.children_min_usage)));
 
 	WRITE_ONCE(memcg->memory.elow, effective_protection(usage, parent_usage,
-			memcg->memory.low, READ_ONCE(parent->memory.elow),
+			READ_ONCE(memcg->memory.low),
+			READ_ONCE(parent->memory.elow),
 			atomic_long_read(&parent->memory.children_low_usage)));
 
 out:

_

author maintainer
#34 lore raw

PATCH 23/32 docs: mm/gup: minor documentation update

In reply to Andrew Morton

From: Souptick Joarder <[email protected]>
Subject: docs: mm/gup: minor documentation update

Now there are 5 cases. Updated the same.

---

 Documentation/core-api/pin_user_pages.rst |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Documentation/core-api/pin_user_pages.rst renamed from Documentation/core-api/pin_user_pages.rst~docs-mm-gup-minor-documentation-update +1 -1
@@ -33,7 +33,7 @@ all combinations of get*(), pin*(), FOLL
 pin_user_pages*() APIs are clearly distinct from the get_user_pages*() APIs, so
 that's a natural dividing line, and a good point to make separate wrapper calls.
 In other words, use pin_user_pages*() for DMA-pinned pages, and
-get_user_pages*() for other cases. There are four cases described later on in
+get_user_pages*() for other cases. There are five cases described later on in
 this document, to further clarify that concept.
 
 FOLL_PIN and FOLL_GET are mutually exclusive for a given gup call. However,

_

author maintainer
#35 lore raw

PATCH 24/32 doc: THP CoW fault no longer allocate THP

In reply to Andrew Morton

From: Yang Shi <[email protected]>
Subject: doc: THP CoW fault no longer allocate THP

Since commit 3917c80280c93a7123f ("thp: change CoW semantics for anon-THP"), THP CoW page fault is rewritten. Now it just splits pmd then fallback to base page fault, it doesn't try to allocate THP anymore. So it is no longer counted in THP_FAULT_ALLOC.

Remove the obsolete statement in documentation about THP CoW allocation to avoid confusion.

---

 Documentation/admin-guide/cgroup-v2.rst    |    4 ++--
 Documentation/admin-guide/mm/transhuge.rst |    3 +--
 2 files changed, 3 insertions(+), 4 deletions(-)
Documentation/admin-guide/cgroup-v2.rst renamed from Documentation/admin-guide/cgroup-v2.rst~doc-thp-cow-fault-no-longer-allocate-thp +2 -2
@@ -1356,8 +1356,8 @@ PAGE_SIZE multiple when read back.
 
 	  thp_fault_alloc
 		Number of transparent hugepages which were allocated to satisfy
-		a page fault, including COW faults. This counter is not present
-		when CONFIG_TRANSPARENT_HUGEPAGE is not set.
+		a page fault. This counter is not present when CONFIG_TRANSPARENT_HUGEPAGE
+                is not set.
 
 	  thp_collapse_alloc
 		Number of transparent hugepages which were allocated to allow
Documentation/admin-guide/mm/transhuge.rst renamed from Documentation/admin-guide/mm/transhuge.rst~doc-thp-cow-fault-no-longer-allocate-thp +1 -2
@@ -305,8 +305,7 @@ monitor how successfully the system is p
 
 thp_fault_alloc
 	is incremented every time a huge page is successfully
-	allocated to handle a page fault. This applies to both the
-	first time a page is faulted and for COW faults.
+	allocated to handle a page fault.
 
 thp_collapse_alloc
 	is incremented by khugepaged when it has found

_

author maintainer
#36 lore raw

PATCH 25/32 mm: workingset: age nonresident information alongside anonymous pages

In reply to Andrew Morton

From: Johannes Weiner <[email protected]>
Subject: mm: workingset: age nonresident information alongside anonymous pages

Patch series "fix for "mm: balance LRU lists based on relative thrashing" patchset"

This patchset fixes some problems of the patchset, "mm: balance LRU lists based on relative thrashing", which is now merged on the mainline.

Patch "mm: workingset: let cache workingset challenge anon fix" is the result of discussion with Johannes. See following link.

http://lkml.kernel.org/r/[email protected]

And, the other two are minor things which are found when I try to rebase my patchset.

This patch (of 3):
After ("mm: workingset: let cache workingset challenge anon fix"), we compare refault distances to active_file + anon. But age of the non-resident information is only driven by the file LRU. As a result, we may overestimate the recency of any incoming refaults and activate them too eagerly, causing unnecessary LRU churn in certain situations.

Make anon aging drive nonresident age as well to address that.

Fixes 34e58cac6d8f2a ("mm: workingset: let cache workingset challenge anon")
Cc Rik van Riel <[email protected]>
Cc Minchan Kim <[email protected]>
Cc Michal Hocko <[email protected]>

---

 include/linux/mmzone.h |    4 +--
 include/linux/swap.h   |    1 
 mm/vmscan.c            |    3 ++
 mm/workingset.c        |   46 ++++++++++++++++++++++-----------------
 4 files changed, 33 insertions(+), 21 deletions(-)
include/linux/mmzone.h renamed from include/linux/mmzone.h~mm-workingset-age-nonresident-information-alongside-anonymous-pages +2 -2
@@ -257,8 +257,8 @@ struct lruvec {
 	 */
 	unsigned long			anon_cost;
 	unsigned long			file_cost;
-	/* Evictions & activations on the inactive file list */
-	atomic_long_t			inactive_age;
+	/* Non-resident age, driven by LRU movement */
+	atomic_long_t			nonresident_age;
 	/* Refaults at the time of last reclaim cycle */
 	unsigned long			refaults;
 	/* Various lruvec state flags (enum lruvec_flags) */
include/linux/swap.h renamed from include/linux/swap.h~mm-workingset-age-nonresident-information-alongside-anonymous-pages +1 -0
@@ -313,6 +313,7 @@ struct vma_swap_readahead {
 };
 
 /* linux/mm/workingset.c */
+void workingset_age_nonresident(struct lruvec *lruvec, unsigned long nr_pages);
 void *workingset_eviction(struct page *page, struct mem_cgroup *target_memcg);
 void workingset_refault(struct page *page, void *shadow);
 void workingset_activation(struct page *page);
mm/vmscan.c renamed from mm/vmscan.c~mm-workingset-age-nonresident-information-alongside-anonymous-pages +3 -0
@@ -904,6 +904,7 @@ static int __remove_mapping(struct addre
 		__delete_from_swap_cache(page, swap);
 		xa_unlock_irqrestore(&mapping->i_pages, flags);
 		put_swap_page(page, swap);
+		workingset_eviction(page, target_memcg);
 	} else {
 		void (*freepage)(struct page *);
 		void *shadow = NULL;
@@ -1884,6 +1885,8 @@ static unsigned noinline_for_stack move_
 				list_add(&page->lru, &pages_to_free);
 		} else {
 			nr_moved += nr_pages;
+			if (PageActive(page))
+				workingset_age_nonresident(lruvec, nr_pages);
 		}
 	}
 
mm/workingset.c renamed from mm/workingset.c~mm-workingset-age-nonresident-information-alongside-anonymous-pages +27 -19

105 lines not on this page · raw message

_

author maintainer
#37 lore raw

PATCH 26/32 mm/swap: fix for "mm: workingset: age nonresident information alongside anonymous pages"

In reply to Andrew Morton

From: Joonsoo Kim <[email protected]>
Subject: mm/swap: fix for "mm: workingset: age nonresident information alongside anonymous pages"

Non-file-lru page could also be activated in mark_page_accessed() and we need to count this activation for nonresident_age.

Note that it's better for this patch to be squashed into the patch "mm: workingset: age nonresident information alongside anonymous pages".

---

 mm/swap.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
mm/swap.c renamed from mm/swap.c~mm-swap-fix-for-mm-workingset-age-nonresident-information-alongside-anonymous-pages +1 -2
@@ -443,8 +443,7 @@ void mark_page_accessed(struct page *pag
 		else
 			__lru_cache_activate_page(page);
 		ClearPageReferenced(page);
-		if (page_is_file_lru(page))
-			workingset_activation(page);
+		workingset_activation(page);
 	}
 	if (page_is_idle(page))
 		clear_page_idle(page);

_

author maintainer
#38 lore raw

PATCH 27/32 mm/memory: fix IO cost for anonymous page

In reply to Andrew Morton

From: Joonsoo Kim <[email protected]>
Subject: mm/memory: fix IO cost for anonymous page

With synchronous IO swap device, swap-in is directly handled in fault code. Since IO cost notation isn't added there, with synchronous IO swap device, LRU balancing could be wrongly biased. Fix it to count it in fault code.

Fixes 314b57fb0460001 ("mm: balance LRU lists based on relative thrashing cache sizing")
Cc Joonsoo Kim <[email protected]>
Cc Michal Hocko <[email protected]>
Cc Minchan Kim <[email protected]>
Cc Rik van Riel <[email protected]>

---

 mm/memory.c |    8 ++++++++
 1 file changed, 8 insertions(+)
mm/memory.c renamed from mm/memory.c~mm-memory-fix-io-cost-for-anonymous-page +8 -0
@@ -3146,6 +3146,14 @@ vm_fault_t do_swap_page(struct vm_fault
 					goto out_page;
 				}
 
+				/*
+				 * XXX: Move to lru_cache_add() when it
+				 * supports new vs putback
+				 */
+				spin_lock_irq(&page_pgdat(page)->lru_lock);
+				lru_note_cost_page(page);
+				spin_unlock_irq(&page_pgdat(page)->lru_lock);
+
 				lru_cache_add(page);
 				swap_readpage(page, true);
 			}

_

author maintainer
#39 lore raw

PATCH 28/32 x86/hyperv: allocate the hypercall page with only read and execute bits

In reply to Andrew Morton

From: Christoph Hellwig <[email protected]>
Subject: x86/hyperv: allocate the hypercall page with only read and execute bits

Patch series "fix a hyperv W^X violation and remove vmalloc_exec"

Dexuan reported a W^X violation due to the fact that the hyper hypercall page due switching it to be allocated using vmalloc_exec. The problem is that PAGE_KERNEL_EXEC as used by vmalloc_exec actually sets writable permissions in the pte. This series fixes the issue by switching to the low-level __vmalloc_node_range interface that allows specifing more detailed permissions instead. It then also open codes the other two callers and removes the somewhat confusing vmalloc_exec interface.

Peter noted that the hyper hypercall page allocation also has another long standing issue in that it shouldn't use the full vmalloc but just the module space. This issue is so far theoretical as the allocation is done early in the boot process. I plan to fix it with another bigger series for 5.9.

This patch (of 3):

Avoid a W^X violation cause by the fact that PAGE_KERNEL_EXEC includes the writable bit.

For this resurrect the removed PAGE_KERNEL_RX definitіon, but as PAGE_KERNEL_ROX to match arm64 and powerpc.

Fixes 78bb17f76edc ("x86/hyperv: use vmalloc_exec for the hypercall page")
Cc Catalin Marinas <[email protected]>
Cc Will Deacon <[email protected]>
Cc Jessica Yu <[email protected]>
Cc David Hildenbrand <[email protected]>

---

 arch/x86/hyperv/hv_init.c            |    4 +++-
 arch/x86/include/asm/pgtable_types.h |    2 ++
 2 files changed, 5 insertions(+), 1 deletion(-)
arch/x86/hyperv/hv_init.c renamed from arch/x86/hyperv/hv_init.c~x86-hyperv-allocate-the-hypercall-page-with-only-read-and-execute-bits +3 -1
@@ -375,7 +375,9 @@ void __init hyperv_init(void)
 	guest_id = generate_guest_id(0, LINUX_VERSION_CODE, 0);
 	wrmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id);
 
-	hv_hypercall_pg = vmalloc_exec(PAGE_SIZE);
+	hv_hypercall_pg = __vmalloc_node_range(PAGE_SIZE, 1, VMALLOC_START,
+			VMALLOC_END, GFP_KERNEL, PAGE_KERNEL_ROX,
+			VM_FLUSH_RESET_PERMS, NUMA_NO_NODE, __func__);
 	if (hv_hypercall_pg == NULL) {
 		wrmsrl(HV_X64_MSR_GUEST_OS_ID, 0);
 		goto remove_cpuhp_state;
arch/x86/include/asm/pgtable_types.h renamed from arch/x86/include/asm/pgtable_types.h~x86-hyperv-allocate-the-hypercall-page-with-only-read-and-execute-bits +2 -0
@@ -194,6 +194,7 @@ enum page_cache_mode {
 #define _PAGE_TABLE_NOENC	 (__PP|__RW|_USR|___A|   0|___D|   0|   0)
 #define _PAGE_TABLE		 (__PP|__RW|_USR|___A|   0|___D|   0|   0| _ENC)
 #define __PAGE_KERNEL_RO	 (__PP|   0|   0|___A|__NX|___D|   0|___G)
+#define __PAGE_KERNEL_ROX	 (__PP|   0|   0|___A|   0|___D|   0|___G)
 #define __PAGE_KERNEL_NOCACHE	 (__PP|__RW|   0|___A|__NX|___D|   0|___G| __NC)
 #define __PAGE_KERNEL_VVAR	 (__PP|   0|_USR|___A|__NX|___D|   0|___G)
 #define __PAGE_KERNEL_LARGE	 (__PP|__RW|   0|___A|__NX|___D|_PSE|___G)
@@ -219,6 +220,7 @@ enum page_cache_mode {
 #define PAGE_KERNEL_RO		__pgprot_mask(__PAGE_KERNEL_RO         | _ENC)
 #define PAGE_KERNEL_EXEC	__pgprot_mask(__PAGE_KERNEL_EXEC       | _ENC)
 #define PAGE_KERNEL_EXEC_NOENC	__pgprot_mask(__PAGE_KERNEL_EXEC       |    0)
+#define PAGE_KERNEL_ROX		__pgprot_mask(__PAGE_KERNEL_ROX        | _ENC)
 #define PAGE_KERNEL_NOCACHE	__pgprot_mask(__PAGE_KERNEL_NOCACHE    | _ENC)
 #define PAGE_KERNEL_LARGE	__pgprot_mask(__PAGE_KERNEL_LARGE      | _ENC)
 #define PAGE_KERNEL_LARGE_EXEC	__pgprot_mask(__PAGE_KERNEL_LARGE_EXEC | _ENC)

_

author maintainer
#40 lore raw

PATCH 29/32 arm64: use PAGE_KERNEL_ROX directly in alloc_insn_page

In reply to Andrew Morton

From: Christoph Hellwig <[email protected]>
Subject: arm64: use PAGE_KERNEL_ROX directly in alloc_insn_page

Use PAGE_KERNEL_ROX directly instead of allocating RWX and setting the page read-only just after the allocation.

---

 arch/arm64/kernel/probes/kprobes.c |   12 +++---------
 1 file changed, 3 insertions(+), 9 deletions(-)
arch/arm64/kernel/probes/kprobes.c renamed from arch/arm64/kernel/probes/kprobes.c~arm64-use-page_kernel_rox-directly-in-alloc_insn_page +0 -7
@@ -120,15 +120,9 @@ int __kprobes arch_prepare_kprobe(struct
 
 void *alloc_insn_page(void)
 {
-	void *page;
-
-	page = vmalloc_exec(PAGE_SIZE);
-	if (page) {
-		set_memory_ro((unsigned long)page, 1);
-		set_vm_flush_reset_perms(page);
-	}
author maintainer
#41 lore raw

PATCH 30/32 mm: remove vmalloc_exec

In reply to Andrew Morton

From: Christoph Hellwig <[email protected]>
Subject: mm: remove vmalloc_exec

Merge vmalloc_exec into its only caller. Note that for !CONFIG_MMU __vmalloc_node_range maps to __vmalloc, which directly clears the __GFP_HIGHMEM added by the vmalloc_exec stub anyway.

---

 include/linux/vmalloc.h |    1 -
 kernel/module.c         |    4 +++-
 mm/nommu.c              |   17 -----------------
 mm/vmalloc.c            |   20 --------------------
 4 files changed, 3 insertions(+), 39 deletions(-)
include/linux/vmalloc.h renamed from include/linux/vmalloc.h~mm-remove-vmalloc_exec +0 -1
@@ -106,7 +106,6 @@ extern void *vzalloc(unsigned long size)
 extern void *vmalloc_user(unsigned long size);
 extern void *vmalloc_node(unsigned long size, int node);
 extern void *vzalloc_node(unsigned long size, int node);
-extern void *vmalloc_exec(unsigned long size);
 extern void *vmalloc_32(unsigned long size);
 extern void *vmalloc_32_user(unsigned long size);
 extern void *__vmalloc(unsigned long size, gfp_t gfp_mask);
kernel/module.c renamed from kernel/module.c~mm-remove-vmalloc_exec +3 -1
@@ -2783,7 +2783,9 @@ static void dynamic_debug_remove(struct
 
 void * __weak module_alloc(unsigned long size)
 {
-	return vmalloc_exec(size);
+	return __vmalloc_node_range(size, 1, VMALLOC_START, VMALLOC_END,
+			GFP_KERNEL, PAGE_KERNEL_EXEC, VM_FLUSH_RESET_PERMS,
+			NUMA_NO_NODE, __func__);
 }
 
 bool __weak module_init_section(const char *name)
mm/nommu.c renamed from mm/nommu.c~mm-remove-vmalloc_exec +0 -17
@@ -291,23 +291,6 @@ void *vzalloc_node(unsigned long size, i
 EXPORT_SYMBOL(vzalloc_node);
 
 /**
- *	vmalloc_exec  -  allocate virtually contiguous, executable memory
- *	@size:		allocation size
- *
- *	Kernel-internal function to allocate enough pages to cover @size
- *	the page level allocator and map them into contiguous and
- *	executable kernel virtual space.
- *
- *	For tight control over page level allocator and protection flags
- *	use __vmalloc() instead.
- */
-
-void *vmalloc_exec(unsigned long size)
-{
-	return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM);
-}
-
-/**
  * vmalloc_32  -  allocate virtually contiguous memory (32bit addressable)
  *	@size:		allocation size
  *
mm/vmalloc.c renamed from mm/vmalloc.c~mm-remove-vmalloc_exec +0 -19
@@ -2695,26 +2695,6 @@ void *vzalloc_node(unsigned long size, i
 }
 EXPORT_SYMBOL(vzalloc_node);
 
-/**
- * vmalloc_exec - allocate virtually contiguous, executable memory
- * @size:	  allocation size
- *
- * Kernel-internal function to allocate enough pages to cover @size
- * the page level allocator and map them into contiguous and
- * executable kernel virtual space.
- *
- * For tight control over page level allocator and protection flags
- * use __vmalloc() instead.
- *
- * Return: pointer to the allocated memory or %NULL on error
- */
-void *vmalloc_exec(unsigned long size)
-{
-	return __vmalloc_node_range(size, 1, VMALLOC_START, VMALLOC_END,
-			GFP_KERNEL, PAGE_KERNEL_EXEC, VM_FLUSH_RESET_PERMS,
-			NUMA_NO_NODE, __builtin_return_address(0));
-}
author maintainer
#42 lore raw

PATCH 31/32 mm/memory_hotplug.c: fix false softlockup during pfn range removal

In reply to Andrew Morton

From: Ben Widawsky <[email protected]>
Subject: mm/memory_hotplug.c: fix false softlockup during pfn range removal

When working with very large nodes, poisoning the struct pages (for which there will be very many) can take a very long time. If the system is using voluntary preemptions, the software watchdog will not be able to detect forward progress. This patch addresses this issue by offering to give up time like __remove_pages() does. This behavior was introduced in v5.6 with: commit d33695b16a9f ("mm/memory_hotplug: poison memmap in remove_pfn_range_from_zone()")

Alternately, init_page_poison could do this cond_resched(), but it seems to me that the caller of init_page_poison() is what actually knows whether or not it should relax its own priority.

Based on Dan's notes, I think this is perfectly safe: commit f931ab479dd2 ("mm: fix devm_memremap_pages crash, use mem_hotplug_{begin, done}")

Aside from fixing the lockup, it is also a friendlier thing to do on lower core systems that might wipe out large chunks of hotplug memory (probably not a very common case).

Fixes this kind of splat:

[  352.142079] watchdog: BUG: soft lockup - CPU#46 stuck for 22s! [daxctl:9922]
[  352.150067] Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_tables ebtable_nat ebtable_broute ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_raw iptable_security rfkill ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ib_isert iscsi_target_mod ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib ib_umad vfat fat kmem intel_rapl_msr intel_rapl_common rpcrdma sunrpc rdma_ucm ib_iser isst_if_common rdma_cm skx_edac iw_cm ib_cm x86_pkg_temp_thermal libiscsi intel_powerclamp scsi_transport_iscsi coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel i40iw intel_cstate iTCO_wdt ib_uverbs iTCO_vendor_support device_dax ib_core joydev intel_uncore i2c_i801 lpc_ich ipmi_ssif ioatdma dca wmi ipmi_si ipmi_devintf ipmi_msghandler dax_pmem
[  352.150123]  dax_pmem_core acpi_pad acpi_power_meter drm ip_tables xfs libcrc32c nd_pmem nd_btt i40e e1000e crc32c_intel nfit
[  352.260774] irq event stamp: 138450
[  352.264692] hardirqs last  enabled at (138449): [<ffffffffa1001f26>] trace_hardirqs_on_thunk+0x1a/0x1c
[  352.275134] hardirqs last disabled at (138450): [<ffffffffa1001f42>] trace_hardirqs_off_thunk+0x1a/0x1c
[  352.285662] softirqs last  enabled at (138448): [<ffffffffa1e00347>] __do_softirq+0x347/0x456
[  352.295233] softirqs last disabled at (138443): [<ffffffffa10c416d>] irq_exit+0x7d/0xb0
[  352.304210] CPU: 46 PID: 9922 Comm: daxctl Not tainted 5.7.0-BEN-14238-g373c6049b336 #30
[  352.313283] Hardware name: Intel Corporation PURLEY/PURLEY, BIOS PLYXCRB1.86B.0578.D07.1902280810 02/28/2019
[  352.324308] RIP: 0010:memset_erms+0x9/0x10
[  352.328905] Code: c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 f3 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 <f3> aa 4c 89 c8 c3 90 49 89 fa 40 0f b6 ce 48 b8 01 01 01 01 01 01
[  352.349953] RSP: 0018:ffffc90021b5fd50 EFLAGS: 00010202 ORIG_RAX: ffffffffffffff13
[  352.358450] RAX: 00000000000000ff RBX: ffff88983ffd5000 RCX: 0000000065df0e40
[  352.366457] RDX: 00000003a0000000 RSI: 00000000ffffffff RDI: ffffea039b20f1c0
[  352.374465] RBP: ffff88983ffd6c00 R08: 0000000000000000 R09: ffffea0061000000
[  352.382473] R10: 0000000000000001 R11: 0000000000000000 R12: ffffea006f808000
[  352.390480] R13: 0000000001840000 R14: 000000000e800000 R15: ffff8997d7b764e0
[  352.398487] FS:  00007f724ef81780(0000) GS:ffff8997df100000(0000) knlGS:0000000000000000
[  352.407562] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  352.414011] CR2: 00007ffcd4070768 CR3: 000001178c722002 CR4: 00000000003606e0
[  352.422056] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  352.430092] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  352.438115] Call Trace:
[  352.440865]  remove_pfn_range_from_zone+0x3a/0x380
[  352.446244]  ? cpumask_next+0x17/0x20
[  352.450361]  memunmap_pages+0x17f/0x280
[  352.454670]  release_nodes+0x22a/0x260
[  352.458888]  __device_release_driver+0x172/0x220
[  352.464070]  device_driver_detach+0x3e/0xa0
[  352.468753]  unbind_store+0x113/0x130
[  352.472868]  kernfs_fop_write+0xdc/0x1c0
[  352.477273]  vfs_write+0xde/0x1d0
[  352.482218]  ksys_write+0x58/0xd0
[  352.487207]  do_syscall_64+0x5a/0x120
[  352.492529]  entry_SYSCALL_64_after_hwframe+0x49/0xb3
[  352.499446] RIP: 0033:0x7f724f40b5e7
[  352.504673] Code: Bad RIP value.
[  352.509484] RSP: 002b:00007ffcd40738f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[  352.519213] RAX: ffffffffffffffda RBX: 00007f724ef816a8 RCX: 00007f724f40b5e7
[  352.528410] RDX: 0000000000000007 RSI: 00005617d7cd1277 RDI: 0000000000000003
[  352.537573] RBP: 0000000000000003 R08: 00000000ffffffff R09: 00007ffcd40737d0
[  352.546764] R10: 0000000000000000 R11: 0000000000000246 R12: 00005617d7cd1277
[  352.555929] R13: 0000000000000000 R14: 0000000000000007 R15: 00005617d7cd1230
[  370.353742] Built 2 zonelists, mobility grouping on.  Total pages: 49050381
[  370.373317] Policy zone: Normal
[  374.948164] Built 3 zonelists, mobility grouping on.  Total pages: 49312525
[  375.017496] Policy zone: Normal

David said: "It really only is an issue for devmem. Ordinary hotplugged system memory is not affected (onlined/offlined in memory block granularity)."

Fixes commit d33695b16a9f ("mm/memory_hotplug: poison memmap in remove_pfn_range_from_zone()")
Cc Dan Williams <[email protected]>
Cc Vishal Verma <[email protected]>

---

 mm/memory_hotplug.c |   13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)
mm/memory_hotplug.c renamed from mm/memory_hotplug.c~mm-fix-false-softlockup-during-pfn-range-removal +11 -2
@@ -471,11 +471,20 @@ void __ref remove_pfn_range_from_zone(st
 				      unsigned long start_pfn,
 				      unsigned long nr_pages)
 {
+	const unsigned long end_pfn = start_pfn + nr_pages;
 	struct pglist_data *pgdat = zone->zone_pgdat;
-	unsigned long flags;
+	unsigned long pfn, cur_nr_pages, flags;
 
 	/* Poison struct pages because they are now uninitialized again. */
-	page_init_poison(pfn_to_page(start_pfn), sizeof(struct page) * nr_pages);
+	for (pfn = start_pfn; pfn < end_pfn; pfn += cur_nr_pages) {
+		cond_resched();
+
+		/* Select all remaining pages up to the next section boundary */
+		cur_nr_pages =
+			min(end_pfn - pfn, SECTION_ALIGN_UP(pfn + 1) - pfn);
+		page_init_poison(pfn_to_page(pfn),
+				 sizeof(struct page) * cur_nr_pages);
+	}
 
 #ifdef CONFIG_ZONE_DEVICE
 	/*

_

author maintainer
#43 lore raw

PATCH 32/32 MAINTAINERS: update info for sparse

In reply to Andrew Morton

From: Luc Van Oostenryck <[email protected]>
Subject: MAINTAINERS: update info for sparse

Update the info for sparse. More specifically:
* change W entry to point to sparse.docs.kernel.org
* add Q & B entry (patchwork & bugzilla)

---

 MAINTAINERS |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
MAINTAINERS renamed from MAINTAINERS~maintainers-update-info-for-sparse +3 -1
@@ -16058,8 +16058,10 @@ SPARSE CHECKER
 M:	"Luc Van Oostenryck" <[email protected]>
 L:	[email protected]
 S:	Maintained
-W:	https://sparse.wiki.kernel.org/
+W:	https://sparse.docs.kernel.org/
 T:	git git://git.kernel.org/pub/scm/devel/sparse/sparse.git
+Q:	https://patchwork.kernel.org/project/linux-sparse/list/
+B:	https://bugzilla.kernel.org/enter_bug.cgi?component=Sparse&product=Tools
 F:	include/linux/compiler.h
 
 SPEAR CLOCK FRAMEWORK SUPPORT

_

#44 lore raw
In reply to Andrew Morton
Quoted 2 lines · Andrew Morton

32 patches, based on 908f7d12d3ba51dfe0449b9723199b423f97ca9a.

You didn't cc lkml, so now none of the nice 'b4' automation seems to work for this series..

Yes, this cover-letter went to linux-mm (which is on lore), but the individual patches didn't.

Konstantin, maybe mm-commits could be on lore too and then they'd have been caught that way?

Linus

#45 lore raw
Quoted 3 lines · Linus Torvalds

You didn't cc lkml, so now none of the nice 'b4' automation seems to work for this series..

Note that I've picked them up the old-fashioned way, so don't re-send them.

So more of a note for "please, next time..."

Linus

#46 lore raw
In reply to Linus Torvalds
Quoted 4 lines · Linus Torvalds
Quoted 2 lines · Andrew Morton

32 patches, based on 908f7d12d3ba51dfe0449b9723199b423f97ca9a.

Quoted 8 lines

You didn't cc lkml, so now none of the nice 'b4' automation seems to work for this series..

Yes, this cover-letter went to linux-mm (which is on lore), but the individual patches didn't.

Konstantin, maybe mm-commits could be on lore too and then they'd have been caught that way?

Yes, I already have a request from Kees for linux-mm addition, so that should show up in archives before long.

-K

#47 lore raw
Quoted 5 lines · Konstantin Ryabitsev
Quoted 2 lines

Konstantin, maybe mm-commits could be on lore too and then they'd have been caught that way?

Yes, I already have a request from Kees for linux-mm addition, so that should show up in archives before long.

correction: mm-commits, that is

-K

author maintainer tree notice
#48 lore raw

+ linux-next-git-rejects.patch added to -mm tree

In reply to Andrew Morton
The patch titled Subject: linux-next-git-rejects has been added to the -mm tree. Its filename is linux-next-git-rejects.patch

The patch titled
Subject: linux-next-git-rejects
has been added to the -mm tree. Its filename is
linux-next-git-rejects.patch

This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/linux-next-git-rejects.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/linux-next-git-rejects.patch

Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***

The -mm tree is included into linux-next and is updated there every 3-4 working days

------------------------------------------------------
From: Andrew Morton <[email protected]>
Subject: linux-next-git-rejects

---

 drivers/cpuidle/cpuidle.c              |    4 ----
 drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c |    5 -----
 net/xfrm/xfrm_device.c                 |    7 -------
 3 files changed, 16 deletions(-)
drivers/cpuidle/cpuidle.c renamed from drivers/cpuidle/cpuidle.c~linux-next-git-rejects +0 -4
@@ -187,11 +187,7 @@ int cpuidle_enter_s2idle(struct cpuidle_
 	 * be frozen safely.
 	 */
 	index = find_deepest_state(drv, dev, U64_MAX, 0, true);
-<<<<<<< HEAD
-	if (index > 0) {
-=======
 	if (index > 0 && !current_clr_polling_and_test())
->>>>>>> linux-next/akpm-base
 		enter_s2idle_proper(drv, dev, index);
 		local_irq_enable();
 	}
drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c renamed from drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c~linux-next-git-rejects +0 -5
@@ -1300,13 +1300,8 @@ static int sdma_v5_0_sw_fini(void *handl
 	int i;
 
 	for (i = 0; i < adev->sdma.num_instances; i++) {
-<<<<<<< HEAD
-		if (adev->sdma.instance[i].fw != NULL)
-			release_firmware(adev->sdma.instance[i].fw);
-=======
 		release_firmware(adev->sdma.instance[i].fw);
 		adev->sdma.instance[i].fw = NULL;
->>>>>>> linux-next/akpm-base
 
 		amdgpu_ring_fini(&adev->sdma.instance[i].ring);
 	}
net/xfrm/xfrm_device.c renamed from net/xfrm/xfrm_device.c~linux-next-git-rejects +0 -6
@@ -135,13 +135,6 @@ struct sk_buff *validate_xmit_xfrm(struc
 	}
 
 	xo->flags |= XFRM_XMIT;
-<<<<<<< HEAD
-
-	if (skb_is_gso(skb)) {
-		struct net_device *dev = skb->dev;
-=======
->>>>>>> linux-next/akpm-base
author maintainer tree notice Applied
#49 lore raw

[merged] dma-remap-align-the-size-in-dma_common__remap.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: kernel/dma/remap.c: align the size in dma_common_*_remap() has been removed from the -mm tree. Its filename was dma-remap-align-the-size-in-dma_common__remap.patch

The patch titled
Subject: kernel/dma/remap.c: align the size in dma_common_*_remap()
has been removed from the -mm tree. Its filename was
dma-remap-align-the-size-in-dma_common__remap.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Eric Auger <[email protected]>
Subject: kernel/dma/remap.c: align the size in dma_common_*_remap()

Running a guest with a virtio-iommu protecting virtio devices is broken since commit 515e5b6d90d4 ("dma-mapping: use vmap insted of reimplementing it"). Before the conversion, the size was page aligned in __get_vm_area_node(). Doing so fixes the regression.

Fixes 515e5b6d90d4 ("dma-mapping: use vmap insted of reimplementing it")
Cc Christoph Hellwig <[email protected]>
Cc Peter Zijlstra (Intel) <[email protected]>
Cc Marek Szyprowski <[email protected]>
Cc Robin Murphy <[email protected]>
Cc Jean-Philippe Brucker <[email protected]>
Cc Bharat Bhushan <[email protected]>

---

 kernel/dma/remap.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
kernel/dma/remap.c renamed from kernel/dma/remap.c~dma-remap-align-the-size-in-dma_common__remap +2 -2
@@ -24,7 +24,7 @@ void *dma_common_pages_remap(struct page
 {
 	void *vaddr;
 
-	vaddr = vmap(pages, size >> PAGE_SHIFT, VM_DMA_COHERENT, prot);
+	vaddr = vmap(pages, PAGE_ALIGN(size) >> PAGE_SHIFT, VM_DMA_COHERENT, prot);
 	if (vaddr)
 		find_vm_area(vaddr)->pages = pages;
 	return vaddr;
@@ -37,7 +37,7 @@ void *dma_common_pages_remap(struct page
 void *dma_common_contiguous_remap(struct page *page, size_t size,
 			pgprot_t prot, const void *caller)
 {
-	int count = size >> PAGE_SHIFT;
+	int count = PAGE_ALIGN(size) >> PAGE_SHIFT;
 	struct page **pages;
 	void *vaddr;
 	int i;

_

Patches currently in -mm which might be from [email protected] are

author maintainer tree notice Applied
#50 lore raw

[merged] openrisc-fix-boot-oops-when-debug_vm-is-enabled.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: openrisc: fix boot oops when DEBUG_VM is enabled has been removed from the -mm tree. Its filename was openrisc-fix-boot-oops-when-debug_vm-is-enabled.patch

The patch titled
Subject: openrisc: fix boot oops when DEBUG_VM is enabled
has been removed from the -mm tree. Its filename was
openrisc-fix-boot-oops-when-debug_vm-is-enabled.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Stafford Horne <[email protected]>
Subject: openrisc: fix boot oops when DEBUG_VM is enabled

Since v5.8-rc1 OpenRISC Linux fails to boot when DEBUG_VM is enabled. This has been bisected to commit 42fc541404f2 ("mmap locking API: add mmap_assert_locked() and mmap_assert_write_locked()").

The added locking checks exposed the issue that OpenRISC was not taking this mmap lock when during page walks for DMA operations. This patch locks and unlocks the mmap lock for page walking.

Fixes 42fc541404f2 ("mmap locking API: add mmap_assert_locked() and mmap_assert_write_locked()"
Cc Jonas Bonn <[email protected]>
Cc Stefan Kristiansson <[email protected]>
Cc Jason Gunthorpe <[email protected]>
Cc Steven Price <[email protected]>
Cc Thomas Hellstrom <[email protected]>
Cc Robin Murphy <[email protected]>
Cc Vlastimil Babka <[email protected]>
Cc Daniel Jordan <[email protected]>

---

 arch/openrisc/kernel/dma.c |    5 +++++
 1 file changed, 5 insertions(+)
arch/openrisc/kernel/dma.c renamed from arch/openrisc/kernel/dma.c~openrisc-fix-boot-oops-when-debug_vm-is-enabled +5 -0
@@ -74,8 +74,11 @@ void *arch_dma_set_uncached(void *cpu_ad
 	 * We need to iterate through the pages, clearing the dcache for
 	 * them and setting the cache-inhibit bit.
 	 */
+	mmap_read_lock(&init_mm);
 	error = walk_page_range(&init_mm, va, va + size, &set_nocache_walk_ops,
 			NULL);
+	mmap_read_unlock(&init_mm);
+
 	if (error)
 		return ERR_PTR(error);
 	return cpu_addr;
@@ -85,9 +88,11 @@ void arch_dma_clear_uncached(void *cpu_a
 {
 	unsigned long va = (unsigned long)cpu_addr;
 
+	mmap_read_lock(&init_mm);
 	/* walk_page_range shouldn't be able to fail here */
 	WARN_ON(walk_page_range(&init_mm, va, va + size,
 			&clear_nocache_walk_ops, NULL));
+	mmap_read_unlock(&init_mm);
 }
 
 void arch_sync_dma_for_device(phys_addr_t addr, size_t size,

_

Patches currently in -mm which might be from [email protected] are

author maintainer tree notice Applied
#51 lore raw

[merged] mm-do_swap_page-fix-up-the-error-code-instantiation.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: mm: do_swap_page(): fix up the error code has been removed from the -mm tree. Its filename was mm-do_swap_page-fix-up-the-error-code-instantiation.patch

The patch titled
Subject: mm: do_swap_page(): fix up the error code
has been removed from the -mm tree. Its filename was
mm-do_swap_page-fix-up-the-error-code-instantiation.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Michal Hocko <[email protected]>
Subject: mm: do_swap_page(): fix up the error code

do_swap_page() returns error codes from the VM_FAULT* space. try_charge() might return -ENOMEM, though, and then do_swap_page() simply returns 0 which means a success.

We almost never return ENOMEM for GFP_KERNEL single page charge. Except for async OOM handling (oom_disabled v1). So this needs translation to VM_FAULT_OOM otherwise the the page fault path will not notify the userspace and wait for an action.

Fixes 4c6355b25e8b ("mm: memcontrol: charge swapin pages on instantiation")
Cc Alex Shi <[email protected]>
Cc Joonsoo Kim <[email protected]>
Cc Shakeel Butt <[email protected]>
Cc Hugh Dickins <[email protected]>
Cc "Kirill A. Shutemov" <[email protected]>
Cc Roman Gushchin <[email protected]>

---

 mm/memory.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
mm/memory.c renamed from mm/memory.c~mm-do_swap_page-fix-up-the-error-code-instantiation +3 -1
@@ -3140,8 +3140,10 @@ vm_fault_t do_swap_page(struct vm_fault
 				err = mem_cgroup_charge(page, vma->vm_mm,
 							GFP_KERNEL);
 				ClearPageSwapCache(page);
-				if (err)
+				if (err) {
+					ret = VM_FAULT_OOM;
 					goto out_page;
+				}
 
 				lru_cache_add(page);
 				swap_readpage(page, true);

_

Patches currently in -mm which might be from [email protected] are

author maintainer tree notice Applied
#52 lore raw

[merged] mm-compaction-make-capture-control-handling-safe-wrt-interrupts.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: mm, compaction: make capture control handling safe wrt interrupts has been removed from the -mm tree. Its filename was…

The patch titled
Subject: mm, compaction: make capture control handling safe wrt interrupts
has been removed from the -mm tree. Its filename was
mm-compaction-make-capture-control-handling-safe-wrt-interrupts.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Vlastimil Babka <[email protected]>
Subject: mm, compaction: make capture control handling safe wrt interrupts

Hugh reports:

: While stressing compaction, one run oopsed on NULL capc->cc in : __free_one_page()'s task_capc(zone): compact_zone_order() had been : interrupted, and a page was being freed in the return from interrupt. :
: Though you would not expect it from the source, both gccs I was using (a : 4.8.1 and a 7.5.0) had chosen to compile compact_zone_order() with the : ".cc = &cc" implemented by mov %rbx,-0xb0(%rbp) immediately before callq : compact_zone - long after the "current->capture_control = &capc". An : interrupt in between those finds capc->cc NULL (zeroed by an earlier rep : stos).
:
: This could presumably be fixed by a barrier() before setting
: current->capture_control in compact_zone_order(); but would also need more : care on return from compact_zone(), in order not to risk leaking a page : captured by interrupt just before capture_control is reset.
:
: Maybe that is the preferable fix, but I felt safer for task_capc() to : exclude the rather surprising possibility of capture at interrupt time.

I have checked that gcc10 also behaves the same.

The advantage of fix in compact_zone_order() is that we don't add another test in the page freeing hot path, and that it might prevent future problems if we stop exposing pointers to uninitialized structures in current task.

So this patch implements the suggestion for compact_zone_order() with barrier() (and WRITE_ONCE() to prevent store tearing) for setting current->capture_control, and prevents page leaking with WRITE_ONCE/READ_ONCE in the proper order.

Fixes 5e1f0f098b46 ("mm, compaction: capture a page under direct compaction")
Cc Alex Shi <[email protected]>
Cc Li Wang <[email protected]>
Cc Mel Gorman <[email protected]>
Cc <[email protected]> [5.1+]

---

 mm/compaction.c |   17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)
mm/compaction.c renamed from mm/compaction.c~mm-compaction-make-capture-control-handling-safe-wrt-interrupts +14 -3
@@ -2316,15 +2316,26 @@ static enum compact_result compact_zone_
 		.page = NULL,
 	};
 
-	current->capture_control = &capc;
+	/*
+	 * Make sure the structs are really initialized before we expose the
+	 * capture control, in case we are interrupted and the interrupt handler
+	 * frees a page.
+	 */
+	barrier();
+	WRITE_ONCE(current->capture_control, &capc);
 
 	ret = compact_zone(&cc, &capc);
 
 	VM_BUG_ON(!list_empty(&cc.freepages));
 	VM_BUG_ON(!list_empty(&cc.migratepages));
 
-	*capture = capc.page;
-	current->capture_control = NULL;
+	/*
+	 * Make sure we hide capture control first before we read the captured
+	 * page pointer, otherwise an interrupt could free and capture a page
+	 * and we would leak it.
+	 */
+	WRITE_ONCE(current->capture_control, NULL);
+	*capture = READ_ONCE(capc.page);
 
 	return ret;
 }

_

Patches currently in -mm which might be from [email protected] are

mm-slub-extend-slub_debug-syntax-for-multiple-blocks.patch mm-slub-make-some-slub_debug-related-attributes-read-only.patch mm-slub-remove-runtime-allocation-order-changes.patch mm-slub-make-remaining-slub_debug-related-attributes-read-only.patch mm-slub-make-reclaim_account-attribute-read-only.patch mm-slub-introduce-static-key-for-slub_debug.patch mm-slub-introduce-kmem_cache_debug_flags.patch mm-slub-introduce-kmem_cache_debug_flags-fix.patch mm-slub-extend-checks-guarded-by-slub_debug-static-key.patch mm-slab-slub-move-and-improve-cache_from_obj.patch mm-slab-slub-improve-error-reporting-and-overhead-of-cache_from_obj.patch mm-slab-slub-improve-error-reporting-and-overhead-of-cache_from_obj-fix.patch mm-page_alloc-use-unlikely-in-task_capc.patch

author maintainer tree notice Applied
#53 lore raw

[merged] kexec-do-not-verify-the-signature-without-the-lockdown-or-mandatory-signature.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: kexec: do not verify the signature without the lockdown or mandatory signature has been removed from the -mm tree. Its filename was…

The patch titled
Subject: kexec: do not verify the signature without the lockdown or mandatory signature
has been removed from the -mm tree. Its filename was
kexec-do-not-verify-the-signature-without-the-lockdown-or-mandatory-signature.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Lianbo Jiang <[email protected]>
Subject: kexec: do not verify the signature without the lockdown or mandatory signature

Signature verification is an important security feature, to protect system from being attacked with a kernel of unknown origin. Kexec rebooting is a way to replace the running kernel, hence need be secured carefully.

In the current code of handling signature verification of kexec kernel, the logic is very twisted. It mixes signature verification, IMA signature appraising and kexec lockdown.

If there is no KEXEC_SIG_FORCE, kexec kernel image doesn't have one of signature, the supported crypto, and key, we don't think this is wrong, Unless kexec lockdown is executed. IMA is considered as another kind of signature appraising method.

If kexec kernel image has signature/crypto/key, it has to go through the signature verification and pass. Otherwise it's seen as verification failure, and won't be loaded.

Seems kexec kernel image with an unqualified signature is even worse than those w/o signature at all, this sounds very unreasonable. E.g. If people get a unsigned kernel to load, or a kernel signed with expired key, which one is more dangerous?

So, here, let's simplify the logic to improve code readability. If the KEXEC_SIG_FORCE enabled or kexec lockdown enabled, signature verification is mandated. Otherwise, we lift the bar for any kernel image.

---

 kernel/kexec_file.c |   36 +++++++-----------------------------
 1 file changed, 7 insertions(+), 29 deletions(-)
kernel/kexec_file.c renamed from kernel/kexec_file.c~kexec-do-not-verify-the-signature-without-the-lockdown-or-mandatory-signature +5 -21
@@ -181,34 +181,19 @@ void kimage_file_post_load_cleanup(struc
 static int
 kimage_validate_signature(struct kimage *image)
 {
-	const char *reason;
 	int ret;
 
 	ret = arch_kexec_kernel_verify_sig(image, image->kernel_buf,
 					   image->kernel_buf_len);
-	switch (ret) {
-	case 0:
-		break;
-
-		/* Certain verification errors are non-fatal if we're not
-		 * checking errors, provided we aren't mandating that there
-		 * must be a valid signature.
-		 */
-	case -ENODATA:
-		reason = "kexec of unsigned image";
-		goto decide;
-	case -ENOPKG:
-		reason = "kexec of image with unsupported crypto";
-		goto decide;
-	case -ENOKEY:
-		reason = "kexec of image with unavailable key";
-	decide:
+	if (ret) {
+
 		if (IS_ENABLED(CONFIG_KEXEC_SIG_FORCE)) {
-			pr_notice("%s rejected\n", reason);
+			pr_notice("Enforced kernel signature verification failed (%d).\n", ret);
 			return ret;
 		}
 
-		/* If IMA is guaranteed to appraise a signature on the kexec
+		/*
+		 * If IMA is guaranteed to appraise a signature on the kexec
 		 * image, permit it even if the kernel is otherwise locked
 		 * down.
 		 */
@@ -216,17 +201,10 @@ kimage_validate_signature(struct kimage
 		    security_locked_down(LOCKDOWN_KEXEC))
 			return -EPERM;
 
-		return 0;
author maintainer tree notice Applied
#54 lore raw

[merged] ocfs2-avoid-inode-removed-while-nfsd-access-it.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: ocfs2: avoid inode removal while nfsd is accessing it has been removed from the -mm tree. Its filename was ocfs2-avoid-inode-removed-while-nfsd-access-it.patch

The patch titled
Subject: ocfs2: avoid inode removal while nfsd is accessing it
has been removed from the -mm tree. Its filename was
ocfs2-avoid-inode-removed-while-nfsd-access-it.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Junxiao Bi <[email protected]>
Subject: ocfs2: avoid inode removal while nfsd is accessing it

Patch series "ocfs2: fix nfsd over ocfs2 issues", v2.

This is a series of patches to fix issues on nfsd over ocfs2. patch 1 is to avoid inode removed while nfsd access it patch 2 & 3 is to fix a panic issue.

This patch (of 4):

When nfsd is getting file dentry using handle or parent dentry of some dentry, one cluster lock is used to avoid inode removed from other node, but it still could be removed from local node, so use a rw lock to avoid this.

---

 fs/ocfs2/dlmglue.c |   17 ++++++++++++++++-
 fs/ocfs2/ocfs2.h   |    1 +
 2 files changed, 17 insertions(+), 1 deletion(-)
fs/ocfs2/dlmglue.c renamed from fs/ocfs2/dlmglue.c~ocfs2-avoid-inode-removed-while-nfsd-access-it +16 -1
@@ -689,6 +689,12 @@ static void ocfs2_nfs_sync_lock_res_init
 				   &ocfs2_nfs_sync_lops, osb);
 }
 
+static void ocfs2_nfs_sync_lock_init(struct ocfs2_super *osb)
+{
+	ocfs2_nfs_sync_lock_res_init(&osb->osb_nfs_sync_lockres, osb);
+	init_rwsem(&osb->nfs_sync_rwlock);
+}
+
 void ocfs2_trim_fs_lock_res_init(struct ocfs2_super *osb)
 {
 	struct ocfs2_lock_res *lockres = &osb->osb_trim_fs_lockres;
@@ -2855,6 +2861,11 @@ int ocfs2_nfs_sync_lock(struct ocfs2_sup
 	if (ocfs2_is_hard_readonly(osb))
 		return -EROFS;
 
+	if (ex)
+		down_write(&osb->nfs_sync_rwlock);
+	else
+		down_read(&osb->nfs_sync_rwlock);
+
 	if (ocfs2_mount_local(osb))
 		return 0;
 
@@ -2873,6 +2884,10 @@ void ocfs2_nfs_sync_unlock(struct ocfs2_
 	if (!ocfs2_mount_local(osb))
 		ocfs2_cluster_unlock(osb, lockres,
 				     ex ? LKM_EXMODE : LKM_PRMODE);
+	if (ex)
+		up_write(&osb->nfs_sync_rwlock);
+	else
+		up_read(&osb->nfs_sync_rwlock);
 }
 
 int ocfs2_trim_fs_lock(struct ocfs2_super *osb,
@@ -3340,7 +3355,7 @@ int ocfs2_dlm_init(struct ocfs2_super *o
 local:
 	ocfs2_super_lock_res_init(&osb->osb_super_lockres, osb);
 	ocfs2_rename_lock_res_init(&osb->osb_rename_lockres, osb);
-	ocfs2_nfs_sync_lock_res_init(&osb->osb_nfs_sync_lockres, osb);
+	ocfs2_nfs_sync_lock_init(osb);
 	ocfs2_orphan_scan_lock_res_init(&osb->osb_orphan_scan.os_lockres, osb);
 
 	osb->cconn = conn;
fs/ocfs2/ocfs2.h renamed from fs/ocfs2/ocfs2.h~ocfs2-avoid-inode-removed-while-nfsd-access-it +1 -0
@@ -395,6 +395,7 @@ struct ocfs2_super
 	struct ocfs2_lock_res osb_super_lockres;
 	struct ocfs2_lock_res osb_rename_lockres;
 	struct ocfs2_lock_res osb_nfs_sync_lockres;
+	struct rw_semaphore nfs_sync_rwlock;
 	struct ocfs2_lock_res osb_trim_fs_lockres;
 	struct mutex obs_trim_fs_mutex;
 	struct ocfs2_dlm_debug *osb_dlm_debug;

_

Patches currently in -mm which might be from [email protected] are

author maintainer tree notice Applied
#55 lore raw

[merged] ocfs2-load-global_inode_alloc.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: ocfs2: load global_inode_alloc has been removed from the -mm tree. Its filename was ocfs2-load-global_inode_alloc.patch

The patch titled
Subject: ocfs2: load global_inode_alloc
has been removed from the -mm tree. Its filename was
ocfs2-load-global_inode_alloc.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Junxiao Bi <[email protected]>
Subject: ocfs2: load global_inode_alloc

Set global_inode_alloc as OCFS2_FIRST_ONLINE_SYSTEM_INODE, that will make it load during mount. It can be used to test whether some global/system inodes are valid. One use case is that nfsd will test whether root inode is valid.

---

 fs/ocfs2/ocfs2_fs.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/ocfs2/ocfs2_fs.h renamed from fs/ocfs2/ocfs2_fs.h~ocfs2-load-global_inode_alloc +1 -1
@@ -326,8 +326,8 @@ struct ocfs2_system_inode_info {
 enum {
 	BAD_BLOCK_SYSTEM_INODE = 0,
 	GLOBAL_INODE_ALLOC_SYSTEM_INODE,
+#define OCFS2_FIRST_ONLINE_SYSTEM_INODE GLOBAL_INODE_ALLOC_SYSTEM_INODE
 	SLOT_MAP_SYSTEM_INODE,
-#define OCFS2_FIRST_ONLINE_SYSTEM_INODE SLOT_MAP_SYSTEM_INODE
 	HEARTBEAT_SYSTEM_INODE,
 	GLOBAL_BITMAP_SYSTEM_INODE,
 	USER_QUOTA_SYSTEM_INODE,

_

Patches currently in -mm which might be from [email protected] are

author maintainer tree notice Applied
#56 lore raw

[merged] ocfs2-fix-panic-on-nfs-server-over-ocfs2.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: ocfs2: fix panic on nfs server over ocfs2 has been removed from the -mm tree. Its filename was ocfs2-fix-panic-on-nfs-server-over-ocfs2.patch

The patch titled
Subject: ocfs2: fix panic on nfs server over ocfs2
has been removed from the -mm tree. Its filename was
ocfs2-fix-panic-on-nfs-server-over-ocfs2.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Junxiao Bi <[email protected]>
Subject: ocfs2: fix panic on nfs server over ocfs2

The following kernel panic was captured when running nfs server over ocfs2, at that time ocfs2_test_inode_bit() was checking whether one inode locating at "blkno" 5 was valid, that is ocfs2 root inode, its "suballoc_slot" was OCFS2_INVALID_SLOT(65535) and it was allocted from //global_inode_alloc, but here it wrongly assumed that it was got from per slot inode alloctor which would cause array overflow and trigger kernel panic.

[430033.469151] BUG: unable to handle kernel paging request at
0000000000001088
[430033.469367] IP: [<ffffffff816f6898>] _raw_spin_lock+0x18/0xf0
[430033.469567] PGD 1e06ba067 PUD 1e9e7d067 PMD 0
[430033.469769] Oops: 0002 [#1] SMP
[430033.469975] Modules linked in: tun nfsd lockd grace nfs_acl auth_rpcgss

ocfs2 xen_netback xen_blkback xen_gntalloc xen_gntdev xen_evtchn xenfs xen_privcmd ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bnx2fc fcoe libfcoe libfc sunrpc bridge 8021q mrp garp stp llc bonding dm_round_robin scsi_dh_emc dm_multipath iTCO_wdt iTCO_vendor_support pcspkr sb_edac edac_core i2c_i801 i2c_core lpc_ich mfd_core sg ext4 jbd2 mbcache2 sd_mod ahci libahci lpfc scsi_transport_fc be2net vxlan udp_tunnel ip6_udp_tunnel mpt3sas scsi_transport_sas raid_class crc32c_intel be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdio libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi dm_mirror dm_region_hash dm_log dm_mod

[430033.472350] CPU: 6 PID: 24873 Comm: nfsd Not tainted
4.1.12-124.36.1.el6uek.x86_64 #2
[430033.472719] Hardware name: Huawei CH121 V3/IT11SGCA1, BIOS 3.87
02/02/2018
[430033.472910] task: ffff88005ae98000 ti: ffff88005ae94000 task.ti:
ffff88005ae94000
[430033.473277] RIP: e030:[<ffffffff816f6898>]  [<ffffffff816f6898>]
_raw_spin_lock+0x18/0xf0
[430033.473655] RSP: e02b:ffff88005ae97908  EFLAGS: 00010206
[430033.473850] RAX: ffff88005ae98000 RBX: 0000000000001088 RCX:
0000000000000000
[430033.474205] RDX: 0000000000020000 RSI: 0000000000000009 RDI:
0000000000001088
[430033.474574] RBP: ffff88005ae97928 R08: 0000000000000000 R09:
ffff880212878e00
[430033.474938] R10: 0000000000007ff0 R11: 0000000000000000 R12:
0000000000001088
[430033.475324] R13: ffff8800063c0aa8 R14: ffff8800650c27d0 R15:
000000000000ffff
[430033.475721] FS:  0000000000000000(0000) GS:ffff880218180000(0000)
knlGS:ffff880218180000
[430033.476199] CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033
[430033.476390] CR2: 0000000000001088 CR3: 00000002033d0000 CR4:
0000000000042660
[430033.476760] Stack:
[430033.476942]  0000000000001000 0000000000001088 ffff8800063c0aa8
ffff8800650c27d0
[430033.477329]  ffff88005ae97948 ffffffff8122a3de 0000000000000009
ffff8800063c0000
[430033.477718]  ffff88005ae979e8 ffffffffc0714e43 ffff88005ae97968
ffff88019de8f958
[430033.478104] Call Trace:
[430033.478286]  [<ffffffff8122a3de>] igrab+0x1e/0x60
[430033.478494]  [<ffffffffc0714e43>] ocfs2_get_system_file_inode+0x63/0x3a0
[ocfs2]
[430033.478870]  [<ffffffffc06a87df>] ? ocfs2_read_blocks_sync+0x13f/0x3c0
[ocfs2]
[430033.479267]  [<ffffffffc06ff2d8>] ocfs2_test_inode_bit+0x328/0xa00
[ocfs2]
[430033.479498]  [<ffffffffc06bef5a>] ocfs2_get_parent+0xba/0x3e0 [ocfs2]
[430033.479730]  [<ffffffff8129b305>] reconnect_path+0xb5/0x300
[430033.479933]  [<ffffffff8129b646>] exportfs_decode_fh+0xf6/0x2b0
[430033.480124]  [<ffffffffc0814af0>] ? nfsd_proc_getattr+0xa0/0xa0 [nfsd]
[430033.480294]  [<ffffffffc081a682>] ? exp_find+0xe2/0x190 [nfsd]
[430033.480461]  [<ffffffff810e5a7e>] ? irq_get_irq_data+0xe/0x10
[430033.480627]  [<ffffffff810ea1a7>] ? __call_rcu_nocb_enqueue+0xd7/0xe0
[430033.480794]  [<ffffffff810eb9e8>] ? __call_rcu+0xe8/0x360
[430033.480959]  [<ffffffffc0815860>] fh_verify+0x350/0x660 [nfsd]
[430033.481134]  [<ffffffffc0535076>] ? cache_check+0x56/0x3a0 [sunrpc]
[430033.481317]  [<ffffffffc0823a4d>] nfsd4_putfh+0x4d/0x60 [nfsd]
[430033.481505]  [<ffffffffc0826003>] nfsd4_proc_compound+0x3d3/0x6f0 [nfsd]
[430033.481730]  [<ffffffffc0811f60>] nfsd_dispatch+0xe0/0x290 [nfsd]
[430033.481950]  [<ffffffffc052b752>] ? svc_tcp_adjust_wspace+0x12/0x30
[sunrpc]
[430033.482152]  [<ffffffffc052a512>] svc_process_common+0x412/0x6a0 [sunrpc]
[430033.482351]  [<ffffffffc052a8c3>] svc_process+0x123/0x210 [sunrpc]
[430033.482550]  [<ffffffffc081190f>] nfsd+0xff/0x170 [nfsd]
[430033.482744]  [<ffffffffc0811810>] ? nfsd_destroy+0x80/0x80 [nfsd]
[430033.482943]  [<ffffffff810a7aeb>] kthread+0xcb/0xf0
[430033.483151]  [<ffffffff816f10ea>] ? __schedule+0x24a/0x810
[430033.483354]  [<ffffffff816f10ea>] ? __schedule+0x24a/0x810
[430033.483553]  [<ffffffff810a7a20>] ? kthread_create_on_node+0x180/0x180
[430033.483777]  [<ffffffff816f72a1>] ret_from_fork+0x61/0x90
[430033.483976]  [<ffffffff810a7a20>] ? kthread_create_on_node+0x180/0x180
[430033.484191] Code: 83 c2 02 0f b7 f2 e8 18 dc 91 ff 66 90 eb bf 0f 1f 40
00 55 48 89 e5 41 56 41 55 41 54 53 0f 1f 44 00 00 48 89 fb ba 00 00 02 00
<f0> 0f c1 17 89 d0 45 31 e4 45 31 ed c1 e8 10 66 39 d0 41 89 c6
[430033.485174] RIP  [<ffffffff816f6898>] _raw_spin_lock+0x18/0xf0
[430033.485370]  RSP <ffff88005ae97908>
[430033.485566] CR2: 0000000000001088
[430033.486223] ---[ end trace 7264463cd1aac8f9 ]---
[430033.666368] Kernel panic - not syncing: Fatal exception

---

 fs/ocfs2/suballoc.c |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)
fs/ocfs2/suballoc.c renamed from fs/ocfs2/suballoc.c~ocfs2-fix-panic-on-nfs-server-over-ocfs2 +6 -3
@@ -2825,9 +2825,12 @@ int ocfs2_test_inode_bit(struct ocfs2_su
 		goto bail;
 	}
 
-	inode_alloc_inode =
-		ocfs2_get_system_file_inode(osb, INODE_ALLOC_SYSTEM_INODE,
-					    suballoc_slot);
+	if (suballoc_slot == (u16)OCFS2_INVALID_SLOT)
+		inode_alloc_inode = ocfs2_get_system_file_inode(osb,
+			GLOBAL_INODE_ALLOC_SYSTEM_INODE, suballoc_slot);
+	else
+		inode_alloc_inode = ocfs2_get_system_file_inode(osb,
+			INODE_ALLOC_SYSTEM_INODE, suballoc_slot);
 	if (!inode_alloc_inode) {
 		/* the error code could be inaccurate, but we are not able to
 		 * get the correct one. */

_

Patches currently in -mm which might be from [email protected] are

author maintainer tree notice Applied
#57 lore raw

[merged] ocfs2-fix-panic-on-nfs-server-over-ocfs2.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: ocfs2: fix panic on nfs server over ocfs2 has been removed from the -mm tree. Its filename was ocfs2-fix-panic-on-nfs-server-over-ocfs2.patch

The patch titled
Subject: ocfs2: fix panic on nfs server over ocfs2
has been removed from the -mm tree. Its filename was
ocfs2-fix-panic-on-nfs-server-over-ocfs2.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Junxiao Bi <[email protected]>
Subject: ocfs2: fix panic on nfs server over ocfs2

The following kernel panic was captured when running nfs server over ocfs2, at that time ocfs2_test_inode_bit() was checking whether one inode locating at "blkno" 5 was valid, that is ocfs2 root inode, its "suballoc_slot" was OCFS2_INVALID_SLOT(65535) and it was allocted from //global_inode_alloc, but here it wrongly assumed that it was got from per slot inode alloctor which would cause array overflow and trigger kernel panic.

[430033.469151] BUG: unable to handle kernel paging request at
0000000000001088
[430033.469367] IP: [<ffffffff816f6898>] _raw_spin_lock+0x18/0xf0
[430033.469567] PGD 1e06ba067 PUD 1e9e7d067 PMD 0
[430033.469769] Oops: 0002 [#1] SMP
[430033.469975] Modules linked in: tun nfsd lockd grace nfs_acl auth_rpcgss

ocfs2 xen_netback xen_blkback xen_gntalloc xen_gntdev xen_evtchn xenfs xen_privcmd ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bnx2fc fcoe libfcoe libfc sunrpc bridge 8021q mrp garp stp llc bonding dm_round_robin scsi_dh_emc dm_multipath iTCO_wdt iTCO_vendor_support pcspkr sb_edac edac_core i2c_i801 i2c_core lpc_ich mfd_core sg ext4 jbd2 mbcache2 sd_mod ahci libahci lpfc scsi_transport_fc be2net vxlan udp_tunnel ip6_udp_tunnel mpt3sas scsi_transport_sas raid_class crc32c_intel be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdio libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi dm_mirror dm_region_hash dm_log dm_mod

[430033.472350] CPU: 6 PID: 24873 Comm: nfsd Not tainted
4.1.12-124.36.1.el6uek.x86_64 #2
[430033.472719] Hardware name: Huawei CH121 V3/IT11SGCA1, BIOS 3.87
02/02/2018
[430033.472910] task: ffff88005ae98000 ti: ffff88005ae94000 task.ti:
ffff88005ae94000
[430033.473277] RIP: e030:[<ffffffff816f6898>]  [<ffffffff816f6898>]
_raw_spin_lock+0x18/0xf0
[430033.473655] RSP: e02b:ffff88005ae97908  EFLAGS: 00010206
[430033.473850] RAX: ffff88005ae98000 RBX: 0000000000001088 RCX:
0000000000000000
[430033.474205] RDX: 0000000000020000 RSI: 0000000000000009 RDI:
0000000000001088
[430033.474574] RBP: ffff88005ae97928 R08: 0000000000000000 R09:
ffff880212878e00
[430033.474938] R10: 0000000000007ff0 R11: 0000000000000000 R12:
0000000000001088
[430033.475324] R13: ffff8800063c0aa8 R14: ffff8800650c27d0 R15:
000000000000ffff
[430033.475721] FS:  0000000000000000(0000) GS:ffff880218180000(0000)
knlGS:ffff880218180000
[430033.476199] CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033
[430033.476390] CR2: 0000000000001088 CR3: 00000002033d0000 CR4:
0000000000042660
[430033.476760] Stack:
[430033.476942]  0000000000001000 0000000000001088 ffff8800063c0aa8
ffff8800650c27d0
[430033.477329]  ffff88005ae97948 ffffffff8122a3de 0000000000000009
ffff8800063c0000
[430033.477718]  ffff88005ae979e8 ffffffffc0714e43 ffff88005ae97968
ffff88019de8f958
[430033.478104] Call Trace:
[430033.478286]  [<ffffffff8122a3de>] igrab+0x1e/0x60
[430033.478494]  [<ffffffffc0714e43>] ocfs2_get_system_file_inode+0x63/0x3a0
[ocfs2]
[430033.478870]  [<ffffffffc06a87df>] ? ocfs2_read_blocks_sync+0x13f/0x3c0
[ocfs2]
[430033.479267]  [<ffffffffc06ff2d8>] ocfs2_test_inode_bit+0x328/0xa00
[ocfs2]
[430033.479498]  [<ffffffffc06bef5a>] ocfs2_get_parent+0xba/0x3e0 [ocfs2]
[430033.479730]  [<ffffffff8129b305>] reconnect_path+0xb5/0x300
[430033.479933]  [<ffffffff8129b646>] exportfs_decode_fh+0xf6/0x2b0
[430033.480124]  [<ffffffffc0814af0>] ? nfsd_proc_getattr+0xa0/0xa0 [nfsd]
[430033.480294]  [<ffffffffc081a682>] ? exp_find+0xe2/0x190 [nfsd]
[430033.480461]  [<ffffffff810e5a7e>] ? irq_get_irq_data+0xe/0x10
[430033.480627]  [<ffffffff810ea1a7>] ? __call_rcu_nocb_enqueue+0xd7/0xe0
[430033.480794]  [<ffffffff810eb9e8>] ? __call_rcu+0xe8/0x360
[430033.480959]  [<ffffffffc0815860>] fh_verify+0x350/0x660 [nfsd]
[430033.481134]  [<ffffffffc0535076>] ? cache_check+0x56/0x3a0 [sunrpc]
[430033.481317]  [<ffffffffc0823a4d>] nfsd4_putfh+0x4d/0x60 [nfsd]
[430033.481505]  [<ffffffffc0826003>] nfsd4_proc_compound+0x3d3/0x6f0 [nfsd]
[430033.481730]  [<ffffffffc0811f60>] nfsd_dispatch+0xe0/0x290 [nfsd]
[430033.481950]  [<ffffffffc052b752>] ? svc_tcp_adjust_wspace+0x12/0x30
[sunrpc]
[430033.482152]  [<ffffffffc052a512>] svc_process_common+0x412/0x6a0 [sunrpc]
[430033.482351]  [<ffffffffc052a8c3>] svc_process+0x123/0x210 [sunrpc]
[430033.482550]  [<ffffffffc081190f>] nfsd+0xff/0x170 [nfsd]
[430033.482744]  [<ffffffffc0811810>] ? nfsd_destroy+0x80/0x80 [nfsd]
[430033.482943]  [<ffffffff810a7aeb>] kthread+0xcb/0xf0
[430033.483151]  [<ffffffff816f10ea>] ? __schedule+0x24a/0x810
[430033.483354]  [<ffffffff816f10ea>] ? __schedule+0x24a/0x810
[430033.483553]  [<ffffffff810a7a20>] ? kthread_create_on_node+0x180/0x180
[430033.483777]  [<ffffffff816f72a1>] ret_from_fork+0x61/0x90
[430033.483976]  [<ffffffff810a7a20>] ? kthread_create_on_node+0x180/0x180
[430033.484191] Code: 83 c2 02 0f b7 f2 e8 18 dc 91 ff 66 90 eb bf 0f 1f 40
00 55 48 89 e5 41 56 41 55 41 54 53 0f 1f 44 00 00 48 89 fb ba 00 00 02 00
<f0> 0f c1 17 89 d0 45 31 e4 45 31 ed c1 e8 10 66 39 d0 41 89 c6
[430033.485174] RIP  [<ffffffff816f6898>] _raw_spin_lock+0x18/0xf0
[430033.485370]  RSP <ffff88005ae97908>
[430033.485566] CR2: 0000000000001088
[430033.486223] ---[ end trace 7264463cd1aac8f9 ]---
[430033.666368] Kernel panic - not syncing: Fatal exception

---

 fs/ocfs2/suballoc.c |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)
fs/ocfs2/suballoc.c renamed from fs/ocfs2/suballoc.c~ocfs2-fix-panic-on-nfs-server-over-ocfs2 +6 -3
@@ -2825,9 +2825,12 @@ int ocfs2_test_inode_bit(struct ocfs2_su
 		goto bail;
 	}
 
-	inode_alloc_inode =
-		ocfs2_get_system_file_inode(osb, INODE_ALLOC_SYSTEM_INODE,
-					    suballoc_slot);
+	if (suballoc_slot == (u16)OCFS2_INVALID_SLOT)
+		inode_alloc_inode = ocfs2_get_system_file_inode(osb,
+			GLOBAL_INODE_ALLOC_SYSTEM_INODE, suballoc_slot);
+	else
+		inode_alloc_inode = ocfs2_get_system_file_inode(osb,
+			INODE_ALLOC_SYSTEM_INODE, suballoc_slot);
 	if (!inode_alloc_inode) {
 		/* the error code could be inaccurate, but we are not able to
 		 * get the correct one. */

_

Patches currently in -mm which might be from [email protected] are

author maintainer tree notice Applied
#58 lore raw

[merged] ocfs2-fix-value-of-ocfs2_invalid_slot.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: ocfs2: fix value of OCFS2_INVALID_SLOT has been removed from the -mm tree. Its filename was ocfs2-fix-value-of-ocfs2_invalid_slot.patch

The patch titled
Subject: ocfs2: fix value of OCFS2_INVALID_SLOT
has been removed from the -mm tree. Its filename was
ocfs2-fix-value-of-ocfs2_invalid_slot.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Junxiao Bi <[email protected]>
Subject: ocfs2: fix value of OCFS2_INVALID_SLOT

In the ocfs2 disk layout, slot number is 16 bits, but in ocfs2 implementation, slot number is 32 bits. Usually this will not cause any issue, because slot number is converted from u16 to u32, but OCFS2_INVALID_SLOT was defined as -1, when an invalid slot number from disk was obtained, its value was (u16)-1, and it was converted to u32. Then the following checking in get_local_system_inode will be always skipped:

static struct inode **get_local_system_inode(struct ocfs2_super *osb,

                                               int type,
                                               u32 slot)
 {
 	BUG_ON(slot == OCFS2_INVALID_SLOT);
	...

}

---

 fs/ocfs2/ocfs2_fs.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/ocfs2/ocfs2_fs.h renamed from fs/ocfs2/ocfs2_fs.h~ocfs2-fix-value-of-ocfs2_invalid_slot +1 -1
@@ -290,7 +290,7 @@
 #define OCFS2_MAX_SLOTS			255
 
 /* Slot map indicator for an empty slot */
-#define OCFS2_INVALID_SLOT		-1
+#define OCFS2_INVALID_SLOT		((u16)-1)
 
 #define OCFS2_VOL_UUID_LEN		16
 #define OCFS2_MAX_VOL_LABEL_LEN		64

_

Patches currently in -mm which might be from [email protected] are

author maintainer tree notice Applied
#59 lore raw

[merged] lib-fix-test_hmmc-reference-after-free.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: lib: fix test_hmm.c reference after free has been removed from the -mm tree. Its filename was lib-fix-test_hmmc-reference-after-free.patch

The patch titled
Subject: lib: fix test_hmm.c reference after free
has been removed from the -mm tree. Its filename was
lib-fix-test_hmmc-reference-after-free.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Randy Dunlap <[email protected]>
Subject: lib: fix test_hmm.c reference after free

Coccinelle scripts report the following errors:

lib/test_hmm.c:523:20-26: ERROR: reference preceded by free on line 521 lib/test_hmm.c:524:21-27: ERROR: reference preceded by free on line 521 lib/test_hmm.c:523:28-35: ERROR: devmem is NULL but dereferenced. lib/test_hmm.c:524:29-36: ERROR: devmem is NULL but dereferenced.

Fix these by using the local variable 'res' instead of devmem.

---

 lib/test_hmm.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
lib/test_hmm.c renamed from lib/test_hmm.c~lib-fix-test_hmmc-reference-after-free +1 -2
@@ -520,8 +520,7 @@ static bool dmirror_allocate_chunk(struc
 err_free:
 	kfree(devmem);
 err_release:
-	release_mem_region(devmem->pagemap.res.start,
-			   resource_size(&devmem->pagemap.res));
+	release_mem_region(res->start, resource_size(res));
 err:
 	mutex_unlock(&mdevice->devmem_lock);
 	return false;

_

Patches currently in -mm which might be from [email protected] are

author maintainer tree notice Applied
#60 lore raw

[merged] mm-slab-fix-sign-conversion-problem-in-memcg_uncharge_slab.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: mm, slab: fix sign conversion problem in memcg_uncharge_slab() has been removed from the -mm tree. Its filename was…

The patch titled
Subject: mm, slab: fix sign conversion problem in memcg_uncharge_slab()
has been removed from the -mm tree. Its filename was
mm-slab-fix-sign-conversion-problem-in-memcg_uncharge_slab.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Waiman Long <[email protected]>
Subject: mm, slab: fix sign conversion problem in memcg_uncharge_slab()

It was found that running the LTP test on a PowerPC system could produce erroneous values in /proc/meminfo, like:

  MemTotal:       531915072 kB
  MemFree:        507962176 kB
  MemAvailable:   1100020596352 kB

Using bisection, the problem is tracked down to commit 9c315e4d7d8c ("mm:
memcg/slab: cache page number in memcg_(un)charge_slab()").

In memcg_uncharge_slab() with a "int order" argument:

  unsigned int nr_pages = 1 << order;
    :
  mod_lruvec_state(lruvec, cache_vmstat_idx(s), -nr_pages);

The mod_lruvec_state() function will eventually call the __mod_zone_page_state() which accepts a long argument. Depending on the compiler and how inlining is done, "-nr_pages" may be treated as a negative number or a very large positive number. Apparently, it was treated as a large positive number in that PowerPC system leading to incorrect stat counts. This problem hasn't been seen in x86-64 yet, perhaps the gcc compiler there has some slight difference in behavior.

It is fixed by making nr_pages a signed value. For consistency, a similar change is applied to memcg_charge_slab() as well.

Fixes 9c315e4d7d8c ("mm: memcg/slab: cache page number in memcg_(un)charge_slab()").
Cc Christoph Lameter <[email protected]>
Cc Pekka Enberg <[email protected]>
Cc David Rientjes <[email protected]>
Cc Joonsoo Kim <[email protected]>
Cc Shakeel Butt <[email protected]>
Cc Johannes Weiner <[email protected]>
Cc Michal Hocko <[email protected]>
Cc Vladimir Davydov <[email protected]>

---

 mm/slab.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
mm/slab.h renamed from mm/slab.h~mm-slab-fix-sign-conversion-problem-in-memcg_uncharge_slab +2 -2
@@ -348,7 +348,7 @@ static __always_inline int memcg_charge_
 					     gfp_t gfp, int order,
 					     struct kmem_cache *s)
 {
-	unsigned int nr_pages = 1 << order;
+	int nr_pages = 1 << order;
 	struct mem_cgroup *memcg;
 	struct lruvec *lruvec;
 	int ret;
@@ -388,7 +388,7 @@ out:
 static __always_inline void memcg_uncharge_slab(struct page *page, int order,
 						struct kmem_cache *s)
 {
-	unsigned int nr_pages = 1 << order;
+	int nr_pages = 1 << order;
 	struct mem_cgroup *memcg;
 	struct lruvec *lruvec;
 

_

Patches currently in -mm which might be from [email protected] are

mm-treewide-rename-kzfree-to-kfree_sensitive.patch sched-mm-optimize-current_gfp_context.patch

author maintainer tree notice Applied
#61 lore raw

[merged] mm-slab-use-memzero_explicit-in-kzfree.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: mm/slab: use memzero_explicit() in kzfree() has been removed from the -mm tree. Its filename was mm-slab-use-memzero_explicit-in-kzfree.patch

The patch titled
Subject: mm/slab: use memzero_explicit() in kzfree()
has been removed from the -mm tree. Its filename was
mm-slab-use-memzero_explicit-in-kzfree.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Waiman Long <[email protected]>
Subject: mm/slab: use memzero_explicit() in kzfree()

The kzfree() function is normally used to clear some sensitive information, like encryption keys, in the buffer before freeing it back to the pool. Memset() is currently used for buffer clearing. However unlikely, there is still a non-zero probability that the compiler may choose to optimize away the memory clearing especially if LTO is being used in the future. To make sure that this optimization will never happen, memzero_explicit(), which is introduced in v3.18, is now used in kzfree() to future-proof it.

Fixes 3ef0e5ba4673 ("slab: introduce kzfree()")
Cc David Howells <[email protected]>
Cc Jarkko Sakkinen <[email protected]>
Cc James Morris <[email protected]>
Cc "Serge E. Hallyn" <[email protected]>
Cc Joe Perches <[email protected]>
Cc Matthew Wilcox <[email protected]>
Cc David Rientjes <[email protected]>
Cc Johannes Weiner <[email protected]>
Cc Dan Carpenter <[email protected]>
Cc "Jason A . Donenfeld" <[email protected]>

---

 mm/slab_common.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
mm/slab_common.c renamed from mm/slab_common.c~mm-slab-use-memzero_explicit-in-kzfree +1 -1
@@ -1726,7 +1726,7 @@ void kzfree(const void *p)
 	if (unlikely(ZERO_OR_NULL_PTR(mem)))
 		return;
 	ks = ksize(mem);
-	memset(mem, 0, ks);
+	memzero_explicit(mem, ks);
 	kfree(mem);
 }
 EXPORT_SYMBOL(kzfree);

_

Patches currently in -mm which might be from [email protected] are

mm-treewide-rename-kzfree-to-kfree_sensitive.patch sched-mm-optimize-current_gfp_context.patch

author maintainer tree notice Applied
#62 lore raw

[merged] slub-cure-list_slab_objects-from-double-fix.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: slub: cure list_slab_objects() from double fix has been removed from the -mm tree. Its filename was slub-cure-list_slab_objects-from-double-fix.patch

The patch titled
Subject: slub: cure list_slab_objects() from double fix
has been removed from the -mm tree. Its filename was
slub-cure-list_slab_objects-from-double-fix.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Sebastian Andrzej Siewior <[email protected]>
Subject: slub: cure list_slab_objects() from double fix

According to Christopher Lameter two fixes have been merged for the same problem. As far as I can tell, the code does not acquire the list_lock and invoke kmalloc(). list_slab_objects() misses an unlock (the counterpart to get_map()) and the memory allocated in free_partial() isn't used.

Revert the mentioned commit.

Fixes aa456c7aebb14 ("slub: remove kmalloc under list_lock from list_slab_objects() V2")
Cc Pekka Enberg <[email protected]>
Cc David Rientjes <[email protected]>
Cc Joonsoo Kim <[email protected]>
Cc Thomas Gleixner <[email protected]>
Cc Yu Zhao <[email protected]>

---

 mm/slub.c |   19 ++++---------------
 1 file changed, 4 insertions(+), 15 deletions(-)
mm/slub.c renamed from mm/slub.c~slub-cure-list_slab_objects-from-double-fix +4 -14
@@ -3766,15 +3766,13 @@ error:
 }
 
 static void list_slab_objects(struct kmem_cache *s, struct page *page,
-			      const char *text, unsigned long *map)
+			      const char *text)
 {
 #ifdef CONFIG_SLUB_DEBUG
 	void *addr = page_address(page);
+	unsigned long *map;
 	void *p;
 
-	if (!map)
-		return;
-
 	slab_err(s, page, text, s->name);
 	slab_lock(page);
 
@@ -3786,6 +3784,7 @@ static void list_slab_objects(struct kme
 			print_tracking(s, p);
 		}
 	}
+	put_map(map);
 	slab_unlock(page);
 #endif
 }
@@ -3799,11 +3798,6 @@ static void free_partial(struct kmem_cac
 {
 	LIST_HEAD(discard);
 	struct page *page, *h;
-	unsigned long *map = NULL;
-
-#ifdef CONFIG_SLUB_DEBUG
-	map = bitmap_alloc(oo_objects(s->max), GFP_KERNEL);
-#endif
 
 	BUG_ON(irqs_disabled());
 	spin_lock_irq(&n->list_lock);
@@ -3813,16 +3807,11 @@ static void free_partial(struct kmem_cac
 			list_add(&page->slab_list, &discard);
 		} else {
 			list_slab_objects(s, page,
-			  "Objects remaining in %s on __kmem_cache_shutdown()",
-			  map);
+			  "Objects remaining in %s on __kmem_cache_shutdown()");
 		}
 	}
 	spin_unlock_irq(&n->list_lock);
 
-#ifdef CONFIG_SLUB_DEBUG
-	bitmap_free(map);
-#endif
author maintainer tree notice Applied
#63 lore raw

[merged] mm-fix-swap-cache-node-allocation-mask.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: mm: fix swap cache node allocation mask has been removed from the -mm tree. Its filename was mm-fix-swap-cache-node-allocation-mask.patch

The patch titled
Subject: mm: fix swap cache node allocation mask
has been removed from the -mm tree. Its filename was
mm-fix-swap-cache-node-allocation-mask.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Hugh Dickins <[email protected]>
Subject: mm: fix swap cache node allocation mask

https://bugzilla.kernel.org/show_bug.cgi?id=208085 reports that a slightly overcommitted load, testing swap and zram along with i915, splats and keeps on splatting, when it had better fail less noisily:

gnome-shell: page allocation failure: order:0, mode:0x400d0(__GFP_IO|__GFP_FS|__GFP_COMP|__GFP_RECLAIMABLE), nodemask=(null),cpuset=/,mems_allowed=0

CPU: 2 PID: 1155 Comm: gnome-shell Not tainted 5.7.0-1.fc33.x86_64 #1
Call Trace:
dump_stack+0x64/0x88
warn_alloc.cold+0x75/0xd9
__alloc_pages_slowpath.constprop.0+0xcfa/0xd30
__alloc_pages_nodemask+0x2df/0x320
alloc_slab_page+0x195/0x310
allocate_slab+0x3c5/0x440
___slab_alloc+0x40c/0x5f0
__slab_alloc+0x1c/0x30
kmem_cache_alloc+0x20e/0x220
xas_nomem+0x28/0x70
add_to_swap_cache+0x321/0x400
__read_swap_cache_async+0x105/0x240
swap_cluster_readahead+0x22c/0x2e0
shmem_swapin+0x8e/0xc0
shmem_swapin_page+0x196/0x740
shmem_getpage_gfp+0x3a2/0xa60
shmem_read_mapping_page_gfp+0x32/0x60
shmem_get_pages+0x155/0x5e0 [i915]
__i915_gem_object_get_pages+0x68/0xa0 [i915]
i915_vma_pin+0x3fe/0x6c0 [i915]
eb_add_vma+0x10b/0x2c0 [i915]
i915_gem_do_execbuffer+0x704/0x3430 [i915]
i915_gem_execbuffer2_ioctl+0x1ea/0x3e0 [i915]
drm_ioctl_kernel+0x86/0xd0 [drm]
drm_ioctl+0x206/0x390 [drm]
ksys_ioctl+0x82/0xc0
__x64_sys_ioctl+0x16/0x20
do_syscall_64+0x5b/0xf0
entry_SYSCALL_64_after_hwframe+0x44/0xa9

Reported on 5.7, but it goes back really to 3.1: when shmem_read_mapping_page_gfp() was implemented for use by i915, and allowed for __GFP_NORETRY and __GFP_NOWARN flags in most places, but missed swapin's "& GFP_KERNEL" mask for page tree node allocation in __read_swap_cache_async() - that was to mask off HIGHUSER_MOVABLE bits from what page cache uses, but GFP_RECLAIM_MASK is now what's needed.

---

 mm/swap_state.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
mm/swap_state.c renamed from mm/swap_state.c~mm-fix-swap-cache-node-allocation-mask +0 -0
@@ -21,7 +21,7 @@
 #include <linux/vmalloc.h>
 #include <linux/swap_slots.h>
 #include <linux/huge_mm.h>
author maintainer tree notice Applied
#64 lore raw

[merged] mm-memoryc-properly-pte_offset_map_lock-unlock-in-vm_insert_pages.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: mm/memory.c: properly pte_offset_map_lock/unlock in vm_insert_pages() has been removed from the -mm tree. Its filename was…

The patch titled
Subject: mm/memory.c: properly pte_offset_map_lock/unlock in vm_insert_pages()
has been removed from the -mm tree. Its filename was
mm-memoryc-properly-pte_offset_map_lock-unlock-in-vm_insert_pages.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Arjun Roy <[email protected]>
Subject: mm/memory.c: properly pte_offset_map_lock/unlock in vm_insert_pages()

Calls to pte_offset_map() in vm_insert_pages() are erroneously not matched with a call to pte_unmap(). This would cause problems on architectures where that is not a no-op.

This patch does away with the non-traditional locking in the existing code, and instead uses pte_offset_map_lock/unlock() as usual, incrementing PTE as necessary. The PTE pointer is kept within bounds since we clamp it with PTRS_PER_PTE.

Fixes 8cd3984d81d5 ("mm/memory.c: add vm_insert_pages()")
Cc Eric Dumazet <[email protected]>
Cc Hugh Dickins <[email protected]>
Cc Soheil Hassas Yeganeh <[email protected]>

---

 mm/memory.c |   21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)
mm/memory.c renamed from mm/memory.c~mm-memoryc-properly-pte_offset_map_lock-unlock-in-vm_insert_pages +11 -10
@@ -1498,7 +1498,7 @@ out:
 }
 
 #ifdef pte_index
-static int insert_page_in_batch_locked(struct mm_struct *mm, pmd_t *pmd,
+static int insert_page_in_batch_locked(struct mm_struct *mm, pte_t *pte,
 			unsigned long addr, struct page *page, pgprot_t prot)
 {
 	int err;
@@ -1506,8 +1506,9 @@ static int insert_page_in_batch_locked(s
 	if (!page_count(page))
 		return -EINVAL;
 	err = validate_page_before_insert(page);
-	return err ? err : insert_page_into_pte_locked(
-		mm, pte_offset_map(pmd, addr), addr, page, prot);
+	if (err)
+		return err;
+	return insert_page_into_pte_locked(mm, pte, addr, page, prot);
 }
 
 /* insert_pages() amortizes the cost of spinlock operations
@@ -1517,7 +1518,8 @@ static int insert_pages(struct vm_area_s
 			struct page **pages, unsigned long *num, pgprot_t prot)
 {
 	pmd_t *pmd = NULL;
-	spinlock_t *pte_lock = NULL;
+	pte_t *start_pte, *pte;
+	spinlock_t *pte_lock;
 	struct mm_struct *const mm = vma->vm_mm;
 	unsigned long curr_page_idx = 0;
 	unsigned long remaining_pages_total = *num;
@@ -1536,18 +1538,17 @@ more:
 	ret = -ENOMEM;
 	if (pte_alloc(mm, pmd))
 		goto out;
-	pte_lock = pte_lockptr(mm, pmd);
 
 	while (pages_to_write_in_pmd) {
 		int pte_idx = 0;
 		const int batch_size = min_t(int, pages_to_write_in_pmd, 8);
 
-		spin_lock(pte_lock);
-		for (; pte_idx < batch_size; ++pte_idx) {
-			int err = insert_page_in_batch_locked(mm, pmd,
+		start_pte = pte_offset_map_lock(mm, pmd, addr, &pte_lock);
+		for (pte = start_pte; pte_idx < batch_size; ++pte, ++pte_idx) {
+			int err = insert_page_in_batch_locked(mm, pte,
 				addr, pages[curr_page_idx], prot);
 			if (unlikely(err)) {
-				spin_unlock(pte_lock);
+				pte_unmap_unlock(start_pte, pte_lock);
 				ret = err;
 				remaining_pages_total -= pte_idx;
 				goto out;
@@ -1555,7 +1556,7 @@ more:
 			addr += PAGE_SIZE;
 			++curr_page_idx;
 		}
-		spin_unlock(pte_lock);
+		pte_unmap_unlock(start_pte, pte_lock);
 		pages_to_write_in_pmd -= batch_size;
 		remaining_pages_total -= batch_size;
 	}

_

Patches currently in -mm which might be from [email protected] are

author maintainer tree notice Applied
#65 lore raw

[merged] mm-debug_vm_pgtable-fix-build-failure-with-powerpc-8xx.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: mm/debug_vm_pgtable: fix build failure with powerpc 8xx has been removed from the -mm tree. Its filename was mm-debug_vm_pgtable-fix-build-failure-with-powerpc-8xx.patch

The patch titled
Subject: mm/debug_vm_pgtable: fix build failure with powerpc 8xx
has been removed from the -mm tree. Its filename was
mm-debug_vm_pgtable-fix-build-failure-with-powerpc-8xx.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Christophe Leroy <[email protected]>
Subject: mm/debug_vm_pgtable: fix build failure with powerpc 8xx

Since commit 9e343b467c70 ("READ_ONCE: Enforce atomicity for {READ,WRITE}_ONCE() memory accesses"), READ_ONCE() cannot be used anymore to read complex page table entries. This leads to:

CC mm/debug_vm_pgtable.o
In file included from ./include/asm-generic/bug.h:5,

                 from ./arch/powerpc/include/asm/bug.h:109,
                 from ./include/linux/bug.h:5,
                 from ./include/linux/mmdebug.h:5,
                 from ./include/linux/gfp.h:5,
                 from mm/debug_vm_pgtable.c:13:

In function 'pte_clear_tests',
inlined from 'debug_vm_pgtable' at mm/debug_vm_pgtable.c:363:2:
./include/linux/compiler.h:392:38: error: call to '__compiletime_assert_210' declared with attribute error: Unsupported access size for {READ,WRITE}_ONCE().
392 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^
./include/linux/compiler.h:373:4: note: in definition of macro '__compiletime_assert'

  373 |    prefix ## suffix();    \
      |    ^~~~~~
./include/linux/compiler.h:392:2: note: in expansion of macro '_compiletime_assert'
  392 |  _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
      |  ^~~~~~~~~~~~~~~~~~~
./include/linux/compiler.h:405:2: note: in expansion of macro 'compiletime_assert'
  405 |  compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long long), \
      |  ^~~~~~~~~~~~~~~~~~
./include/linux/compiler.h:291:2: note: in expansion of macro 'compiletime_assert_rwonce_type'
  291 |  compiletime_assert_rwonce_type(x);    \
      |  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mm/debug_vm_pgtable.c:249:14: note: in expansion of macro 'READ_ONCE'
  249 |  pte_t pte = READ_ONCE(*ptep);
      |              ^~~~~~~~~

make[2]: *** [mm/debug_vm_pgtable.o] Error 1

Fix it by using the recently added ptep_get() helper.

Fixes 9e343b467c70 ("READ_ONCE: Enforce atomicity for {READ,WRITE}_ONCE() memory accesses")
Cc Benjamin Herrenschmidt <[email protected]>
Cc Paul Mackerras <[email protected]>
Cc Michael Ellerman <[email protected]>
Cc "Peter Zijlstra (Intel)" <[email protected]>

---

 mm/debug_vm_pgtable.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
mm/debug_vm_pgtable.c renamed from mm/debug_vm_pgtable.c~mm-debug_vm_pgtable-fix-build-failure-with-powerpc-8xx +2 -2
@@ -246,13 +246,13 @@ static void __init pgd_populate_tests(st
 static void __init pte_clear_tests(struct mm_struct *mm, pte_t *ptep,
 				   unsigned long vaddr)
 {
-	pte_t pte = READ_ONCE(*ptep);
+	pte_t pte = ptep_get(ptep);
 
 	pte = __pte(pte_val(pte) | RANDOM_ORVALUE);
 	set_pte_at(mm, vaddr, ptep, pte);
 	barrier();
 	pte_clear(mm, vaddr, ptep);
-	pte = READ_ONCE(*ptep);
+	pte = ptep_get(ptep);
 	WARN_ON(!pte_none(pte));
 }
 

_

Patches currently in -mm which might be from [email protected] are

author maintainer tree notice Applied
#66 lore raw

[merged] make-asm-generic-cacheflushh-more-standalone.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: make asm-generic/cacheflush.h more standalone has been removed from the -mm tree. Its filename was make-asm-generic-cacheflushh-more-standalone.patch

The patch titled
Subject: make asm-generic/cacheflush.h more standalone
has been removed from the -mm tree. Its filename was
make-asm-generic-cacheflushh-more-standalone.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Stephen Rothwell <[email protected]>
Subject: make asm-generic/cacheflush.h more standalone

Some s390 builds get these warnings:

include/asm-generic/cacheflush.h:16:42: warning: 'struct mm_struct' declared inside parameter list will not be visible outside of this definition or declaration include/asm-generic/cacheflush.h:22:46: warning: 'struct mm_struct' declared inside parameter list will not be visible outside of this definition or declaration include/asm-generic/cacheflush.h:28:45: warning: 'struct vm_area_struct' declared inside parameter list will not be visible outside of this definition or declaration include/asm-generic/cacheflush.h:36:44: warning: 'struct vm_area_struct' declared inside parameter list will not be visible outside of this definition or declaration include/asm-generic/cacheflush.h:44:45: warning: 'struct page' declared inside parameter list will not be visible outside of this definition or declaration include/asm-generic/cacheflush.h:52:50: warning: 'struct address_space' declared inside parameter list will not be visible outside of this definition or declaration include/asm-generic/cacheflush.h:58:52: warning: 'struct address_space' declared inside parameter list will not be visible outside of this definition or declaration include/asm-generic/cacheflush.h:75:17: warning: 'struct page' declared inside parameter list will not be visible outside of this definition or declaration include/asm-generic/cacheflush.h:74:45: warning: 'struct vm_area_struct' declared inside parameter list will not be visible outside of this definition or declaration include/asm-generic/cacheflush.h:82:16: warning: 'struct page' declared inside parameter list will not be visible outside of this definition or declaration include/asm-generic/cacheflush.h:81:50: warning: 'struct vm_area_struct' declared inside parameter list will not be visible outside of this definition or declaration

Forward declare the named structs to get rid of these.

Fixes e0cf615d725c ("asm-generic: don't include <linux/mm.h> in cacheflush.h")
Cc Heiko Carstens <[email protected]>
Cc Vasily Gorbik <[email protected]>
Cc Christian Borntraeger <[email protected]>

---

 include/asm-generic/cacheflush.h |    5 +++++
 1 file changed, 5 insertions(+)
include/asm-generic/cacheflush.h renamed from include/asm-generic/cacheflush.h~make-asm-generic-cacheflushh-more-standalone +5 -0
@@ -2,6 +2,11 @@
 #ifndef _ASM_GENERIC_CACHEFLUSH_H
 #define _ASM_GENERIC_CACHEFLUSH_H
 
+struct mm_struct;
+struct vm_area_struct;
+struct page;
+struct address_space;
+
 /*
  * The cache doesn't need to be flushed when TLB entries change when
  * the cache is mapped to physical memory, not virtual memory

_

Patches currently in -mm which might be from [email protected] are

author maintainer tree notice Applied
#67 lore raw

[merged] media-omap3isp-remove-cacheflushh.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: media: omap3isp: remove cacheflush.h has been removed from the -mm tree. Its filename was media-omap3isp-remove-cacheflushh.patch

The patch titled
Subject: media: omap3isp: remove cacheflush.h
has been removed from the -mm tree. Its filename was
media-omap3isp-remove-cacheflushh.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Nathan Chancellor <[email protected]>
Subject: media: omap3isp: remove cacheflush.h

After mm.h was removed from the asm-generic version of cacheflush.h, s390 allyesconfig shows several warnings of the following nature:

In file included from ./arch/s390/include/generated/asm/cacheflush.h:1,
from drivers/media/platform/omap3isp/isp.c:42:
./include/asm-generic/cacheflush.h:16:42: warning: 'struct mm_struct' declared inside parameter list will not be visible outside of this definition or declaration

As Geert and Laurent point out, this driver does not need this header in the two files that include it. Remove it so there are no warnings.

---

 drivers/media/platform/omap3isp/isp.c      |    2 --
 drivers/media/platform/omap3isp/ispvideo.c |    1 -
 2 files changed, 3 deletions(-)
drivers/media/platform/omap3isp/isp.c renamed from drivers/media/platform/omap3isp/isp.c~media-omap3isp-remove-cacheflushh +0 -1
@@ -39,8 +39,6 @@
  *	Troy Laramy <[email protected]>
  */
 
-#include <asm/cacheflush.h>
author maintainer tree notice Applied
#68 lore raw

[merged] mm-fix-a-warning-while-make-xmldocs.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: mm/vmalloc.c: fix a warning while make xmldocs has been removed from the -mm tree. Its filename was mm-fix-a-warning-while-make-xmldocs.patch

The patch titled
Subject: mm/vmalloc.c: fix a warning while make xmldocs
has been removed from the -mm tree. Its filename was
mm-fix-a-warning-while-make-xmldocs.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Masanari Iida <[email protected]>
Subject: mm/vmalloc.c: fix a warning while make xmldocs

This patch fixes following warning while "make xmldocs"

./mm/vmalloc.c:1877: warning: Excess function parameter 'prot' description in 'vm_map_ram'

This warning started since a patch was merged in 5.8-rc1.

Fixes d4efd79a81ab ("mm: remove the prot argument from vm_map_ram")

---

 mm/vmalloc.c |    1 -
 1 file changed, 1 deletion(-)
mm/vmalloc.c renamed from mm/vmalloc.c~mm-fix-a-warning-while-make-xmldocs +0 -1
@@ -1862,7 +1862,6 @@ EXPORT_SYMBOL(vm_unmap_ram);
  * @pages: an array of pointers to the pages to be mapped
  * @count: number of pages
  * @node: prefer to allocate data structures on this node
- * @prot: memory protection to use. PAGE_KERNEL for regular RAM
  *
  * If you use this function for less than VMAP_MAX_ALLOC pages, it could be
  * faster than vmap so it's good.  But if you mix long-life and short-life

_

Patches currently in -mm which might be from [email protected] are

author maintainer tree notice Applied
#69 lore raw

[merged] mm-memcontrol-handle-div0-crash-race-condition-in-memorylow.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: mm: memcontrol: handle div0 crash race condition in memory.low has been removed from the -mm tree. Its filename was…

The patch titled
Subject: mm: memcontrol: handle div0 crash race condition in memory.low
has been removed from the -mm tree. Its filename was
mm-memcontrol-handle-div0-crash-race-condition-in-memorylow.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Johannes Weiner <[email protected]>
Subject: mm: memcontrol: handle div0 crash race condition in memory.low

Tejun reports seeing rare div0 crashes in memory.low stress testing:

[37228.504582] RIP: 0010:mem_cgroup_calculate_protection+0xed/0x150
[37228.505059] Code: 0f 46 d1 4c 39 d8 72 57 f6 05 16 d6 42 01 40 74 1f 4c 39 d8 76 1a 4c 39 d1 76 15 4c 29 d1 4c 29 d8 4d 29 d9 31 d2 48 0f af c1 <49> f7 f1 49 01 c2 4c 89 96 38 01 00 00 5d c3 48 0f af c7 31 d2 49
[37228.506254] RSP: 0018:ffffa14e01d6fcd0 EFLAGS: 00010246
[37228.506769] RAX: 000000000243e384 RBX: 0000000000000000 RCX: 0000000000008f4b
[37228.507319] RDX: 0000000000000000 RSI: ffff8b89bee84000 RDI: 0000000000000000
[37228.507869] RBP: ffffa14e01d6fcd0 R08: ffff8b89ca7d40f8 R09: 0000000000000000
[37228.508376] R10: 0000000000000000 R11: 00000000006422f7 R12: 0000000000000000
[37228.508881] R13: ffff8b89d9617000 R14: ffff8b89bee84000 R15: ffffa14e01d6fdb8
[37228.509397] FS:  0000000000000000(0000) GS:ffff8b8a1f1c0000(0000) knlGS:0000000000000000
[37228.509917] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[37228.510442] CR2: 00007f93b1fc175b CR3: 000000016100a000 CR4: 0000000000340ea0
[37228.511076] Call Trace:
[37228.511561]  shrink_node+0x1e5/0x6c0
[37228.512044]  balance_pgdat+0x32d/0x5f0
[37228.512521]  kswapd+0x1d7/0x3d0
[37228.513346]  ? wait_woken+0x80/0x80
[37228.514170]  kthread+0x11c/0x160
[37228.514983]  ? balance_pgdat+0x5f0/0x5f0
[37228.515797]  ? kthread_park+0x90/0x90
[37228.516593]  ret_from_fork+0x1f/0x30

This happens when parent_usage == siblings_protected. We check that usage is bigger than protected, which should imply parent_usage being bigger than siblings_protected. However, we don't read (or even update) these values atomically, and they can be out of sync as the memory state changes under us. A bit of fluctuation around the target protection isn't a big deal, but we need to handle the div0 case.

Check the parent state explicitly to make sure we have a reasonable positive value for the divisor.

---

 mm/memcontrol.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)
mm/memcontrol.c renamed from mm/memcontrol.c~mm-memcontrol-handle-div0-crash-race-condition-in-memorylow +4 -0
@@ -6360,11 +6360,16 @@ static unsigned long effective_protectio
 	 * We're using unprotected memory for the weight so that if
 	 * some cgroups DO claim explicit protection, we don't protect
 	 * the same bytes twice.
+	 *
+	 * Check both usage and parent_usage against the respective
+	 * protected values. One should imply the other, but they
+	 * aren't read atomically - make sure the division is sane.
 	 */
 	if (!(cgrp_dfl_root.flags & CGRP_ROOT_MEMORY_RECURSIVE_PROT))
 		return ep;
author maintainer tree notice Applied
#70 lore raw

[merged] mm-memcontrol-fix-do-not-put-the-css-reference.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: mm/memcontrol.c: add missed css_put() has been removed from the -mm tree. Its filename was mm-memcontrol-fix-do-not-put-the-css-reference.patch

The patch titled
Subject: mm/memcontrol.c: add missed css_put()
has been removed from the -mm tree. Its filename was
mm-memcontrol-fix-do-not-put-the-css-reference.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Muchun Song <[email protected]>
Subject: mm/memcontrol.c: add missed css_put()

We should put the css reference when memory allocation failed.

Fixes f0a3a24b532d ("mm: memcg/slab: rework non-root kmem_cache lifecycle management")
Cc Johannes Weiner <[email protected]>
Cc Vladimir Davydov <[email protected]>
Cc Qian Cai <[email protected]>

---

 mm/memcontrol.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
mm/memcontrol.c renamed from mm/memcontrol.c~mm-memcontrol-fix-do-not-put-the-css-reference +3 -1
@@ -2772,8 +2772,10 @@ static void memcg_schedule_kmem_cache_cr
 		return;
 
 	cw = kmalloc(sizeof(*cw), GFP_NOWAIT | __GFP_NOWARN);
-	if (!cw)
+	if (!cw) {
+		css_put(&memcg->css);
 		return;
+	}
 
 	cw->memcg = memcg;
 	cw->cachep = cachep;

_

Patches currently in -mm which might be from [email protected] are

author maintainer tree notice Applied
#71 lore raw

[merged] mm-memcg-prevent-missed-memorylow-load-tears.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: mm/memcontrol.c: prevent missed memory.low load tears has been removed from the -mm tree. Its filename was mm-memcg-prevent-missed-memorylow-load-tears.patch

The patch titled
Subject: mm/memcontrol.c: prevent missed memory.low load tears
has been removed from the -mm tree. Its filename was
mm-memcg-prevent-missed-memorylow-load-tears.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Chris Down <[email protected]>
Subject: mm/memcontrol.c: prevent missed memory.low load tears

Looks like one of these got missed when massaging in f86b810c2610 ("mm,
memcg: prevent memory.low load/store tearing") with other linux-mm changes.

---

 mm/memcontrol.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
mm/memcontrol.c renamed from mm/memcontrol.c~mm-memcg-prevent-missed-memorylow-load-tears +3 -2
@@ -6423,7 +6423,7 @@ enum mem_cgroup_protection mem_cgroup_pr
 
 	if (parent == root) {
 		memcg->memory.emin = READ_ONCE(memcg->memory.min);
-		memcg->memory.elow = memcg->memory.low;
+		memcg->memory.elow = READ_ONCE(memcg->memory.low);
 		goto out;
 	}
 
@@ -6435,7 +6435,8 @@ enum mem_cgroup_protection mem_cgroup_pr
 			atomic_long_read(&parent->memory.children_min_usage)));
 
 	WRITE_ONCE(memcg->memory.elow, effective_protection(usage, parent_usage,
-			memcg->memory.low, READ_ONCE(parent->memory.elow),
+			READ_ONCE(memcg->memory.low),
+			READ_ONCE(parent->memory.elow),
 			atomic_long_read(&parent->memory.children_low_usage)));
 
 out:

_

Patches currently in -mm which might be from [email protected] are

author maintainer tree notice Applied
#72 lore raw

[merged] docs-mm-gup-minor-documentation-update.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: docs: mm/gup: minor documentation update has been removed from the -mm tree. Its filename was docs-mm-gup-minor-documentation-update.patch

The patch titled
Subject: docs: mm/gup: minor documentation update
has been removed from the -mm tree. Its filename was
docs-mm-gup-minor-documentation-update.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Souptick Joarder <[email protected]>
Subject: docs: mm/gup: minor documentation update

Now there are 5 cases. Updated the same.

---

 Documentation/core-api/pin_user_pages.rst |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Documentation/core-api/pin_user_pages.rst renamed from Documentation/core-api/pin_user_pages.rst~docs-mm-gup-minor-documentation-update +1 -1
@@ -33,7 +33,7 @@ all combinations of get*(), pin*(), FOLL
 pin_user_pages*() APIs are clearly distinct from the get_user_pages*() APIs, so
 that's a natural dividing line, and a good point to make separate wrapper calls.
 In other words, use pin_user_pages*() for DMA-pinned pages, and
-get_user_pages*() for other cases. There are four cases described later on in
+get_user_pages*() for other cases. There are five cases described later on in
 this document, to further clarify that concept.
 
 FOLL_PIN and FOLL_GET are mutually exclusive for a given gup call. However,

_

Patches currently in -mm which might be from [email protected] are

author maintainer tree notice Applied
#73 lore raw

[merged] doc-thp-cow-fault-no-longer-allocate-thp.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: doc: THP CoW fault no longer allocate THP has been removed from the -mm tree. Its filename was doc-thp-cow-fault-no-longer-allocate-thp.patch

The patch titled
Subject: doc: THP CoW fault no longer allocate THP
has been removed from the -mm tree. Its filename was
doc-thp-cow-fault-no-longer-allocate-thp.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Yang Shi <[email protected]>
Subject: doc: THP CoW fault no longer allocate THP

Since commit 3917c80280c93a7123f ("thp: change CoW semantics for anon-THP"), THP CoW page fault is rewritten. Now it just splits pmd then fallback to base page fault, it doesn't try to allocate THP anymore. So it is no longer counted in THP_FAULT_ALLOC.

Remove the obsolete statement in documentation about THP CoW allocation to avoid confusion.

---

 Documentation/admin-guide/cgroup-v2.rst    |    4 ++--
 Documentation/admin-guide/mm/transhuge.rst |    3 +--
 2 files changed, 3 insertions(+), 4 deletions(-)
Documentation/admin-guide/cgroup-v2.rst renamed from Documentation/admin-guide/cgroup-v2.rst~doc-thp-cow-fault-no-longer-allocate-thp +2 -2
@@ -1356,8 +1356,8 @@ PAGE_SIZE multiple when read back.
 
 	  thp_fault_alloc
 		Number of transparent hugepages which were allocated to satisfy
-		a page fault, including COW faults. This counter is not present
-		when CONFIG_TRANSPARENT_HUGEPAGE is not set.
+		a page fault. This counter is not present when CONFIG_TRANSPARENT_HUGEPAGE
+                is not set.
 
 	  thp_collapse_alloc
 		Number of transparent hugepages which were allocated to allow
Documentation/admin-guide/mm/transhuge.rst renamed from Documentation/admin-guide/mm/transhuge.rst~doc-thp-cow-fault-no-longer-allocate-thp +1 -2
@@ -305,8 +305,7 @@ monitor how successfully the system is p
 
 thp_fault_alloc
 	is incremented every time a huge page is successfully
-	allocated to handle a page fault. This applies to both the
-	first time a page is faulted and for COW faults.
+	allocated to handle a page fault.
 
 thp_collapse_alloc
 	is incremented by khugepaged when it has found

_

Patches currently in -mm which might be from [email protected] are

mm-filemap-clear-idle-flag-for-writes.patch mm-filemap-add-missing-fgp_-flags-in-kerneldoc-comment-for-pagecache_get_page.patch mm-thp-remove-debug_cow-switch.patch

author maintainer tree notice Applied
#74 lore raw

[merged] mm-workingset-age-nonresident-information-alongside-anonymous-pages.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: mm: workingset: age nonresident information alongside anonymous pages has been removed from the -mm tree. Its filename was…

The patch titled
Subject: mm: workingset: age nonresident information alongside anonymous pages
has been removed from the -mm tree. Its filename was
mm-workingset-age-nonresident-information-alongside-anonymous-pages.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Johannes Weiner <[email protected]>
Subject: mm: workingset: age nonresident information alongside anonymous pages

Patch series "fix for "mm: balance LRU lists based on relative thrashing" patchset"

This patchset fixes some problems of the patchset, "mm: balance LRU lists based on relative thrashing", which is now merged on the mainline.

Patch "mm: workingset: let cache workingset challenge anon fix" is the result of discussion with Johannes. See following link.

http://lkml.kernel.org/r/[email protected]

And, the other two are minor things which are found when I try to rebase my patchset.

This patch (of 3):
After ("mm: workingset: let cache workingset challenge anon fix"), we compare refault distances to active_file + anon. But age of the non-resident information is only driven by the file LRU. As a result, we may overestimate the recency of any incoming refaults and activate them too eagerly, causing unnecessary LRU churn in certain situations.

Make anon aging drive nonresident age as well to address that.

Fixes 34e58cac6d8f2a ("mm: workingset: let cache workingset challenge anon")
Cc Rik van Riel <[email protected]>
Cc Minchan Kim <[email protected]>
Cc Michal Hocko <[email protected]>

---

 include/linux/mmzone.h |    4 +--
 include/linux/swap.h   |    1 
 mm/vmscan.c            |    3 ++
 mm/workingset.c        |   46 ++++++++++++++++++++++-----------------
 4 files changed, 33 insertions(+), 21 deletions(-)
include/linux/mmzone.h renamed from include/linux/mmzone.h~mm-workingset-age-nonresident-information-alongside-anonymous-pages +2 -2
@@ -257,8 +257,8 @@ struct lruvec {
 	 */
 	unsigned long			anon_cost;
 	unsigned long			file_cost;
-	/* Evictions & activations on the inactive file list */
-	atomic_long_t			inactive_age;
+	/* Non-resident age, driven by LRU movement */
+	atomic_long_t			nonresident_age;
 	/* Refaults at the time of last reclaim cycle */
 	unsigned long			refaults;
 	/* Various lruvec state flags (enum lruvec_flags) */
include/linux/swap.h renamed from include/linux/swap.h~mm-workingset-age-nonresident-information-alongside-anonymous-pages +1 -0
@@ -313,6 +313,7 @@ struct vma_swap_readahead {
 };
 
 /* linux/mm/workingset.c */
+void workingset_age_nonresident(struct lruvec *lruvec, unsigned long nr_pages);
 void *workingset_eviction(struct page *page, struct mem_cgroup *target_memcg);
 void workingset_refault(struct page *page, void *shadow);
 void workingset_activation(struct page *page);
mm/vmscan.c renamed from mm/vmscan.c~mm-workingset-age-nonresident-information-alongside-anonymous-pages +3 -0
@@ -904,6 +904,7 @@ static int __remove_mapping(struct addre
 		__delete_from_swap_cache(page, swap);
 		xa_unlock_irqrestore(&mapping->i_pages, flags);
 		put_swap_page(page, swap);
+		workingset_eviction(page, target_memcg);
 	} else {
 		void (*freepage)(struct page *);
 		void *shadow = NULL;
@@ -1884,6 +1885,8 @@ static unsigned noinline_for_stack move_
 				list_add(&page->lru, &pages_to_free);
 		} else {
 			nr_moved += nr_pages;
+			if (PageActive(page))
+				workingset_age_nonresident(lruvec, nr_pages);
 		}
 	}
 
mm/workingset.c renamed from mm/workingset.c~mm-workingset-age-nonresident-information-alongside-anonymous-pages +27 -19

105 lines not on this page · raw message

_

Patches currently in -mm which might be from [email protected] are

mm-memcontrol-decouple-reference-counting-from-page-accounting.patch

author maintainer tree notice Applied
#75 lore raw

[merged] mm-swap-fix-for-mm-workingset-age-nonresident-information-alongside-anonymous-pages.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: mm/swap: fix for "mm: workingset: age nonresident information alongside anonymous pages" has been removed from the -mm tree. Its filename was…

The patch titled
Subject: mm/swap: fix for "mm: workingset: age nonresident information alongside anonymous pages"
has been removed from the -mm tree. Its filename was
mm-swap-fix-for-mm-workingset-age-nonresident-information-alongside-anonymous-pages.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Joonsoo Kim <[email protected]>
Subject: mm/swap: fix for "mm: workingset: age nonresident information alongside anonymous pages"

Non-file-lru page could also be activated in mark_page_accessed() and we need to count this activation for nonresident_age.

Note that it's better for this patch to be squashed into the patch "mm: workingset: age nonresident information alongside anonymous pages".

---

 mm/swap.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
mm/swap.c renamed from mm/swap.c~mm-swap-fix-for-mm-workingset-age-nonresident-information-alongside-anonymous-pages +1 -2
@@ -443,8 +443,7 @@ void mark_page_accessed(struct page *pag
 		else
 			__lru_cache_activate_page(page);
 		ClearPageReferenced(page);
-		if (page_is_file_lru(page))
-			workingset_activation(page);
+		workingset_activation(page);
 	}
 	if (page_is_idle(page))
 		clear_page_idle(page);

_

Patches currently in -mm which might be from [email protected] are

mm-page_isolation-prefer-the-node-of-the-source-page.patch mm-migrate-move-migration-helper-from-h-to-c.patch mm-hugetlb-unify-migration-callbacks.patch mm-hugetlb-make-hugetlb-migration-callback-cma-aware.patch mm-migrate-make-a-standard-migration-target-allocation-function.patch mm-gup-use-a-standard-migration-target-allocation-callback.patch mm-mempolicy-use-a-standard-migration-target-allocation-callback.patch mm-page_alloc-remove-a-wrapper-for-alloc_migration_target.patch

author maintainer tree notice Applied
#76 lore raw

[merged] mm-memory-fix-io-cost-for-anonymous-page.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: mm/memory: fix IO cost for anonymous page has been removed from the -mm tree. Its filename was mm-memory-fix-io-cost-for-anonymous-page.patch

The patch titled
Subject: mm/memory: fix IO cost for anonymous page
has been removed from the -mm tree. Its filename was
mm-memory-fix-io-cost-for-anonymous-page.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Joonsoo Kim <[email protected]>
Subject: mm/memory: fix IO cost for anonymous page

With synchronous IO swap device, swap-in is directly handled in fault code. Since IO cost notation isn't added there, with synchronous IO swap device, LRU balancing could be wrongly biased. Fix it to count it in fault code.

Fixes 314b57fb0460001 ("mm: balance LRU lists based on relative thrashing cache sizing")
Cc Joonsoo Kim <[email protected]>
Cc Michal Hocko <[email protected]>
Cc Minchan Kim <[email protected]>
Cc Rik van Riel <[email protected]>

---

 mm/memory.c |    8 ++++++++
 1 file changed, 8 insertions(+)
mm/memory.c renamed from mm/memory.c~mm-memory-fix-io-cost-for-anonymous-page +8 -0
@@ -3146,6 +3146,14 @@ vm_fault_t do_swap_page(struct vm_fault
 					goto out_page;
 				}
 
+				/*
+				 * XXX: Move to lru_cache_add() when it
+				 * supports new vs putback
+				 */
+				spin_lock_irq(&page_pgdat(page)->lru_lock);
+				lru_note_cost_page(page);
+				spin_unlock_irq(&page_pgdat(page)->lru_lock);
+
 				lru_cache_add(page);
 				swap_readpage(page, true);
 			}

_

Patches currently in -mm which might be from [email protected] are

mm-page_isolation-prefer-the-node-of-the-source-page.patch mm-migrate-move-migration-helper-from-h-to-c.patch mm-hugetlb-unify-migration-callbacks.patch mm-hugetlb-make-hugetlb-migration-callback-cma-aware.patch mm-migrate-make-a-standard-migration-target-allocation-function.patch mm-gup-use-a-standard-migration-target-allocation-callback.patch mm-mempolicy-use-a-standard-migration-target-allocation-callback.patch mm-page_alloc-remove-a-wrapper-for-alloc_migration_target.patch

author maintainer tree notice Applied
#77 lore raw

[merged] x86-hyperv-allocate-the-hypercall-page-with-only-read-and-execute-bits.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: x86/hyperv: allocate the hypercall page with only read and execute bits has been removed from the -mm tree. Its filename was…

The patch titled
Subject: x86/hyperv: allocate the hypercall page with only read and execute bits
has been removed from the -mm tree. Its filename was
x86-hyperv-allocate-the-hypercall-page-with-only-read-and-execute-bits.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Christoph Hellwig <[email protected]>
Subject: x86/hyperv: allocate the hypercall page with only read and execute bits

Patch series "fix a hyperv W^X violation and remove vmalloc_exec"

Dexuan reported a W^X violation due to the fact that the hyper hypercall page due switching it to be allocated using vmalloc_exec. The problem is that PAGE_KERNEL_EXEC as used by vmalloc_exec actually sets writable permissions in the pte. This series fixes the issue by switching to the low-level __vmalloc_node_range interface that allows specifing more detailed permissions instead. It then also open codes the other two callers and removes the somewhat confusing vmalloc_exec interface.

Peter noted that the hyper hypercall page allocation also has another long standing issue in that it shouldn't use the full vmalloc but just the module space. This issue is so far theoretical as the allocation is done early in the boot process. I plan to fix it with another bigger series for 5.9.

This patch (of 3):

Avoid a W^X violation cause by the fact that PAGE_KERNEL_EXEC includes the writable bit.

For this resurrect the removed PAGE_KERNEL_RX definitіon, but as PAGE_KERNEL_ROX to match arm64 and powerpc.

Fixes 78bb17f76edc ("x86/hyperv: use vmalloc_exec for the hypercall page")
Cc Catalin Marinas <[email protected]>
Cc Will Deacon <[email protected]>
Cc Jessica Yu <[email protected]>
Cc David Hildenbrand <[email protected]>

---

 arch/x86/hyperv/hv_init.c            |    4 +++-
 arch/x86/include/asm/pgtable_types.h |    2 ++
 2 files changed, 5 insertions(+), 1 deletion(-)
arch/x86/hyperv/hv_init.c renamed from arch/x86/hyperv/hv_init.c~x86-hyperv-allocate-the-hypercall-page-with-only-read-and-execute-bits +3 -1
@@ -375,7 +375,9 @@ void __init hyperv_init(void)
 	guest_id = generate_guest_id(0, LINUX_VERSION_CODE, 0);
 	wrmsrl(HV_X64_MSR_GUEST_OS_ID, guest_id);
 
-	hv_hypercall_pg = vmalloc_exec(PAGE_SIZE);
+	hv_hypercall_pg = __vmalloc_node_range(PAGE_SIZE, 1, VMALLOC_START,
+			VMALLOC_END, GFP_KERNEL, PAGE_KERNEL_ROX,
+			VM_FLUSH_RESET_PERMS, NUMA_NO_NODE, __func__);
 	if (hv_hypercall_pg == NULL) {
 		wrmsrl(HV_X64_MSR_GUEST_OS_ID, 0);
 		goto remove_cpuhp_state;
arch/x86/include/asm/pgtable_types.h renamed from arch/x86/include/asm/pgtable_types.h~x86-hyperv-allocate-the-hypercall-page-with-only-read-and-execute-bits +2 -0
@@ -194,6 +194,7 @@ enum page_cache_mode {
 #define _PAGE_TABLE_NOENC	 (__PP|__RW|_USR|___A|   0|___D|   0|   0)
 #define _PAGE_TABLE		 (__PP|__RW|_USR|___A|   0|___D|   0|   0| _ENC)
 #define __PAGE_KERNEL_RO	 (__PP|   0|   0|___A|__NX|___D|   0|___G)
+#define __PAGE_KERNEL_ROX	 (__PP|   0|   0|___A|   0|___D|   0|___G)
 #define __PAGE_KERNEL_NOCACHE	 (__PP|__RW|   0|___A|__NX|___D|   0|___G| __NC)
 #define __PAGE_KERNEL_VVAR	 (__PP|   0|_USR|___A|__NX|___D|   0|___G)
 #define __PAGE_KERNEL_LARGE	 (__PP|__RW|   0|___A|__NX|___D|_PSE|___G)
@@ -219,6 +220,7 @@ enum page_cache_mode {
 #define PAGE_KERNEL_RO		__pgprot_mask(__PAGE_KERNEL_RO         | _ENC)
 #define PAGE_KERNEL_EXEC	__pgprot_mask(__PAGE_KERNEL_EXEC       | _ENC)
 #define PAGE_KERNEL_EXEC_NOENC	__pgprot_mask(__PAGE_KERNEL_EXEC       |    0)
+#define PAGE_KERNEL_ROX		__pgprot_mask(__PAGE_KERNEL_ROX        | _ENC)
 #define PAGE_KERNEL_NOCACHE	__pgprot_mask(__PAGE_KERNEL_NOCACHE    | _ENC)
 #define PAGE_KERNEL_LARGE	__pgprot_mask(__PAGE_KERNEL_LARGE      | _ENC)
 #define PAGE_KERNEL_LARGE_EXEC	__pgprot_mask(__PAGE_KERNEL_LARGE_EXEC | _ENC)

_

Patches currently in -mm which might be from [email protected] are

author maintainer tree notice Applied
#78 lore raw

[merged] arm64-use-page_kernel_rox-directly-in-alloc_insn_page.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: arm64: use PAGE_KERNEL_ROX directly in alloc_insn_page has been removed from the -mm tree. Its filename was arm64-use-page_kernel_rox-directly-in-alloc_insn_page.patch

The patch titled
Subject: arm64: use PAGE_KERNEL_ROX directly in alloc_insn_page
has been removed from the -mm tree. Its filename was
arm64-use-page_kernel_rox-directly-in-alloc_insn_page.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Christoph Hellwig <[email protected]>
Subject: arm64: use PAGE_KERNEL_ROX directly in alloc_insn_page

Use PAGE_KERNEL_ROX directly instead of allocating RWX and setting the page read-only just after the allocation.

---

 arch/arm64/kernel/probes/kprobes.c |   12 +++---------
 1 file changed, 3 insertions(+), 9 deletions(-)
arch/arm64/kernel/probes/kprobes.c renamed from arch/arm64/kernel/probes/kprobes.c~arm64-use-page_kernel_rox-directly-in-alloc_insn_page +0 -7
@@ -120,15 +120,9 @@ int __kprobes arch_prepare_kprobe(struct
 
 void *alloc_insn_page(void)
 {
-	void *page;
-
-	page = vmalloc_exec(PAGE_SIZE);
-	if (page) {
-		set_memory_ro((unsigned long)page, 1);
-		set_vm_flush_reset_perms(page);
-	}
author maintainer tree notice Applied
#79 lore raw

[merged] mm-remove-vmalloc_exec.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: mm: remove vmalloc_exec has been removed from the -mm tree. Its filename was mm-remove-vmalloc_exec.patch

The patch titled
Subject: mm: remove vmalloc_exec
has been removed from the -mm tree. Its filename was
mm-remove-vmalloc_exec.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Christoph Hellwig <[email protected]>
Subject: mm: remove vmalloc_exec

Merge vmalloc_exec into its only caller. Note that for !CONFIG_MMU __vmalloc_node_range maps to __vmalloc, which directly clears the __GFP_HIGHMEM added by the vmalloc_exec stub anyway.

---

 include/linux/vmalloc.h |    1 -
 kernel/module.c         |    4 +++-
 mm/nommu.c              |   17 -----------------
 mm/vmalloc.c            |   20 --------------------
 4 files changed, 3 insertions(+), 39 deletions(-)
include/linux/vmalloc.h renamed from include/linux/vmalloc.h~mm-remove-vmalloc_exec +0 -1
@@ -106,7 +106,6 @@ extern void *vzalloc(unsigned long size)
 extern void *vmalloc_user(unsigned long size);
 extern void *vmalloc_node(unsigned long size, int node);
 extern void *vzalloc_node(unsigned long size, int node);
-extern void *vmalloc_exec(unsigned long size);
 extern void *vmalloc_32(unsigned long size);
 extern void *vmalloc_32_user(unsigned long size);
 extern void *__vmalloc(unsigned long size, gfp_t gfp_mask);
kernel/module.c renamed from kernel/module.c~mm-remove-vmalloc_exec +3 -1
@@ -2783,7 +2783,9 @@ static void dynamic_debug_remove(struct
 
 void * __weak module_alloc(unsigned long size)
 {
-	return vmalloc_exec(size);
+	return __vmalloc_node_range(size, 1, VMALLOC_START, VMALLOC_END,
+			GFP_KERNEL, PAGE_KERNEL_EXEC, VM_FLUSH_RESET_PERMS,
+			NUMA_NO_NODE, __func__);
 }
 
 bool __weak module_init_section(const char *name)
mm/nommu.c renamed from mm/nommu.c~mm-remove-vmalloc_exec +0 -17
@@ -291,23 +291,6 @@ void *vzalloc_node(unsigned long size, i
 EXPORT_SYMBOL(vzalloc_node);
 
 /**
- *	vmalloc_exec  -  allocate virtually contiguous, executable memory
- *	@size:		allocation size
- *
- *	Kernel-internal function to allocate enough pages to cover @size
- *	the page level allocator and map them into contiguous and
- *	executable kernel virtual space.
- *
- *	For tight control over page level allocator and protection flags
- *	use __vmalloc() instead.
- */
-
-void *vmalloc_exec(unsigned long size)
-{
-	return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM);
-}
-
-/**
  * vmalloc_32  -  allocate virtually contiguous memory (32bit addressable)
  *	@size:		allocation size
  *
mm/vmalloc.c renamed from mm/vmalloc.c~mm-remove-vmalloc_exec +0 -19
@@ -2695,26 +2695,6 @@ void *vzalloc_node(unsigned long size, i
 }
 EXPORT_SYMBOL(vzalloc_node);
 
-/**
- * vmalloc_exec - allocate virtually contiguous, executable memory
- * @size:	  allocation size
- *
- * Kernel-internal function to allocate enough pages to cover @size
- * the page level allocator and map them into contiguous and
- * executable kernel virtual space.
- *
- * For tight control over page level allocator and protection flags
- * use __vmalloc() instead.
- *
- * Return: pointer to the allocated memory or %NULL on error
- */
-void *vmalloc_exec(unsigned long size)
-{
-	return __vmalloc_node_range(size, 1, VMALLOC_START, VMALLOC_END,
-			GFP_KERNEL, PAGE_KERNEL_EXEC, VM_FLUSH_RESET_PERMS,
-			NUMA_NO_NODE, __builtin_return_address(0));
-}
author maintainer tree notice Applied
#80 lore raw

[merged] mm-fix-false-softlockup-during-pfn-range-removal.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: mm/memory_hotplug.c: fix false softlockup during pfn range removal has been removed from the -mm tree. Its filename was mm-fix-false-softlockup-during-pfn-range-removal.patch

The patch titled
Subject: mm/memory_hotplug.c: fix false softlockup during pfn range removal
has been removed from the -mm tree. Its filename was
mm-fix-false-softlockup-during-pfn-range-removal.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Ben Widawsky <[email protected]>
Subject: mm/memory_hotplug.c: fix false softlockup during pfn range removal

When working with very large nodes, poisoning the struct pages (for which there will be very many) can take a very long time. If the system is using voluntary preemptions, the software watchdog will not be able to detect forward progress. This patch addresses this issue by offering to give up time like __remove_pages() does. This behavior was introduced in v5.6 with: commit d33695b16a9f ("mm/memory_hotplug: poison memmap in remove_pfn_range_from_zone()")

Alternately, init_page_poison could do this cond_resched(), but it seems to me that the caller of init_page_poison() is what actually knows whether or not it should relax its own priority.

Based on Dan's notes, I think this is perfectly safe: commit f931ab479dd2 ("mm: fix devm_memremap_pages crash, use mem_hotplug_{begin, done}")

Aside from fixing the lockup, it is also a friendlier thing to do on lower core systems that might wipe out large chunks of hotplug memory (probably not a very common case).

Fixes this kind of splat:

[  352.142079] watchdog: BUG: soft lockup - CPU#46 stuck for 22s! [daxctl:9922]
[  352.150067] Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_tables ebtable_nat ebtable_broute ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_raw iptable_security rfkill ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ib_isert iscsi_target_mod ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib ib_umad vfat fat kmem intel_rapl_msr intel_rapl_common rpcrdma sunrpc rdma_ucm ib_iser isst_if_common rdma_cm skx_edac iw_cm ib_cm x86_pkg_temp_thermal libiscsi intel_powerclamp scsi_transport_iscsi coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel i40iw intel_cstate iTCO_wdt ib_uverbs iTCO_vendor_support device_dax ib_core joydev intel_uncore i2c_i801 lpc_ich ipmi_ssif ioatdma dca wmi ipmi_si ipmi_devintf ipmi_msghandler dax_pmem
[  352.150123]  dax_pmem_core acpi_pad acpi_power_meter drm ip_tables xfs libcrc32c nd_pmem nd_btt i40e e1000e crc32c_intel nfit
[  352.260774] irq event stamp: 138450
[  352.264692] hardirqs last  enabled at (138449): [<ffffffffa1001f26>] trace_hardirqs_on_thunk+0x1a/0x1c
[  352.275134] hardirqs last disabled at (138450): [<ffffffffa1001f42>] trace_hardirqs_off_thunk+0x1a/0x1c
[  352.285662] softirqs last  enabled at (138448): [<ffffffffa1e00347>] __do_softirq+0x347/0x456
[  352.295233] softirqs last disabled at (138443): [<ffffffffa10c416d>] irq_exit+0x7d/0xb0
[  352.304210] CPU: 46 PID: 9922 Comm: daxctl Not tainted 5.7.0-BEN-14238-g373c6049b336 #30
[  352.313283] Hardware name: Intel Corporation PURLEY/PURLEY, BIOS PLYXCRB1.86B.0578.D07.1902280810 02/28/2019
[  352.324308] RIP: 0010:memset_erms+0x9/0x10
[  352.328905] Code: c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 f3 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 <f3> aa 4c 89 c8 c3 90 49 89 fa 40 0f b6 ce 48 b8 01 01 01 01 01 01
[  352.349953] RSP: 0018:ffffc90021b5fd50 EFLAGS: 00010202 ORIG_RAX: ffffffffffffff13
[  352.358450] RAX: 00000000000000ff RBX: ffff88983ffd5000 RCX: 0000000065df0e40
[  352.366457] RDX: 00000003a0000000 RSI: 00000000ffffffff RDI: ffffea039b20f1c0
[  352.374465] RBP: ffff88983ffd6c00 R08: 0000000000000000 R09: ffffea0061000000
[  352.382473] R10: 0000000000000001 R11: 0000000000000000 R12: ffffea006f808000
[  352.390480] R13: 0000000001840000 R14: 000000000e800000 R15: ffff8997d7b764e0
[  352.398487] FS:  00007f724ef81780(0000) GS:ffff8997df100000(0000) knlGS:0000000000000000
[  352.407562] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  352.414011] CR2: 00007ffcd4070768 CR3: 000001178c722002 CR4: 00000000003606e0
[  352.422056] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  352.430092] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  352.438115] Call Trace:
[  352.440865]  remove_pfn_range_from_zone+0x3a/0x380
[  352.446244]  ? cpumask_next+0x17/0x20
[  352.450361]  memunmap_pages+0x17f/0x280
[  352.454670]  release_nodes+0x22a/0x260
[  352.458888]  __device_release_driver+0x172/0x220
[  352.464070]  device_driver_detach+0x3e/0xa0
[  352.468753]  unbind_store+0x113/0x130
[  352.472868]  kernfs_fop_write+0xdc/0x1c0
[  352.477273]  vfs_write+0xde/0x1d0
[  352.482218]  ksys_write+0x58/0xd0
[  352.487207]  do_syscall_64+0x5a/0x120
[  352.492529]  entry_SYSCALL_64_after_hwframe+0x49/0xb3
[  352.499446] RIP: 0033:0x7f724f40b5e7
[  352.504673] Code: Bad RIP value.
[  352.509484] RSP: 002b:00007ffcd40738f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[  352.519213] RAX: ffffffffffffffda RBX: 00007f724ef816a8 RCX: 00007f724f40b5e7
[  352.528410] RDX: 0000000000000007 RSI: 00005617d7cd1277 RDI: 0000000000000003
[  352.537573] RBP: 0000000000000003 R08: 00000000ffffffff R09: 00007ffcd40737d0
[  352.546764] R10: 0000000000000000 R11: 0000000000000246 R12: 00005617d7cd1277
[  352.555929] R13: 0000000000000000 R14: 0000000000000007 R15: 00005617d7cd1230
[  370.353742] Built 2 zonelists, mobility grouping on.  Total pages: 49050381
[  370.373317] Policy zone: Normal
[  374.948164] Built 3 zonelists, mobility grouping on.  Total pages: 49312525
[  375.017496] Policy zone: Normal

David said: "It really only is an issue for devmem. Ordinary hotplugged system memory is not affected (onlined/offlined in memory block granularity)."

Fixes commit d33695b16a9f ("mm/memory_hotplug: poison memmap in remove_pfn_range_from_zone()")
Cc Dan Williams <[email protected]>
Cc Vishal Verma <[email protected]>

---

 mm/memory_hotplug.c |   13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)
mm/memory_hotplug.c renamed from mm/memory_hotplug.c~mm-fix-false-softlockup-during-pfn-range-removal +11 -2
@@ -471,11 +471,20 @@ void __ref remove_pfn_range_from_zone(st
 				      unsigned long start_pfn,
 				      unsigned long nr_pages)
 {
+	const unsigned long end_pfn = start_pfn + nr_pages;
 	struct pglist_data *pgdat = zone->zone_pgdat;
-	unsigned long flags;
+	unsigned long pfn, cur_nr_pages, flags;
 
 	/* Poison struct pages because they are now uninitialized again. */
-	page_init_poison(pfn_to_page(start_pfn), sizeof(struct page) * nr_pages);
+	for (pfn = start_pfn; pfn < end_pfn; pfn += cur_nr_pages) {
+		cond_resched();
+
+		/* Select all remaining pages up to the next section boundary */
+		cur_nr_pages =
+			min(end_pfn - pfn, SECTION_ALIGN_UP(pfn + 1) - pfn);
+		page_init_poison(pfn_to_page(pfn),
+				 sizeof(struct page) * cur_nr_pages);
+	}
 
 #ifdef CONFIG_ZONE_DEVICE
 	/*

_

Patches currently in -mm which might be from [email protected] are

author maintainer tree notice Applied
#81 lore raw

[merged] maintainers-update-info-for-sparse.patch removed from -mm tree

In reply to Andrew Morton
The patch titled Subject: MAINTAINERS: update info for sparse has been removed from the -mm tree. Its filename was maintainers-update-info-for-sparse.patch

The patch titled
Subject: MAINTAINERS: update info for sparse
has been removed from the -mm tree. Its filename was
maintainers-update-info-for-sparse.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: Luc Van Oostenryck <[email protected]>
Subject: MAINTAINERS: update info for sparse

Update the info for sparse. More specifically:
* change W entry to point to sparse.docs.kernel.org
* add Q & B entry (patchwork & bugzilla)

---

 MAINTAINERS |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
MAINTAINERS renamed from MAINTAINERS~maintainers-update-info-for-sparse +3 -1
@@ -16058,8 +16058,10 @@ SPARSE CHECKER
 M:	"Luc Van Oostenryck" <[email protected]>
 L:	[email protected]
 S:	Maintained
-W:	https://sparse.wiki.kernel.org/
+W:	https://sparse.docs.kernel.org/
 T:	git git://git.kernel.org/pub/scm/devel/sparse/sparse.git
+Q:	https://patchwork.kernel.org/project/linux-sparse/list/
+B:	https://bugzilla.kernel.org/enter_bug.cgi?component=Sparse&product=Tools
 F:	include/linux/compiler.h
 
 SPEAR CLOCK FRAMEWORK SUPPORT

_

Patches currently in -mm which might be from [email protected] are

fix-annotation-of-ioreadwrite1632be.patch sparse-group-the-defines-by-functionality.patch lib-generic-radix-treec-remove-unneeded-__rcu.patch