From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A561C05027 for ; Wed, 1 Feb 2023 19:52:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231660AbjBATwB (ORCPT ); Wed, 1 Feb 2023 14:52:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34440 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231644AbjBATv4 (ORCPT ); Wed, 1 Feb 2023 14:51:56 -0500 Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A00A77F69E for ; Wed, 1 Feb 2023 11:51:54 -0800 (PST) Received: by mail-ed1-x52a.google.com with SMTP id m8so9642417edd.10 for ; Wed, 01 Feb 2023 11:51:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vLOt8Htpi1Up/DCPSKgd2HVLgjbb3KJvZ9wNHdxeIi0=; b=F70AJ99pkUxssTeL0XhQsULJ+i1q3hIfT9mQJxKYXMRcGN/4hPjNKQXfjgd8TBqpBG BetUorZ/VTlYCLAfd+XP2RRKW0JVrfaxYcX4T9dpsWXY9GYLSKeTv64OlMI8Kd6WjuJ/ BWyXoO4myVBwLlBRPvXQouhFGSPXaEWcUSKkI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vLOt8Htpi1Up/DCPSKgd2HVLgjbb3KJvZ9wNHdxeIi0=; b=OdXK8LVL1r7bMm0VXUSoR870uVZfsmXMM9R1Mb9dkzxQULCZD77QHtWDX2JK+yQKq2 D5zeUjcZNFiHZz/Zv5uFz+xoB+3umVW5/px0BHZAZMf+Ykkzz4+14FxWE58dNqNYEdPC lPUX1cRmU68KIlLJM3E42ibNZoTQBUw9QscOVRv5Jh1unPq3zaAhmRRrM4MMyXlXZeA9 Dbc5DTwxLE3ud9PDhpdkqo0b81ipsEbXTLYNBwAeHpZit9TCfJlwfaI5RC5u/yBTlfWZ aOE0g02q9PW8iD6n6fLDwggei0Pnh2AUa4U6OCcS/ePXCnb+39a9vLt/o1nUfks7F98Q gbxg== X-Gm-Message-State: AO0yUKVZ+jDQ3c2lX0W0W+ZrQbi30qN78zAs6hTaJg0ANcCnIPnJUVJG nXxcrLrP0Aar8z5KxgIciNaWAXXkIWZT7sspCyk= X-Google-Smtp-Source: AK7set9PvcBm6hI5F3tY17qQTEGdZyyANNrybs29Vv0CkoKxGBaB5xgVmCJYijv9mLCzG4EwUawvsw== X-Received: by 2002:aa7:c695:0:b0:49d:be2b:b9b1 with SMTP id n21-20020aa7c695000000b0049dbe2bb9b1mr3440333edq.36.1675281112665; Wed, 01 Feb 2023 11:51:52 -0800 (PST) Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com. [209.85.218.54]) by smtp.gmail.com with ESMTPSA id p7-20020a170906b20700b0088478517830sm6879547ejz.83.2023.02.01.11.51.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Feb 2023 11:51:51 -0800 (PST) Received: by mail-ej1-f54.google.com with SMTP id m2so54233047ejb.8 for ; Wed, 01 Feb 2023 11:51:51 -0800 (PST) X-Received: by 2002:a17:906:f8d4:b0:878:51a6:ff35 with SMTP id lh20-20020a170906f8d400b0087851a6ff35mr995069ejb.43.1675281111261; Wed, 01 Feb 2023 11:51:51 -0800 (PST) MIME-Version: 1.0 References: <8f60f7d8-3e2f-2a91-c7a3-6a005d36d7d3@gmx.de> In-Reply-To: <8f60f7d8-3e2f-2a91-c7a3-6a005d36d7d3@gmx.de> From: Linus Torvalds Date: Wed, 1 Feb 2023 11:51:34 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC][PATCHSET] VM_FAULT_RETRY fixes To: Helge Deller Cc: Al Viro , Peter Xu , linux-arch@vger.kernel.org, linux-alpha@vger.kernel.org, linux-ia64@vger.kernel.org, linux-hexagon@vger.kernel.org, linux-m68k@lists.linux-m68k.org, Michal Simek , Dinh Nguyen , openrisc@lists.librecores.org, linux-parisc@vger.kernel.org, linux-riscv@lists.infradead.org, sparclinux@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On Wed, Feb 1, 2023 at 12:21 AM Helge Deller wrote: > > AFAICS, the only applications which really care about the return > code are > - testsuites like LTP (i.e. the fstat05 testcase) Those have actually shown issues with various library implementations, exactly because real system calls act very differently in this area from library wrappers. Things like the vdso implementation of gettimeofday() get a SIGSEGV if the timeval or timezone pointer is invalid, while the "real system call" version returns -1/EFAULT instead. And very similar things happen when glibc ends up wrapping system calls and converting buffers manually. At some point, glibc had a special 'struct stat' and basically converted the native system call to it, so you did 'stat()' on something, and it ended up actually using a private on-stack buffer for the system call, followed by a "convert that kernel 'struct stat' to the glibc 'struct stat'" phase. So once again, instead of -1/EFAULT, you'd first have a successful system call, and then get a SIGSEGV in glibc. And as you say, test suites would notice. But no actual normal app would ever care. Of course, there's always the abnormal apps. There _are_ the odd cases that actually catch faults and fix them up, and can then be confused by changes like that. It's very very rare, but it happens - things like emulators do tend to do some really strange things. Linus