| Message ID | ZLGodUeD307GlINN@work (mailing list archive) |
|---|---|
| State | Mainlined |
| Commit | 4d8cbf6dbcdaebe949461b0a933ae4c71cb53edc |
| Headers | show |
| Series | [next] fs: omfs: Use flexible-array member in struct omfs_extent | expand |
On Fri, Jul 14, 2023 at 01:56:37PM -0600, Gustavo A. R. Silva wrote: > There are some binary differences before and after changes, but this are > expected due to the change in the size of 'struct omfs_extent' and the > necessary adjusments. For binary changes, I think commit logs should have more details. In this case, I can figure it out: > diff --git a/fs/omfs/file.c b/fs/omfs/file.c > index de8f57ee39ec..6b580b9da8e3 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); > } I think the original calculation meant to do: return (sbi->s_sys_blocksize - offset - (sizeof(struct omfs_extent) - sizeof(struct omfs_extent_entry))) / sizeof(struct omfs_extent_entry); So this binary difference looks correct. I rebuilt before/after this patch with omfs_max_extents() marked as noinline, and all the binary changes were isolated here, and did exactly as expected: the first half is 16 smaller (size of struct omfs_extent_entry), and the final +1 is removed: - 2e1: lea -0x20(%rbx),%rax + 2e1: lea -0x10(%rbx),%rax 2e5: pop %rbx 2e6: pop %rbp 2e7: shr $0x4,%rax - 2eb: add $0x1,%eax So this looks correct to me. Thanks! Reviewed-by: Kees Cook <keescook@chromium.org>
On Mon, Jul 17, 2023 at 08:20:22AM -0700, Kees Cook wrote: > > @@ -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); > > } > > I think the original calculation meant to do: > > return (sbi->s_sys_blocksize - offset - > (sizeof(struct omfs_extent) - sizeof(struct omfs_extent_entry))) / > sizeof(struct omfs_extent_entry); I can confirm the intent. I also went back and looked at the usages just to be sure. In this case, there are two possible values for x = s_sys_blocksize - offset: 7728 or 8128, and both can be divided by 16 evenly so you have either: f_old = (x - 32) / 16 + 1 or: f_new = (x - 16) / 16 they both simplify to x/16 - 1 so they are equivalent for these inputs.
diff --git a/fs/omfs/file.c b/fs/omfs/file.c index de8f57ee39ec..6b580b9da8e3 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
Memory for 'struct omfs_extent' and a 'e_extent_count' number of extent entries is indirectly allocated through 'bh->b_data', which is a pointer to data within the page. This implies that the member 'e_entry' (which is the start of extent entries) functions more like an array than a single object of type 'struct omfs_extent_entry'. So we better turn this object into a proper array, in this case a flexible-array member, and with that, fix the following -Wstringop-overflow warning seen after building s390 architecture with allyesconfig (GCC 13): fs/omfs/file.c: In function 'omfs_grow_extent': include/linux/fortify-string.h:57:33: warning: writing 16 bytes into a region of size 0 [-Wstringop-overflow=] 57 | #define __underlying_memcpy __builtin_memcpy | ^ include/linux/fortify-string.h:648:9: note: in expansion of macro '__underlying_memcpy' 648 | __underlying_##op(p, q, __fortify_size); \ | ^~~~~~~~~~~~~ include/linux/fortify-string.h:693:26: note: in expansion of macro '__fortify_memcpy_chk' 693 | #define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \ | ^~~~~~~~~~~~~~~~~~~~ fs/omfs/file.c:170:9: note: in expansion of macro 'memcpy' 170 | memcpy(terminator, entry, sizeof(struct omfs_extent_entry)); | ^~~~~~ In file included from fs/omfs/omfs.h:8, from fs/omfs/file.c:11: fs/omfs/omfs_fs.h:80:34: note: at offset 16 into destination object 'e_entry' of size 16 80 | struct omfs_extent_entry e_entry; /* start of extent entries */ | ^~~~~~~ There are some binary differences before and after changes, but this are expected due to the change in the size of 'struct omfs_extent' and the necessary adjusments. This helps with the ongoing efforts to globally enable -Wstringop-overflow. Link: https://github.com/KSPP/linux/issues/330 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> --- fs/omfs/file.c | 12 ++++++------ fs/omfs/omfs_fs.h | 2 +- 2 files changed, 7 insertions(+), 7 deletions(-)