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.4 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,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 F2632ECE58E for ; Thu, 17 Oct 2019 13:43:18 +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 B686D2089C for ; Thu, 17 Oct 2019 13:43:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="YoofqgWU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B686D2089C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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 1iL63V-0005t5-NA; Thu, 17 Oct 2019 09:43:05 -0400 Received: from mail-ua1-x92f.google.com ([2607:f8b0:4864:20::92f]) by shelob.surriel.com with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.3) (envelope-from ) id 1iL63S-0005sr-UE for kernelnewbies@kernelnewbies.org; Thu, 17 Oct 2019 09:43:03 -0400 Received: by mail-ua1-x92f.google.com with SMTP id b14so675767uap.6 for ; Thu, 17 Oct 2019 06:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=RQbC/LZDJNe+oGhfSgK7VrH8KqHgUAbYmL9+WwrZbsE=; b=YoofqgWU95ho9kTZoWD5tDMJKWhiNloHc9CHbElOSa6dRMl0NMPFXEcv+ZseHeW8xS dbuVHDnL3NbB4ldtiOXFvd9n+1XJMQxPtdKdlYqabWB6ZlqmkqFI9YYm4Ig95rsJyp3J 4j+IS+jGG3CmI41+bMc1ot8A+g2sGaw57Ys5flVtcu3v5WSGlt10orZk7hxUOpv98FY+ kDlTsMRpZo4Pbt+ZMzdI64mNR+hcjeo7377rUQHu4JTTAjWo9hCohGxik108KloIeHfM qor+xUG3I3uaBQ+0Q/YXhMGcnv93ddJjbDj7UIWGLIQkHpaHX1UtxehtvWyB0Q1Bz7G7 ni3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=RQbC/LZDJNe+oGhfSgK7VrH8KqHgUAbYmL9+WwrZbsE=; b=WY0DNGh/W69Gp/Kn1AOv5khhn77u7aBGFoYreFsuealJlCTy9EPiIW+fUkpyBYsk46 KT98dh89owobfZ7JWI1s2/b1kfSXUK1zaAc4dta/qGVzlDUo+nllHQ+aElBYh75tEkue m+ubc1xx1bm2VdBNU9AnB0jXnT1/M46P0TFzP2vwEP+cMPA9i/Jw3MhX5/V/AQ4V/nSK 4BNcCt0RGiijbUmCGDWXorphFLsm1lTDtFWmi7iP1KI6Gw7OT8DtKgnCXMoO6KHcZlZJ rLrSHiTAC2jcl5aJRTNJfgjUEFKe6wR4JCLoEulWzypllqvLFPrG2KdNKnMdIlwWiI/O sXYA== X-Gm-Message-State: APjAAAXOL9PnRC0jlRvmkekucUjiqOW+ht6V/EwxLb+PvlbQEhoD1RFR hx2oXyjgiv2JK7jzLbipqEt7Xu8VDZ7Arx6+I+Q= X-Google-Smtp-Source: APXvYqxJWZs1r07H/hfqJrKOyiFc15a0c7VVV+2hjfURKDDvY8skh1GlB4YD90jQeWRBi57cYTPnReTD8npdQS4aWiA= X-Received: by 2002:ab0:6994:: with SMTP id t20mr2210757uaq.124.1571319781207; Thu, 17 Oct 2019 06:43:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Maria Neptune Date: Thu, 17 Oct 2019 09:42:50 -0400 Message-ID: Subject: Re: Try/catch for modules? To: Martin Galvan , 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="===============6594253014413249792==" Errors-To: kernelnewbies-bounces@kernelnewbies.org --===============6594253014413249792== Content-Type: multipart/alternative; boundary="00000000000063331e05951b65ce" --00000000000063331e05951b65ce Content-Type: text/plain; charset="UTF-8" On Thu, Oct 17, 2019, 09:42 Maria Neptune wrote: > I hate to say it but honestly in a kernel module, your solution is not to > do null dereferences. It's hard but you gotta. > Otherwise I've seen quite a bit of error handling done with gotos (if > ptr==0 goto error), which I believe compiles to similar code as try/except > blocks. Unsure how you'd handle stuff that sends a signal like null > dereferences in that way though. > > On Thu, Oct 17, 2019, 09:37 Martin Galvan wrote: > >> Hi all, >> >> I'm writing a kernel module, and am trying to implement some >> exception-handling mechanism so that the system won't oops/panic if my >> module does e.g. a NULL dereference. The (horribly hackish) way I'm >> doing this right now is registering a die_notifier which will set the >> 'panic_on_oops' variable to 0 if we detect that the current PID >> corresponds to my module. However, this is ugly for many reasons. >> >> What would be the "standard" way of doing this? Is there something >> like Window's try/except blocks, where I can get back control of the >> execution flow, without having the process die? I'm aware of >> _ASM_EXTABLE, but I understand this only works for a single >> instruction and has other limitations. >> >> _______________________________________________ >> Kernelnewbies mailing list >> Kernelnewbies@kernelnewbies.org >> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> > --00000000000063331e05951b65ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Oct 17, 2019, 09:42 Maria Neptune <maria.elysse.n@gmail.com> wrote:
I hate to say = it but honestly in a kernel module, your solution is not to do null derefer= ences. It's hard but you gotta.
Otherwise I'= ve seen quite a bit of error handling done with gotos (if ptr=3D=3D0 goto e= rror), which I believe compiles to similar code as try/except blocks. Unsur= e how you'd handle stuff that sends a signal like null dereferences in = that way though.=C2=A0

On Thu, Oct 17, 2019, 09:37 Martin Galvan = <omgalvan.86@gmail.com> wrote:
Hi all,

I'm writing a kernel module, and am trying to implement some
exception-handling mechanism so that the system won't oops/panic if my<= br> module does e.g. a NULL dereference. The (horribly hackish) way I'm
doing this right now is registering a die_notifier which will set the
'panic_on_oops' variable to 0 if we detect that the current PID
corresponds to my module. However, this is ugly for many reasons.

What would be the "standard" way of doing this? Is there somethin= g
like Window's try/except blocks, where I can get back control of the execution flow, without having the process die? I'm aware of
_ASM_EXTABLE, but I understand this only works for a single
instruction and has other limitations.

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.ke= rnelnewbies.org/mailman/listinfo/kernelnewbies
--00000000000063331e05951b65ce-- --===============6594253014413249792== 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 --===============6594253014413249792==--