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 X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0493C4338F for ; Sun, 25 Jul 2021 23:16:09 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 178A1608FE for ; Sun, 25 Jul 2021 23:16:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 178A1608FE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=vt.edu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.94.2) (envelope-from ) id 1m7nLV-00007Y-Qv; Sun, 25 Jul 2021 19:15:45 -0400 Received: from mail-qv1-xf2c.google.com ([2607:f8b0:4864:20::f2c]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1m7nLS-00007S-US for kernelnewbies@kernelnewbies.org; Sun, 25 Jul 2021 19:15:43 -0400 Received: by mail-qv1-xf2c.google.com with SMTP id hu11so4229069qvb.7 for ; Sun, 25 Jul 2021 16:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vt-edu.20150623.gappssmtp.com; s=20150623; h=sender:from:to:cc:subject:in-reply-to:references:mime-version :content-transfer-encoding:date:message-id; bh=kkKy2vedM/J0uBGvlb8AduuziHErqw8e7Mk29AixgTM=; b=Q4sOnm4KDfWDTgAREKjszIX7NWg7lX+E8iqtBlE1pw2oVjjqCtW29oE5liwsuL2t7I ievaDhZB06cruRyYhTXWLTOz7dy1lwFw7WhJQ4mGSdwFu2A0zwmU99GGsIELHdV1KSAi WseioDiAxgRJW9mb5BZsbrLFQHl8yJqk+uTxMmVuHVSmIHc/orAm1ZUpdcjHOy9DDsdj 4MuueXvOR9HFk66l8E7Wl7akpiyz1F5R4vc+bTqyMxbb6m0/7/opm+Pjom7xz0nu0hkj 1saTCYgh8jYYp+rEAc9ksawREWbpWH2HG3d5QJc5JZvxLp0WeAgppy0i5uo+IqpmKGNp JGPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:in-reply-to:references :mime-version:content-transfer-encoding:date:message-id; bh=kkKy2vedM/J0uBGvlb8AduuziHErqw8e7Mk29AixgTM=; b=Wd8e5zVgo5Aj8HgIYy9NMLtBdkrq/hKGNUbWMKOYYwo2074O1rVsbVqbRIFUuK+QyN XALzgAfX5AhVAjISPMFZEGM9rMYPhgJ9YXlEbTK4CLFU7CiU0284mn0GdvnLkBxQ5Zkp 8nIUCrpXGsWLi3txPBqsboThnTwnE+OLqSt+AHQItfpcyTzdkiYJKnKQuMqtHF4B2J2f ANV8PpkO07Pnw0eQi2yns60G+ZnZ1gBbnfibbHRBWdkhVfl9lz8Y/8innOBUhfDEKW6f 85M+207rMDw7qGbSHx4dsaDuM8o3oCLu+RhpVeC5D9D3y4LUoU2bvM8Mz4UFJjy80orX fI/Q== X-Gm-Message-State: AOAM532Km+Vh0RfT7O/O+ufr0TxLxRBCjpJ51gVpw2D8gx1iUMtnznGf w0Y3E2MYeNE27p6QOnWuhh6yqQ== X-Google-Smtp-Source: ABdhPJzre9UKCmJN8ouYK170RUGWtVrJAoaL3HjbzGSO4OjL8yIh0uu5M1KBjLHGa2QGHKCS2vZY4w== X-Received: by 2002:ad4:56e4:: with SMTP id cr4mr15087259qvb.54.1627254940564; Sun, 25 Jul 2021 16:15:40 -0700 (PDT) Received: from turing-police ([2601:5c0:c380:d61::359]) by smtp.gmail.com with ESMTPSA id b132sm15608539qkg.122.2021.07.25.16.15.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 25 Jul 2021 16:15:40 -0700 (PDT) From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" X-Google-Original-From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" X-Mailer: exmh version 2.10.0-pre 07/05/2021 with nmh-1.7+dev To: Ian Pilcher Subject: Re: Return value for "impossible" situations In-Reply-To: References: Mime-Version: 1.0 Date: Sun, 25 Jul 2021 19:15:39 -0400 Message-ID: <88167.1627254939@turing-police> Cc: kernelnewbies@kernelnewbies.org X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5445594312564268998==" Errors-To: kernelnewbies-bounces@kernelnewbies.org --===============5445594312564268998== Content-Type: multipart/signed; boundary="==_Exmh_1627254938_85440P"; micalg=pgp-sha256; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit --==_Exmh_1627254938_85440P Content-Type: text/plain; charset=us-ascii On Sun, 25 Jul 2021 13:07:21 -0500, Ian Pilcher said: > Is there any sort of convention around what to return in the case of an > error in the logic of the code itself, something that will make it as > obvious as possible that the problem is a bug. In general, there's no good way to signal such issues back to userspace, because there's no reserved '-EHIT_A_BUG' value. This has been true for decades, ever since Unix was still on the 18-bit PDP-7 in 1969. And it's basically useless to return such a value to userspace, because there's nothing useful that userspace can *do* in such a case. Note that pretty much all the defined error codes refer back to things that userspace could at least potentially do something useful - it may retry the operation after a delay, or tell the user that an optional facility isn't available in the currently running kernel, or try an alternate method of doing an operation (for example, trying again with IPv4 if an IPv6 connection fails, or use a different method of file locking). But if a userspace process hits an actual kernel bug, what is it supposed to do to recover? Do you add "check for -EHIT_A_BUG' to every single place you do a syscall? After all, 98% of userspace code is, *at best*, going to simply do an 'if (!erro)' test. And userspace code only does a more detailed check of *which* errno it got handed if it can do something different/useful for a specific code (such as code that goes into a retry loop if it gets -EEXIST when trying to create a lock file that shouldn't exist, and should be removed by another process when it's done). In particular, userspace has no ability to log any useful debugging information. There's the additional issue that the actual problem may not even be in that syscall's code - it could be some previous syscall from the current process that mis-set something in a structure, or some other kernel thread doing a write-after-free and corrupting memory, or code that assumed that it wouldn't be rescheduled to another CPU, or a myriad of other ways to fail. The *proper* thing to do is, instead of deciding to return -EHIT_A_BUG, do a WARN(), or BUG(), so that the dmesg has something that's at least potentially useful. Then use that information to fix the issue. --==_Exmh_1627254938_85440P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Comment: Exmh version 2.9.0 11/07/2018 iQEcBAEBCAAGBQJg/fCaAAoJEI0DS38y7CIc62MIAJ+S/wQXgcpR5weC8CAHi7rk l6HVJIZWk3XpMkyviS5GbUjHv0hSd0wlvO0nKx8ZdkY+7oQy/9QlIPQbC2hTIlsW ISFXh8rb8dNSOxRUrW46hWDo1wBZqwJI352ZtImqEJ/ghgyWP0XAqr91ELuJpflg tgOy8o0F5OTJdPfmY5zeMWTY5okYTxQT7NckVN4YmtEehmsxc/FVygCS0EI3tHtK RmVUPqFJThr8VJWetq2qUblx0/kZnpjLcvqsuf4IuFCecJzNYvyKWgYni64X9spI cWTSI6NSDKfayhlRnKGCgU/xN/c1jJCYDdmqgp4Znz+7sZECXe4bq7lWXADkzLY= =uPYQ -----END PGP SIGNATURE----- --==_Exmh_1627254938_85440P-- --===============5445594312564268998== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies --===============5445594312564268998==--