From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.openvz.org (mail.openvz.org [69.168.225.77]) by lore.virtuozzo.com (Postfix) with ESMTPS id A6CDC812AD for ; Wed, 4 Nov 2026 18:07:07 +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 6A4I5l2K025783; Wed, 4 Nov 2026 21:05:48 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 6A4I5l2K025783 Authentication-Results: mail.openvz.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=virtuozzo.com header.i=@virtuozzo.com header.b="GMok1nv3" Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by mail.openvz.org (8.14.4/8.14.4) with ESMTP id 6A4I5kH7025771 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=FAIL) for ; Wed, 4 Nov 2026 21:05:46 +0300 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.openvz.org 6A4I5kH7025771 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-48afcecb035so272815f8f.0 for ; Wed, 04 Nov 2026 10:05:46 -0800 (PST) X-Forwarded-Encrypted: i=2; AKwUvBxI+SiTzVOXqqzjG5IhKXyrf6wezwx5zurMI9+kJKMXVP8dt28YgbcwPUrn+86P6kT6o4qEMg==@openvz.org X-Gm-Message-State: APuU4Z9/NDaNwlmoi6Uu4GspGMY4GKxJkwP5ZMHU+cpWhx/FtEb9xJxV kP9IUBXGe3BCSdmsxUvZWeYWFAn4F6ZVVXNb1QP6hOmn/WhBS86lavvHAFVynPhAzjVCYTmrm/l qHFw2Oe1qkeihix2LN90S/o97liE3HX2d6E6qY7m71f/if9j9a/FGAQ== X-Gm-Gg: AYBFou0PH6tM8ZfHndNthx3lR3cB4Zk1npKK4iuutYNObQPQdOg005GUwDoE10Qq8Dj cY7EzwxDSkZjhBuoCl/ydNvTc8VQh9Giw45ErMrpbBiOB4GQepKnovXR8XheO1DN9wF3NT4HpC/ y3lC+yq1EYBhLg9hqmsZUNcsMatp9ukGsrTgSH7hleNN9AjUV7gEi26ETxqbU7ITCQMpR42BCHq n58xwS68yoq4vq/ok4JtFnqVMJ3mbEEm//ucl7FHQ9ah0EoAFGVNqNhdue4guhbVPAZWyHSduuJ QvjUz1kXHcR5biu53VfsE84Q+reyEE0YcQVeFAAThEYO9noyR2rDww/OrMqRu0+RTrrGkOajbqA 0+3d6w+ZBU9LPnJ1ikw== X-Received: by 2002:a05:6000:4a1c:b0:490:1395:9b00 with SMTP id ffacd0b85a97d-4911906d26fmr355379f8f.10.1793815546376; Wed, 04 Nov 2026 10:05:46 -0800 (PST) X-Received: by 2002:a05:6000:4a1c:b0:490:1395:9b00 with SMTP id ffacd0b85a97d-4911906d26fmr355337f8f.10.1793815545853; Wed, 04 Nov 2026 10:05:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1793815545; cv=none; d=google.com; s=arc-20260327; b=CVuuNYvCSMSkPIszfNzJCQxUepZUBR1+J0gVUPQW5HgSQTk+PQIQhnWpWEc6dwRYnr WBrdZOXIgdVH3P68DLy7JzQNJahWhRLfiVj340AmOJ407C42kqdE3YxL8dvBc7QRjQEX 5s6uclU/IV4aN4M9yDmLSqQVx9kT0lH1L+VkRtdW4yorYlBs4K41F0t0f7c+ikH3vPYA jZe3x0VkY9oKfENyzlgNUzZ6L5fmuyxPmWtOoTGplCR8q/sOkF2cD2hzxjmVcqFsamZF PxsGPTJ80kwC8vwYU/sN5C7MjEvu1vgYWWoMpiiH8Tv0hukbmjhQ15Vo3x2veBYvnsr1 yTyg== 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=CkZp60QvxNaqkh600aVoBIhcTudMrPP2baa9R2Bzxj4=; fh=abIpJkmHIgqMVCNUyuYIDt/6GCMqAdsBq4YKsDJk+cQ=; b=WZFy2rLtGdgslySf5bM+zcBED0E2Zwj4sNflsvfSzbzOQtTsHdiSZFz0RsHpgbkjjL C+GvzR8OKXBxSmD9Bh9DvqgB3QegniK8Ro2CKnyQdkijJlLte1rJIw8k3ssucbDokNDR lQLTnvoF9gi/WcDt1g95d8GSZkwVJtUubXDqFIhUOFrYlLVQdd4qluxbFEar3NAQif54 uKxm4uVnrY5k0tqjuoJoomOvG4byokiRd6/b5vSbV8FyErG6zHeXrmNw544VBeVfBkcu A7IGYx3UiT7Pc6XEBSSGvBi9/sV+QYqMtNNQVxbDEFonpANffQjbpbtmYdpongtmThn9 Wi/w==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@virtuozzo.com header.s=relay header.b=GMok1nv3; 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-48ff006b256si5355416f8f.408.2026.11.04.10.05.45 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Nov 2026 10:05:45 -0800 (PST) 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=GMok1nv3; 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=CkZp60QvxNaqkh600aVoBIhcTudMrPP2baa9R2Bzxj4=; b=GMok1nv3DH1k2Xqxywz QYpvD699BzzHfv+CyY4rJz1nnTBBIPXgTRHdk9vpLFFzP+3rkrLPT+bAmCvqNJtjWNFMcrUbz84u5 Wlbbw9hMQqu6AIGHOdS9wVgid7YYCAE0NHMTFV38hPCHNZaUt9i6aKeC5hDqYknbAUoChu+vRYZp4 GtT5orsaGpq8kDpfb5DF1aKStQUV5NCsKQKOAE2ST/1XbxwQn5Jb3Ye5aXOWJUSV/Tciy3Ehf2mN5 ZNyjka0XFlzi81eL0ifLJscwdcHZAh1i/utvRx3Kg96gEqT5BEG1o7unOZP5+BpCmsklexFVID0w8 wnNd5XPsTY6BmSQ==; 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 1xOfIq-00G4X6-11; Wed, 04 Nov 2026 19:05:44 +0100 From: Konstantin Khorenko Date: Wed, 04 Nov 2026 19:05:39 +0100 Message-Id: <20261104-b4-prep-khorenko-vstor-149847-1-upstream-fixes-v2-0-2974ec52f0fe@virtuozzo.com> MIME-Version: 1.0 X-B4-Tracking: v=1; b=H4sIAPNz62oC/51Py5LCIBD8FYvzDstQaIyn/Y8tD4ATYS0hBQmls fLvQvyDPXb3TD9eLFPylNlp92KJis8+hgrk145Zp8OVwF8qZlLIAwpUYBSMiUa4uZgo3CKUPMU EqPqj6gBhHvOUSN9h8A/KoIyRUnd7LbqeVdP6uwnV85c56+HIkZ0/Qp7NH9mpxbVTozOBSTpY1 6iY/NWH7w8ByaGAA0fJBUhEvpccuZT8wctSlViWZuF8K/fc1hXcMv87pCAI6IYL9cNgyFD/U3y a5rgskdt4Z+d1Xd8bONMRTgEAAA== X-Change-ID: 20261014-b4-prep-khorenko-vstor-149847-1-upstream-fixes-4bb22a75a079 To: Pavel Tikhomirov , Vasileios Almpanis X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=6093; i=khorenko@virtuozzo.com; h=from:subject:message-id; bh=MQHcQbf9GuzV8zV9ErBd/TPwWSA/9qJ7SaftYqWTp2c=; b=owEBbQKS/ZANAwAKAVGWCkf5YVwqAcsmYgBq63P4AbYZyNpmhgiPbArIjt94mNbxdtJBu738t WfnL/hw1pOJAjMEAAEKAB0WIQRWD23IPcXT0GO9CCxRlgpH+WFcKgUCautz+AAKCRBRlgpH+WFc KhfqD/9M+hahhr88TVjph50So1lLKc2jlFEoZpZ+fE5WyDPQWviY0Og8nl89BrJTCWfUpFEkcwc J4viPGdGI6++4U08Ezw4yDSl6x1KRBx4H7tjND+816M41tzYJNcj3vIAhQC1Mt2WlzSV0yMxFhf z2+Amom8Zs1FMZhXT/MOvVFugOJKnceskkCKPprILSdnDtoD0irE62lFAPQe7nfBfI6KSs6DjhL Sg0VQFo/RI9IsezyvKMGzNXlvZsraZ9dEyPuaXhEmOa9gvO7xp6ZO4dZZAnFtjbeVUtNekcEmw0 Y/XeXwgtVX1rBB++5X26kALrFVHBYAVwsb+V4e7P7TBi4w+/xTnosYlaz8XqDEeFzyE33LH5BEc DoYnpFxQ8EuG9NcTUbjzEmWEJxW7DvKFWVhci0rDR3sh3ReAbpvembzApNajmPjLAqSXylJDfZH u0wTLuwou0j14SG0pEFSDMC2HZCU+H97lS2+LVlHGvwEDysISHqAO3ZWhYSPj/WZdO2XUei583W H0lb0k1fx2yQ4duFb6UCy4Jj2N65P5bA9m+QR2dfmGlZiIz/z402ygVAB6lfyqrKlsyHmsapo8H YkbiqhTNSAYv4cQPfrdbBwvhfa+iObDmB3MCdOVO1VApYqlFmKHeLtYF8sssYjifBUzKC6IZimR c82DbwG0nyTHUqg== 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 v2 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 apply on top of this one, in this order: - mm: keep DMA-pinned MADV_DOEXEC memory working across exec - mm, exec: fix the MADV_DOEXEC code we carry from Oracle - mm: allow MADV_DOEXEC on VFIO BAR mappings, which relies on patch 1 - selftests/mm: broader MADV_DOEXEC coverage 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 Kees Cook asked for a patch that changes the errno and nothing else: https://lore.kernel.org/r/202610142140.D483AE26DF@keescook This version does that; the mainline v2 is not posted yet. 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. The series "mm: allow MADV_DOEXEC on VFIO BAR mappings" 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 this series and the four MADV_DOEXEC series on top of it, 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; 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 Assisted-by: LLM --- Changes in v2: - Patch 2: change the errno only, as asked in mainline review. A short read is no longer read on to get the error behind it: it gives ENOEXEC/ELIBBAD, as before the patch. The table is read with kernel_read() directly, as elf_read() turns a short read into EIO. - Assisted-by moved from the patches to the cover letter. - Link to v1: http://lore.virtuozzo.com/20261014-b4-prep-khorenko-vstor-149847-1-upstream-fixes-v1-0-7fde9ffbebe9@virtuozzo.com --- 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 | 39 ++++++++++++++++++++++++--------------- mm/huge_memory.c | 23 ++++++++++++++++------- 2 files changed, 40 insertions(+), 22 deletions(-) --- base-commit: defa968cbe8c38f1ff0231042dee07f00d27b2c9 change-id: 20261014-b4-prep-khorenko-vstor-149847-1-upstream-fixes-4bb22a75a079 Best regards, -- Konstantin Khorenko, Virtuozzo Linux Kernel Team _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel