May 2020 - Linux-stable-mirror

+ device-dax-dont-leak-kernel-memory-to-user-space-after-unloading-kmem.patch added to -mm tree

by Andrew Morton

The patch titled Subject: device-dax: don't leak kernel memory to user space after unloading kmem has been added to the -mm tree. Its filename is device-dax-dont-leak-kernel-memory-to-user-space-after-unloading-kmem.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/device-dax-dont-leak-kernel-memory… and later at http://ozlabs.org/~akpm/mmotm/broken-out/device-dax-dont-leak-kernel-memory… 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: David Hildenbrand <david(a)redhat.com> Subject: device-dax: don't leak kernel memory to user space after unloading kmem Assume we have kmem configured and loaded: [root@localhost ~]# cat /proc/iomem ... 140000000-33fffffff : Persistent Memory$ 140000000-1481fffff : namespace0.0 150000000-33fffffff : dax0.0 150000000-33fffffff : System RAM Assume we try to unload kmem. This force-unloading will work, even if memory cannot get removed from the system. [root@localhost ~]# rmmod kmem [ 86.380228] removing memory fails, because memory [0x0000000150000000-0x0000000157ffffff] is onlined ... [ 86.431225] kmem dax0.0: DAX region [mem 0x150000000-0x33fffffff] cannot be hotremoved until the next reboot Now, we can reconfigure the namespace: [root@localhost ~]# ndctl create-namespace --force --reconfig=namespace0.0 --mode=devdax [ 131.409351] nd_pmem namespace0.0: could not reserve region [mem 0x140000000-0x33fffffff]dax [ 131.410147] nd_pmem: probe of namespace0.0 failed with error -16namespace0.0 --mode=devdax ... This fails as expected due to the busy memory resource, and the memory cannot be used. However, the dax0.0 device is removed, and along its name. The name of the memory resource now points at freed memory (name of the device). [root@localhost ~]# cat /proc/iomem ... 140000000-33fffffff : Persistent Memory 140000000-1481fffff : namespace0.0 150000000-33fffffff : �_�^7_��/_��wR��WQ��^�� ... 150000000-33fffffff : System RAM We have to make sure to duplicate the string. While at it, remove the superfluous setting of the name and fixup a stale comment. Link: http://lkml.kernel.org/r/20200508084217.9160-2-david@redhat.com Fixes: 9f960da72b25 ("device-dax: "Hotremove" persistent memory that is used like normal RAM") Signed-off-by: David Hildenbrand <david(a)redhat.com> Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: Vishal Verma <vishal.l.verma(a)intel.com> Cc: Dave Jiang <dave.jiang(a)intel.com> Cc: Pavel Tatashin <pasha.tatashin(a)soleen.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: <stable(a)vger.kernel.org> [5.3] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- drivers/dax/kmem.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) --- a/drivers/dax/kmem.c~device-dax-dont-leak-kernel-memory-to-user-space-after-unloading-kmem +++ a/drivers/dax/kmem.c @@ -22,6 +22,7 @@ int dev_dax_kmem_probe(struct device *de resource_size_t kmem_size; resource_size_t kmem_end; struct resource *new_res; + const char *new_res_name; int numa_node; int rc; @@ -48,11 +49,16 @@ int dev_dax_kmem_probe(struct device *de kmem_size &= ~(memory_block_size_bytes() - 1); kmem_end = kmem_start + kmem_size; - /* Region is permanently reserved. Hot-remove not yet implemented. */ - new_res = request_mem_region(kmem_start, kmem_size, dev_name(dev)); + new_res_name = kstrdup(dev_name(dev), GFP_KERNEL); + if (!new_res_name) + return -ENOMEM; + + /* Region is permanently reserved if hotremove fails. */ + new_res = request_mem_region(kmem_start, kmem_size, new_res_name); if (!new_res) { dev_warn(dev, "could not reserve region [%pa-%pa]\n", &kmem_start, &kmem_end); + kfree(new_res_name); return -EBUSY; } @@ -63,12 +69,12 @@ int dev_dax_kmem_probe(struct device *de * unknown to us that will break add_memory() below. */ new_res->flags = IORESOURCE_SYSTEM_RAM; - new_res->name = dev_name(dev); rc = add_memory(numa_node, new_res->start, resource_size(new_res)); if (rc) { release_resource(new_res); kfree(new_res); + kfree(new_res_name); return rc; } dev_dax->dax_kmem_res = new_res; @@ -83,6 +89,7 @@ static int dev_dax_kmem_remove(struct de struct resource *res = dev_dax->dax_kmem_res; resource_size_t kmem_start = res->start; resource_size_t kmem_size = resource_size(res); + const char *res_name = res->name; int rc; /* @@ -102,6 +109,7 @@ static int dev_dax_kmem_remove(struct de /* Release and free dax resources */ release_resource(res); kfree(res); + kfree(res_name); dev_dax->dax_kmem_res = NULL; return 0; _ Patches currently in -mm which might be from david(a)redhat.com are device-dax-dont-leak-kernel-memory-to-user-space-after-unloading-kmem.patch drivers-base-memoryc-cache-memory-blocks-in-xarray-to-accelerate-lookup-fix.patch powerpc-pseries-hotplug-memory-stop-checking-is_mem_section_removable.patch mm-memory_hotplug-remove-is_mem_section_removable.patch mm-memory_hotplug-set-node_start_pfn-of-hotadded-pgdat-to-0.patch mm-memory_hotplug-handle-memblocks-only-with-config_arch_keep_memblock.patch

4 years, 8 months

1
0
0 0

stable-rc/linux-5.4.y boot: 148 boots: 0 failed, 138 passed with 5 offline, 5 untried/unknown (v5.4.39-50-g695621e78832)

by kernelci.org bot

stable-rc/linux-5.4.y boot: 148 boots: 0 failed, 138 passed with 5 offline, 5 untried/unknown (v5.4.39-50-g695621e78832) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.4.y/kernel/v5.4.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.4.y/kernel/v5.4.39-50-g… Tree: stable-rc Branch: linux-5.4.y Git Describe: v5.4.39-50-g695621e78832 Git Commit: 695621e788325e527588a26f1a9c6c526b69a2ee Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 92 unique boards, 24 SoC families, 20 builds out of 200 Boot Regressions Detected: arm: qcom_defconfig: gcc-8: qcom-apq8064-cm-qs600: lab-baylibre-seattle: failing since 90 days (last pass: v5.4.17-99-gbd0c6624a110 - first fail: v5.4.17-238-gbffcaa93483d) Offline Platforms: arm: multi_v7_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab qcom-apq8064-cm-qs600: 1 offline lab stih410-b2120: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab exynos_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab --- For more info write to <info(a)kernelci.org>

4 years, 8 months

1
0
0 0

Herzliche Glückwünsche: € 2,000,000.00 Euro

by Jeff Lindsay

Ich bin Jeff Lindsay, ein älterer Bürger aus Kalifornien, USA. Ich habe einen Jackpot von 447,8 Millionen Dollar gewonnen, der größte Lotterie-Jackpot. Im Namen meiner Familie und aus gutem Willen spenden wir Ihnen und Ihrer Familie einen Betrag von (€ 2.000.000,00 EUR). Ich versuche, die öffentlichen Waisenhäuser zu erreichen. Tragen Sie zur Armutsbekämpfung bei und sorgen Sie für eine angemessene Gesundheitsversorgung für Einzelpersonen, insbesondere während dieser Welt. Pandemic Covid 19. Ich möchte auch, dass Sie einen Teil dieser Spende in die öffentliche Infrastruktur investieren, um Arbeitslosen in Ihrem Land Arbeitsplätze zu bieten. Ich habe dich gewählt, weil ich an dich glaube. Ich brauche Ihre uneingeschränkte Mitarbeit in Bezug auf diese Spende. Bitte kontaktieren Sie mich hier zurück unter meiner privaten E-Mail: povertysolutionsorg(a)gmail.com

4 years, 8 months

1
0
0 0

stable-rc/linux-4.19.y boot: 125 boots: 0 failed, 115 passed with 5 offline, 5 untried/unknown (v4.19.121-33-g7ad26f947708)

by kernelci.org bot

stable-rc/linux-4.19.y boot: 125 boots: 0 failed, 115 passed with 5 offline, 5 untried/unknown (v4.19.121-33-g7ad26f947708) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.121-3… Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.121-33-g7ad26f947708 Git Commit: 7ad26f9477088e4d47b22647fb90e2cb53f1c9c2 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 74 unique boards, 18 SoC families, 18 builds out of 206 Boot Regressions Detected: arm: qcom_defconfig: gcc-8: qcom-apq8064-cm-qs600: lab-baylibre-seattle: failing since 90 days (last pass: v4.19.101 - first fail: v4.19.102-96-g0632821fe218) versatile_defconfig: gcc-8: versatile-pb: lab-collabora: new failure (last pass: v4.19.121) Offline Platforms: arm: multi_v7_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab qcom-apq8064-cm-qs600: 1 offline lab stih410-b2120: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab exynos_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab --- For more info write to <info(a)kernelci.org>

4 years, 8 months

1
0
0 0

[merged] mm-limit-boost_watermark-on-small-zones.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: limit boost_watermark on small zones has been removed from the -mm tree. Its filename was mm-limit-boost_watermark-on-small-zones.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Henry Willard <henry.willard(a)oracle.com> Subject: mm: limit boost_watermark on small zones Commit 1c30844d2dfe ("mm: reclaim small amounts of memory when an external fragmentation event occurs") adds a boost_watermark() function which increases the min watermark in a zone by at least pageblock_nr_pages or the number of pages in a page block. On Arm64, with 64K pages and 512M huge pages, this is 8192 pages or 512M. It does this regardless of the number of managed pages managed in the zone or the likelihood of success. This can put the zone immediately under water in terms of allocating pages from the zone, and can cause a small machine to fail immediately due to OoM. Unlike set_recommended_min_free_kbytes(), which substantially increases min_free_kbytes and is tied to THP, boost_watermark() can be called even if THP is not active. The problem is most likely to appear on architectures such as Arm64 where pageblock_nr_pages is very large. It is desirable to run the kdump capture kernel in as small a space as possible to avoid wasting memory. In some architectures, such as Arm64, there are restrictions on where the capture kernel can run, and therefore, the space available. A capture kernel running in 768M can fail due to OoM immediately after boost_watermark() sets the min in zone DMA32, where most of the memory is, to 512M. It fails even though there is over 500M of free memory. With boost_watermark() suppressed, the capture kernel can run successfully in 448M. This patch limits boost_watermark() to boosting a zone's min watermark only when there are enough pages that the boost will produce positive results. In this case that is estimated to be four times as many pages as pageblock_nr_pages. Mel said: : There is no harm in marking it stable. Clearly it does not happen very : often but it's not impossible. 32-bit x86 is a lot less common now : which would previously have been vulnerable to triggering this easily. : ppc64 has a larger base page size but typically only has one zone. : arm64 is likely the most vulnerable, particularly when CMA is : configured with a small movable zone. Link: http://lkml.kernel.org/r/1588294148-6586-1-git-send-email-henry.willard@ora… Fixes: 1c30844d2dfe ("mm: reclaim small amounts of memory when an external fragmentation event occurs") Signed-off-by: Henry Willard <henry.willard(a)oracle.com> Acked-by: Mel Gorman <mgorman(a)techsingularity.net> Reviewed-by: David Hildenbrand <david(a)redhat.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/page_alloc.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/mm/page_alloc.c~mm-limit-boost_watermark-on-small-zones +++ a/mm/page_alloc.c @@ -2401,6 +2401,14 @@ static inline void boost_watermark(struc if (!watermark_boost_factor) return; + /* + * Don't bother in zones that are unlikely to produce results. + * On small machines, including kdump capture kernels running + * in a small area, boosting the watermark can cause an out of + * memory situation immediately. + */ + if ((pageblock_nr_pages * 4) > zone_managed_pages(zone)) + return; max_boost = mult_frac(zone->_watermark[WMARK_HIGH], watermark_boost_factor, 10000); _ Patches currently in -mm which might be from henry.willard(a)oracle.com are

4 years, 8 months

1
0
0 0

[merged] epoll-atomically-remove-wait-entry-on-wake-up.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: epoll: atomically remove wait entry on wake up has been removed from the -mm tree. Its filename was epoll-atomically-remove-wait-entry-on-wake-up.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Roman Penyaev <rpenyaev(a)suse.de> Subject: epoll: atomically remove wait entry on wake up This patch does two things: 1. fixes lost wakeup introduced by: 339ddb53d373 ("fs/epoll: remove unnecessary wakeups of nested epoll") 2. improves performance for events delivery. The description of the problem is the following: if N (>1) threads are waiting on ep->wq for new events and M (>1) events come, it is quite likely that >1 wakeups hit the same wait queue entry, because there is quite a big window between __add_wait_queue_exclusive() and the following __remove_wait_queue() calls in ep_poll() function. This can lead to lost wakeups, because thread, which was woken up, can handle not all the events in ->rdllist. (in better words the problem is described here: https://lkml.org/lkml/2019/10/7/905) The idea of the current patch is to use init_wait() instead of init_waitqueue_entry(). Internally init_wait() sets autoremove_wake_function as a callback, which removes the wait entry atomically (under the wq locks) from the list, thus the next coming wakeup hits the next wait entry in the wait queue, thus preventing lost wakeups. Problem is very well reproduced by the epoll60 test case [1]. Wait entry removal on wakeup has also performance benefits, because there is no need to take a ep->lock and remove wait entry from the queue after the successful wakeup. Here is the timing output of the epoll60 test case: With explicit wakeup from ep_scan_ready_list() (the state of the code prior 339ddb53d373): real 0m6.970s user 0m49.786s sys 0m0.113s After this patch: real 0m5.220s user 0m36.879s sys 0m0.019s The other testcase is the stress-epoll [2], where one thread consumes all the events and other threads produce many events: With explicit wakeup from ep_scan_ready_list() (the state of the code prior 339ddb53d373): threads events/ms run-time ms 8 5427 1474 16 6163 2596 32 6824 4689 64 7060 9064 128 6991 18309 After this patch: threads events/ms run-time ms 8 5598 1429 16 7073 2262 32 7502 4265 64 7640 8376 128 7634 16767 (number of "events/ms" represents event bandwidth, thus higher is better; number of "run-time ms" represents overall time spent doing the benchmark, thus lower is better) [1] tools/testing/selftests/filesystems/epoll/epoll_wakeup_test.c [2] https://github.com/rouming/test-tools/blob/master/stress-epoll.c Link: http://lkml.kernel.org/r/20200430130326.1368509-2-rpenyaev@suse.de Signed-off-by: Roman Penyaev <rpenyaev(a)suse.de> Reviewed-by: Jason Baron <jbaron(a)akamai.com> Cc: Khazhismel Kumykov <khazhy(a)google.com> Cc: Alexander Viro <viro(a)zeniv.linux.org.uk> Cc: Heiher <r(a)hev.cc> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/eventpoll.c | 43 ++++++++++++++++++++++++------------------- 1 file changed, 24 insertions(+), 19 deletions(-) --- a/fs/eventpoll.c~epoll-atomically-remove-wait-entry-on-wake-up +++ a/fs/eventpoll.c @@ -1822,7 +1822,6 @@ static int ep_poll(struct eventpoll *ep, { int res = 0, eavail, timed_out = 0; u64 slack = 0; - bool waiter = false; wait_queue_entry_t wait; ktime_t expires, *to = NULL; @@ -1867,21 +1866,23 @@ fetch_events: */ ep_reset_busy_poll_napi_id(ep); - /* - * We don't have any available event to return to the caller. We need - * to sleep here, and we will be woken by ep_poll_callback() when events - * become available. - */ - if (!waiter) { - waiter = true; - init_waitqueue_entry(&wait, current); - + do { + /* + * Internally init_wait() uses autoremove_wake_function(), + * thus wait entry is removed from the wait queue on each + * wakeup. Why it is important? In case of several waiters + * each new wakeup will hit the next waiter, giving it the + * chance to harvest new event. Otherwise wakeup can be + * lost. This is also good performance-wise, because on + * normal wakeup path no need to call __remove_wait_queue() + * explicitly, thus ep->lock is not taken, which halts the + * event delivery. + */ + init_wait(&wait); write_lock_irq(&ep->lock); __add_wait_queue_exclusive(&ep->wq, &wait); write_unlock_irq(&ep->lock); - } - for (;;) { /* * We don't want to sleep if the ep_poll_callback() sends us * a wakeup in between. That's why we set the task state @@ -1911,10 +1912,20 @@ fetch_events: timed_out = 1; break; } - } + + /* We were woken up, thus go and try to harvest some events */ + eavail = 1; + + } while (0); __set_current_state(TASK_RUNNING); + if (!list_empty_careful(&wait.entry)) { + write_lock_irq(&ep->lock); + __remove_wait_queue(&ep->wq, &wait); + write_unlock_irq(&ep->lock); + } + send_events: /* * Try to transfer events to user space. In case we get 0 events and @@ -1925,12 +1936,6 @@ send_events: !(res = ep_send_events(ep, events, maxevents)) && !timed_out) goto fetch_events; - if (waiter) { - write_lock_irq(&ep->lock); - __remove_wait_queue(&ep->wq, &wait); - write_unlock_irq(&ep->lock); - } - return res; } _ Patches currently in -mm which might be from rpenyaev(a)suse.de are epoll-call-final-ep_events_available-check-under-the-lock.patch

4 years, 8 months

1
0
0 0

[merged] eventpoll-fix-missing-wakeup-for-ovflist-in-ep_poll_callback.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: eventpoll: fix missing wakeup for ovflist in ep_poll_callback has been removed from the -mm tree. Its filename was eventpoll-fix-missing-wakeup-for-ovflist-in-ep_poll_callback.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Khazhismel Kumykov <khazhy(a)google.com> Subject: eventpoll: fix missing wakeup for ovflist in ep_poll_callback In the event that we add to ovflist, before 339ddb53d373 we would be woken up by ep_scan_ready_list, and did no wakeup in ep_poll_callback. With that wakeup removed, if we add to ovflist here, we may never wake up. Rather than adding back the ep_scan_ready_list wakeup - which was resulting in unnecessary wakeups, trigger a wake-up in ep_poll_callback. We noticed that one of our workloads was missing wakeups starting with 339ddb53d373 and upon manual inspection, this wakeup seemed missing to me. With this patch added, we no longer see missing wakeups. I haven't yet tried to make a small reproducer, but the existing kselftests in filesystem/epoll passed for me with this patch. [khazhy(a)google.com: use if/elif instead of goto + cleanup suggested by Roman] Link: http://lkml.kernel.org/r/20200424190039.192373-1-khazhy@google.com Link: http://lkml.kernel.org/r/20200424025057.118641-1-khazhy@google.com Fixes: 339ddb53d373 ("fs/epoll: remove unnecessary wakeups of nested epoll") Signed-off-by: Khazhismel Kumykov <khazhy(a)google.com> Reviewed-by: Roman Penyaev <rpenyaev(a)suse.de> Cc: Alexander Viro <viro(a)zeniv.linux.org.uk> Cc: Roman Penyaev <rpenyaev(a)suse.de> Cc: Heiher <r(a)hev.cc> Cc: Jason Baron <jbaron(a)akamai.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/eventpoll.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) --- a/fs/eventpoll.c~eventpoll-fix-missing-wakeup-for-ovflist-in-ep_poll_callback +++ a/fs/eventpoll.c @@ -1171,6 +1171,10 @@ static inline bool chain_epi_lockless(st { struct eventpoll *ep = epi->ep; + /* Fast preliminary check */ + if (epi->next != EP_UNACTIVE_PTR) + return false; + /* Check that the same epi has not been just chained from another CPU */ if (cmpxchg(&epi->next, EP_UNACTIVE_PTR, NULL) != EP_UNACTIVE_PTR) return false; @@ -1237,16 +1241,12 @@ static int ep_poll_callback(wait_queue_e * chained in ep->ovflist and requeued later on. */ if (READ_ONCE(ep->ovflist) != EP_UNACTIVE_PTR) { - if (epi->next == EP_UNACTIVE_PTR && - chain_epi_lockless(epi)) + if (chain_epi_lockless(epi)) + ep_pm_stay_awake_rcu(epi); + } else if (!ep_is_linked(epi)) { + /* In the usual case, add event to ready list. */ + if (list_add_tail_lockless(&epi->rdllink, &ep->rdllist)) ep_pm_stay_awake_rcu(epi); - goto out_unlock; - } - - /* If this file is already in the ready list we exit soon */ - if (!ep_is_linked(epi) && - list_add_tail_lockless(&epi->rdllink, &ep->rdllist)) { - ep_pm_stay_awake_rcu(epi); } /* _ Patches currently in -mm which might be from khazhy(a)google.com are

4 years, 8 months

1
0
0 0

[merged] mm-page_alloc-fix-watchdog-soft-lockups-during-set_zone_contiguous.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/page_alloc: fix watchdog soft lockups during set_zone_contiguous() has been removed from the -mm tree. Its filename was mm-page_alloc-fix-watchdog-soft-lockups-during-set_zone_contiguous.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: David Hildenbrand <david(a)redhat.com> Subject: mm/page_alloc: fix watchdog soft lockups during set_zone_contiguous() Without CONFIG_PREEMPT, it can happen that we get soft lockups detected, e.g., while booting up. [ 105.608900] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:1] [ 105.608933] Modules linked in: [ 105.608933] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.6.0-next-20200331+ #4 [ 105.608933] Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014 [ 105.608933] RIP: 0010:__pageblock_pfn_to_page+0x134/0x1c0 [ 105.608933] Code: 85 c0 74 71 4a 8b 04 d0 48 85 c0 74 68 48 01 c1 74 63 f6 01 04 74 5e 48 c1 e7 06 4c 8b 05 cc 991 [ 105.608933] RSP: 0000:ffffb6d94000fe60 EFLAGS: 00010286 ORIG_RAX: ffffffffffffff13 [ 105.608933] RAX: fffff81953250000 RBX: 000000000a4c9600 RCX: ffff8fe9ff7c1990 [ 105.608933] RDX: ffff8fe9ff7dab80 RSI: 000000000a4c95ff RDI: 0000000293250000 [ 105.608933] RBP: ffff8fe9ff7dab80 R08: fffff816c0000000 R09: 0000000000000008 [ 105.608933] R10: 0000000000000014 R11: 0000000000000014 R12: 0000000000000000 [ 105.608933] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 105.608933] FS: 0000000000000000(0000) GS:ffff8fe1ff400000(0000) knlGS:0000000000000000 [ 105.608933] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 105.608933] CR2: 000000000f613000 CR3: 00000088cf20a000 CR4: 00000000000006f0 [ 105.608933] Call Trace: [ 105.608933] set_zone_contiguous+0x56/0x70 [ 105.608933] page_alloc_init_late+0x166/0x176 [ 105.608933] kernel_init_freeable+0xfa/0x255 [ 105.608933] ? rest_init+0xaa/0xaa [ 105.608933] kernel_init+0xa/0x106 [ 105.608933] ret_from_fork+0x35/0x40 The issue becomes visible when having a lot of memory (e.g., 4TB) assigned to a single NUMA node - a system that can easily be created using QEMU. Inside VMs on a hypervisor with quite some memory overcommit, this is fairly easy to trigger. Link: http://lkml.kernel.org/r/20200416073417.5003-1-david@redhat.com Signed-off-by: David Hildenbrand <david(a)redhat.com> Reviewed-by: Pavel Tatashin <pasha.tatashin(a)soleen.com> Reviewed-by: Pankaj Gupta <pankaj.gupta.linux(a)gmail.com> Reviewed-by: Baoquan He <bhe(a)redhat.com> Reviewed-by: Shile Zhang <shile.zhang(a)linux.alibaba.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: Kirill Tkhai <ktkhai(a)virtuozzo.com> Cc: Shile Zhang <shile.zhang(a)linux.alibaba.com> Cc: Pavel Tatashin <pasha.tatashin(a)soleen.com> Cc: Daniel Jordan <daniel.m.jordan(a)oracle.com> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Alexander Duyck <alexander.duyck(a)gmail.com> Cc: Baoquan He <bhe(a)redhat.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/page_alloc.c | 1 + 1 file changed, 1 insertion(+) --- a/mm/page_alloc.c~mm-page_alloc-fix-watchdog-soft-lockups-during-set_zone_contiguous +++ a/mm/page_alloc.c @@ -1607,6 +1607,7 @@ void set_zone_contiguous(struct zone *zo if (!__pageblock_pfn_to_page(block_start_pfn, block_end_pfn, zone)) return; + cond_resched(); } /* We confirm that there is no hole */ _ Patches currently in -mm which might be from david(a)redhat.com are drivers-base-memoryc-cache-memory-blocks-in-xarray-to-accelerate-lookup-fix.patch powerpc-pseries-hotplug-memory-stop-checking-is_mem_section_removable.patch mm-memory_hotplug-remove-is_mem_section_removable.patch mm-memory_hotplug-set-node_start_pfn-of-hotadded-pgdat-to-0.patch mm-memory_hotplug-handle-memblocks-only-with-config_arch_keep_memblock.patch

4 years, 8 months

1
0
0 0

[merged] ipc-mqueuec-change-__do_notify-to-bypass-check_kill_permission-v2.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: ipc/mqueue.c: change __do_notify() to bypass check_kill_permission() has been removed from the -mm tree. Its filename was ipc-mqueuec-change-__do_notify-to-bypass-check_kill_permission-v2.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Oleg Nesterov <oleg(a)redhat.com> Subject: ipc/mqueue.c: change __do_notify() to bypass check_kill_permission() Commit cc731525f26a ("signal: Remove kernel interal si_code magic") changed the value of SI_FROMUSER(SI_MESGQ), this means that mq_notify() no longer works if the sender doesn't have rights to send a signal. Change __do_notify() to use do_send_sig_info() instead of kill_pid_info() to avoid check_kill_permission(). This needs the additional notify.sigev_signo != 0 check, shouldn't we change do_mq_notify() to deny sigev_signo == 0 ? Test-case: #include <signal.h> #include <mqueue.h> #include <unistd.h> #include <sys/wait.h> #include <assert.h> static int notified; static void sigh(int sig) { notified = 1; } int main(void) { signal(SIGIO, sigh); int fd = mq_open("/mq", O_RDWR|O_CREAT, 0666, NULL); assert(fd >= 0); struct sigevent se = { .sigev_notify = SIGEV_SIGNAL, .sigev_signo = SIGIO, }; assert(mq_notify(fd, &se) == 0); if (!fork()) { assert(setuid(1) == 0); mq_send(fd, "",1,0); return 0; } wait(NULL); mq_unlink("/mq"); assert(notified); return 0; } [manfred(a)colorfullife.com: 1) Add self_exec_id evaluation so that the implementation matches do_notify_parent 2) use PIDTYPE_TGID everywhere] Link: http://lkml.kernel.org/r/e2a782e4-eab9-4f5c-c749-c07a8f7a4e66@colorfullife.… Fixes: cc731525f26a ("signal: Remove kernel interal si_code magic") Reported-by: Yoji <yoji.fujihar.min(a)gmail.com> Signed-off-by: Oleg Nesterov <oleg(a)redhat.com> Signed-off-by: Manfred Spraul <manfred(a)colorfullife.com> Acked-by: "Eric W. Biederman" <ebiederm(a)xmission.com> Cc: Davidlohr Bueso <dave(a)stgolabs.net> Cc: Markus Elfring <elfring(a)users.sourceforge.net> Cc: <1vier1(a)web.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- ipc/mqueue.c | 34 ++++++++++++++++++++++++++-------- 1 file changed, 26 insertions(+), 8 deletions(-) --- a/ipc/mqueue.c~ipc-mqueuec-change-__do_notify-to-bypass-check_kill_permission-v2 +++ a/ipc/mqueue.c @@ -142,6 +142,7 @@ struct mqueue_inode_info { struct sigevent notify; struct pid *notify_owner; + u32 notify_self_exec_id; struct user_namespace *notify_user_ns; struct user_struct *user; /* user who created, for accounting */ struct sock *notify_sock; @@ -773,28 +774,44 @@ static void __do_notify(struct mqueue_in * synchronously. */ if (info->notify_owner && info->attr.mq_curmsgs == 1) { - struct kernel_siginfo sig_i; switch (info->notify.sigev_notify) { case SIGEV_NONE: break; - case SIGEV_SIGNAL: - /* sends signal */ + case SIGEV_SIGNAL: { + struct kernel_siginfo sig_i; + struct task_struct *task; + + /* do_mq_notify() accepts sigev_signo == 0, why?? */ + if (!info->notify.sigev_signo) + break; clear_siginfo(&sig_i); sig_i.si_signo = info->notify.sigev_signo; sig_i.si_errno = 0; sig_i.si_code = SI_MESGQ; sig_i.si_value = info->notify.sigev_value; - /* map current pid/uid into info->owner's namespaces */ rcu_read_lock(); + /* map current pid/uid into info->owner's namespaces */ sig_i.si_pid = task_tgid_nr_ns(current, ns_of_pid(info->notify_owner)); - sig_i.si_uid = from_kuid_munged(info->notify_user_ns, current_uid()); + sig_i.si_uid = from_kuid_munged(info->notify_user_ns, + current_uid()); + /* + * We can't use kill_pid_info(), this signal should + * bypass check_kill_permission(). It is from kernel + * but si_fromuser() can't know this. + * We do check the self_exec_id, to avoid sending + * signals to programs that don't expect them. + */ + task = pid_task(info->notify_owner, PIDTYPE_TGID); + if (task && task->self_exec_id == + info->notify_self_exec_id) { + do_send_sig_info(info->notify.sigev_signo, + &sig_i, task, PIDTYPE_TGID); + } rcu_read_unlock(); - - kill_pid_info(info->notify.sigev_signo, - &sig_i, info->notify_owner); break; + } case SIGEV_THREAD: set_cookie(info->notify_cookie, NOTIFY_WOKENUP); netlink_sendskb(info->notify_sock, info->notify_cookie); @@ -1383,6 +1400,7 @@ retry: info->notify.sigev_signo = notification->sigev_signo; info->notify.sigev_value = notification->sigev_value; info->notify.sigev_notify = SIGEV_SIGNAL; + info->notify_self_exec_id = current->self_exec_id; break; } _ Patches currently in -mm which might be from oleg(a)redhat.com are aio-simplify-read_events.patch

4 years, 8 months

1
0
0 0

stable-rc/linux-4.4.y boot: 82 boots: 14 failed, 59 passed with 4 offline, 4 untried/unknown, 1 conflict (v4.4.222-309-g1a571d63aabc)

by kernelci.org bot

stable-rc/linux-4.4.y boot: 82 boots: 14 failed, 59 passed with 4 offline, 4 untried/unknown, 1 conflict (v4.4.222-309-g1a571d63aabc) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.222-309… Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.222-309-g1a571d63aabc Git Commit: 1a571d63aabc342ca6ee6ff5ce981c45dee8e31a Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 43 unique boards, 14 SoC families, 16 builds out of 190 Boot Regressions Detected: arm: imx_v6_v7_defconfig: gcc-8: imx6dl-riotboard: lab-pengutronix: failing since 1 day (last pass: v4.4.222-166-g7ab45cabed0b - first fail: v4.4.222-321-gb1cd678a0c39) imx6dl-wandboard_dual: lab-baylibre-seattle: new failure (last pass: v4.4.222-321-gb1cd678a0c39) imx6dl-wandboard_solo: lab-baylibre-seattle: new failure (last pass: v4.4.222-321-gb1cd678a0c39) multi_v7_defconfig: gcc-8: sun4i-a10-olinuxino-lime: lab-baylibre: new failure (last pass: v4.4.222) sun7i-a20-cubieboard2: lab-clabbe: new failure (last pass: v4.4.222) sun7i-a20-olinuxino-lime2: lab-baylibre: new failure (last pass: v4.4.222) qcom_defconfig: gcc-8: qcom-apq8064-cm-qs600: lab-baylibre-seattle: failing since 90 days (last pass: v4.4.212-56-g758a39807529 - first fail: v4.4.213-28-ga3b43e6eae91) sunxi_defconfig: gcc-8: sun4i-a10-cubieboard: lab-baylibre-seattle: failing since 1 day (last pass: v4.4.222-166-g7ab45cabed0b - first fail: v4.4.222-321-gb1cd678a0c39) sun4i-a10-olinuxino-lime: lab-baylibre: failing since 1 day (last pass: v4.4.222-166-g7ab45cabed0b - first fail: v4.4.222-321-gb1cd678a0c39) sun7i-a20-cubieboard2: lab-clabbe: failing since 1 day (last pass: v4.4.222-166-g7ab45cabed0b - first fail: v4.4.222-321-gb1cd678a0c39) sun7i-a20-olinuxino-lime2: lab-baylibre: failing since 1 day (last pass: v4.4.222-166-g7ab45cabed0b - first fail: v4.4.222-321-gb1cd678a0c39) x86_64: x86_64_defconfig: gcc-8: qemu_x86_64: lab-baylibre: new failure (last pass: v4.4.222-321-gb1cd678a0c39) Boot Failures Detected: arm: multi_v5_defconfig: gcc-8: imx27-phytec-phycard-s-rdk: 1 failed lab imx_v4_v5_defconfig: gcc-8: imx27-phytec-phycard-s-rdk: 1 failed lab multi_v7_defconfig: gcc-8: sun4i-a10-cubieboard: 1 failed lab sun4i-a10-olinuxino-lime: 1 failed lab sun7i-a20-cubieboard2: 1 failed lab sun7i-a20-olinuxino-lime2: 1 failed lab sunxi_defconfig: gcc-8: sun4i-a10-cubieboard: 1 failed lab sun4i-a10-olinuxino-lime: 1 failed lab sun7i-a20-cubieboard2: 1 failed lab sun7i-a20-olinuxino-lime2: 1 failed lab imx_v6_v7_defconfig: gcc-8: imx6dl-riotboard: 1 failed lab imx6dl-wandboard_dual: 1 failed lab imx6dl-wandboard_solo: 1 failed lab imx6q-wandboard: 1 failed lab Offline Platforms: arm: multi_v7_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab qcom-apq8064-cm-qs600: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab exynos_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) x86_64: x86_64_defconfig: qemu_x86_64: lab-baylibre: FAIL (gcc-8) lab-collabora: PASS (gcc-8) --- For more info write to <info(a)kernelci.org>

4 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2020