- Linux-stable-mirror - lists.linaro.org

[patch 15/15] mm: limit boost_watermark on small zones

by Andrew Morton

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); _

5 years, 7 months

1
0
0 0

[patch 12/15] epoll: atomically remove wait entry on wake up

by Andrew Morton

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; } _

5 years, 7 months

1
0
0 0

[patch 07/15] eventpoll: fix missing wakeup for ovflist in ep_poll_callback

by Andrew Morton

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); } /* _

5 years, 7 months

1
0
0 0

[patch 03/15] mm/page_alloc: fix watchdog soft lockups during set_zone_contiguous()

by Andrew Morton

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 */ _

5 years, 7 months

1
0
0 0

[PATCH] scsi: qla2xxx: Do not log message when reading port speed via sysfs

by Ewan D. Milne

Calling ql_log() inside qla2x00_port_speed_show() is causing messages to be output to the console for no particularly good reason. The sysfs read routine should just return the information to userspace. The only reason to log a message is when the port speed actually changes, and this already occurs elsewhere. Cc: <stable(a)vger.kernel.org> # v5.1+ Fixes: 4910b524ac9 ("scsi: qla2xxx: Add support for setting port speed") Signed-off-by: Ewan D. Milne <emilne(a)redhat.com> --- drivers/scsi/qla2xxx/qla_attr.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/scsi/qla2xxx/qla_attr.c b/drivers/scsi/qla2xxx/qla_attr.c index 3325596..2c9e5ac 100644 --- a/drivers/scsi/qla2xxx/qla_attr.c +++ b/drivers/scsi/qla2xxx/qla_attr.c @@ -1850,9 +1850,6 @@ qla2x00_port_speed_show(struct device *dev, struct device_attribute *attr, return -EINVAL; } - ql_log(ql_log_info, vha, 0x70d6, - "port speed:%d\n", ha->link_data_rate); - return scnprintf(buf, PAGE_SIZE, "%s\n", spd[ha->link_data_rate]); } -- 2.1.0

5 years, 7 months

5
4
0 0

[PATCH stable 5.4+] nvme: fix possible hang when ns scanning fails during error recovery

by Sagi Grimberg

When the controller is reconnecting, the host fails I/O and admin commands as the host cannot reach the controller. ns scanning may revalidate namespaces during that period and it is wrong to remove namespaces due to these failures as we may hang (see 205da2434301). One command that may fail is nvme_identify_ns_descs. Since we return success due to having ns descriptor list optional, we continue to validate ns identifiers in nvme_revalidate_disk, obviously fail and return -ENODEV to nvme_validate_ns, which will remove the namespace. Exactly what we don't want to happen. Fixes: 22802bf742c2 ("nvme: Namepace identification descriptor list is optional") Tested-by: Anton Eidelman <anton(a)lightbitslabs.com> Signed-off-by: Sagi Grimberg <sagi(a)grimberg.me> Signed-off-by: Sagi Grimberg <sagi(a)grimberg.me> --- drivers/nvme/host/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index 31b7dcd791c2..8ce9b4fbc821 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -1746,7 +1746,7 @@ static int nvme_report_ns_ids(struct nvme_ctrl *ctrl, unsigned int nsid, if (ret) dev_warn(ctrl->device, "Identify Descriptors failed (%d)\n", ret); - if (ret > 0) + if (ret > 0 && !(ret & NVME_SC_DNR)) ret = 0; } return ret; -- 2.20.1

5 years, 7 months

2
2
0 0

+ ipc-utilc-sysvipc_find_ipc-incorrectly-updates-position-index.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: ipc/util.c: sysvipc_find_ipc() incorrectly updates position index has been added to the -mm tree. Its filename is ipc-utilc-sysvipc_find_ipc-incorrectly-updates-position-index.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/ipc-utilc-sysvipc_find_ipc-incorre… and later at http://ozlabs.org/~akpm/mmotm/broken-out/ipc-utilc-sysvipc_find_ipc-incorre… 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: Vasily Averin <vvs(a)virtuozzo.com> Subject: ipc/util.c: sysvipc_find_ipc() incorrectly updates position index Commit 89163f93c6f9 ("ipc/util.c: sysvipc_find_ipc() should increase position index") is causing this bug (seen on 5.6.8): # ipcs -q ------ Message Queues -------- key msqid owner perms used-bytes messages # ipcmk -Q Message queue id: 0 # ipcs -q ------ Message Queues -------- key msqid owner perms used-bytes messages 0x82db8127 0 root 644 0 0 # ipcmk -Q Message queue id: 1 # ipcs -q ------ Message Queues -------- key msqid owner perms used-bytes messages 0x82db8127 0 root 644 0 0 0x76d1fb2a 1 root 644 0 0 # ipcrm -q 0 # ipcs -q ------ Message Queues -------- key msqid owner perms used-bytes messages 0x76d1fb2a 1 root 644 0 0 0x76d1fb2a 1 root 644 0 0 # ipcmk -Q Message queue id: 2 # ipcrm -q 2 # ipcs -q ------ Message Queues -------- key msqid owner perms used-bytes messages 0x76d1fb2a 1 root 644 0 0 0x76d1fb2a 1 root 644 0 0 # ipcmk -Q Message queue id: 3 # ipcrm -q 1 # ipcs -q ------ Message Queues -------- key msqid owner perms used-bytes messages 0x7c982867 3 root 644 0 0 0x7c982867 3 root 644 0 0 0x7c982867 3 root 644 0 0 0x7c982867 3 root 644 0 0 Whenever an IPC item with a low id is deleted, the items with higher ids are duplicated, as if filling a hole. new_pos should jump through hole of unused ids, pos can be updated inside "for" cycle. Link: http://lkml.kernel.org/r/4921fe9b-9385-a2b4-1dc4-1099be6d2e39@virtuozzo.com Fixes: 89163f93c6f9 ("ipc/util.c: sysvipc_find_ipc() should increase position index") Signed-off-by: Vasily Averin <vvs(a)virtuozzo.com> Reported-by: Andreas Schwab <schwab(a)suse.de> Acked-by: Waiman Long <longman(a)redhat.com> Cc: NeilBrown <neilb(a)suse.com> Cc: Steven Rostedt <rostedt(a)goodmis.org> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Peter Oberparleiter <oberpar(a)linux.ibm.com> Cc: Davidlohr Bueso <dave(a)stgolabs.net> Cc: Manfred Spraul <manfred(a)colorfullife.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- ipc/util.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) --- a/ipc/util.c~ipc-utilc-sysvipc_find_ipc-incorrectly-updates-position-index +++ a/ipc/util.c @@ -764,21 +764,21 @@ static struct kern_ipc_perm *sysvipc_fin total++; } - *new_pos = pos + 1; + ipc = NULL; if (total >= ids->in_use) - return NULL; + goto out; for (; pos < ipc_mni; pos++) { ipc = idr_find(&ids->ipcs_idr, pos); if (ipc != NULL) { rcu_read_lock(); ipc_lock_object(ipc); - return ipc; + break; } } - - /* Out of range - return NULL to terminate iteration */ - return NULL; +out: + *new_pos = pos + 1; + return ipc; } static void *sysvipc_proc_next(struct seq_file *s, void *it, loff_t *pos) _ Patches currently in -mm which might be from vvs(a)virtuozzo.com are ipc-utilc-sysvipc_find_ipc-incorrectly-updates-position-index.patch

5 years, 7 months

1
0
0 0

stable-rc/linux-4.4.y boot: 42 boots: 9 failed, 23 passed with 5 offline, 5 untried/unknown (v4.4.222-321-gb1cd678a0c39)

by kernelci.org bot

stable-rc/linux-4.4.y boot: 42 boots: 9 failed, 23 passed with 5 offline, 5 untried/unknown (v4.4.222-321-gb1cd678a0c39) 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-321… Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.222-321-gb1cd678a0c39 Git Commit: b1cd678a0c3999314bdefe2f279faaa2d2ef5c01 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 33 unique boards, 9 SoC families, 14 builds out of 190 Boot Regressions Detected: arm: davinci_all_defconfig: gcc-8: da850-evm: lab-baylibre-seattle: new failure (last pass: v4.4.222-166-g7ab45cabed0b) dm365evm,legacy: lab-baylibre-seattle: new failure (last pass: v4.4.222-166-g7ab45cabed0b) imx_v6_v7_defconfig: gcc-8: imx6dl-riotboard: lab-pengutronix: new failure (last pass: v4.4.222-166-g7ab45cabed0b) imx6dl-wandboard_dual: lab-baylibre-seattle: new failure (last pass: v4.4.222-166-g7ab45cabed0b) imx6dl-wandboard_solo: lab-baylibre-seattle: new failure (last pass: v4.4.222-166-g7ab45cabed0b) omap2plus_defconfig: gcc-8: am335x-boneblack: lab-baylibre: new failure (last pass: v4.4.222-166-g7ab45cabed0b) qcom_defconfig: gcc-8: qcom-apq8064-cm-qs600: lab-baylibre-seattle: failing since 89 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: new failure (last pass: v4.4.222-166-g7ab45cabed0b) sun4i-a10-olinuxino-lime: lab-baylibre: new failure (last pass: v4.4.222-166-g7ab45cabed0b) sun7i-a20-cubieboard2: lab-clabbe: new failure (last pass: v4.4.222-166-g7ab45cabed0b) sun7i-a20-olinuxino-lime2: lab-baylibre: new failure (last pass: v4.4.222-166-g7ab45cabed0b) 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 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 Offline Platforms: arm: qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab davinci_all_defconfig: gcc-8 da850-evm: 1 offline lab dm365evm,legacy: 1 offline lab exynos_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab imx_v6_v7_defconfig: gcc-8 imx6q-wandboard: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 7 months

1
0
0 0

+ lib-lzo-fix-ambiguous-encoding-bug-in-lzo-rle.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: lib/lzo: fix ambiguous encoding bug in lzo-rle has been added to the -mm tree. Its filename is lib-lzo-fix-ambiguous-encoding-bug-in-lzo-rle.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/lib-lzo-fix-ambiguous-encoding-bug… and later at http://ozlabs.org/~akpm/mmotm/broken-out/lib-lzo-fix-ambiguous-encoding-bug… 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: Dave Rodgman <dave.rodgman(a)arm.com> Subject: lib/lzo: fix ambiguous encoding bug in lzo-rle In some rare cases, for input data over 32 KB, lzo-rle could encode two different inputs to the same compressed representation, so that decompression is then ambiguous (i.e. data may be corrupted - although zram is not affected because it operates over 4 KB pages). This modifies the compressor without changing the decompressor or the bitstream format, such that: - there is no change to how data produced by the old compressor is decompressed - an old decompressor will correctly decode data from the updated compressor - performance and compression ratio are not affected - we avoid introducing a new bitstream format In testing over 12.8M real-world files totalling 903 GB, three files were affected by this bug. I also constructed 37M semi-random 64 KB files totalling 2.27 TB, and saw no affected files. Finally I tested over files constructed to contain each of the ~1024 possible bad input sequences; for all of these cases, updated lzo-rle worked correctly. There is no significant impact to performance or compression ratio. Link: http://lkml.kernel.org/r/20200507100203.29785-1-dave.rodgman@arm.com Signed-off-by: Dave Rodgman <dave.rodgman(a)arm.com> Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: Dave Rodgman <dave.rodgman(a)arm.com> Cc: Willy Tarreau <w(a)1wt.eu> Cc: Sergey Senozhatsky <sergey.senozhatsky.work(a)gmail.com> Cc: Markus F.X.J. Oberhumer <markus(a)oberhumer.com> Cc: Minchan Kim <minchan(a)kernel.org> Cc: Nitin Gupta <ngupta(a)vflare.org> Cc: Chao Yu <yuchao0(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- Documentation/lzo.txt | 8 ++++++-- lib/lzo/lzo1x_compress.c | 13 +++++++++++++ 2 files changed, 19 insertions(+), 2 deletions(-) --- a/Documentation/lzo.txt~lib-lzo-fix-ambiguous-encoding-bug-in-lzo-rle +++ a/Documentation/lzo.txt @@ -159,11 +159,15 @@ Byte sequences distance = 16384 + (H << 14) + D state = S (copy S literals after this block) End of stream is reached if distance == 16384 + In version 1 only, to prevent ambiguity with the RLE case when + ((distance & 0x803f) == 0x803f) && (261 <= length <= 264), the + compressor must not emit block copies where distance and length + meet these conditions. In version 1 only, this instruction is also used to encode a run of - zeros if distance = 0xbfff, i.e. H = 1 and the D bits are all 1. + zeros if distance = 0xbfff, i.e. H = 1 and the D bits are all 1. In this case, it is followed by a fourth byte, X. - run length = ((X << 3) | (0 0 0 0 0 L L L)) + 4. + run length = ((X << 3) | (0 0 0 0 0 L L L)) + 4 0 0 1 L L L L L (32..63) Copy of small block within 16kB distance (preferably less than 34B) --- a/lib/lzo/lzo1x_compress.c~lib-lzo-fix-ambiguous-encoding-bug-in-lzo-rle +++ a/lib/lzo/lzo1x_compress.c @@ -268,6 +268,19 @@ m_len_done: *op++ = (M4_MARKER | ((m_off >> 11) & 8) | (m_len - 2)); else { + if (unlikely(((m_off & 0x403f) == 0x403f) + && (m_len >= 261) + && (m_len <= 264)) + && likely(bitstream_version)) { + // Under lzo-rle, block copies + // for 261 <= length <= 264 and + // (distance & 0x80f3) == 0x80f3 + // can result in ambiguous + // output. Adjust length + // to 260 to prevent ambiguity. + ip -= m_len - 260; + m_len = 260; + } m_len -= M4_MAX_LEN; *op++ = (M4_MARKER | ((m_off >> 11) & 8)); while (unlikely(m_len > 255)) { _ Patches currently in -mm which might be from dave.rodgman(a)arm.com are lib-lzo-fix-ambiguous-encoding-bug-in-lzo-rle.patch

5 years, 7 months

1
0
0 0

[PATCH] x86/fpu/xstate: Clear uninitialized xstate areas in core dump

by Yu-cheng Yu

In a core dump, copy_xstate_to_kernel() copies only enabled user xfeatures to a kernel buffer without touching areas for disabled xfeatures. However, those uninitialized areas may contain random data, which is then written to the core dump file and can be read by a non-privileged user. Fix it by clearing uninitialized areas. Link: https://github.com/google/kmsan/issues/76 Link: https://lore.kernel.org/lkml/20200419100848.63472-1-glider@google.com/ Signed-off-by: Yu-cheng Yu <yu-cheng.yu(a)intel.com> Reported-by: sam <sunhaoyl(a)outlook.com> Cc: "H. Peter Anvin" <hpa(a)zytor.com> Cc: Kees Cook <keescook(a)chromium.org> Cc: Alexey Dobriyan <adobriyan(a)gmail.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Dave Hansen <dave.hansen(a)intel.com> Cc: Jann Horn <jannh(a)google.com> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Alexander Potapenko <glider(a)google.com> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: <stable(a)vger.kernel.org> --- arch/x86/kernel/fpu/xstate.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c index 32b153d38748..0856daa29be7 100644 --- a/arch/x86/kernel/fpu/xstate.c +++ b/arch/x86/kernel/fpu/xstate.c @@ -983,6 +983,7 @@ int copy_xstate_to_kernel(void *kbuf, struct xregs_state *xsave, unsigned int of { unsigned int offset, size; struct xstate_header header; + int last_off; int i; /* @@ -1006,7 +1007,17 @@ int copy_xstate_to_kernel(void *kbuf, struct xregs_state *xsave, unsigned int of __copy_xstate_to_kernel(kbuf, &header, offset, size, size_total); + last_off = 0; + for (i = 0; i < XFEATURE_MAX; i++) { + /* + * Clear uninitialized area before XSAVE header. + */ + if (i == FIRST_EXTENDED_XFEATURE) { + memset(kbuf + last_off, 0, XSAVE_HDR_OFFSET - last_off); + last_off = XSAVE_HDR_OFFSET + XSAVE_HDR_SIZE; + } + /* * Copy only in-use xstates: */ @@ -1020,11 +1031,16 @@ int copy_xstate_to_kernel(void *kbuf, struct xregs_state *xsave, unsigned int of if (offset + size > size_total) break; + memset(kbuf + last_off, 0, offset - last_off); + last_off = offset + size; + __copy_xstate_to_kernel(kbuf, src, offset, size, size_total); } } + memset(kbuf + last_off, 0, size_total - last_off); + if (xfeatures_mxcsr_quirk(header.xfeatures)) { offset = offsetof(struct fxregs_state, mxcsr); size = MXCSR_AND_FLAGS_SIZE; -- 2.21.0

5 years, 7 months

4
6
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror