Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp3303481pxp; Tue, 8 Mar 2022 11:27:17 -0800 (PST) X-Google-Smtp-Source: ABdhPJy/w4vTclkrp/dEVonr+FmIbb3Wm+GSbbqOz8cVb5xaReTw3C7HiLmDjovVnXNBRZIAFp5N X-Received: by 2002:a05:6402:294b:b0:413:d1e5:884e with SMTP id ed11-20020a056402294b00b00413d1e5884emr17639782edb.4.1646767636851; Tue, 08 Mar 2022 11:27:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646767636; cv=none; d=google.com; s=arc-20160816; b=m41uY1cf2HfPyNeQByYjxWZA8KabQIvMmMBZe2KTkGNlCoUZyO9UiWKwKTraOpwVHR ZK4S5WA+cM5/1gm15a8tFVuxZ/YdQj9+lS8rMHoq9YN4g/afka2LUVVPvJgvxsTwICt8 AqNxID7QwVRngj6on9XHwgsUrzTZWu+40yfe0l1+pLJ3l8Aumtx5yNlWfrYJCPQYgpYL idsQPWfI/AsXTHoE0enjtwiTBnOGQjHzDyKmJOBDESfkVtuH8yeKrDsuGyrtroiZ0Z4P WHRUGBl62zCydZge+eXz0O2vDsBtS3uZadhzQIr+jb1Nz3zcHdfk5qHWweulGJ5+phGz 8NtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=vvKgn0sHuAllkwYzvRFG2BC617hGBzzXAeGk4mrg70E=; b=K91yZ2dEeQkABpaG02dEZYTmzoeLpd/Dn2chveAnV9Ustb9E1fNqiI4SXsxtrUHMKz yV0iyHIt7jf2hMMDbC1p88Z23r1pCsq/RgnsUE7r66a81QU2fw8NzxOSFINDAG6fi+Sa G9TUqwGtMGRD2NfvWC3r8cJ9nY8/RMzg7gVe2S7RWMKSwJB6QOLJqHpI3HQle83ffa4w XqTiRm7ROiovHJyPEAC0F/bqzhrHLFCw3LsrnWWhhtSiYN92OTtVf0MAOEzJlKbUC40o K689x5ckcYK9Ap9ksFFm6MrFZD5vPEc0cPysqqCb/Bh5n03FbbDTjCG9NAoBxoJRHyAl j/9Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@googlemail.com header.s=20210112 header.b=G61uZlPu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ek18-20020a056402371200b004159b8a598bsi9874350edb.185.2022.03.08.11.26.47; Tue, 08 Mar 2022 11:27:16 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@googlemail.com header.s=20210112 header.b=G61uZlPu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344122AbiCHP7P (ORCPT + 99 others); Tue, 8 Mar 2022 10:59:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35428 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348959AbiCHP7B (ORCPT ); Tue, 8 Mar 2022 10:59:01 -0500 Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7F99F36E1D; Tue, 8 Mar 2022 07:58:04 -0800 (PST) Received: by mail-ot1-x32a.google.com with SMTP id e25-20020a0568301e5900b005b236d5d74fso4432442otj.0; Tue, 08 Mar 2022 07:58:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=vvKgn0sHuAllkwYzvRFG2BC617hGBzzXAeGk4mrg70E=; b=G61uZlPuyejOW7T+11EayRugjx1w1CLbBDWhQ229Ng+7kH6xC73iT1VpxXwsPswKrm BUJZr1YHDkI/sQz4/JyawVxm42ygHfH7e1BhNAbIPrjHBmvMvX/yB3WuDIWSb8vMgJtp Jq1XF2Rt48ftXftNceQV0+QuOTgGCf+UsebsIEX93H3r34PaztKFoR0g2H0sxBXTFrqF O2p/xx+TVOGZ5oGUlD6F2wsi6hXCYvSAF7Jl2jgPHcko16zU2C1XKjOlPf3gp/3PxnA5 QFcz5e27bcIHeURZILrgFRIfL/MmH5unYekp6LY/zT8jTfjqDcdx1xgyrHsGPe84MUOI SSUg== 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:content-transfer-encoding; bh=vvKgn0sHuAllkwYzvRFG2BC617hGBzzXAeGk4mrg70E=; b=AA3/K7eCyrOYv90XaRMP96cceisCFMOwKt7I1PBLBS+zzYlg5D2gUt+aGqR5n3XeJX CyRW3RVeL/Dwi6ZszxvUIKSGvQznoVH3I+q5JEtvpD+fOpJ2PdrwDncQz5nZj0akVwGb 8oiHJy8tt8FHRl0kMzJadBxn1X2E/+5fOsF7U9wAKOShLTOk9lZQuw8DF3AQXsn8lnzw 0fksnBYw7AmuyqnkxB2qsUACIR5qmlsTHOf/V+/VnujOkSWDUTOVPvEKbTme3DbP04Pd Uw7qP4VRUTTn39da76G4E0vVS861SpviaCO3YWY4Flsmbqcx0SAeyb8OxkHo/LPkiJka IeCw== X-Gm-Message-State: AOAM530Ar13JdUJnuz5uYkrMDkeD+RZUKWqAbqjTj0FXm5z5F0DLf24i DjidO8KoGl8zCCFjQazYfikWYhT1ATVoshYMMZw= X-Received: by 2002:a9d:4b95:0:b0:5b2:46d4:94aa with SMTP id k21-20020a9d4b95000000b005b246d494aamr3241251otf.117.1646755083739; Tue, 08 Mar 2022 07:58:03 -0800 (PST) MIME-Version: 1.0 References: <20220217142133.72205-1-cgzones@googlemail.com> <20220217142133.72205-2-cgzones@googlemail.com> In-Reply-To: From: =?UTF-8?Q?Christian_G=C3=B6ttsche?= Date: Tue, 8 Mar 2022 16:57:52 +0100 Message-ID: Subject: Re: [PATCH 3/5] selinux: use consistent pointer types for boolean arrays To: Paul Moore Cc: SElinux list , Stephen Smalley , Eric Paris , Nathan Chancellor , Nick Desaulniers , Ondrej Mosnacek , James Morris , Austin Kim , Casey Schaufler , Jiapeng Chong , Yang Li , Linux kernel mailing list , llvm@lists.linux.dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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 Fri, 18 Feb 2022 at 17:01, Paul Moore wrote: > > On Thu, Feb 17, 2022 at 9:21 AM Christian G=C3=B6ttsche > wrote: > > > > Use a consistent type of unsigned int* for boolean arrays, instead of > > using implicit casts to and from int*. > > > > Reported by sparse: > > > > security/selinux/selinuxfs.c:1481:30: warning: incorrect type in as= signment (different signedness) > > security/selinux/selinuxfs.c:1481:30: expected unsigned int * > > security/selinux/selinuxfs.c:1481:30: got int *[addressable] val= ues > > security/selinux/selinuxfs.c:1398:48: warning: incorrect type in ar= gument 3 (different signedness) > > security/selinux/selinuxfs.c:1398:48: expected int *values > > security/selinux/selinuxfs.c:1398:48: got unsigned int *bool_pen= ding_values > > > > Signed-off-by: Christian G=C3=B6ttsche > > > > --- > > A more invasive change would be to change all boolean arrays to bool*. > > I think that might be a worthwhile change, although that can happen at > a later date. > > A quick general comment: please try to stick to 80-char long lines. I > realize Linus/checkpatch.pl has started to allow longer lines but I > would still like SELinux to try and keep to 80-chars or under. > > > diff --git a/security/selinux/ss/services.c b/security/selinux/ss/servi= ces.c > > index 6901dc07680d..7865926962ab 100644 > > --- a/security/selinux/ss/services.c > > +++ b/security/selinux/ss/services.c > > @@ -3175,7 +3175,8 @@ int security_get_bool_value(struct selinux_state = *state, > > static int security_preserve_bools(struct selinux_policy *oldpolicy, > > struct selinux_policy *newpolicy) > > { > > - int rc, *bvalues =3D NULL; > > + int rc; > > + unsigned int *bvalues =3D NULL; > > Doesn't this cause a type mismatch (unsigned int vs int) when an entry > from bvalues[] is assigned to cond_bool_datum::state later in the > security_preserve_bools() function? Yes, but those variables *should* only hold the values 0 or 1. But probably it's better to re-spin for 5.19 with all arrays and cond_bool_datum::state converted to literal bool type. > > -- > paul-moore.com