From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.openvz.org (unknown [69.168.225.77]) by lore.virtuozzo.com (Postfix) with ESMTPS id 780B48017D for ; Wed, 14 Oct 2026 17:05:18 +0000 (UTC) Received: from mail.openvz.org (localhost [127.0.0.1]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 69EH3tup001065; Wed, 14 Oct 2026 20:03:56 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 69EH3tup001065 Authentication-Results: mail.openvz.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=virtuozzo.com header.i=@virtuozzo.com header.b="YmOYF+r1" Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 69EH3rTY001053 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=FAIL) for ; Wed, 14 Oct 2026 20:03:54 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 69EH3rTY001053 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-48c4445512dso595061f8f.2 for ; Wed, 14 Oct 2026 10:03:54 -0700 (PDT) X-Gm-Message-State: AFq9FYKZFYAnYBH7E7JAEdA+H2qmxxJVE6gl8ORKGFZUhYIWT8ul3Vp+ FI9Uf9Q4hxoKZA+VFS6uYdxDabnTLmA9R6jekc5loHmrVvBuNWxVyMo92Lowm9QTUu5lfhloKm/ E74ZabwZu5kqnrKm2L6JqZgcYORVVbXZ9sNk5TfCS4KmWLVxTS1KNtg== X-Gm-Gg: AYBFou0412IyPdus+zWnV53x1VgRvmgTNj3YZPLBC8qgrADYSGurCrBN5Kf2NRyLQEA 09M/5XQ/eOJNV1JdZZGPmu0q+Od3xrAoX9k+E3hULmZbexjR2mqyxJif93Kl4c+ZJ0k+eJQBeD5 lRNSIoagynrQmvOrwauGzsAfbvKzIwiPNFg00mxrNK4wwpAcvg4E1w/Ty4gM/BQRTYFwPXjPWBL tiVMki84cpFt8Z1KWuXYfGNxkPbLIHYbqwGa55rT5xV48YWOoKLxepYtxvIubWBdpiHMI36Yd0F g3DcOKHl+5h6y0DE90OtVccVoFBYLcPo4Et22Pd53vSMX+yAx8Rlz6Wt3lVuY5EtVa18JRWarOx 9VSHgiB5oBvGnmWy8Cg== X-Received: by 2002:a05:6000:4a1b:b0:48b:a4b:5a27 with SMTP id ffacd0b85a97d-48dbaceab84mr30767988f8f.49.1791997433544; Wed, 14 Oct 2026 10:03:53 -0700 (PDT) X-Received: by 2002:a05:6000:4a1b:b0:48b:a4b:5a27 with SMTP id ffacd0b85a97d-48dbaceab84mr30767904f8f.49.1791997432766; Wed, 14 Oct 2026 10:03:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1791997432; cv=none; d=google.com; s=arc-20260327; b=FkDnJCDb/z0jJP9qyv6yuDF1nqHmMCxY7PANTdLNBaArrXUX6oOXvdJAbgxcEWkw+T 8SnYxQbU/7bI/xCgNyqKfAmcbw9ak5WvcaYfNmqNlc5+oar6H1zvZkz2wPYDHVM7OOmZ yRWV+X1NEDxYOT5K684WxgrY8+P2u5iBRATeHpRtZ39h38gW+w5GEL14NIU1mUp8fJ5p 7fvNKEIbi2nAtyK3FguvMD3PsLrdFrFclNAQBX3k7Ym14G3WMbLu5xsfTdRnBkyKklph 3HIoP56leffB+DgoT3/Ex/fIXI45GbXlqBB85bDXftBjDFdMRRQjKSnX0+jL6z3G034b Egrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:content-transfer-encoding:mime-version:message-id:date :subject:from:dkim-signature; bh=ID6f2HMzJKGYi8BY2H2uKR/wncxpj87TMs9a6Mva98w=; fh=xUcS46XhSaUOWFT7CPWNuABJ4EJ7/+S5u4N+e+rlWN4=; b=m+l/8KW9+L4FPOUvB2syd1m1dNy90046isNO6m5s1Z7rwMoaKpoUTOTvkcvV/Eb127 8/4W/Mk2qlVh+pmaV5O8QIl6/LXwWY61vZUhREw78VAPHR/+U0wceqbmpFz0KY9Num6R QwD5Vrx3SFZOD5HPFHxUmRfMzmww674arndmObaqvllpdP0iqIQ1XfAu00mJK22MR6kV ljnNK9Am841kOGLBdHQtzJyUir3n1wq1Zt29cyxBsAdZPsjyx3J0yIbae446uH4516MQ ecV0kXxpaNTsUOLtmTIG4eHez8UsbuMpv0c8mItalMoS7NNEy8PhyQo4gL+ppVaIBBud T87g==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=relay header.b=YmOYF+r1; spf=pass (google.com: domain of khorenko@virtuozzo.com designates 130.117.225.111 as permitted sender) smtp.mailfrom=khorenko@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com Received: from relay.virtuozzo.com (relay.virtuozzo.com. [130.117.225.111]) by mx.google.com with ESMTPS id ffacd0b85a97d-48de0be91ccsi13158983f8f.254.2026.10.14.10.03.52 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Oct 2026 10:03:52 -0700 (PDT) Received-SPF: pass (google.com: domain of khorenko@virtuozzo.com designates 130.117.225.111 as permitted sender) client-ip=130.117.225.111; Authentication-Results: mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=relay header.b=YmOYF+r1; spf=pass (google.com: domain of khorenko@virtuozzo.com designates 130.117.225.111 as permitted sender) smtp.mailfrom=khorenko@virtuozzo.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=virtuozzo.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=virtuozzo.com; s=relay; h=Content-Type:MIME-Version:Message-Id:Date:Subject :From; bh=ID6f2HMzJKGYi8BY2H2uKR/wncxpj87TMs9a6Mva98w=; b=YmOYF+r134U4qlTBUb8 AYs5wNBwPMsMS1vVAGaIvA0TV+rny4PyZldGpwV0WngsqlBoalvF2yReTbXqZJR+kajBIB6cZyOAG mR5/vLx+50wvfRfVonv8SWIJbxQEtk3zPHhPE5j7scd/XfCtn6tPx7B8DsZpD3tzYRFtHNv03y4MB 4rUvCjgtQnPTnEc9mGF3jVYajZ/yQSZIxhuSk89f+o0FA5khFvn2lyEikORlLkdq/x6FwbBzxrYf+ cP7VlWnNSsNtwq5xnycvhf1fTZwHzx8YK0iX8meRvrzoique37ZBXH1WfliBNZjDg1ppZW6BO15CK vv9CzYBQvDyMckw==; Received: from ch-demo-asa.virtuozzo.com ([130.117.225.8] helo=f0.sw.ru) by relay.virtuozzo.com with esmtp (Exim 4.96) (envelope-from ) id 1xH2Kx-007syU-0Q; Wed, 14 Oct 2026 19:03:51 +0200 From: Konstantin Khorenko Date: Wed, 14 Oct 2026 19:03:18 +0200 Message-Id: <20261014-b4-prep-khorenko-vstor-149847-1-upstream-fixes-v1-0-7fde9ffbebe9@virtuozzo.com> MIME-Version: 1.0 X-B4-Tracking: v=1; b=H4sIANa1z2oC/yWN3Q4BMRCFX0Xm2lRnUhavIi7aNbREu5mujRDvr svlOd/5eUMVTVJhv3iDypRqKrkJWi6gjz5fBNOpaWDLG7LkMDgcVAa8xaKSbwWnOhZFcrut65D wMdRRxd/xnJ5S0YXA7Lu1t90O2mjr/kDbPEDsE24NwfEP6iNcpR/nuzkafBUM6nMfZ6touqS8+ huokSxuDLGxyERmzYYMs3ma6dVImV7w+XwBeyFnPd4AAAA= X-Change-ID: 20261014-b4-prep-khorenko-vstor-149847-1-upstream-fixes-4bb22a75a079 To: Pavel Tikhomirov , Andrey Drobyshev , Vasileios Almpanis X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=5189; i=khorenko@virtuozzo.com; h=from:subject:message-id; bh=W/s3OHJgm5R7uhnR7xfRIa6rHwPmXWdiXWO0uzwmmMQ=; b=owEBbQKS/ZANAwAKAVGWCkf5YVwqAcsmYgBqz7X3e0LMKCgOjtrog+ZmVjjDgQqMW/ShotRbA MnmoL9cBmOJAjMEAAEKAB0WIQRWD23IPcXT0GO9CCxRlgpH+WFcKgUCas+19wAKCRBRlgpH+WFc KrHiD/9NU9KHgGoqNzThxxkm3Vd8q49rYSsNePUruxUTJTVx/T5mUks1GazDOUbwmDUaV7htabv O2z+dabuF9gTrV1kBN7qkI3p3yOtfV+wm8Xye2MSgoYGov/VRjwvyJr7KVSI4KexqkAIlMxbVVO UkjmDwpT18vFCDe8DELbr9Lkq8GPmF3iYbMouK8w7x1c6c+DmAGJ5fAyzzk7nsTw4yFV7a1MXcQ 7fFFPX62pWeC7ovjjBFONMrVDiBxGtFITZ0P+eruzljEMlpM5pCCO7MI4DarPUtvndCeYeFMOoJ sszImtmE2pdfgrav6VJQrYGJfObeiHXoJqW9jlgV/xQvFXnqchSOGPB4r3KltlLaPU5pIr91OTJ 0qArFWT70TvpaIEfLYvY1Revo3qxSU3Jcg8lobtsXie5LZFP14xQyr6oCAuiHufbgporsI+7NHi MHD75lax25bcmW0HbROlUfSwZdAo0k/YZ2uQDO7gjOwqkHOW2CE2EQuJgrsVPmlUxmVdrwce412 jKtZng0VnwArRKpDPF6BAfzkiGUMC3arELraNZYM/wLXY8vomgjc/9Jlnn6C3tR8tBkLz0r2E7M tNaIbXs1bQ8T5XOmVpvFAAt8qOuSA5DfUuRjlNuldocOpUesP+qXU6zy7A5pO9t905jrXesWQIP h+5A22/8yHkZQnQ== X-Developer-Key: i=khorenko@virtuozzo.com; a=openpgp; fpr=560F6DC83DC5D3D063BD082C51960A47F9615C2A X-OZ-Fwd: true Cc: devel@openvz.org Subject: [Devel] [PATCH hci-8.1 0/2] mm, binfmt_elf: two fixes also posted to mainline X-BeenThere: devel@openvz.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OpenVZ development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: devel-bounces@openvz.org Errors-To: devel-bounces@openvz.org Two independent fixes for bugs that mainline has as well. Both are posted to mainline; the backport notes name what differs in this tree. The MADV_DOEXEC series that follow (2 to 5) apply on top of this one, and series 4 relies on patch 1. Mainline ======== - Patch 1 is patch 1/2 of "mm/huge_memory: fix the copy of special PMDs at fork", v3: https://lore.kernel.org/r/20261014-b4-prep-vstor-149847-copy_huge_pmd-recheck-special-pmd-v3-0-85eaec8417f6@virtuozzo.com Sashiko review: https://sashiko.dev/#/patchset/20261014-b4-prep-vstor-149847-copy_huge_pmd-recheck-special-pmd-v3-0-85eaec8417f6@virtuozzo.com The Sashiko review of v1 found the ppc64 issue that patch 2/2 there fixes: https://sashiko.dev/#/patchset/20261014-b4-prep-vstor-149847-copy_huge_pmd-recheck-special-pmd-v1-1-d225c60bc316@virtuozzo.com - Patch 2 is "binfmt_elf: return the real error when program headers cannot be loaded", v1: https://lore.kernel.org/r/20261014-b4-prep-vstor-149847-binfmt_elf-enomem-load-elf-phdrs-v1-1-f39c74d55e42@virtuozzo.com Sashiko review: https://sashiko.dev/#/patchset/20261014-b4-prep-vstor-149847-binfmt_elf-enomem-load-elf-phdrs-v1-1-f39c74d55e42@virtuozzo.com Patch 1: copy_huge_pmd() recheck ================================ fork copies a special (PFN) huge PMD from a value read without the page table lock. vfio-pci zaps its BAR mappings with unmap_mapping_range(), which takes no mmap lock, when device memory is disabled or the device is reset. A fork that races with that zap leaves the child with a BAR mapping the zap removed: the child keeps reaching MMIO that vfio-pci has disabled instead of getting SIGBUS. Series 4 copies these PMDs on every live-update exec. In mainline this patch is now the first of two. The second deposits a page table for the copied PMD on ppc64 in hash mode; it is not needed here, as this tree has no huge pfnmap support on ppc64. Patch 2: the real error from load_elf_phdrs() ============================================= load_elf_phdrs() returns NULL on any failure, and load_elf_binary() turns that into a fixed error: -ENOEXEC for the executable, -ELIBBAD for its interpreter. The real cause is lost: cause really execve() returns ------------------------------------- ---------- ---------------- bad e_phentsize, e_phnum 0 or too big bad file ENOEXEC (right) file ends before the header table bad file ENOEXEC (right) kmalloc() of the table fails ENOMEM ENOEXEC (wrong) kernel_read() fails EIO/ENOMEM ENOEXEC (wrong) For the interpreter every row gives ELIBBAD. ENOEXEC says the file is not an executable, which is a property of the file, not a transient failure: - glibc's execvp() and execlp() take ENOEXEC as "not a binary" and run the ELF file with /bin/sh, which reports a binary it cannot execute instead of the ENOMEM or EIO. - search_binary_handler() tries the next binary format instead of returning the error. - For the interpreter the caller gets ELIBBAD, "Accessing a corrupted shared library", about an ld.so that is fine. When it happens here: this tree lacks the v6.17 change that lets the table grow past ELF_MIN_ALIGN, so the allocation fails in practice only under fault injection; the read fails with an I/O error, or with -ENOMEM when the page cache cannot take the pages. Where it came from: - Until commit 6a8d38945cf4 ("binfmt_elf: Hoist ELF program header loading to a function") load_elf_binary() returned -ENOMEM and the read error. That commit documented an ERR_PTR return but returned NULL; commit cfc46ca4fdca later fixed the comment, not the code. - Commit a9d9ef133f44 ("binfmt_elf: load interpreter program headers earlier") gave the interpreter's headers the same NULL check, and with it -ELIBBAD. Testing ======= On a KVM guest with the whole stack (series 1 to 5), release and debug kernels: - a fork-vs-revoke reproducer on a vfio-pci BAR (QXL in no-IOMMU mode): no stale child mapping; on mainline the same reproducer with a delay in the window shows the bug and that the patch closes it; - failslab sweep over one execve(): ENOMEM instead of ENOEXEC/ELIBBAD, execvp() no longer falls back to /bin/sh; a header table whose second page fails to read gives EIO; truncated tables and e_phoff = 2^63 still give ENOEXEC/ELIBBAD; - selftests/exec, the MADV_DOEXEC selftests, gup_test, a Container start/exec/stop. https://virtuozzo.atlassian.net/browse/VSTOR-150144 --- Konstantin Khorenko (2): mm/huge_memory: recheck a special PMD under the lock in copy_huge_pmd() binfmt_elf: return the real error when program headers cannot be loaded fs/binfmt_elf.c | 51 +++++++++++++++++++++++++++++++++------------------ mm/huge_memory.c | 23 ++++++++++++++++------- 2 files changed, 49 insertions(+), 25 deletions(-) --- base-commit: defa968cbe8c38f1ff0231042dee07f00d27b2c9 change-id: 20261014-b4-prep-khorenko-vstor-149847-1-upstream-fixes-4bb22a75a079 Best regards, -- Konstantin Khorenko _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel