All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: linux-kernel@vger.kernel.org, Bob Copeland <me@bobcopeland.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Alexios Zavras <alexios.zavras@intel.com>,
	John Hubbard <jhubbard@nvidia.com>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	linux-karma-devel@lists.sourceforge.net
Subject: [PATCH 11/15] omfs: avoid gcc-10 stringop-overflow warning
Date: Thu, 30 Apr 2020 23:30:53 +0200	[thread overview]
Message-ID: <20200430213101.135134-12-arnd@arndb.de> (raw)
In-Reply-To: <20200430213101.135134-1-arnd@arndb.de>

gcc-10 correctly points out a memcpy beyond the end of the structure
it gets copied into:

fs/omfs/file.c: In function 'omfs_grow_extent':
cc1: warning: writing 16 bytes into a region of size 0 [-Wstringop-overflow=]
In file included from fs/omfs/omfs.h:8,
                 from fs/omfs/file.c:11:
fs/omfs/omfs_fs.h:80:27: note: at offset 0 to object 'e_entry' with size 16 declared here
   80 |  struct omfs_extent_entry e_entry; /* start of extent entries */
      |                           ^~~~~~~

This is not a bug however, as the file system layout contains an array
of extent entries instead of just a single one that was part of the
structure definition.

Changing the definition to use a c99 flexible array member makes
makes the code match the actual layout, which avoids the warning and
an odd '+1' in the calculation of the number of extent entries.

Fixes: 8f09e98768c1 ("omfs: add file routines")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 fs/omfs/file.c    | 12 ++++++------
 fs/omfs/omfs_fs.h |  2 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/fs/omfs/file.c b/fs/omfs/file.c
index d7b5f09d298c..94344386c6ff 100644
--- a/fs/omfs/file.c
+++ b/fs/omfs/file.c
@@ -14,7 +14,7 @@ static u32 omfs_max_extents(struct omfs_sb_info *sbi, int offset)
 {
 	return (sbi->s_sys_blocksize - offset -
 		sizeof(struct omfs_extent)) /
-		sizeof(struct omfs_extent_entry) + 1;
+		sizeof(struct omfs_extent_entry);
 }
 
 void omfs_make_empty_table(struct buffer_head *bh, int offset)
@@ -24,8 +24,8 @@ void omfs_make_empty_table(struct buffer_head *bh, int offset)
 	oe->e_next = ~cpu_to_be64(0ULL);
 	oe->e_extent_count = cpu_to_be32(1),
 	oe->e_fill = cpu_to_be32(0x22),
-	oe->e_entry.e_cluster = ~cpu_to_be64(0ULL);
-	oe->e_entry.e_blocks = ~cpu_to_be64(0ULL);
+	oe->e_entry[0].e_cluster = ~cpu_to_be64(0ULL);
+	oe->e_entry[0].e_blocks = ~cpu_to_be64(0ULL);
 }
 
 int omfs_shrink_inode(struct inode *inode)
@@ -68,7 +68,7 @@ int omfs_shrink_inode(struct inode *inode)
 
 		last = next;
 		next = be64_to_cpu(oe->e_next);
-		entry = &oe->e_entry;
+		entry = oe->e_entry;
 
 		/* ignore last entry as it is the terminator */
 		for (; extent_count > 1; extent_count--) {
@@ -117,7 +117,7 @@ static int omfs_grow_extent(struct inode *inode, struct omfs_extent *oe,
 			u64 *ret_block)
 {
 	struct omfs_extent_entry *terminator;
-	struct omfs_extent_entry *entry = &oe->e_entry;
+	struct omfs_extent_entry *entry = oe->e_entry;
 	struct omfs_sb_info *sbi = OMFS_SB(inode->i_sb);
 	u32 extent_count = be32_to_cpu(oe->e_extent_count);
 	u64 new_block = 0;
@@ -245,7 +245,7 @@ static int omfs_get_block(struct inode *inode, sector_t block,
 
 		extent_count = be32_to_cpu(oe->e_extent_count);
 		next = be64_to_cpu(oe->e_next);
-		entry = &oe->e_entry;
+		entry = oe->e_entry;
 
 		if (extent_count > max_extents)
 			goto out_brelse;
diff --git a/fs/omfs/omfs_fs.h b/fs/omfs/omfs_fs.h
index caecb3d5a344..1ff6b9e41297 100644
--- a/fs/omfs/omfs_fs.h
+++ b/fs/omfs/omfs_fs.h
@@ -77,7 +77,7 @@ struct omfs_extent {
 	__be64 e_next;			/* next extent table location */
 	__be32 e_extent_count;		/* total # extents in this table */
 	__be32 e_fill;
-	struct omfs_extent_entry e_entry;	/* start of extent entries */
+	struct omfs_extent_entry e_entry[];	/* start of extent entries */
 };
 
 #endif
-- 
2.26.0


  parent reply	other threads:[~2020-04-30 21:33 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-30 21:30 [PATCH 00/15] gcc-10 warning fixes Arnd Bergmann
2020-04-30 21:30 ` Arnd Bergmann
2020-04-30 21:30 ` Arnd Bergmann
2020-04-30 21:30 ` [PATCH 01/15] crypto - Avoid free() namespace collision Arnd Bergmann
2020-05-08  6:06   ` Herbert Xu
2020-04-30 21:30 ` [PATCH 02/15] iwlwifi: mvm: fix gcc-10 zero-length-bounds warning Arnd Bergmann
2020-06-10 12:18   ` Luciano Coelho
2020-04-30 21:30 ` [PATCH 03/15] mwifiex: avoid -Wstringop-overflow warning Arnd Bergmann
2020-05-06  8:43   ` Kalle Valo
2020-04-30 21:30 ` [PATCH 04/15] ath10k: fix gcc-10 zero-length-bounds warnings Arnd Bergmann
2020-04-30 21:30   ` Arnd Bergmann
2020-04-30 21:45   ` Gustavo A. R. Silva
2020-04-30 21:45     ` Gustavo A. R. Silva
2020-04-30 21:44     ` Arnd Bergmann
2020-04-30 21:44       ` Arnd Bergmann
2020-05-04 11:54     ` Kalle Valo
2020-05-04 11:54       ` Kalle Valo
2020-05-04 16:09       ` Gustavo A. R. Silva
2020-05-04 16:09         ` Gustavo A. R. Silva
2020-05-05  4:56         ` Kalle Valo
2020-05-05  4:56           ` Kalle Valo
2020-04-30 21:30 ` [PATCH 05/15] bpf: avoid gcc-10 stringop-overflow warning Arnd Bergmann
2020-05-04 21:06   ` Daniel Borkmann
2020-04-30 21:30 ` [PATCH 06/15] netfilter: conntrack: avoid gcc-10 zero-length-bounds warning Arnd Bergmann
2020-05-10 21:48   ` Pablo Neira Ayuso
2020-04-30 21:30 ` [PATCH 07/15] drop_monitor: work around gcc-10 stringop-overflow warning Arnd Bergmann
2020-05-01 11:28   ` Neil Horman
2020-04-30 21:30 ` [PATCH 08/15] usb: ehci: avoid gcc-10 zero-length-bounds warning Arnd Bergmann
2020-05-01  2:42   ` Alan Stern
2020-05-01 20:06     ` Arnd Bergmann
2020-05-01 20:10       ` Alan Stern
2020-04-30 21:30 ` [PATCH 09/15] udf: avoid gcc-10 zero-length-bounds warnings Arnd Bergmann
2020-04-30 21:54   ` Pali Rohár
2020-05-01 20:30     ` Arnd Bergmann
2020-05-01 20:48       ` Jan Kara
2020-05-01 20:57       ` Pali Rohár
2020-04-30 21:30 ` [PATCH 10/15] hpfs: avoid gcc-10 zero-length-bounds warning Arnd Bergmann
2020-04-30 21:30 ` Arnd Bergmann [this message]
2020-04-30 21:30 ` [PATCH 12/15] media: s5k5baf: " Arnd Bergmann
2020-04-30 21:46   ` Gustavo A. R. Silva
2020-04-30 21:30 ` [PATCH 13/15] scsi: sas: " Arnd Bergmann
2020-05-01  7:47   ` John Garry
2020-05-01  7:54     ` Arnd Bergmann
2020-05-01 14:53       ` James Bottomley
2020-05-01 17:36         ` Arnd Bergmann
2020-04-30 21:30 ` [PATCH 14/15] isci: " Arnd Bergmann
2020-04-30 21:30 ` [PATCH 15/15] nvme: " Arnd Bergmann
2020-04-30 21:30   ` Arnd Bergmann
2020-05-01  7:32   ` Christoph Hellwig
2020-05-01  7:32     ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200430213101.135134-12-arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=akpm@linux-foundation.org \
    --cc=alexios.zavras@intel.com \
    --cc=jhubbard@nvidia.com \
    --cc=linux-karma-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=me@bobcopeland.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.