Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Elliott, Robert (Servers)" <elliott@hpe.com>
To:     Herbert Xu <herbert@gondor.apana.org.au>,
        Ard Biesheuvel <ardb@kernel.org>
CC:     kernel test robot <lkp@intel.com>,
        "llvm@lists.linux.dev" <llvm@lists.linux.dev>,
        "oe-kbuild-all@lists.linux.dev" <oe-kbuild-all@lists.linux.dev>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: RE: [PATCH] crypto: arm/sha1 - Fix clang function cast warnings
Thread-Topic: [PATCH] crypto: arm/sha1 - Fix clang function cast warnings
Thread-Index: AQHZDt/YWeaq+QJSTUWPekiEZOhXR65r7ftQ
Date:   Tue, 13 Dec 2022 15:19:35 +0000
Message-ID: <MW5PR84MB1842AD2188993B2EC6412BABABE39@MW5PR84MB1842.NAMPRD84.PROD.OUTLOOK.COM>
References: <202211041904.f9S5gAGL-lkp@intel.com>
 <Y5FvChDBD/+uaFy8@gondor.apana.org.au>
 <CAMj1kXGkdp_cwOWeX_49Y5xTCH8Y7X-LnM8pJufCH3yw7anBWQ@mail.gmail.com>
 <Y5hXUlvSmHrP8PTN@gondor.apana.org.au>
In-Reply-To: <Y5hXUlvSmHrP8PTN@gondor.apana.org.au>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?60RUzwpYTHrMuRy969pn+i56D+UvZ4s8wXmpnQujDIAQWmKHJWjqi+PCD+Q1?=
 =?us-ascii?Q?AbbRrAfzOLYzkvegarPNpxPw9jtMPy77e+qVMBZAnTbNKcimbCNnWQUbwIVU?=
 =?us-ascii?Q?djZHWr3f/CUIQ9NEA3Yc3aF0adTQu1osik26X3Tkidn6RPoeX2zAoxBTVDfn?=
 =?us-ascii?Q?XEemJJviwVKyzCnfngkf9IddsiU0+u8WRVQ/9VXgnduCjFKRh/pKgOoQZLox?=
 =?us-ascii?Q?IizLs3jS5rn0+LBd3zar2kBdHNLerXMZ37KG6mjR944sZSErqqiQ7m8zaaoH?=
 =?us-ascii?Q?hQ9xpcieNuIg+ZIW2FKImUOGU/IYhnA1Pet8xLRxp0jhKD3iJLz3fYeNTnnS?=
 =?us-ascii?Q?I2D+mwzBsGzpamN0EkxowLjeVYlsB1I7723ucwIfmRZz9Mi9uxZqeKfe5uUd?=
 =?us-ascii?Q?7To3FwpG40n6cOAzmyvbBdIkSqYbwlOhk2IQwsJWpRCgr86zIZjKPhsZI24o?=
 =?us-ascii?Q?udeuvY8fJoPyzsbSOjU1iGvqjTIhScsByYBNY3UnT0huAXPTxzAnSFSOlrak?=
 =?us-ascii?Q?Kfl2Fsvz8LSYiifXitYGksKhB1L6hQpDFGCYaZytI1AsMJjgg7oEyVSK3hRi?=
 =?us-ascii?Q?o37Ahi0Ed14pyfUKviXb8wdEshOhWtr03F85dhaUBdR8BgGIUgJWvGg2luFD?=
 =?us-ascii?Q?NAffpUD0NaPwdaDhX3da40+XF8Rv730qIOf6/RH1ioSOqm0ziHGgSlnCKl+O?=
 =?us-ascii?Q?/G6ntxQbKHoDvvkvr8f/Q8xds9lFdFzF9OjmbVumsxtx+D/gSJRNAqAydUV3?=
 =?us-ascii?Q?kkj8zPQqQNBKltqap2Gm3zJZqY5m0lx//zyGzinzBItxu571rlYkHTgzeCHz?=
 =?us-ascii?Q?wt8j4GB5jl6b1RRLpucZqHv/lY+2RxYksycjTnkL1aFfJGU7zw1sA7p6CmnJ?=
 =?us-ascii?Q?VAORSjO6P73NRefDV379nch/3dLMuQ0rP0LdoZsHNe/q3WKZRquMTEKNoekz?=
 =?us-ascii?Q?nZHp3qmkP6hzjs9KxrdnX76UpRwSYRj6uGpQYAH025OdIHtSDHRGGxTO4dTU?=
 =?us-ascii?Q?NhygXEcySU+rbwXTstI2w1vcJTjVOSwrKgHxRadgCbbt/QWbDQ2hmbAWHjGJ?=
 =?us-ascii?Q?VCaRrxzMa6f+fOXSamKklIon2QuFyZms9XRj9iTdKPzcLP8UYQ4nqDuqkkKA?=
 =?us-ascii?Q?UmhGcboYj1YvnGBk13PDEMt8phh++zfiZBAlkMxtRlAl+IM4ABeN3QnKirpx?=
 =?us-ascii?Q?wDwqa9n9hLkP8mCG08pOH0ndQAPjJOfx7VUJjVkxq12W/nAx7xNCoSXsRB1z?=
 =?us-ascii?Q?efSYnBDmiGgMU0Z2+dsNM0P1vZbrI3M51KfX8p39AYIaHDekfseikpJTfPtx?=
 =?us-ascii?Q?IXiRQ0BnSNREGV7n0yqCmLVQKKYlZcqtcXzv3mlh82kOW/DJubcCD+PYrMN3?=
 =?us-ascii?Q?qCDGhtVVajNSY/cnhMHBoRXX8DSX9MmE+08mfFwzk3/62yL9bSZtVUvrEOvA?=
 =?us-ascii?Q?h6Kgfdw3SO+fzcyfOHtSKGXE/K9VJJD2zEIneYwpM4vGdNmG14LUodz1wRKw?=
 =?us-ascii?Q?yKnXHnCytHH4DE7JLujSlqY/s3mu1BZ3mrQn5eKrLk9FKcqD6a1eTiAaJud8?=
 =?us-ascii?Q?XExqS9d1jncRUrlnoL4=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW5PR84MB1842.NAMPRD84.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: ad0b5302-c2d2-4cb2-35ef-08dadd1d7179
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2022 15:19:35.3593
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ceqib05CEeeBdpvFMGPXEAt/SqMqlb3YoVW4ESPJcdVzKkwJSWDpERZSsIkfwU5v
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR84MB1542
X-OriginatorOrg: hpe.com
X-Proofpoint-ORIG-GUID: fhKQDmGomby8a0TCJ4J5UfVWtONl89k2
X-Proofpoint-GUID: fhKQDmGomby8a0TCJ4J5UfVWtONl89k2
X-HPE-SCL: -1
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1
 definitions=2022-12-13_03,2022-12-13_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 spamscore=0
 phishscore=0 bulkscore=0 suspectscore=0 mlxscore=0 impostorscore=0
 mlxlogscore=999 malwarescore=0 clxscore=1011 lowpriorityscore=0
 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2210170000 definitions=main-2212130135
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        SPF_HELO_NONE,SPF_NONE 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: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org


> On Thu, Dec 08, 2022 at 07:05:45PM +0100, Ard Biesheuvel wrote:
...
> Instead of casting the function which upsets clang for some reason,
> change the assembly function siganture instead.

Since the assembly function is passed directly to the generic sha1 helper
(sha1_base_do_update) then I agree that is the right approach. The
casts are a clue that something is not quite right.

There are several other arm modules with casts, not just sha1:
    sha1, sha1_neon, sha256, sha256_neon, sha2-ce, sha512, sha512-neon

> -       /* make sure casting to sha1_block_fn() is safe */
> +       /* make sure signature matches sha1_block_fn() */
>         BUILD_BUG_ON(offsetof(struct sha1_state, state) !=3D 0);

I think this wording used by some of the modules provides a better
explanation (e.g. arch/arm/sha512-neon-glue.c):
	* Make sure struct sha512_state begins directly with the SHA512
	* 512-bit internal state, as this is what the asm functions expect.

Most of them only access the first field in the structure, so I'd be
tempted to change the callers to pass the offset of the state subfield
and make the prototypes match that, changing:
	block_fn(sctx, data, blocks);
to
	block_fn(sctx->state, data, blocks);

However, a few of them (e.g., arm64 sha1_neon_ce) do carefully
manipulate the other fields (it's important to not confuse the
caller by doing so), so that's not viable for sha1.