Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp6529435rwd; Mon, 5 Jun 2023 20:46:45 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6hLhpRa05lwP6qyuW2ET3xDZlPPrI9yMtP5FQ73ujO8acN1j6LiOml+ucOvOBJBLhJikLM X-Received: by 2002:a05:6a00:b82:b0:647:e45f:1a49 with SMTP id g2-20020a056a000b8200b00647e45f1a49mr1114355pfj.4.1686023205587; Mon, 05 Jun 2023 20:46:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686023205; cv=none; d=google.com; s=arc-20160816; b=I4FhNff/+zm814Bzm9hlmltiXDWS87Zr9WyIT7DohIMqy+BcN1s3bHbsI05Jv+Pv9X xSe8pyDh/afKrvDx3NwNbJzu47ktTBZKXw3ZIxVHO1TonvbP1yq+TK3vmyPZx39Dt3PT +Vr41DYs1rVo3LtUbxJQHQqopg8ytA5vcGEO2OZu2EMeo3OeDfGwO7Wf5RqEqWSpCTRO S1p/PLN+5+RpeB7qenZ3kDOEL2pRMBOvLyw9zsmlRNOrl0XIW3uG501BgDseQlf+pdhq kya50h40CbqVXf4lOuIsfWaJcZ+oAKXIt10qLpQWTS9KsV+3z6KELig5G/A/cKssetUD 1Jew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=umKcDqByXDn9b3jENbumXB3sP0yStm0gsG9oCHXds7A=; b=QmW/IvDusCYe0QrtYFfShUSm20I41j3HNx122ZN1txT3nJz6v47O6fLDYwx+H7IAWw MX5UY9rc2xacsV4i4ZpJFkNLJGzyhem9WTdngek83rasEgPWwcJWR3pM1KhDBjuZTvy4 EEcntOITDH2wXfSLYk5MjcXdD6U01JwD8wrPkPGxvKBjLMBupyeMRuBGxW3myPm4IqpB zpERa11pDF+ark/MWOjxifTCCxBq1chnbLLAF9CFnfvtCow/sZVwVf1pRPacuCAgvBAw DjdHOhqrx+fO5H2sZ9IIDOPQqD8Y5jdsVg99R7Eu/wChLGo/sxGyMb1VMHCqXM3H7FCE vIsw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a26-20020aa794ba000000b0064d2a385c1csi6429068pfl.252.2023.06.05.20.46.32; Mon, 05 Jun 2023 20:46:45 -0700 (PDT) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231490AbjFFD3B (ORCPT + 99 others); Mon, 5 Jun 2023 23:29:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42702 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230499AbjFFD3A (ORCPT ); Mon, 5 Jun 2023 23:29:00 -0400 Received: from mail.hallyn.com (mail.hallyn.com [178.63.66.53]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1708711B; Mon, 5 Jun 2023 20:28:46 -0700 (PDT) Received: by mail.hallyn.com (Postfix, from userid 1001) id C18AD1D20; Mon, 5 Jun 2023 22:28:44 -0500 (CDT) Date: Mon, 5 Jun 2023 22:28:44 -0500 From: "Serge E. Hallyn" To: "GONG, Ruiqi" Cc: Serge Hallyn , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Wang Weiyang , Xiu Jianfeng , gongruiqi1@huawei.com Subject: Re: [PATCH] capability: erase checker warnings about struct __user_cap_data_struct Message-ID: <20230606032844.GA628899@mail.hallyn.com> References: <20230602054527.290696-1-gongruiqi@huaweicloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230602054527.290696-1-gongruiqi@huaweicloud.com> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS, 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, Jun 02, 2023 at 01:45:27PM +0800, GONG, Ruiqi wrote: > Currently Sparse warns the following when compiling kernel/capability.c: > > kernel/capability.c:191:35: warning: incorrect type in argument 2 (different address spaces) > kernel/capability.c:191:35: expected void const *from > kernel/capability.c:191:35: got struct __user_cap_data_struct [noderef] __user * > kernel/capability.c:168:14: warning: dereference of noderef expression > ...... (multiple noderef warnings on different locations) > kernel/capability.c:244:29: warning: incorrect type in argument 1 (different address spaces) > kernel/capability.c:244:29: expected void *to > kernel/capability.c:244:29: got struct __user_cap_data_struct [noderef] __user ( * )[2] > kernel/capability.c:247:42: warning: dereference of noderef expression > ...... (multiple noderef warnings on different locations) > > It seems that defining `struct __user_cap_data_struct` together with > `cap_user_data_t` make Sparse believe that the struct is `noderef` as > well. Separate their definitions to clarify their respective attributes. > > Signed-off-by: GONG, Ruiqi Seems ok. There's still so much noise in the make C=2 output even just for kernel/capability.c that I'm not sure it's worth it, but no objection. Acked-by: Serge Hallyn > --- > include/uapi/linux/capability.h | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h > index 3d61a0ae055d..5bb906098697 100644 > --- a/include/uapi/linux/capability.h > +++ b/include/uapi/linux/capability.h > @@ -41,11 +41,12 @@ typedef struct __user_cap_header_struct { > int pid; > } __user *cap_user_header_t; > > -typedef struct __user_cap_data_struct { > +struct __user_cap_data_struct { > __u32 effective; > __u32 permitted; > __u32 inheritable; > -} __user *cap_user_data_t; > +}; > +typedef struct __user_cap_data_struct __user *cap_user_data_t; > > > #define VFS_CAP_REVISION_MASK 0xFF000000 > -- > 2.25.1