From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Qiuyang Sun <sunqiuyang@huawei.com>,
Jaegeuk Kim <jaegeuk@kernel.org>, Chao Yu <yuchao0@huawei.com>
Cc: linux-next@vger.kernel.org,
Geert Uytterhoeven <geert@linux-m68k.org>,
linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net
Subject: [f2fs-dev] [PATCH -next] f2fs: Use div_u64*() for 64-bit divisions
Date: Thu, 20 Jun 2019 16:38:00 +0200 [thread overview]
Message-ID: <20190620143800.20640-1-geert@linux-m68k.org> (raw)
On 32-bit (e.g. m68k):
fs/f2fs/gc.o: In function `f2fs_resize_fs':
gc.c:(.text+0x3056): undefined reference to `__umoddi3'
gc.c:(.text+0x30c4): undefined reference to `__udivdi3'
Fix this by using div_u64_rem() and div_u64() for 64-by-32 modulo resp.
division operations.
Reported-by: noreply@ellerman.id.au
Fixes: d2ae7494d043bfaf ("f2fs: ioctl for removing a range from F2FS")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
This assumes BLKS_PER_SEC(sbi) is 32-bit.
#define BLKS_PER_SEC(sbi) \
((sbi)->segs_per_sec * (sbi)->blocks_per_seg)
Notes:
1. f2fs_sb_info.segs_per_sec and f2fs_sb_info.blocks_per_seg are both
unsigned int,
2. The multiplication is done in 32-bit arithmetic, hence the result
is of type unsigned int.
3. Is it guaranteed that the result will always fit in 32-bit, or can
this overflow?
4. fs/f2fs/debug.c:update_sit_info() assigns BLKS_PER_SEC(sbi) to
unsigned long long blks_per_sec, anticipating a 64-bit value.
---
fs/f2fs/gc.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 5b1076505ade9f84..c65f87f11de029f4 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -1438,13 +1438,15 @@ int f2fs_resize_fs(struct f2fs_sb_info *sbi, __u64 block_count)
unsigned int secs;
int gc_mode, gc_type;
int err = 0;
+ __u32 rem;
old_block_count = le64_to_cpu(F2FS_RAW_SUPER(sbi)->block_count);
if (block_count > old_block_count)
return -EINVAL;
/* new fs size should align to section size */
- if (block_count % BLKS_PER_SEC(sbi))
+ div_u64_rem(block_count, BLKS_PER_SEC(sbi), &rem);
+ if (rem)
return -EINVAL;
if (block_count == old_block_count)
@@ -1463,7 +1465,7 @@ int f2fs_resize_fs(struct f2fs_sb_info *sbi, __u64 block_count)
freeze_bdev(sbi->sb->s_bdev);
shrunk_blocks = old_block_count - block_count;
- secs = shrunk_blocks / BLKS_PER_SEC(sbi);
+ secs = div_u64(shrunk_blocks, BLKS_PER_SEC(sbi));
spin_lock(&sbi->stat_lock);
if (shrunk_blocks + valid_user_blocks(sbi) +
sbi->current_reserved_blocks + sbi->unusable_block_count +
--
2.17.1
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Qiuyang Sun <sunqiuyang@huawei.com>,
Jaegeuk Kim <jaegeuk@kernel.org>, Chao Yu <yuchao0@huawei.com>
Cc: linux-f2fs-devel@lists.sourceforge.net,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Geert Uytterhoeven <geert@linux-m68k.org>
Subject: [PATCH -next] f2fs: Use div_u64*() for 64-bit divisions
Date: Thu, 20 Jun 2019 16:38:00 +0200 [thread overview]
Message-ID: <20190620143800.20640-1-geert@linux-m68k.org> (raw)
On 32-bit (e.g. m68k):
fs/f2fs/gc.o: In function `f2fs_resize_fs':
gc.c:(.text+0x3056): undefined reference to `__umoddi3'
gc.c:(.text+0x30c4): undefined reference to `__udivdi3'
Fix this by using div_u64_rem() and div_u64() for 64-by-32 modulo resp.
division operations.
Reported-by: noreply@ellerman.id.au
Fixes: d2ae7494d043bfaf ("f2fs: ioctl for removing a range from F2FS")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
This assumes BLKS_PER_SEC(sbi) is 32-bit.
#define BLKS_PER_SEC(sbi) \
((sbi)->segs_per_sec * (sbi)->blocks_per_seg)
Notes:
1. f2fs_sb_info.segs_per_sec and f2fs_sb_info.blocks_per_seg are both
unsigned int,
2. The multiplication is done in 32-bit arithmetic, hence the result
is of type unsigned int.
3. Is it guaranteed that the result will always fit in 32-bit, or can
this overflow?
4. fs/f2fs/debug.c:update_sit_info() assigns BLKS_PER_SEC(sbi) to
unsigned long long blks_per_sec, anticipating a 64-bit value.
---
fs/f2fs/gc.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 5b1076505ade9f84..c65f87f11de029f4 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -1438,13 +1438,15 @@ int f2fs_resize_fs(struct f2fs_sb_info *sbi, __u64 block_count)
unsigned int secs;
int gc_mode, gc_type;
int err = 0;
+ __u32 rem;
old_block_count = le64_to_cpu(F2FS_RAW_SUPER(sbi)->block_count);
if (block_count > old_block_count)
return -EINVAL;
/* new fs size should align to section size */
- if (block_count % BLKS_PER_SEC(sbi))
+ div_u64_rem(block_count, BLKS_PER_SEC(sbi), &rem);
+ if (rem)
return -EINVAL;
if (block_count == old_block_count)
@@ -1463,7 +1465,7 @@ int f2fs_resize_fs(struct f2fs_sb_info *sbi, __u64 block_count)
freeze_bdev(sbi->sb->s_bdev);
shrunk_blocks = old_block_count - block_count;
- secs = shrunk_blocks / BLKS_PER_SEC(sbi);
+ secs = div_u64(shrunk_blocks, BLKS_PER_SEC(sbi));
spin_lock(&sbi->stat_lock);
if (shrunk_blocks + valid_user_blocks(sbi) +
sbi->current_reserved_blocks + sbi->unusable_block_count +
--
2.17.1
next reply other threads:[~2019-06-20 14:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-20 14:38 Geert Uytterhoeven [this message]
2019-06-20 14:38 ` [PATCH -next] f2fs: Use div_u64*() for 64-bit divisions Geert Uytterhoeven
2019-06-21 9:54 ` [f2fs-dev] " Chao Yu
2019-06-21 9:54 ` Chao Yu
2019-06-21 9:55 ` [f2fs-dev] " Geert Uytterhoeven
2019-06-21 9:55 ` Geert Uytterhoeven
2019-06-21 18:02 ` [f2fs-dev] " Jaegeuk Kim
2019-06-21 18:02 ` Jaegeuk Kim
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=20190620143800.20640-1-geert@linux-m68k.org \
--to=geert@linux-m68k.org \
--cc=jaegeuk@kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=sunqiuyang@huawei.com \
--cc=yuchao0@huawei.com \
/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.