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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 91FD2CA9EA9 for ; Fri, 18 Oct 2019 21:53:47 +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 4E9EB20700 for ; Fri, 18 Oct 2019 21:53:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4E9EB20700 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=vt.edu Authentication-Results: mail.kernel.org; spf=fail smtp.mailfrom=kernelnewbies-bounces@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.92.3) (envelope-from ) id 1iLaBZ-0006gp-Ij; Fri, 18 Oct 2019 17:53:25 -0400 Received: from omr2.cc.ipv6.vt.edu ([2607:b400:92:8400:0:33:fb76:806e] helo=omr2.cc.vt.edu) by shelob.surriel.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1iLaBW-0006gj-Ec for kernelnewbies@kernelnewbies.org; Fri, 18 Oct 2019 17:53:22 -0400 Received: from mr4.cc.vt.edu (mr4.cc.vt.edu [IPv6:2607:b400:92:8300:0:7b:e2b1:6a29]) by omr2.cc.vt.edu (8.14.4/8.14.4) with ESMTP id x9ILrLRV017069 for ; Fri, 18 Oct 2019 17:53:21 -0400 Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by mr4.cc.vt.edu (8.14.7/8.14.7) with ESMTP id x9ILrGXQ027005 for ; Fri, 18 Oct 2019 17:53:21 -0400 Received: by mail-qk1-f197.google.com with SMTP id g65so6886016qkf.19 for ; Fri, 18 Oct 2019 14:53:21 -0700 (PDT) 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=C0GQXRRh4hRqADSqSWBhYwOqfZu047kTzP3UvOVeOa8=; b=jdSdEr4yk8q4Jws41o9c3Do9hrGQTyRzF2Ia3YoKAmQYvX4UdMx3bBSBbdSAZ0xkcz RWhDF7oFcmnc1MyHRSQaQwVdWYQI63/4U3qBaP9o3ol2HlQpKLk9ccbJrARTypZBYEyf fa+vfqNBD3ia8F6tLWUzJgMI2nQFJShSy7bXxcoHLzDfxjwL1/5kz3aT+MXXezmgguKd yvwW/QnrjkEUGWWclSedcDO3GyJzl/VPt1/2NK/rlp1cl6rvFxuHFnUCBs1XsuQXd8np Z0hdA0JA4B4zsO7yKLKO5ryA8k/fbo0GTqv1FfoubwpLSdSY5Vi60F/FGA9GQ7nfe1/e +ROw== X-Gm-Message-State: APjAAAVGm+XLRB+TG49huE/HGTQHHL99h8YqOihGx/EGsui2hmV6rSMH jVpebTOAYcxfXrMDjQvb9JeNQffr06mk/OC9x0VyT8WmiMjuHTcBVMh0xFTcR1QeYNGwfRMY+wk WpxuLCFz90UnHVxjcVS7ZHLk1u2QNkGu6mVdYysc= X-Received: by 2002:a05:6214:1234:: with SMTP id p20mr12202911qvv.204.1571435595664; Fri, 18 Oct 2019 14:53:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqx82qQ3QyL5JsKHFU/fEuvscCEeDzk92zW8RoZ0CngU68tSkSapVVvrevTdKLocnyMGqJhjgA== X-Received: by 2002:a05:6214:1234:: with SMTP id p20mr12202890qvv.204.1571435595235; Fri, 18 Oct 2019 14:53:15 -0700 (PDT) Received: from turing-police ([2601:5c0:c001:4341::9ca]) by smtp.gmail.com with ESMTPSA id j4sm3483742qkf.116.2019.10.18.14.53.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Oct 2019 14:53:13 -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.9.0 11/07/2018 with nmh-1.7+dev To: Martin Galvan Subject: Re: Try/catch for modules? In-Reply-To: References: <29246.1571350377@turing-police> <24fe8b41-2bc0-181e-7252-9e787949ab68@petrovitsch.priv.at> Mime-Version: 1.0 Date: Fri, 18 Oct 2019 17:53:12 -0400 Message-ID: <123581.1571435592@turing-police> Cc: Bernd Petrovitsch , 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="===============8844779532020099064==" Errors-To: kernelnewbies-bounces@kernelnewbies.org --===============8844779532020099064== Content-Type: multipart/signed; boundary="==_Exmh_1571435592_13653P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit --==_Exmh_1571435592_13653P Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, 18 Oct 2019 13:11:54 -0300, Martin Galvan said: > I don't think I was clear. My intent is that if a pointer bug isn't > fixed, my module will fail gracefully and go through the catch block > instead of panicking the whole system.=20 Well..here's the thing. Unless you have =22panic_on_oops=22 set, hitting= a null pointer will usually *NOT* panic the whole system. In fact, that =230000 = in the panic message is a counter of how many times the kernel has OOPs'ed alrea= dy. Way back in the dark mists of time, I had a system that managed to get it= up to =231500 or so overnight. The problem is that at that point, a generic =22fail gracefully=22 isn't= really an option. The most graceful generic thing the kernel can do at that point is kill t= he execution thread that hit the error. This can quickly go sideways if that thread h= eld a lock or similar critical resource. And no, even though the kernel knows all t= he locks the thread had, it *does not* know which ones, if any, are safe to unlock= . The answer is probably =22none of them=22, because locks are usually around t= he smallest amount of code possible, so if the lock was held, it's probably unsafe to= break it. The few places in the kernel that do lock-breaking are basically all things l= ike the printk/sysrq code that is basically a =22we're dead anyhow, try to get some logging in= fo=22. I've seen systems that manage to get the load average up to 17,000 or so,= because process after process got into 'D' state because they tried to do filesys= tem I/O to a filesystem that had a lock wedged when a process oopsed. (A good reason= for production systems to have lots of filesystems - if a kernel bug causes t= he /apps/database/logs filesystem to hang, you can probably reboot and recover because /apps/dat= abase/replay is synced to disk, and you have lots of stuff in /var that's got forensic= info in it. Use one big filesystem, and when it locks up, you're immediately dead in the wate= r. Might not even be able to ssh in, because that hangs because it writes to /var whic= h is wedged along with everything else....) And if you actually *think* about it - a 'try/catch' is semantically *ide= ntical* to coding a parameter test before the event or checking a return code after.= (A good place to interject Tom Duff's First Law of Systems Programming - = =22Never test for an error condition you don't know how to handle=22. Note in this con= text, =22kill the thread and pray=22 means you *do* know how to handle it - by killing the thread.= ..) Also - say you have a try/catch around a statement. For some exceptions,= such as an end-of-file or a dropped network connection, it's reasonably easy t= o know how to clean up and continue. But what if the statement hits a null point= er error. What do you do to clean things up? You have a bad pointer, and= you have *no way to actually fix it and continue normally*. And don't get me started on try/catch/throw - that's got even *more* land= mines. :) --==_Exmh_1571435592_13653P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Comment: Exmh version 2.9.0 11/07/2018 iQIVAwUBXao0SAdmEQWDXROgAQK0FA//cQpnt4b9rcHYegr1QiVbkh+ZSxkI95od /zlFQum5Y0xEjLWmj74Pm4iQpDxjGwJRfIiUzOOBLi9LwPNDt04Jm3Ub6zM2mnyn 1chrLALH7pW2IqJNUrYCC9w1cIjto7w8gsGDKz03LaKOmh0k0pY0ECyggZp+tFH7 Opxe5DlAINRRF9bYm26WyYdILHEzSvKy+5tKufnMmPMneqk8HK+oUEJ64LASD0j6 tyrTg2B6ZUI4yLFw4V4QWnbgU1DEH9BxZJcPWlFMw7c/8n3nD/hxKgBgVsjJJjfz Y/38G7Bxtkr88WLvHz/7wGfNRfMB5bbZ/zXMKdD5d2oojLoVUT4MxFv7pJyGpIQ9 XCXodPxO06HRspXkJoyCY3L5O6SbNnU/TDXZn526ba6UYmhHWVaR3HYzo4LMJdGr I8phRZrsCAXzrmQZvGciC2hsgx8qNI7Hf/tPwapa0MJm8cZViRcZd0/gGcI4uzKs 5/lZdKcmiPR4SrgoCqVjrEvkaIvOmwSzi0bVXIK4pAhYAkkdk/YBHKUF6Ql5z3/K POCv9jXGz0NzlPrpVOW9jhM3MyX+ltGqJ7Wed1iqNFBMNendl7+EUJ/A5hgkycV5 O2hGvZOmXbeybfDoHpgG9VspKPyX4g4AZa5MMCcKADQYjzxF+qDbNJMyXWyAZ0PX x2hF7KIKkXE= =K5D3 -----END PGP SIGNATURE----- --==_Exmh_1571435592_13653P-- --===============8844779532020099064== 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 --===============8844779532020099064==--