From: "Kiselev, Oleg" <okiselev@amazon.com>
To: Jan Kara <jack@suse.cz>
Cc: "linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
Theodore Ts'o <tytso@mit.edu>
Subject: Re: [PATCH 1/2] ext4: reduce computation of overhead during resize
Date: Fri, 15 Jul 2022 23:52:32 +0000 [thread overview]
Message-ID: <23CB6B29-F40D-4359-B7E3-85515217D45B@amazon.com> (raw)
In-Reply-To: <20220715092736.oa2tfcgh5a6dcpnf@quack3>
> On Jul 15, 2022, at 2:27 AM, Jan Kara <jack@suse.cz> wrote:
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On Thu 14-07-22 19:53:38, Kiselev, Oleg wrote:
>>>
>>>> + sbi->s_overhead += overhead;
>>>> + es->s_overhead_clusters = cpu_to_le32((unsigned long) sbi->s_overhead);
>>> ^^^ the typecast looks
>>> bogus here...
>>
>> This cast is the reverse of le32_to_cpu() cast done in fs/ext4/super.c:__ext4_fill_super():
>> sbi->s_overhead = le32_to_cpu(es->s_overhead_clusters);
>> And follows the logic of casting done in fs/ext4/ioctl.c:set_overhead() and fs/ext4/ioctl.c:ext4_update_overhead().
>
> I didn't mean the cpu_to_le32() call but rather the (unsigned long) part.
> That is pointless because sbi->s_overhead is already 'unsigned long' and
> even if it was not, I have hard time seeing a reason why would casting to
> unsigned long make any difference here.
Got it. You are right. The indent of your comment got mangled by mail, so it looked like it was directed to cpu_to_ie32()!
>
> Honza
> --
> Jan Kara <jack@suse.com>
> SUSE Labs, CR
prev parent reply other threads:[~2022-07-15 23:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-30 2:17 [PATCH 1/2] ext4: reduce computation of overhead during resize Kiselev, Oleg
2022-07-14 13:46 ` Jan Kara
2022-07-14 19:53 ` Kiselev, Oleg
2022-07-15 9:27 ` Jan Kara
2022-07-15 23:52 ` Kiselev, Oleg [this message]
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=23CB6B29-F40D-4359-B7E3-85515217D45B@amazon.com \
--to=okiselev@amazon.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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