From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B6573C2B9F4 for ; Mon, 14 Jun 2021 14:14:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 90AD961206 for ; Mon, 14 Jun 2021 14:14:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233881AbhFNOQv (ORCPT ); Mon, 14 Jun 2021 10:16:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53062 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233780AbhFNOQq (ORCPT ); Mon, 14 Jun 2021 10:16:46 -0400 Received: from zeniv-ca.linux.org.uk (zeniv-ca.linux.org.uk [IPv6:2607:5300:60:148a::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9FFD5C061574 for ; Mon, 14 Jun 2021 07:14:43 -0700 (PDT) Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1lsnLz-0086xp-Gz; Mon, 14 Jun 2021 14:14:15 +0000 Date: Mon, 14 Jun 2021 14:14:15 +0000 From: Al Viro To: Jhih Ming Huang Cc: Greg KH , fabioaiuto83@gmail.com, ross.schm.dev@gmail.com, maqianga@uniontech.com, marcocesati@gmail.com, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] rtw_security: fix cast to restricted __le32 Message-ID: References: <20210613122858.1433252-1-fbihjmeric@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 14, 2021 at 12:40:27AM +0800, Jhih Ming Huang wrote: > On Sun, Jun 13, 2021 at 8:34 PM Greg KH wrote: > > > > On Sun, Jun 13, 2021 at 08:28:58PM +0800, Jhih-Ming Huang wrote: > > > This patch fixes the sparse warning of fix cast to restricted __le32. > > > > > > Last month, there was a change for replacing private CRC-32 routines with > > > in-kernel ones. > > > In that patch, we replaced getcrc32 with crc32_le in calling le32_to_cpu. > > > le32_to_cpu accepts __le32 type as arg, but crc32_le returns unsigned int. > > > That how it introduced the sparse warning. > > > > As crc32_le returns a u32 which is in native-endian format, how can you > > cast it to le32? Why do you cast it to le32? Isn't that going to be > > incorrect for big endian systems? > > > > thanks, > > > > greg k-h > > Thanks for the fast reply. > Yes, you are right. I did not notice that le32_to_cpu already handles > both of the cases. > > So it seems the warning from sparse is false positives, am I right? In a sense that on all architectures we would be ever likely to support le32_to_cpu and cpu_to_le32 do the same bit-shuffling - yes. In a sense of having those used correctly it's not a false positive, though - it's much easier to follow "this variable always hold native-endian, this - little-endian" and watch for conversions done correctly than to count the byteswaps and try to prove that it's either even for all execution histories or odd for all execution histories. IOW, there's a good reason for keeping separate cpu_to_le32 and le32_to_cpu and not mixing them with each other - it's easier to prove correctness that way *and* easier to look for endianness bugs.