Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp4037500pxu; Mon, 12 Oct 2020 07:58:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxPRNxPHvaFWaUlze+UilV+BsQd8FDkVp4hg6mI4noSmy83Vka/Leww37PEiHRVMGhVs6f5 X-Received: by 2002:a17:907:20e6:: with SMTP id rh6mr27719364ejb.169.1602514735168; Mon, 12 Oct 2020 07:58:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602514735; cv=none; d=google.com; s=arc-20160816; b=vICApgFh5Grn/RcCp+bhrHvpOz6vLpB4o5I9YBfGcXjWP60E2/vp7Uhxd2a7d7mATH 2bgblF9kqhcdGM5TY87usGokM6J8yBP9k2V3PIefbDRBqvrAgjCLhMfOFeS/+kv+iKgU Z6BwJ9h1mv3Gy7PB/kAC3/tlwgReU883nJOD9gSkOK4niDHEBduTlwkG+g1i8FkFbl94 /+uppg+nRPoZTMhn96SzYlFXZMns6QyN8DUi/dXUayu7o8hk1OoOEs0HJ6oJwyymUk/K lR9wwG37hbhrWGVjTyGppIqgbHprG8yppHnoqH3vH9wSUdx73/R+/ryAI2VYd4Wvh+aQ eqsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=xL1IOHsUGGNdprpbkpFZ/Z/OP30dFOQcVY1+Y+ioMmg=; b=sf5DR3RJaBzVnQCzk07fQ8wBld0cA5wOu2beJeuiPEWSTqvuYmrqDfnjqd/hZVQMRk EBKKsdvs8Nh7Dh0kc9ZaminLvnUCSRaHn1fJaUdpNGLXTsz8IObW4lrbHcFvAX0sQEbm eo+WpqTgK+pdzDhL9o4C3Xjz2UQ8bKUlUB/h2UYU0pFIoJ94pACQjmtPEp0//DO/TVli FQaaiPB8vUjZHX56h/efcNrirPhndaRQPKcvCunVDZoaN5QJCqmokzzuP5jl1Smdiwpi p+8ymZSVvyP6zZ/ObI7Hed8SMI/zDofJifAV0sDAf/ikhJ47kSHAROdVCCslDTifLQHy KuKQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v19si12256458ejf.257.2020.10.12.07.58.30; Mon, 12 Oct 2020 07:58:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730003AbgJLO5L (ORCPT + 99 others); Mon, 12 Oct 2020 10:57:11 -0400 Received: from netrider.rowland.org ([192.131.102.5]:58117 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1729667AbgJLO5L (ORCPT ); Mon, 12 Oct 2020 10:57:11 -0400 Received: (qmail 632421 invoked by uid 1000); 12 Oct 2020 10:57:10 -0400 Date: Mon, 12 Oct 2020 10:57:10 -0400 From: Alan Stern To: Lukas Bulwahn Cc: Sudip Mukherjee , Greg Kroah-Hartman , 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 Message-ID: <20201012145710.GA631710@rowland.harvard.edu> References: <20201011205008.24369-1-sudipm.mukherjee@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 12, 2020 at 04:11:38PM +0200, Lukas Bulwahn wrote: > > > On Sun, 11 Oct 2020, Sudip Mukherjee wrote: > > > Add a comment explaining why find_tt() will not return error even though > > find_tt() is checking for NULL and other errors. > > > > Signed-off-by: Sudip Mukherjee > > I get the intent of the comment but there is a large risk that somebody > could remove the find_tt() call before the calling the function and there > is no chance to then see later that the comment is actually wrong. Why would anybody do that? Who would deliberately go change a driver in a way that is obviously wrong and would break it? Especially when such changes are likely to cause compile errors? There are tons of changes one might make to any program that will leave it syntactically valid but will cause it to fail. What's special about removing the early calls to find_tt()? > I guess you want to link this comment here to a code line above and > request anyone touching the line above to reconsider the comment then. That really seems unnecessary. > But there is no 'concept' for such kind of requests to changes and > comments. > > So, the comment is true now, but might be true or wrong later. > > I am wondering if such comment deserves to be included if we cannot check > its validity later... > > I would prefer a simple tool that could check that your basic assumption > on the code is valid and if it the basic assumption is still valid, > just shut up any stupid tool that simply does not get that these calls > here cannot return any error. Real code contains so many assumptions, especially if you include ones which are obvious to everybody, that such a tool seems impractical. Alan Stern