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
next prev parent reply other threads:[~2020-04-30 21:33 UTC|newest]
Thread overview: 40+ 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 ` [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:45 ` Gustavo A. R. Silva
2020-04-30 21:44 ` Arnd Bergmann
2020-05-04 11:54 ` Kalle Valo
2020-05-04 16:09 ` Gustavo A. R. Silva
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-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®