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 4E8FAC05027 for ; Wed, 1 Feb 2023 19:51:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231302AbjBATv4 (ORCPT ); Wed, 1 Feb 2023 14:51:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34418 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231359AbjBATvz (ORCPT ); Wed, 1 Feb 2023 14:51:55 -0500 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 15B9D3C04 for ; Wed, 1 Feb 2023 11:51:54 -0800 (PST) Received: by mail-ej1-x636.google.com with SMTP id m2so54233229ejb.8 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=lTMfsuTizJ66bYwDo1wDsnNbaAo5cZg7nWhrD1XrEymFYe0wYkKYG2GcPYqUuBf1zS j/aGezQX9efGZPeKIufInMiYZJlJlo2cXjrSB93nNBU/5YPhc3uY1fFNg0FukEgg66tO IKfIdFMlMyhD+1VPlAlYJociOJaSffKlnFwGtWE+b+wlL0E2eI9tdn+26Y8RsfdiNqvG LMXTdBP7a9nIutj/VckLpwJgMCZ5yYKvwPqFD9U6M2g4ydbh+SLBZiixg22An27QWq3W vosZIDKI5MMaZLuwenSa8VOBNrchfQ050rHqZlU5OlDsfLwnfzTzIUCCS5ZukOrNJqqS gxNw== X-Gm-Message-State: AO0yUKVhh3WMoodWrQJiugzjgIdmHMkoQfNhlbsDEMiek0qlDUcKSCPL gvjMVBnKnVoNtVdxil8vwR/lJ1ju8OYuFLIE9+o= X-Google-Smtp-Source: AK7set+Ocupp6AIxh8u8M9je2Mb/TIBjp0oM0vH2TIzeAyPyaDq+bVDXRLVf5zr0Nt9ccJZxqWkITw== X-Received: by 2002:a17:907:8745:b0:882:82b3:58bc with SMTP id qo5-20020a170907874500b0088282b358bcmr4193018ejc.65.1675281112341; Wed, 01 Feb 2023 11:51:52 -0800 (PST) Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com. [209.85.218.50]) by smtp.gmail.com with ESMTPSA id m21-20020a1709062b9500b0086621d9d9b0sm10398446ejg.81.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-f50.google.com with SMTP id mf7so35972422ejc.6 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: sparclinux@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