Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp2149428pxb; Mon, 20 Sep 2021 13:35:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzMip0K+uEPnNkMYv87rbc9v7a7r5zquODZDlXAsR3wxr6BuGVuSBOY3gZNS2qqMthidoE6 X-Received: by 2002:a5d:88d7:: with SMTP id i23mr118643iol.38.1632170132137; Mon, 20 Sep 2021 13:35:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632170132; cv=none; d=google.com; s=arc-20160816; b=rqPWeNjzZKz9hW9IvyIFzGnl839mmL+4zU2nmoyM+1m1fSXGrU/X87FuiZ42yzeoKl N+G28sMZAu8CBkaBxRQdCm+KIWbyQUrWrXPPTKSnMR2vrmZTqxVpQ/swnY1VgDD8idGy OyucHfQR8pxw9M6YqvKK4OnsoFD4Mf/mZ8P9QHdMfcz+DUyTiloZNlEGo+ZWl7I0kobC jbhCVCDYrvugIN3uVDpR2pIfWLAdFO4GYcDZB6qlQ6Y5Vy7lbYBf5zsugvUCoSeYMK0S khGrBK8JDfGvn0BG7jiI4f5M9OdF4ILeL7UDq6HPayGVQXeIaRRkqiR2j25BsrGMiS8f 99Ww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=IROGqsmaJtEx6i7e7+cyEDq3klWzmgRV7d6+fNHyavk=; b=chL90RWI/BNMrFualPFmj6DNhFacaJ+vDt3GMqlQk4fY/7fRxDDG+CdJWXA+jSoFcF 91dN2ODR5o1qDdbziS/Dl+jVxq+VMc4CT324giK+8rIeP89el7dRLo7GtmV2aAj4MqBy eaWx1mJG86qcScyTyCiqGJNOdHOWHytiu/ixW6Ffw3npb8tPcXdreo3X6MHIU+L38yZh qyt7pVcw69gor8fv4RhLU9jKmIxJGLRz0hU8Kevye+R0NtymhHLg4BQFXM7QepGq/Msa wH9j66GzAPkv41jO11PJvEnebcKW182m7CijFmVlwx/k+AHvYgVla6ff1KNdFGJoKt1k u7sg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ehs0nfWl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f22si15148474jam.69.2021.09.20.13.35.18; Mon, 20 Sep 2021 13:35:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ehs0nfWl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237514AbhITMNq (ORCPT + 99 others); Mon, 20 Sep 2021 08:13:46 -0400 Received: from mail.kernel.org ([198.145.29.99]:44014 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231792AbhITMNp (ORCPT ); Mon, 20 Sep 2021 08:13:45 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id DECA760F50; Mon, 20 Sep 2021 12:12:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1632139938; bh=nzt73uefio2OAcopLpAYc2RbWIrjwpkcYn0/qlrcaSo=; h=From:To:Cc:Subject:Date:From; b=ehs0nfWlz0oj+qxGtys9lkGUkwM3BEQyE1w6kGkIrlk0RyNext5oQyQoNle05MfVh jTVNMsstJXCC9IEY9fNHRp+gmmNcR4t0mz+ThBwbarp0i9rjqnVO2JivQwbyYnhar4 SQI9HMVGH3w9fBpgtdIRKLAhy6F9zEkSMDO5659D/yIXPkKo7uUQN4IFH1z4fK4zgK Nzpr2ebuA+ikUUn6zWcoRNPnc4wl2jPcqVNYlbyLPW8y5PscuQSL5WdAapqNBz1ygl 62nVvBctdviNE205UejVk0HU1vs30O4PH8EAhGsOB0kr8nNLnykBfUUo1HS+otJSUl ml1ZYCJsEpvFA== From: Arnd Bergmann To: Anders Larsen Cc: Linus Torvalds , Arnd Bergmann , linux-kernel@vger.kernel.org Subject: [PATCH] [RFC v2] qnx: avoid -Wstringop-overread warning, again Date: Mon, 20 Sep 2021 14:12:02 +0200 Message-Id: <20210920121208.54732-1-arnd@kernel.org> X-Mailer: git-send-email 2.29.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Arnd Bergmann There is still a gcc-11 warning about stringop-overread in some configurations, despite the earlier fix that was meant to address this issue: fs/qnx4/dir.c: In function 'qnx4_readdir': fs/qnx4/dir.c:76:32: error: 'strnlen' specified bound [16, 48] exceeds source size 1 [-Werror=stringop-overread] 76 | size = strnlen(name, size); | ^~~~~~~~~~~~~~~~~~~ fs/qnx4/dir.c:26:22: note: source object declared here 26 | char de_name; | ^~~~~~~ The problem here is that we access the same pointer using two different structure layouts, but gcc determines the object size based on whatever it encounters first, in this case, the single-byte field. Rework the union once more, to have a flexible-array member as the thing that gets accessed first to deal with current gcc versions, but leave everything else in place so that a future fixed compiler will correctly see the struct member sizes. Unfortunately, this makes the code really ugly again. In my original patch, I just changed the if (!de->de_name) check to access the longer of the two fields, which worked. Another option would be to make de_name a longer array. Fixes: b7213ffa0e58 ("qnx4: avoid stringop-overread errors") Link: https://lore.kernel.org/all/20210322160253.4032422-6-arnd@kernel.org/ Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 Signed-off-by: Arnd Bergmann --- v2: rebase on top of the earlier patch. --- fs/qnx4/dir.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/fs/qnx4/dir.c b/fs/qnx4/dir.c index 2a66844b7ff8..d7eb5a9b79e4 100644 --- a/fs/qnx4/dir.c +++ b/fs/qnx4/dir.c @@ -23,8 +23,16 @@ */ union qnx4_directory_entry { struct { - char de_name; - char de_pad[62]; + /* + * work around gcc-11.x using the first field it observes + * to determing the actual length + * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 + */ + char __empty[0]; + char de_name[]; + }; + struct { + char de_pad[63]; char de_status; }; struct qnx4_inode_entry inode; @@ -58,7 +66,7 @@ static int qnx4_readdir(struct file *file, struct dir_context *ctx) offset = ix * QNX4_DIR_ENTRY_SIZE; de = (union qnx4_directory_entry *) (bh->b_data + offset); - if (!de->de_name) + if (!de->de_name[0]) continue; if (!(de->de_status & (QNX4_FILE_USED|QNX4_FILE_LINK))) continue; -- 2.29.2