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;
Date:   Thu, 15 Sep 2022 12:09:21 +0300
From:   Dan Carpenter <dan.carpenter@oracle.com>
To:     Arnd Bergmann <arnd@arndb.de>
Cc:     Nathan Huckleberry <nhuck@google.com>, nathan@kernel.org,
        error27@gmail.com, Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-kernel@vger.kernel.org, linux-staging@lists.linux.dev,
        llvm@lists.linux.dev, Nick Desaulniers <ndesaulniers@google.com>,
        trix@redhat.com
Subject: Re: [PATCH v3] staging: octeon: Fix return type of cvm_oct_xmit and
 cvm_oct_xmit_pow
Message-ID: <YyLrwW0qHpgxq4MK@kadam>
References: <YyEQr//Iq7bautrm@dev-arch.thelio-3990X>
 <20220914211057.423617-1-nhuck@google.com>
 <b66ea89d-c62e-4772-b3d7-6e236da837af@www.fastmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b66ea89d-c62e-4772-b3d7-6e236da837af@www.fastmail.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?isSVGDepO2me1Dyt2m+NsY8eG7Epith/oCPXKbmlSWzTl+Jh0veQGcX+GI1S?=
 =?us-ascii?Q?3LH+KUVnHqX3oE0QB8D2xhkmSlkpL6mIP/17TA0zavEHKXTVTkGqkaU2YLec?=
 =?us-ascii?Q?SkTUl5TdHXqPsaaGr788IqpuaY98TMsIL2eb9Y7u4Ie+jAqBGIDPhemVHf8H?=
 =?us-ascii?Q?GzfiiS7HlZlkqjhYrZuQCFbnkA0+PhihWXOQgqtfVoz1U1Eki+IScrqqZ2mQ?=
 =?us-ascii?Q?6wQZi0YXu/HL3gS+SdU+ILWt79qGFvJE4RIUpwMbOOqxu1w2VHXej+J8zi79?=
 =?us-ascii?Q?sH200EPRx52mJDBr5bS9kfvdD2ngvNtWdoAcClGdpcR0SY1Wu2KJGLWoVgWF?=
 =?us-ascii?Q?Ads9NQg34rbHpnYy90FNq1qkX6QgBc6gyQ//hPZoX+rNTaVAO1Vr2EByUhvn?=
 =?us-ascii?Q?a09LZ+3kZbq97FUGmsYFOIFto2LR1OpqbWYHDby8wLXphXR3SCusQJMpbnxl?=
 =?us-ascii?Q?xsEpe1uxm8DklK0sEkB2VhwLIS0AaX+0J8OhEzBjWw6FpaMsXaVlPNwqyx2W?=
 =?us-ascii?Q?542h5/pESv34OlzqGdGZhUz7mKZKM4hWXqJzNCgX5qR+Y4QNrGKOlaDHawgr?=
 =?us-ascii?Q?mHWSeQ82xwOL6q7unP/4Y/545Sv5V0TAGCG9hd+OQTrZ2C3aGYMIMWVXQjxi?=
 =?us-ascii?Q?BxiWPC0IA9mzJblywotgB13a02YPB/RHljkZJwN2v0eFXodw9PEEdOXs9EGN?=
 =?us-ascii?Q?cUnRzzuGuLMg6jo+Hy6N4Q7DP7440iuIvVCFWzpgdtLCyRF0EOfnwc9cojZI?=
 =?us-ascii?Q?uqgDtT2OA0bCRgacczZnNrBM83qj5rpHOH1JKm6ux/KUsQPQIU0qpwEjee4/?=
 =?us-ascii?Q?rzsaVboa1MmFI0lvFLkBQa0laG5K1zFHzzVs0ekbKnZv92uJqjnCyg7imfsK?=
 =?us-ascii?Q?Br+l/O/dU8ZRzP09ak8ANue2YkQl5Ch5nqrHhRSY1Xzt6we0RDN0U86o07tH?=
 =?us-ascii?Q?1ThHWBzQiwZ0R/mPXHa0PsOUgPqTwe2zvDy4kgQd6NlXuOy7T+ODWe/PHTkP?=
 =?us-ascii?Q?e65N890rzsVcpz7k9p8QihHWDF3Y7Ibh327H5hzcObkPH2bpPG5w9wNVOzd9?=
 =?us-ascii?Q?kmzp+j1/ZiYjQD+wEBGbEzZ0xtSkkvP2WxsyljkE4c8JHQAduzwWS7UYAgyH?=
 =?us-ascii?Q?GsyIAGKEN8RsPrm1OGFRas3SJ8XhrviCp14fFa1GYFksPpHQ2/s2aMhV560t?=
 =?us-ascii?Q?EuMAQKGR3JTSrYuu1YZFvmvy4U0D3yt0Iq4dcOcNzSysH1NnOkC0DREGJnkE?=
 =?us-ascii?Q?sMcCeMryoj7LDzfY/UXT11zbmIXMEdRCYF1wXiMkgxO2oN7BE2hvVSY1xig9?=
 =?us-ascii?Q?LNoILf6R04IgvTFn929GaGcd7rNVAM6MKIWg/7+KRWC+d3kBdyOYkxpCTzTl?=
 =?us-ascii?Q?694YlbVY8/cU+8CPExSf4G+/3qptPhRc9j2yxPQKS+lGIDTr/FcMbyOVsizw?=
 =?us-ascii?Q?wWGQymJDMftylt7qZmFoigwGxwa/fYZChgJW5jy2Gl125x5YupXLQJxHh7xr?=
 =?us-ascii?Q?njmZTAkYafsB0La3IL6dM/rtH1oBBZXq1aiKeTJ3SyYhzXY0gzo2KbXtJO+8?=
 =?us-ascii?Q?fkkRHM9GDyHUVQ0lwfQgYg15+PR4ILYCMqwcLsAJtnfU+KModIRHsKDLFoMV?=
 =?us-ascii?Q?Ng=3D=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 62e9d467-a427-4130-781f-08da96fa0409
X-MS-Exchange-CrossTenant-AuthSource: MWHPR1001MB2365.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2022 09:09:38.5690
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: r0XybRdipiE0jpBewcGyQHoyaZux7w/nEqz+0mfIUCVMvmCyuHXGgNGUshgttulEqrWZiqUHaRvg5CEkaKjn24fAYN7wv5X5JzHw5o19eSw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR10MB5661
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1
 definitions=2022-09-15_04,2022-09-14_04,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 adultscore=0
 malwarescore=0 spamscore=0 bulkscore=0 mlxscore=0 mlxlogscore=999
 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2208220000 definitions=main-2209150050
X-Proofpoint-ORIG-GUID: 81MaRgJtbO6499EpVp0Ar0cCtb8ggz54
X-Proofpoint-GUID: 81MaRgJtbO6499EpVp0Ar0cCtb8ggz54
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,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-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Sep 15, 2022 at 10:21:47AM +0200, Arnd Bergmann wrote:
> On Wed, Sep 14, 2022, at 11:10 PM, Nathan Huckleberry wrote:
> > The ndo_start_xmit field in net_device_ops is expected to be of type
> > netdev_tx_t (*ndo_start_xmit)(struct sk_buff *skb, struct net_device *dev).
> >
> > The mismatched return type breaks forward edge kCFI since the underlying
> > function definition does not match the function hook definition.
> >
> > The return type of cvm_oct_xmit and cvm_oct_xmit_pow should be changed
> > from int to netdev_tx_t.
> >
> > Reported-by: Dan Carpenter <error27@gmail.com>
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1703
> > Cc: llvm@lists.linux.dev
> > Signed-off-by: Nathan Huckleberry <nhuck@google.com>
> > Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> >
> > ---
> >
> > Changes v1 -> v2:
> > - Update function signatures in ethernet-tx.h.
> >
> > Changes v2 -> v3:
> > - Move changes below the scissors --- so they don't show in commit msg
> > - Add reviewed-by tag
> 
> The patch looks correct to me so
> 
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> 
> but I have two more general comments:
> 
> - For your changelogs, it would help to include the diagnostic message
>   from smatch that you link to.
> 
> - This has probably been discussed before, but why is this only
>   reported by smatch but by clang itself when building with CFI
>   enabled? It appears that CFI enforces stricter C++ style type
>   compatibility on enums while the warnings only catch incompatible
>   types according to the normal C11 rules.

This is not in a released version of Smatch.  I wrote the check and
attached it to the email with the bug reports but I wasn't really sure
how enums are handled in Clang. It's a gray area in the C standard.

I'll release it now since no one complained about false positives, but
yes, ideally this would be built into the compiler.

GCC does some sort of surprising things with enums and the kernel relies
on it in various places.  By default enums in GCC are unsigned int.  If
they have to store values which don't fit into unsigned int (negatives
or larger than UINT_MAX) type is adjusted to be signed or a larger type.

Also if the enum is in a struct and the type can be made smaller then
GCC will.  And example of this is in union myrs_cmd_mbox where the
enum myrs_cmd_opcode opcode only takes one byte. The SCSI_MYRB driver
relies on the struct thing and will corrupt memory if the struct is
larger than expected.  This is the only example I know of in the kernel
where this matters.

Sparse and thus Smatch default to unsigned int as well, but they won't
make the enum smaller for a struct.  There are some implications of
such as can an enum be less than zero?  If no then there is a potential
for if (err < 0) being a bug, and if yes then there is a potential for
array underflows

regards,
dan carpenter