Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2153598pxb; Fri, 5 Feb 2021 10:10:23 -0800 (PST) X-Google-Smtp-Source: ABdhPJxcuwDWnGOMVi9iR9DCmE1GRdyzRJuKb9zBOS3ivZkCkRwA6q7+PawB7RRZOjovdanHteHa X-Received: by 2002:a17:906:c1d9:: with SMTP id bw25mr5027348ejb.452.1612548623781; Fri, 05 Feb 2021 10:10:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612548623; cv=none; d=google.com; s=arc-20160816; b=pwnLnC0/5v7sJmD72A5eL7prDh48cLkzlYhzLYga1UdteG3dhAEeaKUFslLebW2fEU ikUo5dukzMa6OiO2ho8wTj/hVwBQAXvy8ccdvAajuBOtDn6vfVTARVVjpU2plDMB0or9 9r6oe+74imq4fMDKAoNpXj5gqNUT2HAy2Ol3m1Caw4P5SKSQ22BbMKmPgnJDJTypPIPg y+BxpUNZK+hcJWeWAwadklO+I9HTn6IzOlNCajnmCD4rV12nrk7BKnfDbBenMcTn78i3 LciJhpaqLkX2+ywjhSi3F4BqelbDn+NcCCX5iWrO79yty6Gr4NZG6DVXcWNj+NGyRqID Tz+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=H34KrSWW8kUUSXnnWRVEEdOuXln0L4LyPZbJGtNDCWA=; b=wvJCnhDP9gCrAZiIb3SBd/GpjUZb9Ep7JdqfEnb//r0BQtLMsv4nGvV9y1T2fMOEIb f566qjJM9KAZigILk02KdwwJvrr7K8SqTffZhZaR3Zpgwil7uRqH/4RzTD2vMxHcEniz tR5Ku90DQK1NKT615dsJZ6Dk+nkvGYY2l2gYo/YmbHZJaAo8Vk4dRjOHXQ6gMSjie4u6 TIx9JYYI3pFxEerfjg3umB/ItSkbaAEEG/uZ7Th8uUZXQ54shykq4BtH+cyQPLEQH3GA +dPdY7kEaQRwtYg7c0c0ubo7E0LwAbBHmpSSOv3G8DpclzcFbs01v00HrzRah7thGzKl cxew== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-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 w1si6245139edl.186.2021.02.05.10.09.56; Fri, 05 Feb 2021 10:10:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-wireless-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-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233679AbhBEQ0O (ORCPT + 99 others); Fri, 5 Feb 2021 11:26:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40486 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233678AbhBEQX5 (ORCPT ); Fri, 5 Feb 2021 11:23:57 -0500 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 48C1DC06178B; Fri, 5 Feb 2021 10:05:37 -0800 (PST) Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94) (envelope-from ) id 1l85U1-00GNbQ-8w; Fri, 05 Feb 2021 19:05:29 +0100 Message-ID: <15f435a791b0c4b853c8c6b284042c7057d6efaf.camel@sipsolutions.net> Subject: Re: Potential invalid ~ operator in net/mac80211/cfg.c From: Johannes Berg To: Colin Ian King Cc: "David S. Miller" , Jakub Kicinski , "linux-wireless@vger.kernel.org" , "netdev@vger.kernel.org" Date: Fri, 05 Feb 2021 19:05:13 +0100 In-Reply-To: <4bb65f2f-48f9-7d9c-ab2e-15596f15a4d8@canonical.com> References: <4bb65f2f-48f9-7d9c-ab2e-15596f15a4d8@canonical.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-malware-bazaar: not-scanned Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org Hi Colin, > while working through a backlog of older static analysis reports from > Coverity So ... yeah. Every time I look at Coverity (not frequently, I must admit) I see the same thing, and get confused. > I found an interesting use of the ~ operator that looks > incorrect to me in function ieee80211_set_bitrate_mask(): > > for (j = 0; j < IEEE80211_HT_MCS_MASK_LEN; j++) { > if (~sdata->rc_rateidx_mcs_mask[i][j]) { > sdata->rc_has_mcs_mask[i] = true; > break; > } > } > > for (j = 0; j < NL80211_VHT_NSS_MAX; j++) { > if (~sdata->rc_rateidx_vht_mcs_mask[i][j]) { > sdata->rc_has_vht_mcs_mask[i] = true; > break; > } > } > > For the ~ operator in both if stanzas, Coverity reports: > > Logical vs. bitwise operator (CONSTANT_EXPRESSION_RESULT) > logical_vs_bitwise: > > ~sdata->rc_rateidx_mcs_mask[i][j] is always 1/true regardless of the > values of its operand. This occurs as the logical operand of if. > Did you intend to use ! rather than ~? > > I've checked the results of this and it does seem that ~ is incorrect > and always returns true for the if expression. So it probably should be > !, but I'm not sure if I'm missing something deeper here and wondering > why this has always worked. But is it really always true? I _think_ it was intended to check that it's not 0xffffffff or something? https://lore.kernel.org/linux-wireless/516C0C7F.3000204@openwrt.org/ But maybe that isn't actually quite right due to integer promotion? OTOH, that's a u8, so it should do the ~ in u8 space, and then compare to 0 also? johannes