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

[patch 069/158] mm, memfd: fix COW issue on MAP_PRIVATE and F_SEAL_FUTURE_WRITE mappings

by akpm＠linux-foundation.org

From: Nicolas Geoffray <ngeoffray(a)google.com> Subject: mm, memfd: fix COW issue on MAP_PRIVATE and F_SEAL_FUTURE_WRITE mappings F_SEAL_FUTURE_WRITE has unexpected behavior when used with MAP_PRIVATE: A private mapping created after the memfd file that gets sealed with F_SEAL_FUTURE_WRITE loses the copy-on-write at fork behavior, meaning children and parent share the same memory, even though the mapping is private. The reason for this is due to the code below: static int shmem_mmap(struct file *file, struct vm_area_struct *vma) { struct shmem_inode_info *info = SHMEM_I(file_inode(file)); if (info->seals & F_SEAL_FUTURE_WRITE) { /* * New PROT_WRITE and MAP_SHARED mmaps are not allowed when * "future write" seal active. */ if ((vma->vm_flags & VM_SHARED) && (vma->vm_flags & VM_WRITE)) return -EPERM; /* * Since the F_SEAL_FUTURE_WRITE seals allow for a MAP_SHARED * read-only mapping, take care to not allow mprotect to revert * protections. */ vma->vm_flags &= ~(VM_MAYWRITE); } ... } And for the mm to know if a mapping is copy-on-write: static inline bool is_cow_mapping(vm_flags_t flags) { return (flags & (VM_SHARED | VM_MAYWRITE)) == VM_MAYWRITE; } The patch fixes the issue by making the mprotect revert protection happen only for shared mappings. For private mappings, using mprotect will have no effect on the seal behavior. The F_SEAL_FUTURE_WRITE feature was introduced in v5.1 so v5.3.x stable kernels would need a backport. [akpm(a)linux-foundation.org: reflow comment, per Christoph] Link: http://lkml.kernel.org/r/20191107195355.80608-1-joel@joelfernandes.org Fixes: ab3948f58ff84 ("mm/memfd: add an F_SEAL_FUTURE_WRITE seal to memfd") Signed-off-by: Nicolas Geoffray <ngeoffray(a)google.com> Signed-off-by: Joel Fernandes (Google) <joel(a)joelfernandes.org> Cc: Hugh Dickins <hughd(a)google.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/shmem.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) --- a/mm/shmem.c~memfd-fix-cow-issue-on-map_private-and-f_seal_future_write-mappings +++ a/mm/shmem.c @@ -2214,11 +2214,14 @@ static int shmem_mmap(struct file *file, return -EPERM; /* - * Since the F_SEAL_FUTURE_WRITE seals allow for a MAP_SHARED - * read-only mapping, take care to not allow mprotect to revert - * protections. + * Since an F_SEAL_FUTURE_WRITE sealed memfd can be mapped as + * MAP_SHARED and read-only, take care to not allow mprotect to + * revert protections on such mappings. Do this only for shared + * mappings. For private mappings, don't need to mask + * VM_MAYWRITE as we still want them to be COW-writable. */ - vma->vm_flags &= ~(VM_MAYWRITE); + if (vma->vm_flags & VM_SHARED) + vma->vm_flags &= ~(VM_MAYWRITE); } file_accessed(file); _

5 years, 11 months

1
0
0 0

[patch 045/158] mm/memory.c: fix a huge pud insertion race during faulting

by akpm＠linux-foundation.org

From: Thomas Hellstrom <thellstrom(a)vmware.com> Subject: mm/memory.c: fix a huge pud insertion race during faulting A huge pud page can theoretically be faulted in racing with pmd_alloc() in __handle_mm_fault(). That will lead to pmd_alloc() returning an invalid pmd pointer. Fix this by adding a pud_trans_unstable() function similar to pmd_trans_unstable() and check whether the pud is really stable before using the pmd pointer. Race: Thread 1: Thread 2: Comment create_huge_pud() Fallback - not taken. create_huge_pud() Taken. pmd_alloc() Returns an invalid pointer. This will result in user-visible huge page data corruption. Note that this was caught during a code audit rather than a real experienced problem. It looks to me like the only implementation that currently creates huge pud pagetable entries is dev_dax_huge_fault() which doesn't appear to care much about private (COW) mappings or write-tracking which is, I believe, a prerequisite for create_huge_pud() falling back on thread 1, but not in thread 2. Link: http://lkml.kernel.org/r/20191115115808.21181-2-thomas_os@shipmail.org Fixes: a00cc7d9dd93 ("mm, x86: add support for PUD-sized transparent hugepages") Signed-off-by: Thomas Hellstrom <thellstrom(a)vmware.com> Acked-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/asm-generic/pgtable.h | 25 +++++++++++++++++++++++++ mm/memory.c | 6 ++++++ 2 files changed, 31 insertions(+) --- a/include/asm-generic/pgtable.h~mm-fix-a-huge-pud-insertion-race-during-faulting +++ a/include/asm-generic/pgtable.h @@ -938,6 +938,31 @@ static inline int pud_trans_huge(pud_t p } #endif +/* See pmd_none_or_trans_huge_or_clear_bad for discussion. */ +static inline int pud_none_or_trans_huge_or_dev_or_clear_bad(pud_t *pud) +{ + pud_t pudval = READ_ONCE(*pud); + + if (pud_none(pudval) || pud_trans_huge(pudval) || pud_devmap(pudval)) + return 1; + if (unlikely(pud_bad(pudval))) { + pud_clear_bad(pud); + return 1; + } + return 0; +} + +/* See pmd_trans_unstable for discussion. */ +static inline int pud_trans_unstable(pud_t *pud) +{ +#if defined(CONFIG_TRANSPARENT_HUGEPAGE) && \ + defined(CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD) + return pud_none_or_trans_huge_or_dev_or_clear_bad(pud); +#else + return 0; +#endif +} + #ifndef pmd_read_atomic static inline pmd_t pmd_read_atomic(pmd_t *pmdp) { --- a/mm/memory.c~mm-fix-a-huge-pud-insertion-race-during-faulting +++ a/mm/memory.c @@ -4010,6 +4010,7 @@ static vm_fault_t __handle_mm_fault(stru vmf.pud = pud_alloc(mm, p4d, address); if (!vmf.pud) return VM_FAULT_OOM; +retry_pud: if (pud_none(*vmf.pud) && __transparent_hugepage_enabled(vma)) { ret = create_huge_pud(&vmf); if (!(ret & VM_FAULT_FALLBACK)) @@ -4036,6 +4037,11 @@ static vm_fault_t __handle_mm_fault(stru vmf.pmd = pmd_alloc(mm, vmf.pud, address); if (!vmf.pmd) return VM_FAULT_OOM; + + /* Huge pud page fault raced with pmd_alloc? */ + if (pud_trans_unstable(vmf.pud)) + goto retry_pud; + if (pmd_none(*vmf.pmd) && __transparent_hugepage_enabled(vma)) { ret = create_huge_pmd(&vmf); if (!(ret & VM_FAULT_FALLBACK)) _

5 years, 11 months

1
0
0 0

+ mm-memcg-slab-wait-for-root-kmem_cache-refcnt-killing-on-root-kmem_cache-destruction.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: memcg/slab: wait for !root kmem_cache refcnt killing on root kmem_cache destruction has been added to the -mm tree. Its filename is mm-memcg-slab-wait-for-root-kmem_cache-refcnt-killing-on-root-kmem_cache-destruction.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-memcg-slab-wait-for-root-kmem_c… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-memcg-slab-wait-for-root-kmem_c… 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: Roman Gushchin <guro(a)fb.com> Subject: mm: memcg/slab: wait for !root kmem_cache refcnt killing on root kmem_cache destruction Christian reported a warning like the following obtained during running some KVM-related tests on s390: WARNING: CPU: 8 PID: 208 at lib/percpu-refcount.c:108 percpu_ref_exit+0x50/0x58 Modules linked in: kvm(-) xt_CHECKSUM xt_MASQUERADE bonding xt_tcpudp ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ip6table_na> CPU: 8 PID: 208 Comm: kworker/8:1 Not tainted 5.2.0+ #66 Hardware name: IBM 2964 NC9 712 (LPAR) Workqueue: events sysfs_slab_remove_workfn Krnl PSW : 0704e00180000000 0000001529746850 (percpu_ref_exit+0x50/0x58) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 00000000ffff8808 0000001529746740 000003f4e30e8e18 0036008100000000 0000001f00000000 0035008100000000 0000001fb3573ab8 0000000000000000 0000001fbdb6de00 0000000000000000 0000001529f01328 0000001fb3573b00 0000001fbb27e000 0000001fbdb69300 000003e009263d00 000003e009263cd0 Krnl Code: 0000001529746842: f0a0000407fe srp 4(11,%r0),2046,0 0000001529746848: 47000700 bc 0,1792 #000000152974684c: a7f40001 brc 15,152974684e >0000001529746850: a7f4fff2 brc 15,1529746834 0000001529746854: 0707 bcr 0,%r7 0000001529746856: 0707 bcr 0,%r7 0000001529746858: eb8ff0580024 stmg %r8,%r15,88(%r15) 000000152974685e: a738ffff lhi %r3,-1 Call Trace: ([<000003e009263d00>] 0x3e009263d00) [<00000015293252ea>] slab_kmem_cache_release+0x3a/0x70 [<0000001529b04882>] kobject_put+0xaa/0xe8 [<000000152918cf28>] process_one_work+0x1e8/0x428 [<000000152918d1b0>] worker_thread+0x48/0x460 [<00000015291942c6>] kthread+0x126/0x160 [<0000001529b22344>] ret_from_fork+0x28/0x30 [<0000001529b2234c>] kernel_thread_starter+0x0/0x10 Last Breaking-Event-Address: [<000000152974684c>] percpu_ref_exit+0x4c/0x58 ---[ end trace b035e7da5788eb09 ]--- The problem occurs because kmem_cache_destroy() is called immediately after deleting of a memcg, so it races with the memcg kmem_cache deactivation. flush_memcg_workqueue() at the beginning of kmem_cache_destroy() is supposed to guarantee that all deactivation processes are finished, but failed to do so. It waits for an rcu grace period, after which all children kmem_caches should be deactivated. During the deactivation percpu_ref_kill() is called for non root kmem_cache refcounters, but it requires yet another rcu grace period to finish the transition to the atomic (dead) state. So in a rare case when not all children kmem_caches are destroyed at the moment when the root kmem_cache is about to be gone, we need to wait another rcu grace period before destroying the root kmem_cache. This issue can be triggered only with dynamically created kmem_caches which are used with memcg accounting. In this case per-memcg child kmem_caches are created. They are deactivated from the cgroup removing path. If the destruction of the root kmem_cache is racing with the removal of the cgroup (both are quite complicated multi-stage processes), the described issue can occur. The only known way to trigger it in the real life, is to unload some kernel module which creates a dedicated kmem_cache, used from different memory cgroups with GFP_ACCOUNT flag. If the unloading happens immediately after calling rmdir on the corresponding cgroup, there is some chance to trigger the issue. Link: http://lkml.kernel.org/r/20191129025011.3076017-1-guro@fb.com Fixes: f0a3a24b532d ("mm: memcg/slab: rework non-root kmem_cache lifecycle management") Signed-off-by: Roman Gushchin <guro(a)fb.com> Reported-by: Christian Borntraeger <borntraeger(a)de.ibm.com> Tested-by: Christian Borntraeger <borntraeger(a)de.ibm.com> Reviewed-by: Shakeel Butt <shakeelb(a)google.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/slab_common.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) --- a/mm/slab_common.c~mm-memcg-slab-wait-for-root-kmem_cache-refcnt-killing-on-root-kmem_cache-destruction +++ a/mm/slab_common.c @@ -904,6 +904,18 @@ static void flush_memcg_workqueue(struct * previous workitems on workqueue are processed. */ flush_workqueue(memcg_kmem_cache_wq); + + /* + * If we're racing with children kmem_cache deactivation, it might + * take another rcu grace period to complete their destruction. + * At this moment the corresponding percpu_ref_kill() call should be + * done, but it might take another rcu grace period to complete + * switching to the atomic mode. + * Please, note that we check without grabbing the slab_mutex. It's safe + * because at this moment the children list can't grow. + */ + if (!list_empty(&s->memcg_params.children)) + rcu_barrier(); } #else static inline int shutdown_memcg_caches(struct kmem_cache *s) _ Patches currently in -mm which might be from guro(a)fb.com are mm-memcg-slab-wait-for-root-kmem_cache-refcnt-killing-on-root-kmem_cache-destruction.patch

5 years, 11 months

1
0
0 0

[PATCH v2] taskstats: fix data-race

by Christian Brauner

When assiging and testing taskstats in taskstats_exit() there's a race when writing and reading sig->stats when a thread-group with more than one thread exits: cpu0: thread catches fatal signal and whole thread-group gets taken down do_exit() do_group_exit() taskstats_exit() taskstats_tgid_alloc() The tasks reads sig->stats holding sighand lock seeing garbage. cpu1: task calls exit_group() do_exit() do_group_exit() taskstats_exit() taskstats_tgid_alloc() The task takes sighand lock and assigns new stats to sig->stats. Fix this by using READ_ONCE() and smp_store_release(). Reported-by: syzbot+c5d03165a1bd1dead0c1(a)syzkaller.appspotmail.com Fixes: 34ec12349c8a ("taskstats: cleanup ->signal->stats allocation") Cc: stable(a)vger.kernel.org Signed-off-by: Christian Brauner <christian.brauner(a)ubuntu.com> Reviewed-by: Dmitry Vyukov <dvyukov(a)google.com> Link: https://lore.kernel.org/r/20191006235216.7483-1-christian.brauner@ubuntu.com --- /* v1 */ Link: https://lore.kernel.org/r/20191005112806.13960-1-christian.brauner@ubuntu.c… /* v2 */ - Dmitry Vyukov <dvyukov(a)google.com>, Marco Elver <elver(a)google.com>: - fix the original double-checked locking using memory barriers /* v3 */ - Andrea Parri <parri.andrea(a)gmail.com>: - document memory barriers to make checkpatch happy --- kernel/taskstats.c | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/kernel/taskstats.c b/kernel/taskstats.c index 13a0f2e6ebc2..978d7931fb65 100644 --- a/kernel/taskstats.c +++ b/kernel/taskstats.c @@ -554,24 +554,27 @@ static int taskstats_user_cmd(struct sk_buff *skb, struct genl_info *info) static struct taskstats *taskstats_tgid_alloc(struct task_struct *tsk) { struct signal_struct *sig = tsk->signal; - struct taskstats *stats; + struct taskstats *stats_new, *stats; - if (sig->stats || thread_group_empty(tsk)) - goto ret; + /* Pairs with smp_store_release() below. */ + stats = READ_ONCE(sig->stats); + if (stats || thread_group_empty(tsk)) + return stats; /* No problem if kmem_cache_zalloc() fails */ - stats = kmem_cache_zalloc(taskstats_cache, GFP_KERNEL); + stats_new = kmem_cache_zalloc(taskstats_cache, GFP_KERNEL); spin_lock_irq(&tsk->sighand->siglock); if (!sig->stats) { - sig->stats = stats; - stats = NULL; + /* Pairs with READ_ONCE() above. */ + smp_store_release(&sig->stats, stats_new); + stats_new = NULL; } spin_unlock_irq(&tsk->sighand->siglock); - if (stats) - kmem_cache_free(taskstats_cache, stats); -ret: + if (stats_new) + kmem_cache_free(taskstats_cache, stats_new); + return sig->stats; } -- 2.23.0

5 years, 11 months

6
40
0 0

❌ FAIL: Test report for kernel 5.3.14-b8e1670.cki (stable)

by CKI Project

Hello, We ran automated tests on a recent commit from this kernel tree: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Commit: b8e167066e85 - Linux 5.3.14 The results of these automated tests are provided below. Overall result: FAILED (see details below) Merge: OK Compile: OK Tests: FAILED All kernel binaries, config files, and logs are available for download here: https://artifacts.cki-project.org/pipelines/314428 One or more kernel tests failed: x86_64: ❌ Memory function: kaslr We hope that these logs can help you find the problem quickly. For the full detail on our testing procedures, please scroll to the bottom of this message. Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Compile testing --------------- We compiled the kernel for 3 architectures: aarch64: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg ppc64le: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg x86_64: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg Hardware testing ---------------- We booted each kernel and ran the following tests: aarch64: Host 1: ✅ Boot test ✅ Podman system integration test (as root) ✅ Podman system integration test (as user) ✅ LTP ✅ Loopdev Sanity ✅ Memory function: memfd_create ✅ Memory function: kaslr ✅ AMTU (Abstract Machine Test Utility) ✅ Networking bridge: sanity ✅ Ethernet drivers sanity ✅ Networking MACsec: sanity ✅ Networking socket: fuzz ✅ Networking sctp-auth: sockopts test ✅ Networking: igmp conformance test ✅ Networking route: pmtu ✅ Networking route_func: local ✅ Networking route_func: forward ✅ Networking TCP: keepalive test ✅ Networking UDP: socket ✅ Networking tunnel: geneve basic test ✅ Networking tunnel: gre basic ✅ L2TP basic test ✅ Networking tunnel: vxlan basic ✅ Networking ipsec: basic netns transport ✅ Networking ipsec: basic netns tunnel ✅ audit: audit testsuite test ✅ httpd: mod_ssl smoke sanity ✅ tuned: tune-processes-through-perf ✅ ALSA PCM loopback test ✅ ALSA Control (mixer) Userspace Element test ✅ storage: SCSI VPD ✅ stress: stress-ng ✅ trace: ftrace/tracer 🚧 ✅ CIFS Connectathon 🚧 ✅ POSIX pjd-fstest suites 🚧 ✅ jvm test suite 🚧 ✅ LTP: openposix test suite 🚧 ✅ Networking vnic: ipvlan/basic 🚧 ✅ iotop: sanity 🚧 ✅ Usex - version 1.9-29 🚧 ✅ storage: dm/common Host 2: ✅ Boot test ✅ xfstests: ext4 ✅ xfstests: xfs ✅ lvm thinp sanity ✅ storage: software RAID testing 🚧 ✅ selinux-policy: serge-testsuite 🚧 ✅ Storage blktests ppc64le: Host 1: ✅ Boot test ✅ Podman system integration test (as root) ✅ Podman system integration test (as user) ✅ LTP ✅ Loopdev Sanity ✅ Memory function: memfd_create ✅ Memory function: kaslr ✅ AMTU (Abstract Machine Test Utility) ✅ Networking bridge: sanity ✅ Ethernet drivers sanity ✅ Networking MACsec: sanity ✅ Networking socket: fuzz ✅ Networking sctp-auth: sockopts test ✅ Networking route: pmtu ✅ Networking route_func: local ✅ Networking route_func: forward ✅ Networking TCP: keepalive test ✅ Networking UDP: socket ✅ Networking tunnel: geneve basic test ✅ Networking tunnel: gre basic ✅ L2TP basic test ✅ Networking tunnel: vxlan basic ✅ Networking ipsec: basic netns tunnel ✅ audit: audit testsuite test ✅ httpd: mod_ssl smoke sanity ✅ tuned: tune-processes-through-perf ✅ ALSA PCM loopback test ✅ ALSA Control (mixer) Userspace Element test ✅ trace: ftrace/tracer 🚧 ✅ CIFS Connectathon 🚧 ✅ POSIX pjd-fstest suites 🚧 ✅ jvm test suite 🚧 ✅ LTP: openposix test suite 🚧 ✅ Networking vnic: ipvlan/basic 🚧 ✅ iotop: sanity 🚧 ✅ Usex - version 1.9-29 🚧 ✅ storage: dm/common Host 2: ✅ Boot test ✅ xfstests: ext4 ✅ xfstests: xfs ✅ lvm thinp sanity ✅ storage: software RAID testing 🚧 ✅ IPMI driver test 🚧 ✅ IPMItool loop stress test 🚧 ✅ selinux-policy: serge-testsuite 🚧 ✅ Storage blktests x86_64: Host 1: ✅ Boot test ✅ Podman system integration test (as root) ✅ Podman system integration test (as user) ✅ LTP ✅ Loopdev Sanity ✅ Memory function: memfd_create ❌ Memory function: kaslr ✅ AMTU (Abstract Machine Test Utility) ✅ Networking bridge: sanity ✅ Ethernet drivers sanity ✅ Networking MACsec: sanity ✅ Networking socket: fuzz ✅ Networking sctp-auth: sockopts test ✅ Networking: igmp conformance test ✅ Networking route: pmtu ✅ Networking route_func: local ✅ Networking route_func: forward ✅ Networking TCP: keepalive test ✅ Networking UDP: socket ✅ Networking tunnel: geneve basic test ✅ Networking tunnel: gre basic ✅ L2TP basic test ✅ Networking tunnel: vxlan basic ✅ Networking ipsec: basic netns transport ✅ Networking ipsec: basic netns tunnel ✅ audit: audit testsuite test ✅ httpd: mod_ssl smoke sanity ✅ tuned: tune-processes-through-perf ✅ pciutils: sanity smoke test ✅ ALSA PCM loopback test ✅ ALSA Control (mixer) Userspace Element test ✅ storage: SCSI VPD ✅ stress: stress-ng ✅ trace: ftrace/tracer 🚧 ✅ CIFS Connectathon 🚧 ✅ POSIX pjd-fstest suites 🚧 ✅ jvm test suite 🚧 ✅ LTP: openposix test suite 🚧 ✅ Networking vnic: ipvlan/basic 🚧 ✅ iotop: sanity 🚧 ✅ Usex - version 1.9-29 🚧 ✅ storage: dm/common Host 2: ⏱ Boot test ⏱ Storage SAN device stress - mpt3sas driver Host 3: ✅ Boot test ✅ xfstests: ext4 ✅ xfstests: xfs ✅ lvm thinp sanity ✅ storage: software RAID testing 🚧 ✅ IOMMU boot test 🚧 ✅ IPMI driver test 🚧 ✅ IPMItool loop stress test 🚧 ✅ selinux-policy: serge-testsuite 🚧 ✅ Storage blktests Host 4: ⏱ Boot test ⏱ Storage SAN device stress - megaraid_sas Test sources: https://github.com/CKI-project/tests-beaker 💚 Pull requests are welcome for new tests or improvements to existing tests! Waived tests ------------ If the test run included waived tests, they are marked with 🚧. Such tests are executed but their results are not taken into account. Tests are waived when their results are not reliable enough, e.g. when they're just introduced or are being fixed. Testing timeout --------------- We aim to provide a report within reasonable timeframe. Tests that haven't finished running are marked with ⏱. Reports for non-upstream kernels have a Beaker recipe linked to next to each host.

5 years, 11 months

1
0
0 0

❌ FAIL: Test report for kernel 5.3.13-1fa816c.cki (stable-queue)

by CKI Project

Hello, We ran automated tests on a recent commit from this kernel tree: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git Commit: 1fa816c05741 - net-sysfs: fix netdev_queue_add_kobject() breakage The results of these automated tests are provided below. Overall result: FAILED (see details below) Merge: OK Compile: OK Tests: FAILED All kernel binaries, config files, and logs are available for download here: https://artifacts.cki-project.org/pipelines/314327 One or more kernel tests failed: x86_64: ❌ Memory function: kaslr We hope that these logs can help you find the problem quickly. For the full detail on our testing procedures, please scroll to the bottom of this message. Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Compile testing --------------- We compiled the kernel for 3 architectures: aarch64: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg ppc64le: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg x86_64: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg Hardware testing ---------------- We booted each kernel and ran the following tests: aarch64: Host 1: ✅ Boot test ✅ Podman system integration test (as root) ✅ Podman system integration test (as user) ✅ LTP ✅ Loopdev Sanity ✅ Memory function: memfd_create ✅ Memory function: kaslr ✅ AMTU (Abstract Machine Test Utility) ✅ Networking bridge: sanity ✅ Ethernet drivers sanity ✅ Networking MACsec: sanity ✅ Networking socket: fuzz ✅ Networking sctp-auth: sockopts test ✅ Networking: igmp conformance test ✅ Networking route: pmtu ✅ Networking route_func: local ✅ Networking route_func: forward ✅ Networking TCP: keepalive test ✅ Networking UDP: socket ✅ Networking tunnel: geneve basic test ✅ Networking tunnel: gre basic ✅ L2TP basic test ✅ Networking tunnel: vxlan basic ✅ Networking ipsec: basic netns transport ✅ Networking ipsec: basic netns tunnel ✅ audit: audit testsuite test ✅ httpd: mod_ssl smoke sanity ✅ tuned: tune-processes-through-perf ✅ ALSA PCM loopback test ✅ ALSA Control (mixer) Userspace Element test ✅ storage: SCSI VPD ✅ trace: ftrace/tracer 🚧 ✅ CIFS Connectathon 🚧 ✅ POSIX pjd-fstest suites 🚧 ✅ jvm test suite 🚧 ✅ LTP: openposix test suite 🚧 ✅ Networking vnic: ipvlan/basic 🚧 ✅ iotop: sanity 🚧 ✅ Usex - version 1.9-29 🚧 ✅ storage: dm/common Host 2: ✅ Boot test ✅ xfstests: ext4 ✅ xfstests: xfs ✅ lvm thinp sanity ✅ storage: software RAID testing 🚧 ✅ selinux-policy: serge-testsuite 🚧 ✅ Storage blktests ppc64le: Host 1: ✅ Boot test ✅ Podman system integration test (as root) ✅ Podman system integration test (as user) ✅ LTP ✅ Loopdev Sanity ✅ Memory function: memfd_create ✅ Memory function: kaslr ✅ AMTU (Abstract Machine Test Utility) ✅ Networking bridge: sanity ✅ Ethernet drivers sanity ✅ Networking MACsec: sanity ✅ Networking socket: fuzz ✅ Networking sctp-auth: sockopts test ✅ Networking route: pmtu ✅ Networking route_func: local ✅ Networking route_func: forward ✅ Networking TCP: keepalive test ✅ Networking UDP: socket ✅ Networking tunnel: geneve basic test ✅ Networking tunnel: gre basic ✅ L2TP basic test ✅ Networking tunnel: vxlan basic ✅ Networking ipsec: basic netns tunnel ✅ audit: audit testsuite test ✅ httpd: mod_ssl smoke sanity ✅ tuned: tune-processes-through-perf ✅ ALSA PCM loopback test ✅ ALSA Control (mixer) Userspace Element test ✅ trace: ftrace/tracer 🚧 ✅ CIFS Connectathon 🚧 ✅ POSIX pjd-fstest suites 🚧 ✅ jvm test suite 🚧 ✅ LTP: openposix test suite 🚧 ✅ Networking vnic: ipvlan/basic 🚧 ✅ iotop: sanity 🚧 ✅ Usex - version 1.9-29 🚧 ✅ storage: dm/common Host 2: ✅ Boot test ✅ xfstests: ext4 ✅ xfstests: xfs ✅ lvm thinp sanity ✅ storage: software RAID testing 🚧 ✅ IPMI driver test 🚧 ✅ IPMItool loop stress test 🚧 ✅ selinux-policy: serge-testsuite 🚧 ❌ Storage blktests x86_64: Host 1: ✅ Boot test ✅ Podman system integration test (as root) ✅ Podman system integration test (as user) ✅ LTP ✅ Loopdev Sanity ✅ Memory function: memfd_create ❌ Memory function: kaslr ✅ AMTU (Abstract Machine Test Utility) ✅ Networking bridge: sanity ✅ Ethernet drivers sanity ✅ Networking MACsec: sanity ✅ Networking socket: fuzz ✅ Networking sctp-auth: sockopts test ✅ Networking: igmp conformance test ✅ Networking route: pmtu ✅ Networking route_func: local ✅ Networking route_func: forward ✅ Networking TCP: keepalive test ✅ Networking UDP: socket ✅ Networking tunnel: geneve basic test ✅ Networking tunnel: gre basic ✅ L2TP basic test ✅ Networking tunnel: vxlan basic ✅ Networking ipsec: basic netns transport ✅ Networking ipsec: basic netns tunnel ✅ audit: audit testsuite test ✅ httpd: mod_ssl smoke sanity ✅ tuned: tune-processes-through-perf ✅ pciutils: sanity smoke test ✅ ALSA PCM loopback test ✅ ALSA Control (mixer) Userspace Element test ✅ storage: SCSI VPD ✅ stress: stress-ng ✅ trace: ftrace/tracer 🚧 ✅ CIFS Connectathon 🚧 ✅ POSIX pjd-fstest suites 🚧 ✅ jvm test suite 🚧 ✅ LTP: openposix test suite 🚧 ✅ Networking vnic: ipvlan/basic 🚧 ✅ iotop: sanity 🚧 ✅ Usex - version 1.9-29 🚧 ✅ storage: dm/common Host 2: ⏱ Boot test ⏱ Storage SAN device stress - mpt3sas driver Host 3: ✅ Boot test ✅ xfstests: ext4 ✅ xfstests: xfs ✅ lvm thinp sanity ✅ storage: software RAID testing 🚧 ✅ IOMMU boot test 🚧 ✅ IPMI driver test 🚧 ✅ IPMItool loop stress test 🚧 ✅ selinux-policy: serge-testsuite 🚧 ✅ Storage blktests Host 4: ⏱ Boot test ⏱ Storage SAN device stress - megaraid_sas Test sources: https://github.com/CKI-project/tests-beaker 💚 Pull requests are welcome for new tests or improvements to existing tests! Waived tests ------------ If the test run included waived tests, they are marked with 🚧. Such tests are executed but their results are not taken into account. Tests are waived when their results are not reliable enough, e.g. when they're just introduced or are being fixed. Testing timeout --------------- We aim to provide a report within reasonable timeframe. Tests that haven't finished running are marked with ⏱. Reports for non-upstream kernels have a Beaker recipe linked to next to each host.

5 years, 11 months

1
0
0 0

✅ PASS: Test report for kernel 5.3.13-71944cf.cki (stable-queue)

by CKI Project

Hello, We ran automated tests on a recent commit from this kernel tree: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git Commit: 71944cfeb47e - net-sysfs: fix netdev_queue_add_kobject() breakage The results of these automated tests are provided below. Overall result: PASSED Merge: OK Compile: OK Tests: OK All kernel binaries, config files, and logs are available for download here: https://artifacts.cki-project.org/pipelines/314294 Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Compile testing --------------- We compiled the kernel for 3 architectures: aarch64: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg ppc64le: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg x86_64: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg Hardware testing ---------------- We booted each kernel and ran the following tests: aarch64: Host 1: ✅ Boot test ✅ Podman system integration test (as root) ✅ Podman system integration test (as user) ✅ LTP ✅ Loopdev Sanity ✅ Memory function: memfd_create ✅ Memory function: kaslr ✅ AMTU (Abstract Machine Test Utility) ✅ Networking bridge: sanity ✅ Ethernet drivers sanity ✅ Networking MACsec: sanity ✅ Networking socket: fuzz ✅ Networking sctp-auth: sockopts test ✅ Networking: igmp conformance test ✅ Networking route: pmtu ✅ Networking route_func: local ✅ Networking route_func: forward ✅ Networking TCP: keepalive test ✅ Networking UDP: socket ✅ Networking tunnel: geneve basic test ✅ Networking tunnel: gre basic ✅ L2TP basic test ✅ Networking tunnel: vxlan basic ✅ Networking ipsec: basic netns transport ✅ Networking ipsec: basic netns tunnel ✅ audit: audit testsuite test ✅ httpd: mod_ssl smoke sanity ✅ tuned: tune-processes-through-perf ✅ ALSA PCM loopback test ✅ ALSA Control (mixer) Userspace Element test ✅ storage: SCSI VPD ✅ trace: ftrace/tracer 🚧 ✅ CIFS Connectathon 🚧 ✅ POSIX pjd-fstest suites 🚧 ✅ jvm test suite 🚧 ✅ LTP: openposix test suite 🚧 ✅ Networking vnic: ipvlan/basic 🚧 ✅ iotop: sanity 🚧 ✅ Usex - version 1.9-29 🚧 ✅ storage: dm/common Host 2: ✅ Boot test ✅ xfstests: ext4 ✅ xfstests: xfs ✅ lvm thinp sanity ✅ storage: software RAID testing 🚧 ✅ selinux-policy: serge-testsuite 🚧 ✅ Storage blktests ppc64le: Host 1: ✅ Boot test ✅ Podman system integration test (as root) ✅ Podman system integration test (as user) ✅ LTP ✅ Loopdev Sanity ✅ Memory function: memfd_create ✅ Memory function: kaslr ✅ AMTU (Abstract Machine Test Utility) ✅ Networking bridge: sanity ✅ Ethernet drivers sanity ✅ Networking MACsec: sanity ✅ Networking socket: fuzz ✅ Networking sctp-auth: sockopts test ✅ Networking route: pmtu ✅ Networking route_func: local ✅ Networking route_func: forward ✅ Networking TCP: keepalive test ✅ Networking UDP: socket ✅ Networking tunnel: geneve basic test ✅ Networking tunnel: gre basic ✅ L2TP basic test ✅ Networking tunnel: vxlan basic ✅ Networking ipsec: basic netns tunnel ✅ audit: audit testsuite test ✅ httpd: mod_ssl smoke sanity ✅ tuned: tune-processes-through-perf ✅ ALSA PCM loopback test ✅ ALSA Control (mixer) Userspace Element test ✅ trace: ftrace/tracer 🚧 ✅ CIFS Connectathon 🚧 ✅ POSIX pjd-fstest suites 🚧 ✅ jvm test suite 🚧 ✅ LTP: openposix test suite 🚧 ✅ Networking vnic: ipvlan/basic 🚧 ✅ iotop: sanity 🚧 ✅ Usex - version 1.9-29 🚧 ✅ storage: dm/common Host 2: ✅ Boot test ✅ xfstests: ext4 ✅ xfstests: xfs ✅ lvm thinp sanity ✅ storage: software RAID testing 🚧 ✅ IPMI driver test 🚧 ✅ IPMItool loop stress test 🚧 ✅ selinux-policy: serge-testsuite 🚧 ✅ Storage blktests x86_64: Host 1: ✅ Boot test ✅ Podman system integration test (as root) ✅ Podman system integration test (as user) ✅ LTP ✅ Loopdev Sanity ✅ Memory function: memfd_create ✅ Memory function: kaslr ✅ AMTU (Abstract Machine Test Utility) ✅ Networking bridge: sanity ✅ Ethernet drivers sanity ✅ Networking MACsec: sanity ✅ Networking socket: fuzz ✅ Networking sctp-auth: sockopts test ✅ Networking: igmp conformance test ✅ Networking route: pmtu ✅ Networking route_func: local ✅ Networking route_func: forward ✅ Networking TCP: keepalive test ✅ Networking UDP: socket ✅ Networking tunnel: geneve basic test ✅ Networking tunnel: gre basic ✅ L2TP basic test ✅ Networking tunnel: vxlan basic ✅ Networking ipsec: basic netns transport ✅ Networking ipsec: basic netns tunnel ✅ audit: audit testsuite test ✅ httpd: mod_ssl smoke sanity ✅ tuned: tune-processes-through-perf ✅ pciutils: sanity smoke test ✅ ALSA PCM loopback test ✅ ALSA Control (mixer) Userspace Element test ✅ storage: SCSI VPD ✅ stress: stress-ng ✅ trace: ftrace/tracer 🚧 ✅ CIFS Connectathon 🚧 ✅ POSIX pjd-fstest suites 🚧 ✅ jvm test suite 🚧 ✅ LTP: openposix test suite 🚧 ✅ Networking vnic: ipvlan/basic 🚧 ✅ iotop: sanity 🚧 ✅ Usex - version 1.9-29 🚧 ✅ storage: dm/common Host 2: ⏱ Boot test ⏱ Storage SAN device stress - megaraid_sas Host 3: ⏱ Boot test ⏱ Storage SAN device stress - mpt3sas driver Host 4: ✅ Boot test ✅ xfstests: ext4 ✅ xfstests: xfs ✅ lvm thinp sanity ✅ storage: software RAID testing 🚧 ✅ IOMMU boot test 🚧 ✅ IPMI driver test 🚧 ✅ IPMItool loop stress test 🚧 ✅ selinux-policy: serge-testsuite 🚧 ✅ Storage blktests Test sources: https://github.com/CKI-project/tests-beaker 💚 Pull requests are welcome for new tests or improvements to existing tests! Waived tests ------------ If the test run included waived tests, they are marked with 🚧. Such tests are executed but their results are not taken into account. Tests are waived when their results are not reliable enough, e.g. when they're just introduced or are being fixed. Testing timeout --------------- We aim to provide a report within reasonable timeframe. Tests that haven't finished running are marked with ⏱. Reports for non-upstream kernels have a Beaker recipe linked to next to each host.

5 years, 11 months

1
0
0 0

[PATCH for-4.9-stable] ath10k: restore QCA9880-AR1A (v1) detection

by Christian Lamparter

commit f8914a14623a79b73f72b2b1ee4cd9b2cb91b735 upstream --- >From f8914a14623a79b73f72b2b1ee4cd9b2cb91b735 Mon Sep 17 00:00:00 2001 From: Christian Lamparter <chunkeey(a)gmail.com> Date: Mon, 25 Mar 2019 13:50:19 +0100 Subject: [PATCH 4.9] ath10k: restore QCA9880-AR1A (v1) detection To: linux-wireless(a)vger.kernel.org, ath10k(a)lists.infradead.org Cc: Kalle Valo <kvalo(a)codeaurora.org> This patch restores the old behavior that read the chip_id on the QCA988x before resetting the chip. This needs to be done in this order since the unsupported QCA988x AR1A chips fall off the bus when resetted. Otherwise the next MMIO Op after the reset causes a BUS ERROR and panic. Cc: stable(a)vger.kernel.org # 4.9 Fixes: 1a7fecb766c8 ("ath10k: reset chip before reading chip_id in probe") Signed-off-by: Christian Lamparter <chunkeey(a)gmail.com> --- drivers/net/wireless/ath/ath10k/pci.c | 36 +++++++++++++++++++-------- 1 file changed, 25 insertions(+), 11 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c --- a/drivers/net/wireless/ath/ath10k/pci.c 2019-09-08 00:07:21.374565470 +0200 +++ b/drivers/net/wireless/ath/ath10k/pci.c 2019-09-08 00:17:15.365912133 +0200 @@ -3172,7 +3172,7 @@ static int ath10k_pci_probe(struct pci_d struct ath10k_pci *ar_pci; enum ath10k_hw_rev hw_rev; u32 chip_id; - bool pci_ps; + bool pci_ps, is_qca988x = false; int (*pci_soft_reset)(struct ath10k *ar); int (*pci_hard_reset)(struct ath10k *ar); u32 (*targ_cpu_to_ce_addr)(struct ath10k *ar, u32 addr); @@ -3181,6 +3181,7 @@ static int ath10k_pci_probe(struct pci_d case QCA988X_2_0_DEVICE_ID: hw_rev = ATH10K_HW_QCA988X; pci_ps = false; + is_qca988x = true; pci_soft_reset = ath10k_pci_warm_reset; pci_hard_reset = ath10k_pci_qca988x_chip_reset; targ_cpu_to_ce_addr = ath10k_pci_qca988x_targ_cpu_to_ce_addr; @@ -3300,6 +3301,19 @@ static int ath10k_pci_probe(struct pci_d goto err_deinit_irq; } + /* Read CHIP_ID before reset to catch QCA9880-AR1A v1 devices that + * fall off the bus during chip_reset. These chips have the same pci + * device id as the QCA9880 BR4A or 2R4E. So that's why the check. + */ + if (is_qca988x) { + chip_id = ath10k_pci_soc_read32(ar, SOC_CHIP_ID_ADDRESS); + if (chip_id != 0xffffffff) { + if (!ath10k_pci_chip_is_supported(pdev->device, + chip_id)) + goto err_unsupported; + } + } + ret = ath10k_pci_chip_reset(ar); if (ret) { ath10k_err(ar, "failed to reset chip: %d\n", ret); @@ -3312,11 +3326,8 @@ static int ath10k_pci_probe(struct pci_d goto err_free_irq; } - if (!ath10k_pci_chip_is_supported(pdev->device, chip_id)) { - ath10k_err(ar, "device %04x with chip_id %08x isn't supported\n", - pdev->device, chip_id); - goto err_free_irq; - } + if (!ath10k_pci_chip_is_supported(pdev->device, chip_id)) + goto err_unsupported; ret = ath10k_core_register(ar, chip_id); if (ret) { @@ -3326,6 +3337,10 @@ static int ath10k_pci_probe(struct pci_d return 0; +err_unsupported: + ath10k_err(ar, "device %04x with chip_id %08x isn't supported\n", + pdev->device, bus_params.chip_id); + err_free_irq: ath10k_pci_free_irq(ar); ath10k_pci_rx_retry_sync(ar);

5 years, 11 months

1
0
0 0

[PATCH for-4.14-stable] ath10k: restore QCA9880-AR1A (v1) detection

by Christian Lamparter

commit f8914a14623a79b73f72b2b1ee4cd9b2cb91b735 upstream --- >From f8914a14623a79b73f72b2b1ee4cd9b2cb91b735 Mon Sep 17 00:00:00 2001 From: Christian Lamparter <chunkeey(a)gmail.com> Date: Mon, 25 Mar 2019 13:50:19 +0100 Subject: [PATCH 4.14] ath10k: restore QCA9880-AR1A (v1) detection To: linux-wireless(a)vger.kernel.org, ath10k(a)lists.infradead.org Cc: Kalle Valo <kvalo(a)codeaurora.org> This patch restores the old behavior that read the chip_id on the QCA988x before resetting the chip. This needs to be done in this order since the unsupported QCA988x AR1A chips fall off the bus when resetted. Otherwise the next MMIO Op after the reset causes a BUS ERROR and panic. Cc: stable(a)vger.kernel.org # 4.14 Fixes: 1a7fecb766c8 ("ath10k: reset chip before reading chip_id in probe") Signed-off-by: Christian Lamparter <chunkeey(a)gmail.com> --- drivers/net/wireless/ath/ath10k/pci.c | 36 +++++++++++++++++++-------- 1 file changed, 25 insertions(+), 11 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c --- a/drivers/net/wireless/ath/ath10k/pci.c 2019-09-08 00:07:21.374565470 +0200 +++ b/drivers/net/wireless/ath/ath10k/pci.c 2019-09-08 00:17:15.365912133 +0200 @@ -3202,7 +3202,7 @@ static int ath10k_pci_probe(struct pci_d struct ath10k_pci *ar_pci; enum ath10k_hw_rev hw_rev; u32 chip_id; - bool pci_ps; + bool pci_ps, is_qca988x = false; int (*pci_soft_reset)(struct ath10k *ar); int (*pci_hard_reset)(struct ath10k *ar); u32 (*targ_cpu_to_ce_addr)(struct ath10k *ar, u32 addr); @@ -3211,6 +3211,7 @@ static int ath10k_pci_probe(struct pci_d case QCA988X_2_0_DEVICE_ID: hw_rev = ATH10K_HW_QCA988X; pci_ps = false; + is_qca988x = true; pci_soft_reset = ath10k_pci_warm_reset; pci_hard_reset = ath10k_pci_qca988x_chip_reset; targ_cpu_to_ce_addr = ath10k_pci_qca988x_targ_cpu_to_ce_addr; @@ -3331,6 +3332,19 @@ static int ath10k_pci_probe(struct pci_d goto err_deinit_irq; } + /* Read CHIP_ID before reset to catch QCA9880-AR1A v1 devices that + * fall off the bus during chip_reset. These chips have the same pci + * device id as the QCA9880 BR4A or 2R4E. So that's why the check. + */ + if (is_qca988x) { + chip_id = ath10k_pci_soc_read32(ar, SOC_CHIP_ID_ADDRESS); + if (chip_id != 0xffffffff) { + if (!ath10k_pci_chip_is_supported(pdev->device, + chip_id)) + goto err_unsupported; + } + } + ret = ath10k_pci_chip_reset(ar); if (ret) { ath10k_err(ar, "failed to reset chip: %d\n", ret); @@ -3343,11 +3357,8 @@ static int ath10k_pci_probe(struct pci_d goto err_free_irq; } - if (!ath10k_pci_chip_is_supported(pdev->device, chip_id)) { - ath10k_err(ar, "device %04x with chip_id %08x isn't supported\n", - pdev->device, chip_id); - goto err_free_irq; - } + if (!ath10k_pci_chip_is_supported(pdev->device, chip_id)) + goto err_unsupported; ret = ath10k_core_register(ar, chip_id); if (ret) { @@ -3357,6 +3368,10 @@ static int ath10k_pci_probe(struct pci_d return 0; +err_unsupported: + ath10k_err(ar, "device %04x with chip_id %08x isn't supported\n", + pdev->device, bus_params.chip_id); + err_free_irq: ath10k_pci_free_irq(ar); ath10k_pci_rx_retry_sync(ar);

5 years, 11 months

1
0
0 0

io_uring stable additions

by Jens Axboe

Hi, I have a few commits that went into 5.5-rc that should go into stable. The first one is: commit 181e448d8709e517c9c7b523fcd209f24eb38ca7 Author: Jens Axboe <axboe(a)kernel.dk> Date: Mon Nov 25 08:52:30 2019 -0700 io_uring: async workers should inherit the user creds and I'm attaching a 5.4 port of this patch, since the one in 5.5 is built on top of new code. The 5.4 port will apply all the way back to 5.1 when io_uring was introduced. Secondly, these two (in order): commit 4257c8ca13b084550574b8c9a667d9c90ff746eb Author: Jens Axboe <axboe(a)kernel.dk> Date: Mon Nov 25 14:27:34 2019 -0700 net: separate out the msghdr copy from ___sys_{send,recv}msg() and commit d69e07793f891524c6bbf1e75b9ae69db4450953 Author: Jens Axboe <axboe(a)kernel.dk> Date: Mon Nov 25 17:04:13 2019 -0700 net: disallow ancillary data for __sys_{send,recv}msg_file() should be applied to 5.3/5.4 stable as well. They might look like pure networking commits, but only io_uring uses the interface. These three fix important issues, which is why we need them in stable. -- Jens Axboe

5 years, 11 months

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror