From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 30AAC339872 for ; Fri, 14 Aug 2026 17:27:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786728469; cv=none; b=OWVtj0Dq+yycuDR8LgAS27wqWQYi50GFrzg1npueQmNOucPj/+0Ea8gf0giPTkJIxNSXDdmQGuAmJPDY3Y6Apx9YhPiAOQfhwDC4yColmgib7x1ghIZOUgBIG5XKacw787og8FY1/Nug+V/BMuxEYn6WI+7hkwLyZmaV2qan+tA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786728469; c=relaxed/simple; bh=+Rip0zxiBV4f6VW9V8yC+4tAp3H7GBB761i0PoOEi98=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=NjzkqBCRwvdn9guTl10AritENuuzT4WNifY4oHwu2iYv6ZQMF0OFbgz6L0gMKwA019bIlwMtop8xja/2F20Z0aTef9R7N+ZhVoTIbs8OnzU/pirKQSwJbaRpfgDDzj+mVoeRw83pfziaapL5j/hLMTlE+mpykS6gV7SOWEJjvzg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=KGjyFqK2; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=U44KCI+t; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="KGjyFqK2"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="U44KCI+t" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1786728467; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ALhGJdbaDFJ0vhwNsd55hO+rgDN52tftmXEPKqTi+XU=; b=KGjyFqK2FsUXyVbx33uyyXM542P2RHujeIDJEH6aLwUbeaI4X2rLUJzDh7gAMz1RBqvyNv UW1xQvjobleCl5Ppc+SZqISZ1uOkVhtmkJmJ1HS0l5xXf2VmAetvEP47EJfw7A1YsEV4q+ es0hHhyxPPDsAZPcCiKiRkIA7/xPEM0= Received: from mail-pj1-f72.google.com (mail-pj1-f72.google.com [209.85.216.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-325-db3Bj5bwO1WYzVg3w57nlg-1; Fri, 14 Aug 2026 13:27:45 -0400 X-MC-Unique: db3Bj5bwO1WYzVg3w57nlg-1 X-Mimecast-MFC-AGG-ID: db3Bj5bwO1WYzVg3w57nlg_1786728465 Received: by mail-pj1-f72.google.com with SMTP id 98e67ed59e1d1-38e7b87ce77so2666234a91.0 for ; Fri, 14 Aug 2026 10:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1786728465; x=1787333265; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ALhGJdbaDFJ0vhwNsd55hO+rgDN52tftmXEPKqTi+XU=; b=U44KCI+t7NQioQmORQ2yi59dGYW9Ppgbe5nbCVWAex28ZVNcnTP+VazkmebFbriiJn c3SL6Y5YTc9QxbPrRY+wQFwfPkCItn7QomyDAivs1nnxzHQ7ULp/62kC7wXkbI7J6jQb BbN8D8TWzGjNdFaZ4pMvdvVxPDxWIT4nGwDNlkjYL7e3Wfxm2LRviWEZt41aPa/Hxuxl pRNt1SFeS7TtJmG2DIBgX3IkTGLL7yzMf+flgJTL0+xvR9hDbjcMa4Ff+gBSEWp5+lFD R/omFrqVwfOVj3tsGYNiXcrG8dffHuoYwX4POSVP2MkSOfX4ggMf9VC0Fp2lq+p2EJ4f cWIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786728465; x=1787333265; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=ALhGJdbaDFJ0vhwNsd55hO+rgDN52tftmXEPKqTi+XU=; b=W4fp+I41WRusyAAeZrYF8yvJG8yoRlIGzciDgUzCJst+1kwvXLibXpT406m3cU2Nii M+9Pk3/Cy2PdOXzcvjvIXcAz6t1UfXi3Aq2QUu30OFGCNN2xl71VlhPrxwD+9AFWgH+N 8iajf22vuUyYs+L6icqqv23zyceTyrdtp4Az6fEtw0XlD8YWfeW1GLXsRgI/auqO5USR gvk7lWowl0y01BEvxrDuKHpSxaecVlskPVS6fsZ3c8oC/sRDF7ovXxpGT7HvW/YWZYvD p9Glk67YDNiHKCfpr/Bgz+kVmRcIDlyattbct+mOdK1RcEWdHBxrqERi2eWdAGbnULzv pajA== X-Forwarded-Encrypted: i=1; AHgh+Rq8+/ikv4Sqo3oVYPmDMCT7GCYmq5qa9uYzV5IECIZYpzyif+s+0venVSnlbdiGXKxNGB4pQZppQjWxKj4=@vger.kernel.org X-Gm-Message-State: AOJu0Yxj/+T0/dd/NTnGKA+fKDcXTsImj6SWTzHkG7cffhGl35ijiCo4 azDPx3z+ITLmD4RasVNe3JMP+UsbvG7CfBfUA/VXn9BBhvcJnvPkoUV//TucqkRmvpWIyygoQLU 18xrxnB7/Kkv/Pzt+wQjzm9WQvypWtlL7dGsxaangV2/de6QnpVW1lqizb3+v4UID7A== X-Gm-Gg: AR+sD11VO9zgthy/IqID/K5HYJo2TRNxvjoiCzsxSDjNHT8ult0vDB6KsTecaNa/T1+ awq66Gz7bb9xZIrilI+4f4GhOCFP0P4pubiU7Y2pexedcQw6jEXChH9QgVdICAYBYNxPJ+geyUv +xcE6YM5Nt+ieDc6i5o//+J3bb3GPrlr4ONRJhytUME6i82+WR4eDrM274hiQ5aR3qHYFIdrNf9 M4q2I+Ai9OdLlNGfqUrF2Iapns/asoay4qqEV3LOJwtiIoDCey+Bnug4oMkSUd/05fOdvvoduaW g2f2xcbz4n01HZcttD8WXihwT7PJHdp9tXEHEChqpfkPi21kXV/ek/EIyn1xqqT1GFP2QZO6Coz IpHR376UBD0BCxO+o/Q== X-Received: by 2002:a17:90b:48ce:b0:390:b41a:b92b with SMTP id 98e67ed59e1d1-3933b6d05c3mr9535909a91.4.1786728464572; Fri, 14 Aug 2026 10:27:44 -0700 (PDT) X-Received: by 2002:a17:90b:48ce:b0:390:b41a:b92b with SMTP id 98e67ed59e1d1-3933b6d05c3mr9535821a91.4.1786728463979; Fri, 14 Aug 2026 10:27:43 -0700 (PDT) Received: from [192.168.1.2] ([122.171.16.134]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-394ebbcbb78sm3512184a91.13.2026.08.14.10.27.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Aug 2026 10:27:43 -0700 (PDT) Message-ID: <9cbe111c-ff63-4f24-b518-094ddd7cea30@redhat.com> Date: Fri, 14 Aug 2026 22:57:36 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] kexec: return -ENOEXEC from image probe functions on mismatch To: Pratyush Yadav Cc: Catalin Marinas , Will Deacon , Mark Rutland , Huacai Chen , WANG Xuerui , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Andrew Morton , Baoquan He , Mike Rapoport , Pasha Tatashin , Tao Liu , Philipp Rudo , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, loongarch@lists.linux.dev, linux-riscv@lists.infradead.org, kexec@lists.infradead.org References: <20260813-mpilaniy-v1-1-777d4d0e30f7@redhat.com> <2vxzv79c23j6.fsf@kernel.org> Content-Language: en-US From: Mukesh Pilaniya In-Reply-To: <2vxzv79c23j6.fsf@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Pratyush, On 14/08/26 7:43 pm, Pratyush Yadav wrote: > On Thu, Aug 13 2026, Mukesh Pilaniya wrote: > >> Several kexec_file_load() image probe functions return -EINVAL when >> they do not recognize the image format. A probe function that rejects >> an image should return -ENOEXEC to indicate that the image is not a >> recognized executable format. -EINVAL implies a problem with the >> syscall parameters, not with image recognition. >> >> kexec_image_probe_default() iterates through registered loaders and >> returns the last probe's error code to the caller. That error >> propagates as the kexec_file_load() return value to userspace. >> Returning -EINVAL from a probe when no loader matches is semantically >> incorrect and misleads userspace about the nature of the failure. >> >> Return -ENOEXEC from all probe functions and their helpers when the >> image format is not recognized. > > Sounds fine in principle but can you please also share what the real > problem you face is and how changing these return codes helps? These > error codes are uAPI and while we _can_ change them as long as we don't > break something, there should be a clear motivation for doing so. > > [...] > While debugging a misleading error on s390x where kexec -s reported "syscall kexec_file_load not available" instead of the actual EINVAL from a kernel command line that exceeded the architecture limit, we traced the problem to the kexec-tools userspace utility treating EINVAL the same as ENOSYS and ENOEXEC -- as a signal to silently fall back to kexec_load(). kexec-tools supports two syscalls: kexec_file_load() and the older kexec_load(). With -a (the default), it tries kexec_file_load() first and falls back to kexec_load() when the syscall is not implemented (ENOSYS) or the kernel does not have a loader for the image format. With -s, it uses kexec_file_load() only with no fallback. When the kernel returns -EINVAL it means something went wrong while loading the image, not that the syscall is missing or the image format is unrecognized. kexec-tools should not fall back to the older syscall in that case. However, some kernel probe functions currently return -EINVAL when the image header does not match, instead of returning -ENOEXEC. Keeping EINVAL in the fallback set to accommodate these probes has the side effect of also hiding genuine loading errors like an oversized command line. kexec-tools should only fall back when kexec_file_load() is not implemented or does not have a matching loader -- not when something goes wrong during load. The fix on the kexec-tools side is to remove EINVAL from the fallback set, but that requires the kernel to be clean first -- probe functions must return -ENOEXEC when they do not recognize an image format, not -EINVAL. kexec-tools patch: https://lore.kernel.org/all/20260814075329.30203-1-mpilaniy@redhat.com/ A review of all kexec_file_ops.probe implementations found that arm64 image_probe(), riscv image_probe(), and loongarch efi_kexec_probe() return -EINVAL where they should return -ENOEXEC. x86 bzImage64_probe() and s390 s390_elf_probe() already use -ENOEXEC correctly.