Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp2199611pxf; Sat, 20 Mar 2021 07:29:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzHH3f2CFJetNJdjHI0adQIZzo4tvdytQUyfx4dn9bokITZiQoYuyLq0VWPGd0jWq869DdN X-Received: by 2002:aa7:cb82:: with SMTP id r2mr15802824edt.209.1616250559878; Sat, 20 Mar 2021 07:29:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616250559; cv=none; d=google.com; s=arc-20160816; b=HOKM10O46Np+3fle0mPEIGazvhX/lq2qmBkKAziNePVcYqEHRtbmEJh38H5KOMigsV QRt+jINiFvlQP0m8chP3aqqf+0krAam27YF14V3bpVkURNT/cXYhMKCVPQ5/PVGfiUbn bpy618F4+/JnAJsEXo7zrezNxVaHrHA0alLJswa+yqgNk4SAYq9iShui+AAwEYJ5TUvV uAB4/oxoMgRYzr2Npd5FPOKHLZcK31LiOMm9KA6Y+WcXqXNncT0QRzYUIZQ80YotFsOK KDToOCOxELvFO0C8qllDHjZy+DmAzrBHRDX0vak87My5RQqg85dbD1uq1XYVj1Igu87H MXvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:references:cc :to:from:subject:dkim-signature; bh=kQcbTGanAzrgBGCF/DKThsZjt/13iN1Rp0nICH3M9pk=; b=znNlQn2LGt+KO0C18PeXQEDVjTQ7AsS7ve2Wo/VquVOZn67Y1ZATsTyZvbk2Q/IR6g zAYpGzzOMD7pwfVmu2LlANbVozM4fnDlMt3/fJiH1QDzGIHzjqJt/OGVv9PW9OpAuDF/ UdrR+0AcZc3Tm1e4Mvt9THoRWGqvBe60yc8QiI2FeeeHnDhG+7zNnmUvCTGMKkZ16VhN Yh678y5eMGVnbZ1lOF2VJxj8hMMlLaVnSSdhdNR0YvYdk6HBtHiPhjMRDoMCemuZHSc+ eXB1D5xM7VsSZIM3Vg4uHdFwkDwnIrPpk15C1K51ElJcpMUEX3KQg4DuX9anZhvcID8S 4jow== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=olTZRjho; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p14si6924589eji.719.2021.03.20.07.28.57; Sat, 20 Mar 2021 07:29:19 -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; dkim=pass header.i=@linaro.org header.s=google header.b=olTZRjho; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229972AbhCTOXx (ORCPT + 99 others); Sat, 20 Mar 2021 10:23:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52066 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229967AbhCTOXi (ORCPT ); Sat, 20 Mar 2021 10:23:38 -0400 Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3CC1FC061762 for ; Sat, 20 Mar 2021 07:23:38 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id v26so9197331iox.11 for ; Sat, 20 Mar 2021 07:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=kQcbTGanAzrgBGCF/DKThsZjt/13iN1Rp0nICH3M9pk=; b=olTZRjhoRaI6B/JDy56MsvNTIlwMF27aPC5lL9ePvK033EmT21syW+tJhy4QUKIo+R vGiHj1e9xEGqU9fUhiyCzN5zPFPUzZNFndaEjiSLQhxHSrtEvMEoBGNd1dUWpo8kYhq0 F34cThDXnkcumLUcCRgqM+qBIDt/RLg3gQlrVyX7OdCnq8zbnxNsXfi8lSfCq2bmK2IO eq/dxP9egxoyv/cs8gdiXamFKKzT59vLCqIbdlMOMM6Gj9wRi/M+PSKy27CCjfOsiH+X h5HOuEmNbPvg/Rppw5BzXl74pE23jtV2b+JHw+6QLwLOwOYki8PymWXgHBYZosPme19a HD6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kQcbTGanAzrgBGCF/DKThsZjt/13iN1Rp0nICH3M9pk=; b=h4E9ywk4lbs1L8UN8wL5RPsUhr/F/H7BV3LdVRd3YZD6TbZdlERerS6kr2R7k5yjwj Tq7tETPMHSJsUfYbLdJfJdb7zZC35DhTGXtRReMHvRluUGn8VFVOTro64H6MwwEFeb8m 6/TB+80uHbGdHvWW7qlbjs3UNct6HtSNkIfse51ypb0tJUM7G0hr46Sshtv6NvgK5EjJ 6PzHboLU5NCbAsXFXGDlsw63drJo/HuQnqi9nUuIBvcr0eY/oy4wEs+36F/RYabuRucO zj1cSyX+Qp8QKoMIx+8svOw8ala9k7oYYVSCQ3mVxyaXu6k54L3+Y+iXliSMei8hdyAk KZ5A== X-Gm-Message-State: AOAM532ZKta4uUCHrnLtliaW4qNVQrMFx4txdkBoZmyAyVyQ021FYXq7 j0K7wVYbfrVaAmeZLVo8c/gkRKE3odapoCiy X-Received: by 2002:a5d:9250:: with SMTP id e16mr6164893iol.27.1616250217388; Sat, 20 Mar 2021 07:23:37 -0700 (PDT) Received: from [172.22.22.4] (c-73-185-129-58.hsd1.mn.comcast.net. [73.185.129.58]) by smtp.googlemail.com with ESMTPSA id v19sm4234117iol.21.2021.03.20.07.23.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 20 Mar 2021 07:23:36 -0700 (PDT) Subject: Re: [PATCH net-next 0/4] net: ipa: fix validation From: Alex Elder To: davem@davemloft.net, kuba@kernel.org Cc: bjorn.andersson@linaro.org, evgreen@chromium.org, cpratapa@codeaurora.org, elder@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <20210319042923.1584593-1-elder@linaro.org> <5c6fabcf-88c7-29db-431e-01818321e9e7@linaro.org> Message-ID: <9ef8e593-d6be-a936-7a02-0a08e0be51be@linaro.org> Date: Sat, 20 Mar 2021 09:23:36 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <5c6fabcf-88c7-29db-431e-01818321e9e7@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/20/21 8:24 AM, Alex Elder wrote: > On 3/18/21 11:29 PM, Alex Elder wrote: >> There is sanity checking code in the IPA driver that's meant to be >> enabled only during development.  This allows the driver to make >> certain assumptions, but not have to verify those assumptions are >> true at (operational) runtime.  This code is built conditional on >> IPA_VALIDATION, set (if desired) inside the IPA makefile. > > Given the pushback on the ipa_assert() patch I will send > out version 2 of this series, omitting the two patches > that involve assertions. I posted version 2, but I think dropping two patches without changing the subject might have messed up the robots. I don't know how to fix that and don't want to make any more trouble by trying. If there's something I can do, someone please tell me. -Alex > I still think there's a case for my proposal, but I'm > going to move on for now and try to find other ways > to do what I want.  In some cases BUILD_BUG_ON() or > WARN_ON_DEV() could be used.  In other spots, I might > be able to use dev_dbg() for checking things only > while developing.  But there remain a few cases where > none of these options is quite right. > > If I ever want to suggest an assertion again I'll do > it as an RFC and will copy Leon and Andrew, to make > sure they can provide input. > > Thanks. > >                     -Alex > >> Unfortunately, this validation code has some errors.  First, there >> are some mismatched arguments supplied to some dev_err() calls in >> ipa_cmd_table_valid() and ipa_cmd_header_valid(), and these are >> exposed if validation is enabled.  Second, the tag that enables >> this conditional code isn't used consistently (it's IPA_VALIDATE >> in some spots and IPA_VALIDATION in others). >> >> This series fixes those two problems with the conditional validation >> code. >> >> In addition, this series introduces some new assertion macros.  I >> have been meaning to add this for a long time.  There are comments >> indicating places where assertions could be checked throughout the >> code. >> >> The macros are designed so that any asserted condition will be >> checked at compile time if possible.  Otherwise, the condition >> will be checked at runtime *only* if IPA_VALIDATION is enabled, >> and ignored otherwise. >> >> NOTE:  The third patch produces two bogus (but understandable) >> warnings from checkpatch.pl.  It does not recognize that the "expr" >> argument passed to those macros aren't actually evaluated more than >> once.  In both cases, all but one reference is consumed by the >> preprocessor or compiler. >> >> A final patch converts a handful of commented assertions into >> "real" ones.  Some existing validation code can done more simply >> with assertions, so over time such cases will be converted.  For >> now though, this series adds this assertion capability. >> >>                     -Alex >> >> Alex Elder (4): >>    net: ipa: fix init header command validation >>    net: ipa: fix IPA validation >>    net: ipa: introduce ipa_assert() >>    net: ipa: activate some commented assertions >> >>   drivers/net/ipa/Makefile       |  2 +- >>   drivers/net/ipa/gsi_trans.c    |  8 ++--- >>   drivers/net/ipa/ipa_assert.h   | 50 ++++++++++++++++++++++++++++++++ >>   drivers/net/ipa/ipa_cmd.c      | 53 ++++++++++++++++++++++------------ >>   drivers/net/ipa/ipa_cmd.h      |  6 ++-- >>   drivers/net/ipa/ipa_endpoint.c |  6 ++-- >>   drivers/net/ipa/ipa_main.c     |  6 ++-- >>   drivers/net/ipa/ipa_mem.c      |  6 ++-- >>   drivers/net/ipa/ipa_reg.h      |  7 +++-- >>   drivers/net/ipa/ipa_table.c    | 11 ++++--- >>   drivers/net/ipa/ipa_table.h    |  6 ++-- >>   11 files changed, 115 insertions(+), 46 deletions(-) >>   create mode 100644 drivers/net/ipa/ipa_assert.h >> >