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.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MALFORMED_FREEMAIL, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 691B1C433E7 for ; Tue, 13 Oct 2020 08:02:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0271F20BED for ; Tue, 13 Oct 2020 08:02:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="fFXcbyA5" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390721AbgJMICz (ORCPT ); Tue, 13 Oct 2020 04:02:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60844 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390591AbgJMICr (ORCPT ); Tue, 13 Oct 2020 04:02:47 -0400 Received: from mail-ej1-x643.google.com (mail-ej1-x643.google.com [IPv6:2a00:1450:4864:20::643]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 85E78C0613D0; Tue, 13 Oct 2020 01:02:47 -0700 (PDT) Received: by mail-ej1-x643.google.com with SMTP id t25so26879474ejd.13; Tue, 13 Oct 2020 01:02:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=Nlo+ICeKz+qCTf+x4IerNhRGMWRTbpLUIF6/RSAckKo=; b=fFXcbyA5ROqDDWnjwA2mdrpNGdVVXDmgbZtslUt9b1Er8Lgmb6GdDKv4m2RuLU9U8d MKUl8XffdlKiyGBaxVMMHBRQFZaLzi0t2XYcjrvencmZAXJ4RkZflp4wOXt/2A65KT2v sIlQH9TPwnkXo8u/UBJHiSAp0Y/UQAppjf+CaglLysf9PnM3dcVYRtpMI28BJ5d4EAoB 72YZG+jVqgMvuF2gbtsk2TpgPR1A9u9vxbVpSaqznar9xMVMxufDPx6wmWvw9twn1PCH SL66tYIoLxWgFr9OxtoRvfR/L8fwPl2AC8eyGijNNq+f/CZ06qYbFZHzkkx7WAUI/nNK O2PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=Nlo+ICeKz+qCTf+x4IerNhRGMWRTbpLUIF6/RSAckKo=; b=cSXRHpbjblPt9IDVDdOH1hIezpaG42bhsXofG0kwesplgVvH+oS6Ag1WGRPY1uiXvX Dyze/ShUQFMMliFtGrj3Fh/ko7923snE0nHRAg3eqVsc3ewOzl8wEggy3LRQYvmjLrRQ jz8o1pDqWwJcLrVtIrct5rj/AHqH3x7oOOEGaMdPhh4H7yxw2BG5XhDvvC+z7hfXPsD8 IbVHD8AUylxqtZ4IPM4VJzWQS4eju6ADn/TJLOebJpn7zelE6uhrzp1H3ail18prtBFd 6PHmDVyX03XtmOew5gaGT50RXWMqhlYJ/xHQ8Gh4q4lAKFyEq5PeMB4giNj4oz+O4kUL QDpQ== X-Gm-Message-State: AOAM5311OJUgUE+QZfUY9lF73MHkvr2oYccMIgKB2Bndj5ZrcP+KZchr vfEDej5+108L5imIfvgS7X8= X-Google-Smtp-Source: ABdhPJyLFkBZSBBn/rB2G6MUdeWoKMj+AJ4gkZlhm7FuDYga4WD8VPHx68gUCzdFaDVqLWTGbDRsCA== X-Received: by 2002:a17:906:453:: with SMTP id e19mr33287437eja.391.1602576166191; Tue, 13 Oct 2020 01:02:46 -0700 (PDT) Received: from felia ([2001:16b8:2d05:8100:95ae:bd1a:3e4e:4242]) by smtp.gmail.com with ESMTPSA id r11sm11970080edi.91.2020.10.13.01.02.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Oct 2020 01:02:45 -0700 (PDT) From: Lukas Bulwahn X-Google-Original-From: Lukas Bulwahn Date: Tue, 13 Oct 2020 10:02:43 +0200 (CEST) X-X-Sender: lukas@felia To: Greg Kroah-Hartman cc: Lukas Bulwahn , Alan Stern , Sudip Mukherjee , linux-kernel@vger.kernel.org, linux-safety@lists.elisa.tech, linux-usb@vger.kernel.org Subject: Re: [linux-safety] [PATCH] usb: host: ehci-sched: add comment about find_tt() not returning error In-Reply-To: <20201013073524.GA1674118@kroah.com> Message-ID: References: <20201011205008.24369-1-sudipm.mukherjee@gmail.com> <20201012145710.GA631710@rowland.harvard.edu> <20201012151816.GA1559916@kroah.com> <20201013052317.GB330398@kroah.com> <20201013063636.GA1663576@kroah.com> <20201013073524.GA1674118@kroah.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 13 Oct 2020, Greg Kroah-Hartman wrote: > On Tue, Oct 13, 2020 at 09:16:27AM +0200, Lukas Bulwahn wrote: > > Some others actually believe that the use of static analysis tools > > increase software quality and ONLY IF a static analysis tool is used, a > > specific level of software quality is achieved and they want to prove > > that the software reaches a certain level that way. (I do not > > understand that argument but some have been repeating it quite often > > around me. This argument seems to come from a specific interpretation of > > safety standards that claim to have methods to predict the absense of > > bugs up to a certain confidence.) > > So do those others also audit the static analysis tools to ensure that > they actually work as they "think" they do? If not, then their > requirement is pretty pointless :) > Yes, they do audit the tools, but those audits and why that proves the absense of a bug class is yet a completely different story... > > I am doing it for the fun and learning about tools, and I am not such a > > believer but those others would be forced by their beliefs until they > > understand what static analysis tools and their janitors really already > > contribute to the kernel development and where the real gaps might be. > > > > I hope that helps to get a bit of the motivation. Consider us > > kernel newbies :) > > Watch out, sending patches to subsystems to "fix" issues that really > are not real problems is a sure way to get your patches rejected and > make maintainers grumpy. > > I recommend starting out with code that we all "know" needs help, in > drivers/staging/ for stuff like this, so you can learn the process > better, as well as start to understand the limitations of your tools > better. > > good luck! > Thanks for the advice. We will need to learn about the limitations and what is worth a patch and what is not and we will need luck on the way learning that. Lukas From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f66.google.com (mail-ej1-f66.google.com [209.85.218.66]) by mx.groups.io with SMTP id smtpd.web12.6898.1602576167715343532 for ; Tue, 13 Oct 2020 01:02:48 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20161025 header.b=fFXcbyA5; spf=pass (domain: gmail.com, ip: 209.85.218.66, mailfrom: lukas.bulwahn@gmail.com) Received: by mail-ej1-f66.google.com with SMTP id x7so16801920eje.8 for ; Tue, 13 Oct 2020 01:02:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=Nlo+ICeKz+qCTf+x4IerNhRGMWRTbpLUIF6/RSAckKo=; b=fFXcbyA5ROqDDWnjwA2mdrpNGdVVXDmgbZtslUt9b1Er8Lgmb6GdDKv4m2RuLU9U8d MKUl8XffdlKiyGBaxVMMHBRQFZaLzi0t2XYcjrvencmZAXJ4RkZflp4wOXt/2A65KT2v sIlQH9TPwnkXo8u/UBJHiSAp0Y/UQAppjf+CaglLysf9PnM3dcVYRtpMI28BJ5d4EAoB 72YZG+jVqgMvuF2gbtsk2TpgPR1A9u9vxbVpSaqznar9xMVMxufDPx6wmWvw9twn1PCH SL66tYIoLxWgFr9OxtoRvfR/L8fwPl2AC8eyGijNNq+f/CZ06qYbFZHzkkx7WAUI/nNK O2PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=Nlo+ICeKz+qCTf+x4IerNhRGMWRTbpLUIF6/RSAckKo=; b=jhDd4bQW9+N2I3Q+2xe5bpPZBScZ1vtFTHAsAFcNicuIbdh5ozNZpdBWyFDjA5VqXg xH36ntuSTiBcI34jeyZZy9oSbPJHoxpDFmQrFLlxdDoBepa3Ahcmix2xVq3ehvG4bjME DdNVp3GE1p6Rx4R7OM45K42XhdEH7x+RsTzkC18qxqH40YKNiOOTiDkDCj7CmMWUlX/v rWJD7gVGnAMMkAEUcp/wDjD6Hd1VSQQ78XtF17SZe5QS9jcRz6drI5luexO8L5SqiG67 ah0DVtYvf00E+vDkez0oo37LN3U6mpr+wyRB4tYgsLwPWsqABpHvZLDQfU0LiaQgshJK SxiQ== X-Gm-Message-State: AOAM5304AymrTfu5amgK6d1w61h5w0LTyRA/UL86lCva1nnKvWF25wSs YVxIyjMhihGL4XpGE5vf2AA= X-Google-Smtp-Source: ABdhPJyLFkBZSBBn/rB2G6MUdeWoKMj+AJ4gkZlhm7FuDYga4WD8VPHx68gUCzdFaDVqLWTGbDRsCA== X-Received: by 2002:a17:906:453:: with SMTP id e19mr33287437eja.391.1602576166191; Tue, 13 Oct 2020 01:02:46 -0700 (PDT) Return-Path: Received: from felia ([2001:16b8:2d05:8100:95ae:bd1a:3e4e:4242]) by smtp.gmail.com with ESMTPSA id r11sm11970080edi.91.2020.10.13.01.02.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Oct 2020 01:02:45 -0700 (PDT) From: "Lukas Bulwahn" X-Google-Original-From: Lukas Bulwahn Date: Tue, 13 Oct 2020 10:02:43 +0200 (CEST) X-X-Sender: lukas@felia To: Greg Kroah-Hartman cc: Lukas Bulwahn , Alan Stern , Sudip Mukherjee , linux-kernel@vger.kernel.org, linux-safety@lists.elisa.tech, linux-usb@vger.kernel.org Subject: Re: [linux-safety] [PATCH] usb: host: ehci-sched: add comment about find_tt() not returning error In-Reply-To: <20201013073524.GA1674118@kroah.com> Message-ID: References: <20201011205008.24369-1-sudipm.mukherjee@gmail.com> <20201012145710.GA631710@rowland.harvard.edu> <20201012151816.GA1559916@kroah.com> <20201013052317.GB330398@kroah.com> <20201013063636.GA1663576@kroah.com> <20201013073524.GA1674118@kroah.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Tue, 13 Oct 2020, Greg Kroah-Hartman wrote: > On Tue, Oct 13, 2020 at 09:16:27AM +0200, Lukas Bulwahn wrote: > > Some others actually believe that the use of static analysis tools > > increase software quality and ONLY IF a static analysis tool is used, a > > specific level of software quality is achieved and they want to prove > > that the software reaches a certain level that way. (I do not > > understand that argument but some have been repeating it quite often > > around me. This argument seems to come from a specific interpretation of > > safety standards that claim to have methods to predict the absense of > > bugs up to a certain confidence.) > > So do those others also audit the static analysis tools to ensure that > they actually work as they "think" they do? If not, then their > requirement is pretty pointless :) > Yes, they do audit the tools, but those audits and why that proves the absense of a bug class is yet a completely different story... > > I am doing it for the fun and learning about tools, and I am not such a > > believer but those others would be forced by their beliefs until they > > understand what static analysis tools and their janitors really already > > contribute to the kernel development and where the real gaps might be. > > > > I hope that helps to get a bit of the motivation. Consider us > > kernel newbies :) > > Watch out, sending patches to subsystems to "fix" issues that really > are not real problems is a sure way to get your patches rejected and > make maintainers grumpy. > > I recommend starting out with code that we all "know" needs help, in > drivers/staging/ for stuff like this, so you can learn the process > better, as well as start to understand the limitations of your tools > better. > > good luck! > Thanks for the advice. We will need to learn about the limitations and what is worth a patch and what is not and we will need luck on the way learning that. Lukas