February 2020 - Linux-stable-mirror

[patch 13/15] mm/sparsemem: pfn_to_page is not valid yet on SPARSEMEM

by akpm＠linux-foundation.org

From: Wei Yang <richardw.yang(a)linux.intel.com> Subject: mm/sparsemem: pfn_to_page is not valid yet on SPARSEMEM When we use SPARSEMEM instead of SPARSEMEM_VMEMMAP, pfn_to_page() doesn't work before sparse_init_one_section() is called. This leads to a crash when hotplug memory: [ 41.839170] BUG: unable to handle page fault for address: 0000000006400000 [ 41.840663] #PF: supervisor write access in kernel mode [ 41.841822] #PF: error_code(0x0002) - not-present page [ 41.842970] PGD 0 P4D 0 [ 41.843538] Oops: 0002 [#1] SMP PTI [ 41.844125] CPU: 3 PID: 221 Comm: kworker/u16:1 Tainted: G W 5.5.0-next-20200205+ #343 [ 41.845659] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 [ 41.846977] Workqueue: kacpi_hotplug acpi_hotplug_work_fn [ 41.847904] RIP: 0010:__memset+0x24/0x30 [ 41.848660] Code: cc cc cc cc cc cc 0f 1f 44 00 00 49 89 f9 48 89 d1 83 e2 07 48 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 [ 41.851836] RSP: 0018:ffffb43ac0373c80 EFLAGS: 00010a87 [ 41.852686] RAX: ffffffffffffffff RBX: ffff8a1518800000 RCX: 0000000000050000 [ 41.853824] RDX: 0000000000000000 RSI: 00000000000000ff RDI: 0000000006400000 [ 41.854967] RBP: 0000000000140000 R08: 0000000000100000 R09: 0000000006400000 [ 41.856107] R10: 0000000000000000 R11: 0000000000000002 R12: 0000000000000000 [ 41.857255] R13: 0000000000000028 R14: 0000000000000000 R15: ffff8a153ffd9280 [ 41.858414] FS: 0000000000000000(0000) GS:ffff8a153ab00000(0000) knlGS:0000000000000000 [ 41.859703] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 41.860627] CR2: 0000000006400000 CR3: 0000000136fca000 CR4: 00000000000006e0 [ 41.861716] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 41.862680] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 41.863628] Call Trace: [ 41.863983] sparse_add_section+0x1c9/0x26a [ 41.864570] __add_pages+0xbf/0x150 [ 41.865057] add_pages+0x12/0x60 [ 41.865489] add_memory_resource+0xc8/0x210 [ 41.866017] ? wake_up_q+0xa0/0xa0 [ 41.866416] __add_memory+0x62/0xb0 [ 41.866825] acpi_memory_device_add+0x13f/0x300 [ 41.867410] acpi_bus_attach+0xf6/0x200 [ 41.867890] acpi_bus_scan+0x43/0x90 [ 41.868448] acpi_device_hotplug+0x275/0x3d0 [ 41.868972] acpi_hotplug_work_fn+0x1a/0x30 [ 41.869473] process_one_work+0x1a7/0x370 [ 41.869953] worker_thread+0x30/0x380 [ 41.870396] ? flush_rcu_work+0x30/0x30 [ 41.870846] kthread+0x112/0x130 [ 41.871236] ? kthread_create_on_node+0x60/0x60 [ 41.871770] ret_from_fork+0x35/0x40 We should use memmap as it did. On x86 the impact is limited to x86_32 builds, or x86_64 configurations that override the default setting for SPARSEMEM_VMEMMAP. Other memory hotplug archs (arm64, ia64, and ppc) also default to SPARSEMEM_VMEMMAP=y. [dan.j.williams(a)intel.com: changelog update] {rppt(a)linux.ibm.com: changelog update] Link: http://lkml.kernel.org/r/20200219030454.4844-1-bhe@redhat.com Fixes: ba72b4c8cf60 ("mm/sparsemem: support sub-section hotplug") Signed-off-by: Wei Yang <richardw.yang(a)linux.intel.com> Signed-off-by: Baoquan He <bhe(a)redhat.com> Acked-by: David Hildenbrand <david(a)redhat.com> Reviewed-by: Baoquan He <bhe(a)redhat.com> Reviewed-by: Dan Williams <dan.j.williams(a)intel.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: Mike Rapoport <rppt(a)linux.ibm.com> Cc: Oscar Salvador <osalvador(a)suse.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/sparse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/sparse.c~mm-sparsemem-pfn_to_page-is-not-valid-yet-on-sparsemem +++ a/mm/sparse.c @@ -876,7 +876,7 @@ int __meminit sparse_add_section(int nid * Poison uninitialized struct pages in order to catch invalid flags * combinations. */ - page_init_poison(pfn_to_page(start_pfn), sizeof(struct page) * nr_pages); + page_init_poison(memmap, sizeof(struct page) * nr_pages); ms = __nr_to_section(section_nr); set_section_nid(section_nr, nid); _

4 years, 10 months

1
0
0 0

[patch 12/15] mm/vmscan.c: don't round up scan size for online memory cgroup

by akpm＠linux-foundation.org

From: Gavin Shan <gshan(a)redhat.com> Subject: mm/vmscan.c: don't round up scan size for online memory cgroup commit 68600f623d69 ("mm: don't miss the last page because of round-off error") makes the scan size round up to @denominator regardless of the memory cgroup's state, online or offline. This affects the overall reclaiming behavior: The corresponding LRU list is eligible for reclaiming only when its size logically right shifted by @sc->priority is bigger than zero in the former formula. For example, the inactive anonymous LRU list should have at least 0x4000 pages to be eligible for reclaiming when we have 60/12 for swappiness/priority and without taking scan/rotation ratio into account. After the roundup is applied, the inactive anonymous LRU list becomes eligible for reclaiming when its size is bigger than or equal to 0x1000 in the same condition. (0x4000 >> 12) * 60 / (60 + 140 + 1) = 1 ((0x1000 >> 12) * 60) + 200) / (60 + 140 + 1) = 1 aarch64 has 512MB huge page size when the base page size is 64KB. The memory cgroup that has a huge page is always eligible for reclaiming in that case. The reclaiming is likely to stop after the huge page is reclaimed, meaing the further iteration on @sc->priority and the silbing and child memory cgroups will be skipped. The overall behaviour has been changed. This fixes the issue by applying the roundup to offlined memory cgroups only, to give more preference to reclaim memory from offlined memory cgroup. It sounds reasonable as those memory is unlikedly to be used by anyone. The issue was found by starting up 8 VMs on a Ampere Mustang machine, which has 8 CPUs and 16 GB memory. Each VM is given with 2 vCPUs and 2GB memory. It took 264 seconds for all VMs to be completely up and 784MB swap is consumed after that. With this patch applied, it took 236 seconds and 60MB swap to do same thing. So there is 10% performance improvement for my case. Note that KSM is disable while THP is enabled in the testing. total used free shared buff/cache available Mem: 16196 10065 2049 16 4081 3749 Swap: 8175 784 7391 total used free shared buff/cache available Mem: 16196 11324 3656 24 1215 2936 Swap: 8175 60 8115 Link: http://lkml.kernel.org/r/20200211024514.8730-1-gshan@redhat.com Fixes: 68600f623d69 ("mm: don't miss the last page because of round-off error") Signed-off-by: Gavin Shan <gshan(a)redhat.com> Acked-by: Roman Gushchin <guro(a)fb.com> Cc: <stable(a)vger.kernel.org> [4.20+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/vmscan.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- a/mm/vmscan.c~mm-vmscan-dont-round-up-scan-size-for-online-memory-cgroup +++ a/mm/vmscan.c @@ -2415,10 +2415,13 @@ out: /* * Scan types proportional to swappiness and * their relative recent reclaim efficiency. - * Make sure we don't miss the last page - * because of a round-off error. + * Make sure we don't miss the last page on + * the offlined memory cgroups because of a + * round-off error. */ - scan = DIV64_U64_ROUND_UP(scan * fraction[file], + scan = mem_cgroup_online(memcg) ? + div64_u64(scan * fraction[file], denominator) : + DIV64_U64_ROUND_UP(scan * fraction[file], denominator); break; case SCAN_FILE: _

4 years, 10 months

1
0
0 0

[patch 10/15] mm/memcontrol.c: lost css_put in memcg_expand_shrinker_maps()

by akpm＠linux-foundation.org

From: Vasily Averin <vvs(a)virtuozzo.com> Subject: mm/memcontrol.c: lost css_put in memcg_expand_shrinker_maps() for_each_mem_cgroup() increases css reference counter for memory cgroup and requires to use mem_cgroup_iter_break() if the walk is cancelled. Link: http://lkml.kernel.org/r/c98414fb-7e1f-da0f-867a-9340ec4bd30b@virtuozzo.com Fixes: 0a4465d34028 ("mm, memcg: assign memcg-aware shrinkers bitmap to memcg") Signed-off-by: Vasily Averin <vvs(a)virtuozzo.com> Acked-by: Kirill Tkhai <ktkhai(a)virtuozzo.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Reviewed-by: Roman Gushchin <guro(a)fb.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Vladimir Davydov <vdavydov.dev(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memcontrol.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/mm/memcontrol.c~memcg-lost-css_put-in-memcg_expand_shrinker_maps +++ a/mm/memcontrol.c @@ -409,8 +409,10 @@ int memcg_expand_shrinker_maps(int new_i if (mem_cgroup_is_root(memcg)) continue; ret = memcg_expand_one_shrinker_map(memcg, size, old_size); - if (ret) + if (ret) { + mem_cgroup_iter_break(NULL, memcg); goto unlock; + } } unlock: if (!ret) _

4 years, 10 months

1
0
0 0

[patch 04/15] Revert "ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()"

by akpm＠linux-foundation.org

From: Ioanna Alifieraki <ioanna-maria.alifieraki(a)canonical.com> Subject: Revert "ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()" This reverts commit a97955844807e327df11aa33869009d14d6b7de0. Commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()") removes a lock that is needed. This leads to a process looping infinitely in exit_sem() and can also lead to a crash. There is a reproducer available in [1] and with the commit reverted the issue does not reproduce anymore. Using the reproducer found in [1] is fairly easy to reach a point where one of the child processes is looping infinitely in exit_sem between for(;;) and if (semid == -1) block, while it's trying to free its last sem_undo structure which has already been freed by freeary(). Each sem_undo struct is on two lists: one per semaphore set (list_id) and one per process (list_proc). The list_id list tracks undos by semaphore set, and the list_proc by process. Undo structures are removed either by freeary() or by exit_sem(). The freeary function is invoked when the user invokes a syscall to remove a semaphore set. During this operation freeary() traverses the list_id associated with the semaphore set and removes the undo structures from both the list_id and list_proc lists. For this case, exit_sem() is called at process exit. Each process contains a struct sem_undo_list (referred to as "ulp") which contains the head for the list_proc list. When the process exits, exit_sem() traverses this list to remove each sem_undo struct. As in freeary(), whenever a sem_undo struct is removed from list_proc, it is also removed from the list_id list. Removing elements from list_id is safe for both exit_sem() and freeary() due to sem_lock(). Removing elements from list_proc is not safe; freeary() locks &un->ulp->lock when it performs list_del_rcu(&un->list_proc) but exit_sem() does not (locking was removed by commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()"). This can result in the following situation while executing the reproducer [1] : Consider a child process in exit_sem() and the parent in freeary() (because of semctl(sid[i], NSEM, IPC_RMID)). The list_proc for the child contains the last two undo structs A and B (the rest have been removed either by exit_sem() or freeary()). The semid for A is 1 and semid for B is 2. exit_sem() removes A and at the same time freeary() removes B. Since A and B have different semid sem_lock() will acquire different locks for each process and both can proceed. The bug is that they remove A and B from the same list_proc at the same time because only freeary() acquires the ulp lock. When exit_sem() removes A it makes ulp->list_proc.next to point at B and at the same time freeary() removes B setting B->semid=-1. At the next iteration of for(;;) loop exit_sem() will try to remove B. The only way to break from for(;;) is for (&un->list_proc == &ulp->list_proc) to be true which is not. Then exit_sem() will check if B->semid=-1 which is and will continue looping in for(;;) until the memory for B is reallocated and the value at B->semid is changed. At that point, exit_sem() will crash attempting to unlink B from the lists (this can be easily triggered by running the reproducer [1] a second time). To prove this scenario instrumentation was added to keep information about each sem_undo (un) struct that is removed per process and per semaphore set (sma). CPU0 CPU1 [caller holds sem_lock(sma for A)] ... freeary() exit_sem() ... ... ... sem_lock(sma for B) spin_lock(A->ulp->lock) ... list_del_rcu(un_A->list_proc) list_del_rcu(un_B->list_proc) Undo structures A and B have different semid and sem_lock() operations proceed. However they belong to the same list_proc list and they are removed at the same time. This results into ulp->list_proc.next pointing to the address of B which is already removed. After reverting commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()") the issue was no longer reproducible. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1694779 Link: http://lkml.kernel.org/r/20191211191318.11860-1-ioanna-maria.alifieraki@can… Fixes: a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()") Signed-off-by: Ioanna Alifieraki <ioanna-maria.alifieraki(a)canonical.com> Acked-by: Manfred Spraul <manfred(a)colorfullife.com> Acked-by: Herton R. Krzesinski <herton(a)redhat.com> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: <malat(a)debian.org> Cc: Joel Fernandes (Google) <joel(a)joelfernandes.org> Cc: Davidlohr Bueso <dave(a)stgolabs.net> Cc: Jay Vosburgh <jay.vosburgh(a)canonical.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- ipc/sem.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) --- a/ipc/sem.c~revert-ipcsem-remove-uneeded-sem_undo_list-lock-usage-in-exit_sem +++ a/ipc/sem.c @@ -2384,11 +2384,9 @@ void exit_sem(struct task_struct *tsk) ipc_assert_locked_object(&sma->sem_perm); list_del(&un->list_id); - /* we are the last process using this ulp, acquiring ulp->lock - * isn't required. Besides that, we are also protected against - * IPC_RMID as we hold sma->sem_perm lock now - */ + spin_lock(&ulp->lock); list_del_rcu(&un->list_proc); + spin_unlock(&ulp->lock); /* perform adjustments registered in un */ for (i = 0; i < sma->sem_nsems; i++) { _

4 years, 10 months

1
0
0 0

[PATCH 6/8] perf arm-spe: Fix endless record after being terminated

by Arnaldo Carvalho de Melo

From: Adrian Hunter <adrian.hunter(a)intel.com> In __cmd_record(), when receiving SIGINT(ctrl + c), a 'done' flag will be set and the event list will be disabled by evlist__disable() once. While in auxtrace_record.read_finish(), the related events will be enabled again, if they are continuous, the recording seems to be endless. If the event is disabled, don't enable it again here. Based-on-patch-by: Wei Li <liwei391(a)huawei.com> Signed-off-by: Adrian Hunter <adrian.hunter(a)intel.com> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: Tan Xiaojun <tanxiaojun(a)huawei.com> Cc: stable(a)vger.kernel.org # 5.4+ Link: http://lore.kernel.org/lkml/20200214132654.20395-5-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> --- tools/perf/arch/arm64/util/arm-spe.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/tools/perf/arch/arm64/util/arm-spe.c b/tools/perf/arch/arm64/util/arm-spe.c index eba6541ec0f1..1d993c27242b 100644 --- a/tools/perf/arch/arm64/util/arm-spe.c +++ b/tools/perf/arch/arm64/util/arm-spe.c @@ -165,9 +165,12 @@ static int arm_spe_read_finish(struct auxtrace_record *itr, int idx) struct evsel *evsel; evlist__for_each_entry(sper->evlist, evsel) { - if (evsel->core.attr.type == sper->arm_spe_pmu->type) + if (evsel->core.attr.type == sper->arm_spe_pmu->type) { + if (evsel->disabled) + return 0; return perf_evlist__enable_event_idx(sper->evlist, evsel, idx); + } } return -EINVAL; } -- 2.21.1

4 years, 10 months

1
0
0 0

[PATCH 5/8] perf cs-etm: Fix endless record after being terminated

by Arnaldo Carvalho de Melo

From: Wei Li <liwei391(a)huawei.com> In __cmd_record(), when receiving SIGINT(ctrl + c), a 'done' flag will be set and the event list will be disabled by evlist__disable() once. While in auxtrace_record.read_finish(), the related events will be enabled again, if they are continuous, the recording seems to be endless. If the cs_etm event is disabled, we don't enable it again here. Note: This patch is NOT tested since i don't have such a machine with coresight feature, but the code seems buggy same as arm-spe and intel-pt. Tester notes: Thanks for looping, Adrian. Applied this patch and tested with CoreSight on juno board, it works well. Signed-off-by: Wei Li <liwei391(a)huawei.com> Reviewed-by: Leo Yan <leo.yan(a)linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier(a)linaro.org> Tested-by: Leo Yan <leo.yan(a)linaro.org> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: Tan Xiaojun <tanxiaojun(a)huawei.com> Cc: stable(a)vger.kernel.org # 5.4+ Link: http://lore.kernel.org/lkml/20200214132654.20395-4-adrian.hunter@intel.com [ahunter: removed redundant 'else' after 'return'] Signed-off-by: Adrian Hunter <adrian.hunter(a)intel.com> Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> --- tools/perf/arch/arm/util/cs-etm.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/tools/perf/arch/arm/util/cs-etm.c b/tools/perf/arch/arm/util/cs-etm.c index 2898cfdf8fe1..60141c3007a9 100644 --- a/tools/perf/arch/arm/util/cs-etm.c +++ b/tools/perf/arch/arm/util/cs-etm.c @@ -865,9 +865,12 @@ static int cs_etm_read_finish(struct auxtrace_record *itr, int idx) struct evsel *evsel; evlist__for_each_entry(ptr->evlist, evsel) { - if (evsel->core.attr.type == ptr->cs_etm_pmu->type) + if (evsel->core.attr.type == ptr->cs_etm_pmu->type) { + if (evsel->disabled) + return 0; return perf_evlist__enable_event_idx(ptr->evlist, evsel, idx); + } } return -EINVAL; -- 2.21.1

4 years, 10 months

1
0
0 0

[PATCH 4/8] perf intel-bts: Fix endless record after being terminated

by Arnaldo Carvalho de Melo

From: Wei Li <liwei391(a)huawei.com> In __cmd_record(), when receiving SIGINT(ctrl + c), a 'done' flag will be set and the event list will be disabled by evlist__disable() once. While in auxtrace_record.read_finish(), the related events will be enabled again, if they are continuous, the recording seems to be endless. If the intel_bts event is disabled, we don't enable it again here. Note: This patch is NOT tested since i don't have such a machine with intel_bts feature, but the code seems buggy same as arm-spe and intel-pt. Signed-off-by: Wei Li <liwei391(a)huawei.com> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: Tan Xiaojun <tanxiaojun(a)huawei.com> Cc: stable(a)vger.kernel.org # 5.4+ Link: http://lore.kernel.org/lkml/20200214132654.20395-3-adrian.hunter@intel.com [ahunter: removed redundant 'else' after 'return'] Signed-off-by: Adrian Hunter <adrian.hunter(a)intel.com> Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> --- tools/perf/arch/x86/util/intel-bts.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/tools/perf/arch/x86/util/intel-bts.c b/tools/perf/arch/x86/util/intel-bts.c index 27d9e214d068..39e363151ad7 100644 --- a/tools/perf/arch/x86/util/intel-bts.c +++ b/tools/perf/arch/x86/util/intel-bts.c @@ -420,9 +420,12 @@ static int intel_bts_read_finish(struct auxtrace_record *itr, int idx) struct evsel *evsel; evlist__for_each_entry(btsr->evlist, evsel) { - if (evsel->core.attr.type == btsr->intel_bts_pmu->type) + if (evsel->core.attr.type == btsr->intel_bts_pmu->type) { + if (evsel->disabled) + return 0; return perf_evlist__enable_event_idx(btsr->evlist, evsel, idx); + } } return -EINVAL; } -- 2.21.1

4 years, 10 months

1
0
0 0

[PATCH 3/8] perf intel-pt: Fix endless record after being terminated

by Arnaldo Carvalho de Melo

From: Wei Li <liwei391(a)huawei.com> In __cmd_record(), when receiving SIGINT(ctrl + c), a 'done' flag will be set and the event list will be disabled by evlist__disable() once. While in auxtrace_record.read_finish(), the related events will be enabled again, if they are continuous, the recording seems to be endless. If the intel_pt event is disabled, we don't enable it again here. Before the patch: huawei@huawei-2288H-V5:~/linux-5.5-rc4/tools/perf$ ./perf record -e \ intel_pt//u -p 46803 ^C^C^C^C^C^C After the patch: huawei@huawei-2288H-V5:~/linux-5.5-rc4/tools/perf$ ./perf record -e \ intel_pt//u -p 48591 ^C[ perf record: Woken up 0 times to write data ] Warning: AUX data lost 504 times out of 4816! [ perf record: Captured and wrote 2024.405 MB perf.data ] Signed-off-by: Wei Li <liwei391(a)huawei.com> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: Tan Xiaojun <tanxiaojun(a)huawei.com> Cc: stable(a)vger.kernel.org # 5.4+ Link: http://lore.kernel.org/lkml/20200214132654.20395-2-adrian.hunter@intel.com [ ahunter: removed redundant 'else' after 'return' ] Signed-off-by: Adrian Hunter <adrian.hunter(a)intel.com> Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> --- tools/perf/arch/x86/util/intel-pt.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/tools/perf/arch/x86/util/intel-pt.c b/tools/perf/arch/x86/util/intel-pt.c index 20df442fdf36..be07d6886256 100644 --- a/tools/perf/arch/x86/util/intel-pt.c +++ b/tools/perf/arch/x86/util/intel-pt.c @@ -1173,9 +1173,12 @@ static int intel_pt_read_finish(struct auxtrace_record *itr, int idx) struct evsel *evsel; evlist__for_each_entry(ptr->evlist, evsel) { - if (evsel->core.attr.type == ptr->intel_pt_pmu->type) + if (evsel->core.attr.type == ptr->intel_pt_pmu->type) { + if (evsel->disabled) + return 0; return perf_evlist__enable_event_idx(ptr->evlist, evsel, idx); + } } return -EINVAL; } -- 2.21.1

4 years, 10 months

1
0
0 0

+ mm-fix-possible-pmd-dirty-bit-lost-in-set_pmd_migration_entry.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: fix possible PMD dirty bit lost in set_pmd_migration_entry() has been added to the -mm tree. Its filename is mm-fix-possible-pmd-dirty-bit-lost-in-set_pmd_migration_entry.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-fix-possible-pmd-dirty-bit-lost… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-fix-possible-pmd-dirty-bit-lost… 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: Huang Ying <ying.huang(a)intel.com> Subject: mm: fix possible PMD dirty bit lost in set_pmd_migration_entry() In set_pmd_migration_entry(), pmdp_invalidate() is used to change PMD atomically. But the PMD is read before that with an ordinary memory reading. If the THP (transparent huge page) is written between the PMD reading and pmdp_invalidate(), the PMD dirty bit may be lost, and cause data corruption. The race window is quite small, but still possible in theory, so need to be fixed. The race is fixed via using the return value of pmdp_invalidate() to get the original content of PMD, which is a read/modify/write atomic operation. So no THP writing can occur in between. The race has been introduced when the THP migration support is added in the commit 616b8371539a ("mm: thp: enable thp migration in generic path"). But this fix depends on the commit d52605d7cb30 ("mm: do not lose dirty and accessed bits in pmdp_invalidate()"). So it's easy to be backported after v4.16. But the race window is really small, so it may be fine not to backport the fix at all. Link: http://lkml.kernel.org/r/20200220075220.2327056-1-ying.huang@intel.com Signed-off-by: "Huang, Ying" <ying.huang(a)intel.com> Reviewed-by: William Kucharski <william.kucharski(a)oracle.com> Acked-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Reviewed-by: Zi Yan <ziy(a)nvidia.com> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/huge_memory.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/mm/huge_memory.c~mm-fix-possible-pmd-dirty-bit-lost-in-set_pmd_migration_entry +++ a/mm/huge_memory.c @@ -3043,8 +3043,7 @@ void set_pmd_migration_entry(struct page return; flush_cache_range(vma, address, address + HPAGE_PMD_SIZE); - pmdval = *pvmw->pmd; - pmdp_invalidate(vma, address, pvmw->pmd); + pmdval = pmdp_invalidate(vma, address, pvmw->pmd); if (pmd_dirty(pmdval)) set_page_dirty(page); entry = make_migration_entry(page, pmd_write(pmdval)); _ Patches currently in -mm which might be from ying.huang(a)intel.com are mm-fix-possible-pmd-dirty-bit-lost-in-set_pmd_migration_entry.patch

4 years, 10 months

1
0
0 0

[PATCH V2] tpm: Don't make log failures fatal

by Matthew Garrett

If a TPM is in disabled state, it's reasonable for it to have an empty log. Bailing out of probe in this case means that the PPI interface isn't available, so there's no way to then enable the TPM from the OS. In general it seems reasonable to ignore log errors - they shouldn't interfere with any other TPM functionality. Signed-off-by: Matthew Garrett <mjg59(a)google.com> Cc: stable(a)vger.kernel.org --- V2: make tpm_bios_log_setup() void, since we're not using the return code now. Fix typo in patch description. drivers/char/tpm/eventlog/common.c | 12 ++++-------- drivers/char/tpm/tpm-chip.c | 4 +--- drivers/char/tpm/tpm.h | 2 +- 3 files changed, 6 insertions(+), 12 deletions(-) diff --git a/drivers/char/tpm/eventlog/common.c b/drivers/char/tpm/eventlog/common.c index 7a0fca659b6a6..7460f230bae4c 100644 --- a/drivers/char/tpm/eventlog/common.c +++ b/drivers/char/tpm/eventlog/common.c @@ -99,11 +99,8 @@ static int tpm_read_log(struct tpm_chip *chip) * * If an event log is found then the securityfs files are setup to * export it to userspace, otherwise nothing is done. - * - * Returns -ENODEV if the firmware has no event log or securityfs is not - * supported. */ -int tpm_bios_log_setup(struct tpm_chip *chip) +void tpm_bios_log_setup(struct tpm_chip *chip) { const char *name = dev_name(&chip->dev); unsigned int cnt; @@ -112,7 +109,7 @@ int tpm_bios_log_setup(struct tpm_chip *chip) rc = tpm_read_log(chip); if (rc < 0) - return rc; + return; log_version = rc; cnt = 0; @@ -158,13 +155,12 @@ int tpm_bios_log_setup(struct tpm_chip *chip) cnt++; } - return 0; + return; err: - rc = PTR_ERR(chip->bios_dir[cnt]); chip->bios_dir[cnt] = NULL; tpm_bios_log_teardown(chip); - return rc; + return; } void tpm_bios_log_teardown(struct tpm_chip *chip) diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c index 3d6d394a86618..58073836b5555 100644 --- a/drivers/char/tpm/tpm-chip.c +++ b/drivers/char/tpm/tpm-chip.c @@ -596,9 +596,7 @@ int tpm_chip_register(struct tpm_chip *chip) tpm_sysfs_add_device(chip); - rc = tpm_bios_log_setup(chip); - if (rc != 0 && rc != -ENODEV) - return rc; + tpm_bios_log_setup(chip); tpm_add_ppi(chip); diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h index b9e1547be6b51..1df2cf40ab794 100644 --- a/drivers/char/tpm/tpm.h +++ b/drivers/char/tpm/tpm.h @@ -236,7 +236,7 @@ int tpm2_prepare_space(struct tpm_chip *chip, struct tpm_space *space, u8 *cmd, int tpm2_commit_space(struct tpm_chip *chip, struct tpm_space *space, void *buf, size_t *bufsiz); -int tpm_bios_log_setup(struct tpm_chip *chip); +void tpm_bios_log_setup(struct tpm_chip *chip); void tpm_bios_log_teardown(struct tpm_chip *chip); int tpm_dev_common_init(void); void tpm_dev_common_exit(void); -- 2.24.1.735.g03f4e72817-goog

4 years, 10 months

4
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2020