Message ID | 20240213101756.461701-1-arnd@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-63330-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:bc8a:b0:106:860b:bbdd with SMTP id dn10csp441396dyb; Tue, 13 Feb 2024 02:18:16 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCX94cXMGLDGpLHCCOfrW9lICs2YXIp/wyFUvAXf2uziPPYKN9xhEvBBvqykOagyFPkfQv3dRTWHGcamJww5OLoivBQ2Yg== X-Google-Smtp-Source: AGHT+IFYTfHlD8YVEMEbIHFIbWGpwucdXFobKPEVS0cQl7+ni2pgz7Y1/tNj4pEAz1jE3e0xOtVy X-Received: by 2002:a1f:6dc4:0:b0:4c0:2416:6fd0 with SMTP id i187-20020a1f6dc4000000b004c024166fd0mr5445977vkc.6.1707819496134; Tue, 13 Feb 2024 02:18:16 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707819496; cv=pass; d=google.com; s=arc-20160816; b=Q7B1hjVkze9tuIm0dG4r7XTzGgCVZgC6lwny6PCfXT0DbRrtPiFc85h+n3FG+W8c/M rJmreqat6ktLvPjHiU6lHgx23fUwcZ2hfHdtbYd3D5c1A27g7MI4wsaZd+scw4JbBAMf 9+P0//sA9aaLyYPyTnhMAhRINGvvU5lhL71EAnIJCZlHG2qE17AoVkVNP+9vkJzVqC/U 0HALhKwlkbCbxD5I2ys2o2BACMyKJ4oUZqY8vX1wYC31QczipPsVEaLc21NfYv2uzY6Q yC00HDWW0M+72L0SIKgWEEyGNKTaZn7kScE10t6aa25KqH25mKPYgDT/73JCU1NhqV+w FfJg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=PrQvkDeOfrBGSkq8h73vAbf5K8D8FMs4yU2qgi1sTdE=; fh=M5s1LocGEx+BnvxAK01Mcfjgalq0BTeh81G4QJgKkH8=; b=F52PWasFUfMNuLjmVME9sTrCI3VgoX/GLCjsAdEZWw7pf0W+V/67oRVeFjpMPy0hk9 nN+2R5Nr68uHCrXmIS7P3ss5DJMfcFwUD0KF3cdNi7hVvhUSyR42zgVgENoJg3WADtPa NxMgHRD0fzpKr0mH5WR6UVIREvFRNMM8opGuqz5gYtCKume9pANxXVol6aDS/wid5FPz Lyw4+06aAmL/yNLsfKtLazfOlepky9O4Yc8M9FhwZCsbphRks82knRxmZozQe3SASpDY wNjV7rIq+hP5a5NjBrUgzSLkVh0b4ehCgrl3/sOcc2I6AuFjdhtYsgC32ZHNGHtulj6f PNDg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=s9rSz7y2; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-63330-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-63330-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org X-Forwarded-Encrypted: i=2; AJvYcCXsp8kjCSB/9suLfbBlO+l4MXVozuPO8QqOpGTSBupPYauiQM0l2J1hJRoHhcUUUqIt82EhVZV5Gs2EaWf4HLFbyPNMjw== Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id im11-20020a056214246b00b0068c84216c8dsi2433115qvb.414.2024.02.13.02.18.16 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Feb 2024 02:18:16 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-63330-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=s9rSz7y2; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-63330-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-63330-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id E7A831C2153F for <ouuuleilei@gmail.com>; Tue, 13 Feb 2024 10:18:15 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6FB1523749; Tue, 13 Feb 2024 10:18:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="s9rSz7y2" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BC99C249E6; Tue, 13 Feb 2024 10:18:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707819481; cv=none; b=nfwvkJVn7of/ObW0E4MMO8CE2TJaNT7MWkgVpRD3/re8/WXlOhoVz79/EYb3bEQ28KosYRO+TV+YsSPKrAoVpUwfOSxcqvZg8gd0kZio4UIgRkY8gVOuI0/n9maDKhkv3BIUZni0eInNm/F6+2Z8c/OK6XDaDMSLtMU6UD8CXP0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707819481; c=relaxed/simple; bh=M0omCzupnR3eO9G0ZEKmTrZW1r/VLKkL8eLhQp9cwrA=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=gjbPMEdVoMh+Rf6d1VzDTJdFNIX9bT1JnEi8zM8v3pPCHLPVkvfUe2a4ZlZNW1dtflndEiq2SceufKCaZdgW0kEktBxyAsuK3MnUHUCzoki40gGksbfiuNVUcd6MDYoJwTI6MECGWAdfRVQLDYvXc9VJDoBcBA/S54L045e0uGE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=s9rSz7y2; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 311D5C433F1; Tue, 13 Feb 2024 10:17:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1707819481; bh=M0omCzupnR3eO9G0ZEKmTrZW1r/VLKkL8eLhQp9cwrA=; h=From:To:Cc:Subject:Date:From; b=s9rSz7y2uHJMnZhKr4qSW9mpG7iRl6rFaesUumx6kTwL75nBPio0n+kTi3qJv/DKP gNGyOl0ZlFS40+OiuZJuVQV18VucJadwMoEhCT8xe5gBgM1y8CHioDDwWwczTl02G7 DiJDA8DIUmNoelB2CJCau+WyZulEZK67E53aoxc+Wnfbc3TOjsjDoVG1UyoiAJPYJc Naqu3voXnhoBzjqKcUvajkwaOASC+Q0ljhyjtD19NregQBDzt6GyzkCgVjB4XK5DkP I9Z0+AvAv0g3JtOSu3ydnaCIY6C1beITu7hnuSMBApg08r46EuSu/Ye7oFNzdSg/mH KREKGIuYyWMZQ== From: Arnd Bergmann <arnd@kernel.org> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Jiri Slaby <jirislaby@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de>, Nathan Chancellor <nathan@kernel.org>, Nick Desaulniers <ndesaulniers@google.com>, Bill Wendling <morbo@google.com>, Justin Stitt <justinstitt@google.com>, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org, llvm@lists.linux.dev Subject: [PATCH] tty: hvc-iucv: fix function pointer casts Date: Tue, 13 Feb 2024 11:17:49 +0100 Message-Id: <20240213101756.461701-1-arnd@kernel.org> X-Mailer: git-send-email 2.39.2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790778536177441890 X-GMAIL-MSGID: 1790778536177441890 |
Series |
tty: hvc-iucv: fix function pointer casts
|
|
Commit Message
Arnd Bergmann
Feb. 13, 2024, 10:17 a.m. UTC
From: Arnd Bergmann <arnd@arndb.de> clang warns about explicitly casting between incompatible function pointers: drivers/tty/hvc/hvc_iucv.c:1100:23: error: cast from 'void (*)(const void *)' to 'void (*)(struct device *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict] 1100 | priv->dev->release = (void (*)(struct device *)) kfree; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Add a separate function to handle this correctly. Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- drivers/tty/hvc/hvc_iucv.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
Comments
On Tue, Feb 13, 2024 at 11:17:49AM +0100, Arnd Bergmann wrote: > clang warns about explicitly casting between incompatible function > pointers: > > drivers/tty/hvc/hvc_iucv.c:1100:23: error: cast from 'void (*)(const void *)' to 'void (*)(struct device *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict] > 1100 | priv->dev->release = (void (*)(struct device *)) kfree; > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Such a cast of course is explicitly allowed by 6.3.2.3/8, only calling a function using a non-compatible type is UB. This warning message is quite misleading. Doubly so because of the -Werror, as always. Your proposed new code of course is nice and simple (albeit a bit bigger than it was before, both source and binary). Such is life ;-) Segher
On 13. 02. 24, 11:17, Arnd Bergmann wrote: > From: Arnd Bergmann <arnd@arndb.de> > > clang warns about explicitly casting between incompatible function > pointers: > > drivers/tty/hvc/hvc_iucv.c:1100:23: error: cast from 'void (*)(const void *)' to 'void (*)(struct device *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict] > 1100 | priv->dev->release = (void (*)(struct device *)) kfree; > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Add a separate function to handle this correctly. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Jiri Slaby <jirislaby@kernel.org> > diff --git a/drivers/tty/hvc/hvc_iucv.c b/drivers/tty/hvc/hvc_iucv.c > index fdecc0d63731..b1149bc62ca1 100644 > --- a/drivers/tty/hvc/hvc_iucv.c > +++ b/drivers/tty/hvc/hvc_iucv.c > @@ -1035,6 +1035,10 @@ static const struct attribute_group *hvc_iucv_dev_attr_groups[] = { > NULL, > }; > > +static void hvc_iucv_free(struct device *data) > +{ > + kfree(data); > +} > > /** > * hvc_iucv_alloc() - Allocates a new struct hvc_iucv_private instance > @@ -1097,7 +1101,7 @@ static int __init hvc_iucv_alloc(int id, unsigned int is_console) > priv->dev->bus = &iucv_bus; > priv->dev->parent = iucv_root; > priv->dev->groups = hvc_iucv_dev_attr_groups; > - priv->dev->release = (void (*)(struct device *)) kfree; > + priv->dev->release = hvc_iucv_free; > rc = device_register(priv->dev); > if (rc) { > put_device(priv->dev);
From: Segher Boessenkool > Sent: 13 February 2024 19:13 > > On Tue, Feb 13, 2024 at 11:17:49AM +0100, Arnd Bergmann wrote: > > clang warns about explicitly casting between incompatible function > > pointers: > > > > drivers/tty/hvc/hvc_iucv.c:1100:23: error: cast from 'void (*)(const void *)' to 'void (*)(struct > device *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict] > > 1100 | priv->dev->release = (void (*)(struct device *)) kfree; > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Such a cast of course is explicitly allowed by 6.3.2.3/8, only calling a > function using a non-compatible type is UB. This warning message is > quite misleading. Doubly so because of the -Werror, as always. But it will get called using the wrong type. And (is it) fine-ibt will reject the incorrect call. Has clang/gcc added an attribute to 'seed' the ibt hash yet? So that functions that are void (*)(void) can be separated? David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
On Wed, Feb 14, 2024 at 09:46:33AM +0000, David Laight wrote: > From: Segher Boessenkool > > Sent: 13 February 2024 19:13 > > > > On Tue, Feb 13, 2024 at 11:17:49AM +0100, Arnd Bergmann wrote: > > > clang warns about explicitly casting between incompatible function > > > pointers: > > > > > > drivers/tty/hvc/hvc_iucv.c:1100:23: error: cast from 'void (*)(const void *)' to 'void (*)(struct > > device *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict] > > > 1100 | priv->dev->release = (void (*)(struct device *)) kfree; > > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > Such a cast of course is explicitly allowed by 6.3.2.3/8, only calling a > > function using a non-compatible type is UB. This warning message is > > quite misleading. Doubly so because of the -Werror, as always. > > But it will get called using the wrong type. > And (is it) fine-ibt will reject the incorrect call. And rightfully so, this type of casting abuse is just that, abuse. Almost no one should be just calling kfree() on a device pointer, I'll look at the surrounding code as odds are something odd is going on. But for now, this patch is correct. thanks, greg k-h
On Wed, Feb 14, 2024 at 11:37:21AM +0100, Greg Kroah-Hartman wrote: > On Wed, Feb 14, 2024 at 09:46:33AM +0000, David Laight wrote: > > From: Segher Boessenkool > > > Sent: 13 February 2024 19:13 > > > > > > On Tue, Feb 13, 2024 at 11:17:49AM +0100, Arnd Bergmann wrote: > > > > clang warns about explicitly casting between incompatible function > > > > pointers: > > > > > > > > drivers/tty/hvc/hvc_iucv.c:1100:23: error: cast from 'void (*)(const void *)' to 'void (*)(struct > > > device *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict] > > > > 1100 | priv->dev->release = (void (*)(struct device *)) kfree; > > > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > Such a cast of course is explicitly allowed by 6.3.2.3/8, only calling a > > > function using a non-compatible type is UB. This warning message is > > > quite misleading. Doubly so because of the -Werror, as always. > > > > But it will get called using the wrong type. > > And (is it) fine-ibt will reject the incorrect call. > > And rightfully so, this type of casting abuse is just that, abuse. > > Almost no one should be just calling kfree() on a device pointer, I'll > look at the surrounding code as odds are something odd is going on. But > for now, this patch is correct. Yes, and I said so. My point is that the warning message pretends the cast is bad or dangerous. It is not, similar casts are the only way in C to do certain things (yes, you can always avoid it completely, by writing completely different code, like the patch does, and that sometimes is a better idea even). But the warning message is misleading and does more damage than it helps avoid. Segher
diff --git a/drivers/tty/hvc/hvc_iucv.c b/drivers/tty/hvc/hvc_iucv.c index fdecc0d63731..b1149bc62ca1 100644 --- a/drivers/tty/hvc/hvc_iucv.c +++ b/drivers/tty/hvc/hvc_iucv.c @@ -1035,6 +1035,10 @@ static const struct attribute_group *hvc_iucv_dev_attr_groups[] = { NULL, }; +static void hvc_iucv_free(struct device *data) +{ + kfree(data); +} /** * hvc_iucv_alloc() - Allocates a new struct hvc_iucv_private instance @@ -1097,7 +1101,7 @@ static int __init hvc_iucv_alloc(int id, unsigned int is_console) priv->dev->bus = &iucv_bus; priv->dev->parent = iucv_root; priv->dev->groups = hvc_iucv_dev_attr_groups; - priv->dev->release = (void (*)(struct device *)) kfree; + priv->dev->release = hvc_iucv_free; rc = device_register(priv->dev); if (rc) { put_device(priv->dev);