Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp2369770ioo; Sat, 28 May 2022 11:31:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx610epx4bBY0tp4G+V3DqETp91iBv/wU1k0dnq8PC6bvbV2BG6AKEL3+NxYr7wnkBA/NqE X-Received: by 2002:a17:90a:fd87:b0:1e2:cdfc:cbd3 with SMTP id cx7-20020a17090afd8700b001e2cdfccbd3mr1053095pjb.28.1653762707501; Sat, 28 May 2022 11:31:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653762707; cv=none; d=google.com; s=arc-20160816; b=L8nax7CIHJ8pqIiRv+yea1nesjYjVk/OvUoymcCR0k7aBX/WlFVlHrmy1uaWfumyZV 9hInaiLCHc3WIqrXlVvTtxrKEEfqLG/DcrMrd1dRPChdlSuHlYvyWc/GImnU0VUSTyXS 8s6/bofnIgsyc3wf7t2rJSlKebd4JFukpat8E8TqBMGY/qpjwXPBnoBxFnQouNdk7s/I 0aqH7wEzgxGKooHnwUm66ZyGI2OOfsmq++ksuKvNKER1tJqkPbDOnr+ft5PKKTqg77Zt B1rsqjSbOayH+k5JnGf6pL/8KrApTx6q2ngZ+aK2W/8chFNZGa1vxpsDl9rjLJZRFECY 87CA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=ScB3NEe+9Ln+Tkzu5WY+q2tuSZNjpx/VGcUZnRc1NIc=; b=MaoOkFAUkvy0CaRJejpvBFfhkHM98Z4gmz7wFBYNJq2KYRdcWtVonJbO0nzQNthOpY Q+P5ufgoDncJT0cBEXlICB1yUlsDIvX2D1TLRKcmMC21rbziFWxqzVsrIeGmY5trIlCa FMwVzVoE5FpYImRJ4IJrFiNGFGpFZdgF7+P+78PrV8/VQfK0SHc3X7o6lnL9WvzBV1e1 A5ozRiimOpd47fEYDkyH56s+9sHEbYTGA4eom4bYoCl2PX5kv+H+t0qQ+yMizY6BMiGo vWsT+qamzm+fUiCULI3WDslt4RtpPSJhl4i1gtvqUwaMj1dn0n9SJfdshDDhySzjdfSm ABfg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=TyGZgqPm; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id lp6-20020a17090b4a8600b001e049d7ca99si8551235pjb.138.2022.05.28.11.31.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 May 2022 11:31:47 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=TyGZgqPm; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 55F31201A6; Sat, 28 May 2022 11:28:50 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229612AbiEZRAt (ORCPT + 99 others); Thu, 26 May 2022 13:00:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58248 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237076AbiEZRAr (ORCPT ); Thu, 26 May 2022 13:00:47 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 85B5AA3085 for ; Thu, 26 May 2022 10:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1653584445; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ScB3NEe+9Ln+Tkzu5WY+q2tuSZNjpx/VGcUZnRc1NIc=; b=TyGZgqPmo90bOgltHcH0GwdbclgOPTA6KfkazPVLZi4OHk4JAH4TOuYm5t/YjgRgCDwACU DafnVMHm5KvUBFyzafKKZ2qsKtNG90GLuruxlNJBV/Gn/G+TYI3PPuBtRuPXobsejiWuTV vjRF9gNznDwDNavCHlZCr76GUim1NUc= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-84-Ng8Nmd7oO8ejZDTN24hs2A-1; Thu, 26 May 2022 13:00:44 -0400 X-MC-Unique: Ng8Nmd7oO8ejZDTN24hs2A-1 Received: by mail-qk1-f199.google.com with SMTP id b1-20020a05620a118100b006a36dec1b16so1947842qkk.2 for ; Thu, 26 May 2022 10:00:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ScB3NEe+9Ln+Tkzu5WY+q2tuSZNjpx/VGcUZnRc1NIc=; b=67aLVpDhWtyJnDdoPsmx8JlNGGS+T4fSvshaAtLmkOW6a0i+4h+abr1s5b8e54mPc2 Mp/xuW3mI4vbt0e1P9wkLKT8ib9/bkmg0EsoFVPyV8BtvTV0bqK6CN7jyWP2Q5oGKB3P L7GiOLDcSqYEMe22KgDsK5oDGRF7dB6t+aesZnt0yKNFuErxfyTOKdsCQH4RhSL9HVSu F36NI1SXrF2nP2Yxu5eWvc8+vLeVVwhnlLtGOgcVroKvtok2qz9ZrY+Up8+5muDzjrdR YwuhqJwZ/ASyU8Vho64otU8Lh9NCQxKI5PEQTOcSJln0iarKtBfKTfJDWyIf7h1kE3eT jOqA== X-Gm-Message-State: AOAM531kFldbAxk6hgCIPjLw15jC+SYQSk81rEVILDWbnxHbzBW2a7Gp LURyn77x65QvlQ+c+Gfg7FjsX/SmEFloOUo2mRdMstreoC8HmmlYpoDgkBXqzqIpvVbORwtICiG Hc6o84gerqiS5U+nMt+64NGhUVds8xUq5J5LRuXjA X-Received: by 2002:a05:6214:20ec:b0:461:dc16:163d with SMTP id 12-20020a05621420ec00b00461dc16163dmr31140864qvk.40.1653584443713; Thu, 26 May 2022 10:00:43 -0700 (PDT) X-Received: by 2002:a05:6214:20ec:b0:461:dc16:163d with SMTP id 12-20020a05621420ec00b00461dc16163dmr31140772qvk.40.1653584443120; Thu, 26 May 2022 10:00:43 -0700 (PDT) MIME-Version: 1.0 References: <20220525105922.2413991-1-eperezma@redhat.com> <20220525105922.2413991-3-eperezma@redhat.com> <20220526090706.maf645wayelb7mcp@sgarzare-redhat> <20220526132038.GF2168@kadam> In-Reply-To: <20220526132038.GF2168@kadam> From: Eugenio Perez Martin Date: Thu, 26 May 2022 19:00:06 +0200 Message-ID: Subject: Re: [PATCH v3 2/4] vhost-vdpa: introduce STOP backend feature bit To: Dan Carpenter Cc: Stefano Garzarella , "Dawar, Gautam" , "Michael S. Tsirkin" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" , "virtualization@lists.linux-foundation.org" , Jason Wang , Zhu Lingshan , "martinh@xilinx.com" , "ecree.xilinx@gmail.com" , Eli Cohen , Parav Pandit , Wu Zongyong , "dinang@xilinx.com" , Christophe JAILLET , Xie Yongji , "lulu@redhat.com" , "martinpo@xilinx.com" , "pabloc@xilinx.com" , Longpeng , "Piotr.Uminski@intel.com" , "Kamde, Tanuj" , Si-Wei Liu , "habetsm.xilinx@gmail.com" , "lvivier@redhat.com" , Zhang Min , "hanand@xilinx.com" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 26, 2022 at 3:21 PM Dan Carpenter wrote: > > On Thu, May 26, 2022 at 02:44:02PM +0200, Eugenio Perez Martin wrote: > > > >> +static bool vhost_vdpa_can_stop(const struct vhost_vdpa *v) { > > > >> + struct vdpa_device *vdpa = v->vdpa; > > > >> + const struct vdpa_config_ops *ops = vdpa->config; > > > >> + > > > >> + return ops->stop; > > > >> [GD>>] Would it be better to explicitly return a bool to match the return type? > > > > > > > >I'm not sure about the kernel code style regarding that casting. Maybe > > > >it's better to return !!ops->stop here. The macros likely and unlikely > > > >do that. > > > > > > IIUC `ops->stop` is a function pointer, so what about > > > > > > return ops->stop != NULL; > > > > > > > I'm ok with any method proposed. Both three ways can be found in the > > kernel so I think they are all valid (although the double negation is > > from bool to integer in (0,1) set actually). > > > > Maybe Jason or Michael (as maintainers) can state the preferred method here. > > Always just do whatever the person who responded feels like because > they're likely the person who cares the most. ;) > This is interesting and I think it's good advice :). I'm fine with whatever we chose, I just wanted to "break the tie" between the three. > I don't think there are any static analysis tools which will complain > about this. Smatch will complain if you return a negative literal. Maybe a negative literal is a bad code signal, yes. > It feels like returning any literal that isn't 1 or 0 should trigger a > warning... I've written that and will check it out tonight. > I'm not sure this should be so strict, or "literal" does not include pointers? As an experiment, can Smatch be used to count how many times a returned pointer is converted to int / bool before returning vs not converted? I find Smatch interesting, especially when switching between projects frequently. Does it support changing the code like clang-format? To offload cognitive load to tools is usually good :). Thanks! > Really anything negative should trigger a warning. See new Smatch stuff > below. > > regards, > dan carpenter > > ================ TEST CASE ========================= > > int x; > _Bool one(int *p) > { > if (p) > x = -2; > return x; > } > _Bool two(int *p) > { > return -4; // returning 2 triggers a warning now > } > > =============== OUTPUT ============================= > > test.c:10 one() warn: potential negative cast to bool 'x' > test.c:14 two() warn: signedness bug returning '(-4)' > test.c:14 two() warn: '(-4)' is not bool > > =============== CODE =============================== > > #include "smatch.h" > #include "smatch_extra.h" > #include "smatch_slist.h" > > static int my_id; > > static void match_literals(struct expression *ret_value) > { > struct symbol *type; > sval_t sval; > > type = cur_func_return_type(); > if (!type || sval_type_max(type).value != 1) > return; > > if (!get_implied_value(ret_value, &sval)) > return; > > if (sval.value == 0 || sval.value == 1) > return; > > sm_warning("'%s' is not bool", sval_to_str(sval)); > } > > static void match_any_negative(struct expression *ret_value) > { > struct symbol *type; > struct sm_state *extra, *sm; > sval_t sval; > char *name; > > type = cur_func_return_type(); > if (!type || sval_type_max(type).value != 1) > return; > > extra = get_extra_sm_state(ret_value); > if (!extra) > return; > FOR_EACH_PTR(extra->possible, sm) { > if (estate_get_single_value(sm->state, &sval) && > sval_is_negative(sval)) { > name = expr_to_str(ret_value); > sm_warning("potential negative cast to bool '%s'", name); > free_string(name); > return; > } > } END_FOR_EACH_PTR(sm); > } > > void check_bool_return(int id) > { > my_id = id; > > add_hook(&match_literals, RETURN_HOOK); > add_hook(&match_any_negative, RETURN_HOOK); > } >