From 51c7fc291455f6f609f3f65cf368edb219c86a3e Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sun, 9 May 2021 15:50:30 +0200 Subject: [PATCH] 4.9-stable patches added patches: jffs2-fix-kasan-slab-out-of-bounds-problem.patch nfsv4-don-t-discard-segments-marked-for-return-in-_pnfs_return_layout.patch openvswitch-fix-stack-oob-read-while-fragmenting-ipv4-packets.patch powerpc-eeh-fix-eeh-handling-for-hugepages-in-ioremap-space.patch powerpc-fix-edeadlock-redefinition-error-in-uapi-asm-errno.h.patch --- ...fix-kasan-slab-out-of-bounds-problem.patch | 138 ++++++++++++++++++ ...ed-for-return-in-_pnfs_return_layout.patch | 33 +++++ ...-read-while-fragmenting-ipv4-packets.patch | 115 +++++++++++++++ ...dling-for-hugepages-in-ioremap-space.patch | 119 +++++++++++++++ ...definition-error-in-uapi-asm-errno.h.patch | 53 +++++++ queue-4.9/series | 5 + 6 files changed, 463 insertions(+) create mode 100644 queue-4.9/jffs2-fix-kasan-slab-out-of-bounds-problem.patch create mode 100644 queue-4.9/nfsv4-don-t-discard-segments-marked-for-return-in-_pnfs_return_layout.patch create mode 100644 queue-4.9/openvswitch-fix-stack-oob-read-while-fragmenting-ipv4-packets.patch create mode 100644 queue-4.9/powerpc-eeh-fix-eeh-handling-for-hugepages-in-ioremap-space.patch create mode 100644 queue-4.9/powerpc-fix-edeadlock-redefinition-error-in-uapi-asm-errno.h.patch diff --git a/queue-4.9/jffs2-fix-kasan-slab-out-of-bounds-problem.patch b/queue-4.9/jffs2-fix-kasan-slab-out-of-bounds-problem.patch new file mode 100644 index 00000000000..8f138ce4c21 --- /dev/null +++ b/queue-4.9/jffs2-fix-kasan-slab-out-of-bounds-problem.patch @@ -0,0 +1,138 @@ +From 960b9a8a7676b9054d8b46a2c7db52a0c8766b56 Mon Sep 17 00:00:00 2001 +From: lizhe +Date: Thu, 18 Mar 2021 11:06:57 +0800 +Subject: jffs2: Fix kasan slab-out-of-bounds problem + +From: lizhe + +commit 960b9a8a7676b9054d8b46a2c7db52a0c8766b56 upstream. + +KASAN report a slab-out-of-bounds problem. The logs are listed below. +It is because in function jffs2_scan_dirent_node, we alloc "checkedlen+1" +bytes for fd->name and we check crc with length rd->nsize. If checkedlen +is less than rd->nsize, it will cause the slab-out-of-bounds problem. + +jffs2: Dirent at *** has zeroes in name. Truncating to %d char +================================================================== +BUG: KASAN: slab-out-of-bounds in crc32_le+0x1ce/0x260 at addr ffff8800842cf2d1 +Read of size 1 by task test_JFFS2/915 +============================================================================= +BUG kmalloc-64 (Tainted: G B O ): kasan: bad access detected +----------------------------------------------------------------------------- +INFO: Allocated in jffs2_alloc_full_dirent+0x2a/0x40 age=0 cpu=1 pid=915 + ___slab_alloc+0x580/0x5f0 + __slab_alloc.isra.24+0x4e/0x64 + __kmalloc+0x170/0x300 + jffs2_alloc_full_dirent+0x2a/0x40 + jffs2_scan_eraseblock+0x1ca4/0x3b64 + jffs2_scan_medium+0x285/0xfe0 + jffs2_do_mount_fs+0x5fb/0x1bbc + jffs2_do_fill_super+0x245/0x6f0 + jffs2_fill_super+0x287/0x2e0 + mount_mtd_aux.isra.0+0x9a/0x144 + mount_mtd+0x222/0x2f0 + jffs2_mount+0x41/0x60 + mount_fs+0x63/0x230 + vfs_kern_mount.part.6+0x6c/0x1f4 + do_mount+0xae8/0x1940 + SyS_mount+0x105/0x1d0 +INFO: Freed in jffs2_free_full_dirent+0x22/0x40 age=27 cpu=1 pid=915 + __slab_free+0x372/0x4e4 + kfree+0x1d4/0x20c + jffs2_free_full_dirent+0x22/0x40 + jffs2_build_remove_unlinked_inode+0x17a/0x1e4 + jffs2_do_mount_fs+0x1646/0x1bbc + jffs2_do_fill_super+0x245/0x6f0 + jffs2_fill_super+0x287/0x2e0 + mount_mtd_aux.isra.0+0x9a/0x144 + mount_mtd+0x222/0x2f0 + jffs2_mount+0x41/0x60 + mount_fs+0x63/0x230 + vfs_kern_mount.part.6+0x6c/0x1f4 + do_mount+0xae8/0x1940 + SyS_mount+0x105/0x1d0 + entry_SYSCALL_64_fastpath+0x1e/0x97 +Call Trace: + [] dump_stack+0x59/0x7e + [] print_trailer+0x125/0x1b0 + [] object_err+0x34/0x40 + [] kasan_report.part.1+0x21f/0x534 + [] ? vprintk+0x2d/0x40 + [] ? crc32_le+0x1ce/0x260 + [] kasan_report+0x26/0x30 + [] __asan_load1+0x3d/0x50 + [] crc32_le+0x1ce/0x260 + [] ? jffs2_alloc_full_dirent+0x2a/0x40 + [] jffs2_scan_eraseblock+0x1d0c/0x3b64 + [] ? jffs2_scan_medium+0xccf/0xfe0 + [] ? jffs2_scan_make_ino_cache+0x14c/0x14c + [] ? kasan_unpoison_shadow+0x35/0x50 + [] ? kasan_unpoison_shadow+0x35/0x50 + [] ? kasan_kmalloc+0x5e/0x70 + [] ? kmem_cache_alloc_trace+0x10c/0x2cc + [] ? mtd_point+0xf7/0x130 + [] jffs2_scan_medium+0x285/0xfe0 + [] ? jffs2_scan_eraseblock+0x3b64/0x3b64 + [] ? kasan_unpoison_shadow+0x35/0x50 + [] ? kasan_unpoison_shadow+0x35/0x50 + [] ? kasan_kmalloc+0x5e/0x70 + [] ? __kmalloc+0x12b/0x300 + [] ? kasan_kmalloc+0x5e/0x70 + [] ? jffs2_sum_init+0x9f/0x240 + [] jffs2_do_mount_fs+0x5fb/0x1bbc + [] ? jffs2_del_noinode_dirent+0x640/0x640 + [] ? kasan_kmalloc+0x5e/0x70 + [] ? __init_rwsem+0x97/0xac + [] jffs2_do_fill_super+0x245/0x6f0 + [] jffs2_fill_super+0x287/0x2e0 + [] ? jffs2_parse_options+0x594/0x594 + [] mount_mtd_aux.isra.0+0x9a/0x144 + [] mount_mtd+0x222/0x2f0 + [] ? jffs2_parse_options+0x594/0x594 + [] ? mount_mtd_aux.isra.0+0x144/0x144 + [] ? free_pages+0x13/0x1c + [] ? selinux_sb_copy_data+0x278/0x2e0 + [] jffs2_mount+0x41/0x60 + [] mount_fs+0x63/0x230 + [] ? alloc_vfsmnt+0x32f/0x3b0 + [] vfs_kern_mount.part.6+0x6c/0x1f4 + [] do_mount+0xae8/0x1940 + [] ? audit_filter_rules.constprop.6+0x1d10/0x1d10 + [] ? copy_mount_string+0x40/0x40 + [] ? alloc_pages_current+0xa4/0x1bc + [] ? __get_free_pages+0x25/0x50 + [] ? copy_mount_options.part.17+0x183/0x264 + [] SyS_mount+0x105/0x1d0 + [] ? copy_mnt_ns+0x560/0x560 + [] ? msa_space_switch_handler+0x13d/0x190 + [] entry_SYSCALL_64_fastpath+0x1e/0x97 + [] ? msa_space_switch+0xb0/0xe0 +Memory state around the buggy address: + ffff8800842cf180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc + ffff8800842cf200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc +>ffff8800842cf280: fc fc fc fc fc fc 00 00 00 00 01 fc fc fc fc fc + ^ + ffff8800842cf300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc + ffff8800842cf380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc +================================================================== + +Cc: stable@vger.kernel.org +Reported-by: Kunkun Xu +Signed-off-by: lizhe +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman +--- + fs/jffs2/scan.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/jffs2/scan.c ++++ b/fs/jffs2/scan.c +@@ -1075,7 +1075,7 @@ static int jffs2_scan_dirent_node(struct + memcpy(&fd->name, rd->name, checkedlen); + fd->name[checkedlen] = 0; + +- crc = crc32(0, fd->name, rd->nsize); ++ crc = crc32(0, fd->name, checkedlen); + if (crc != je32_to_cpu(rd->name_crc)) { + pr_notice("%s(): Name CRC failed on node at 0x%08x: Read 0x%08x, calculated 0x%08x\n", + __func__, ofs, je32_to_cpu(rd->name_crc), crc); diff --git a/queue-4.9/nfsv4-don-t-discard-segments-marked-for-return-in-_pnfs_return_layout.patch b/queue-4.9/nfsv4-don-t-discard-segments-marked-for-return-in-_pnfs_return_layout.patch new file mode 100644 index 00000000000..df0714af817 --- /dev/null +++ b/queue-4.9/nfsv4-don-t-discard-segments-marked-for-return-in-_pnfs_return_layout.patch @@ -0,0 +1,33 @@ +From de144ff4234f935bd2150108019b5d87a90a8a96 Mon Sep 17 00:00:00 2001 +From: Trond Myklebust +Date: Sun, 18 Apr 2021 15:00:45 -0400 +Subject: NFSv4: Don't discard segments marked for return in _pnfs_return_layout() + +From: Trond Myklebust + +commit de144ff4234f935bd2150108019b5d87a90a8a96 upstream. + +If the pNFS layout segment is marked with the NFS_LSEG_LAYOUTRETURN +flag, then the assumption is that it has some reporting requirement +to perform through a layoutreturn (e.g. flexfiles layout stats or error +information). + +Fixes: 6d597e175012 ("pnfs: only tear down lsegs that precede seqid in LAYOUTRETURN args") +Cc: stable@vger.kernel.org +Signed-off-by: Trond Myklebust +Signed-off-by: Greg Kroah-Hartman +--- + fs/nfs/pnfs.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/nfs/pnfs.c ++++ b/fs/nfs/pnfs.c +@@ -1088,7 +1088,7 @@ _pnfs_return_layout(struct inode *ino) + pnfs_get_layout_hdr(lo); + empty = list_empty(&lo->plh_segs); + pnfs_clear_layoutcommit(ino, &tmp_list); +- pnfs_mark_matching_lsegs_invalid(lo, &tmp_list, NULL, 0); ++ pnfs_mark_matching_lsegs_return(lo, &tmp_list, NULL, 0); + + if (NFS_SERVER(ino)->pnfs_curr_ld->return_range) { + struct pnfs_layout_range range = { diff --git a/queue-4.9/openvswitch-fix-stack-oob-read-while-fragmenting-ipv4-packets.patch b/queue-4.9/openvswitch-fix-stack-oob-read-while-fragmenting-ipv4-packets.patch new file mode 100644 index 00000000000..778c7b4b155 --- /dev/null +++ b/queue-4.9/openvswitch-fix-stack-oob-read-while-fragmenting-ipv4-packets.patch @@ -0,0 +1,115 @@ +From 7c0ea5930c1c211931819d83cfb157bff1539a4c Mon Sep 17 00:00:00 2001 +From: Davide Caratti +Date: Wed, 28 Apr 2021 15:23:07 +0200 +Subject: openvswitch: fix stack OOB read while fragmenting IPv4 packets + +From: Davide Caratti + +commit 7c0ea5930c1c211931819d83cfb157bff1539a4c upstream. + +running openvswitch on kernels built with KASAN, it's possible to see the +following splat while testing fragmentation of IPv4 packets: + + BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60 + Read of size 1 at addr ffff888112fc713c by task handler2/1367 + + CPU: 0 PID: 1367 Comm: handler2 Not tainted 5.12.0-rc6+ #418 + Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014 + Call Trace: + dump_stack+0x92/0xc1 + print_address_description.constprop.7+0x1a/0x150 + kasan_report.cold.13+0x7f/0x111 + ip_do_fragment+0x1b03/0x1f60 + ovs_fragment+0x5bf/0x840 [openvswitch] + do_execute_actions+0x1bd5/0x2400 [openvswitch] + ovs_execute_actions+0xc8/0x3d0 [openvswitch] + ovs_packet_cmd_execute+0xa39/0x1150 [openvswitch] + genl_family_rcv_msg_doit.isra.15+0x227/0x2d0 + genl_rcv_msg+0x287/0x490 + netlink_rcv_skb+0x120/0x380 + genl_rcv+0x24/0x40 + netlink_unicast+0x439/0x630 + netlink_sendmsg+0x719/0xbf0 + sock_sendmsg+0xe2/0x110 + ____sys_sendmsg+0x5ba/0x890 + ___sys_sendmsg+0xe9/0x160 + __sys_sendmsg+0xd3/0x170 + do_syscall_64+0x33/0x40 + entry_SYSCALL_64_after_hwframe+0x44/0xae + RIP: 0033:0x7f957079db07 + Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 eb ec ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 24 ed ff ff 48 + RSP: 002b:00007f956ce35a50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e + RAX: ffffffffffffffda RBX: 0000000000000019 RCX: 00007f957079db07 + RDX: 0000000000000000 RSI: 00007f956ce35ae0 RDI: 0000000000000019 + RBP: 00007f956ce35ae0 R08: 0000000000000000 R09: 00007f9558006730 + R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 + R13: 00007f956ce37308 R14: 00007f956ce35f80 R15: 00007f956ce35ae0 + + The buggy address belongs to the page: + page:00000000af2a1d93 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x112fc7 + flags: 0x17ffffc0000000() + raw: 0017ffffc0000000 0000000000000000 dead000000000122 0000000000000000 + raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 + page dumped because: kasan: bad access detected + + addr ffff888112fc713c is located in stack of task handler2/1367 at offset 180 in frame: + ovs_fragment+0x0/0x840 [openvswitch] + + this frame has 2 objects: + [32, 144) 'ovs_dst' + [192, 424) 'ovs_rt' + + Memory state around the buggy address: + ffff888112fc7000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + ffff888112fc7080: 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00 + >ffff888112fc7100: 00 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 + ^ + ffff888112fc7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + ffff888112fc7200: 00 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00 + +for IPv4 packets, ovs_fragment() uses a temporary struct dst_entry. Then, +in the following call graph: + + ip_do_fragment() + ip_skb_dst_mtu() + ip_dst_mtu_maybe_forward() + ip_mtu_locked() + +the pointer to struct dst_entry is used as pointer to struct rtable: this +turns the access to struct members like rt_mtu_locked into an OOB read in +the stack. Fix this changing the temporary variable used for IPv4 packets +in ovs_fragment(), similarly to what is done for IPv6 few lines below. + +Fixes: d52e5a7e7ca4 ("ipv4: lock mtu in fnhe when received PMTU < net.ipv4.route.min_pmt") +Cc: +Acked-by: Eelco Chaudron +Signed-off-by: Davide Caratti +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/openvswitch/actions.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/net/openvswitch/actions.c ++++ b/net/openvswitch/actions.c +@@ -710,16 +710,16 @@ static void ovs_fragment(struct net *net + } + + if (ethertype == htons(ETH_P_IP)) { +- struct dst_entry ovs_dst; ++ struct rtable ovs_rt = { 0 }; + unsigned long orig_dst; + + prepare_frag(vport, skb); +- dst_init(&ovs_dst, &ovs_dst_ops, NULL, 1, ++ dst_init(&ovs_rt.dst, &ovs_dst_ops, NULL, 1, + DST_OBSOLETE_NONE, DST_NOCOUNT); +- ovs_dst.dev = vport->dev; ++ ovs_rt.dst.dev = vport->dev; + + orig_dst = skb->_skb_refdst; +- skb_dst_set_noref(skb, &ovs_dst); ++ skb_dst_set_noref(skb, &ovs_rt.dst); + IPCB(skb)->frag_max_size = mru; + + ip_do_fragment(net, skb->sk, skb, ovs_vport_output); diff --git a/queue-4.9/powerpc-eeh-fix-eeh-handling-for-hugepages-in-ioremap-space.patch b/queue-4.9/powerpc-eeh-fix-eeh-handling-for-hugepages-in-ioremap-space.patch new file mode 100644 index 00000000000..e40b4f80edb --- /dev/null +++ b/queue-4.9/powerpc-eeh-fix-eeh-handling-for-hugepages-in-ioremap-space.patch @@ -0,0 +1,119 @@ +From 5ae5bc12d0728db60a0aa9b62160ffc038875f1a Mon Sep 17 00:00:00 2001 +From: Mahesh Salgaonkar +Date: Mon, 12 Apr 2021 13:22:50 +0530 +Subject: powerpc/eeh: Fix EEH handling for hugepages in ioremap space. + +From: Mahesh Salgaonkar + +commit 5ae5bc12d0728db60a0aa9b62160ffc038875f1a upstream. + +During the EEH MMIO error checking, the current implementation fails to map +the (virtual) MMIO address back to the pci device on radix with hugepage +mappings for I/O. This results into failure to dispatch EEH event with no +recovery even when EEH capability has been enabled on the device. + +eeh_check_failure(token) # token = virtual MMIO address + addr = eeh_token_to_phys(token); + edev = eeh_addr_cache_get_dev(addr); + if (!edev) + return 0; + eeh_dev_check_failure(edev); <= Dispatch the EEH event + +In case of hugepage mappings, eeh_token_to_phys() has a bug in virt -> phys +translation that results in wrong physical address, which is then passed to +eeh_addr_cache_get_dev() to match it against cached pci I/O address ranges +to get to a PCI device. Hence, it fails to find a match and the EEH event +never gets dispatched leaving the device in failed state. + +The commit 33439620680be ("powerpc/eeh: Handle hugepages in ioremap space") +introduced following logic to translate virt to phys for hugepage mappings: + +eeh_token_to_phys(): ++ pa = pte_pfn(*ptep); ++ ++ /* On radix we can do hugepage mappings for io, so handle that */ ++ if (hugepage_shift) { ++ pa <<= hugepage_shift; <= This is wrong ++ pa |= token & ((1ul << hugepage_shift) - 1); ++ } + +This patch fixes the virt -> phys translation in eeh_token_to_phys() +function. + + $ cat /sys/kernel/debug/powerpc/eeh_address_cache + mem addr range [0x0000040080000000-0x00000400807fffff]: 0030:01:00.1 + mem addr range [0x0000040080800000-0x0000040080ffffff]: 0030:01:00.1 + mem addr range [0x0000040081000000-0x00000400817fffff]: 0030:01:00.0 + mem addr range [0x0000040081800000-0x0000040081ffffff]: 0030:01:00.0 + mem addr range [0x0000040082000000-0x000004008207ffff]: 0030:01:00.1 + mem addr range [0x0000040082080000-0x00000400820fffff]: 0030:01:00.0 + mem addr range [0x0000040082100000-0x000004008210ffff]: 0030:01:00.1 + mem addr range [0x0000040082110000-0x000004008211ffff]: 0030:01:00.0 + +Above is the list of cached io address ranges of pci 0030:01:00.. + +Before this patch: + +Tracing 'arg1' of function eeh_addr_cache_get_dev() during error injection +clearly shows that 'addr=' contains wrong physical address: + + kworker/u16:0-7 [001] .... 108.883775: eeh_addr_cache_get_dev: + (eeh_addr_cache_get_dev+0xc/0xf0) addr=0x80103000a510 + +dmesg shows no EEH recovery messages: + + [ 108.563768] bnx2x: [bnx2x_timer:5801(eth2)]MFW seems hanged: drv_pulse (0x9ae) != mcp_pulse (0x7fff) + [ 108.563788] bnx2x: [bnx2x_hw_stats_update:870(eth2)]NIG timer max (4294967295) + [ 108.883788] bnx2x: [bnx2x_acquire_hw_lock:2013(eth1)]lock_status 0xffffffff resource_bit 0x1 + [ 108.884407] bnx2x 0030:01:00.0 eth1: MDC/MDIO access timeout + [ 108.884976] bnx2x 0030:01:00.0 eth1: MDC/MDIO access timeout + <..> + +After this patch: + +eeh_addr_cache_get_dev() trace shows correct physical address: + + -0 [001] ..s. 1043.123828: eeh_addr_cache_get_dev: + (eeh_addr_cache_get_dev+0xc/0xf0) addr=0x40080bc7cd8 + +dmesg logs shows EEH recovery getting triggerred: + + [ 964.323980] bnx2x: [bnx2x_timer:5801(eth2)]MFW seems hanged: drv_pulse (0x746f) != mcp_pulse (0x7fff) + [ 964.323991] EEH: Recovering PHB#30-PE#10000 + [ 964.324002] EEH: PE location: N/A, PHB location: N/A + [ 964.324006] EEH: Frozen PHB#30-PE#10000 detected + <..> + +Fixes: 33439620680b ("powerpc/eeh: Handle hugepages in ioremap space") +Cc: stable@vger.kernel.org # v5.3+ +Reported-by: Dominic DeMarco +Signed-off-by: Mahesh Salgaonkar +Signed-off-by: Aneesh Kumar K.V +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/161821396263.48361.2796709239866588652.stgit@jupiter +Signed-off-by: Greg Kroah-Hartman +--- + arch/powerpc/kernel/eeh.c | 11 ++++------- + 1 file changed, 4 insertions(+), 7 deletions(-) + +--- a/arch/powerpc/kernel/eeh.c ++++ b/arch/powerpc/kernel/eeh.c +@@ -366,14 +366,11 @@ static inline unsigned long eeh_token_to + pa = pte_pfn(*ptep); + + /* On radix we can do hugepage mappings for io, so handle that */ +- if (hugepage_shift) { +- pa <<= hugepage_shift; +- pa |= token & ((1ul << hugepage_shift) - 1); +- } else { +- pa <<= PAGE_SHIFT; +- pa |= token & (PAGE_SIZE - 1); +- } ++ if (!hugepage_shift) ++ hugepage_shift = PAGE_SHIFT; + ++ pa <<= PAGE_SHIFT; ++ pa |= token & ((1ul << hugepage_shift) - 1); + return pa; + } + diff --git a/queue-4.9/powerpc-fix-edeadlock-redefinition-error-in-uapi-asm-errno.h.patch b/queue-4.9/powerpc-fix-edeadlock-redefinition-error-in-uapi-asm-errno.h.patch new file mode 100644 index 00000000000..bd64733541e --- /dev/null +++ b/queue-4.9/powerpc-fix-edeadlock-redefinition-error-in-uapi-asm-errno.h.patch @@ -0,0 +1,53 @@ +From 7de21e679e6a789f3729e8402bc440b623a28eae Mon Sep 17 00:00:00 2001 +From: Tony Ambardar +Date: Thu, 17 Sep 2020 06:54:37 -0700 +Subject: powerpc: fix EDEADLOCK redefinition error in uapi/asm/errno.h + +From: Tony Ambardar + +commit 7de21e679e6a789f3729e8402bc440b623a28eae upstream. + +A few archs like powerpc have different errno.h values for macros +EDEADLOCK and EDEADLK. In code including both libc and linux versions of +errno.h, this can result in multiple definitions of EDEADLOCK in the +include chain. Definitions to the same value (e.g. seen with mips) do +not raise warnings, but on powerpc there are redefinitions changing the +value, which raise warnings and errors (if using "-Werror"). + +Guard against these redefinitions to avoid build errors like the following, +first seen cross-compiling libbpf v5.8.9 for powerpc using GCC 8.4.0 with +musl 1.1.24: + + In file included from ../../arch/powerpc/include/uapi/asm/errno.h:5, + from ../../include/linux/err.h:8, + from libbpf.c:29: + ../../include/uapi/asm-generic/errno.h:40: error: "EDEADLOCK" redefined [-Werror] + #define EDEADLOCK EDEADLK + + In file included from toolchain-powerpc_8540_gcc-8.4.0_musl/include/errno.h:10, + from libbpf.c:26: + toolchain-powerpc_8540_gcc-8.4.0_musl/include/bits/errno.h:58: note: this is the location of the previous definition + #define EDEADLOCK 58 + + cc1: all warnings being treated as errors + +Cc: Stable +Reported-by: Rosen Penev +Signed-off-by: Tony Ambardar +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20200917135437.1238787-1-Tony.Ambardar@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/powerpc/include/uapi/asm/errno.h | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/powerpc/include/uapi/asm/errno.h ++++ b/arch/powerpc/include/uapi/asm/errno.h +@@ -1,6 +1,7 @@ + #ifndef _ASM_POWERPC_ERRNO_H + #define _ASM_POWERPC_ERRNO_H + ++#undef EDEADLOCK + #include + + #undef EDEADLOCK diff --git a/queue-4.9/series b/queue-4.9/series index 8391a8c40ae..d0461bc4942 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -48,3 +48,8 @@ scsi-libfc-fix-a-format-specifier.patch alsa-emu8000-fix-a-use-after-free-in-snd_emu8000_create_mixer.patch alsa-sb-fix-two-use-after-free-in-snd_sb_qsound_build.patch arm64-vdso-discard-.note.gnu.property-sections-in-vd.patch +openvswitch-fix-stack-oob-read-while-fragmenting-ipv4-packets.patch +nfsv4-don-t-discard-segments-marked-for-return-in-_pnfs_return_layout.patch +jffs2-fix-kasan-slab-out-of-bounds-problem.patch +powerpc-eeh-fix-eeh-handling-for-hugepages-in-ioremap-space.patch +powerpc-fix-edeadlock-redefinition-error-in-uapi-asm-errno.h.patch -- 2.47.3