From: "Arnd Bergmann" <arnd@arndb.de>
To: "Zhiguo Niu" <niuzhiguo84@gmail.com>
Cc: "kernel test robot" <lkp@intel.com>,
"zhiguo.niu" <zhiguo.niu@unisoc.com>,
jaegeuk@kernel.org, chao@kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, llvm@lists.linux.dev,
oe-kbuild-all@lists.linux.dev
Subject: Re: [PATCH V2] f2fs: fix atgc bug on issue in 32bits platform
Date: Thu, 10 Nov 2022 14:45:31 +0100 [thread overview]
Message-ID: <97c529f2-c5a2-4ed6-89eb-c79f020e9d0c@app.fastmail.com> (raw)
In-Reply-To: <CAHJ8P3+g7dr3PBZFQCD5HQLZ2b0WHe=b6Jt7ha1o7mqZJ7_-BQ@mail.gmail.com>
On Thu, Nov 10, 2022, at 11:20, Zhiguo Niu wrote:
> Arnd Bergmann <arnd@arndb.de> 于2022年11月10日周四 17:07写道:
>> On Thu, Nov 10, 2022, at 09:33, kernel test robot wrote:
>> > base:
>> > https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git
>> > dev-test
>> > patch link:
>> > https://lore.kernel.org/r/1667889638-9106-1-git-send-email-zhiguo.niu%40unisoc.com
>> > patch subject: [PATCH V2] f2fs: fix atgc bug on issue in 32bits platform
>> > All warnings (new ones prefixed by >>):
>> >
>> > In file included from fs/f2fs/gc.c:22:
>> >>> fs/f2fs/gc.h:65:2: warning: field within 'struct victim_entry' is less aligned than 'union victim_entry::(anonymous at fs/f2fs/gc.h:65:2)' and is usually due to 'struct victim_entry' being packed, which can lead to unaligned accesses [-Wunaligned-access]
>> > union {
>>
>> It looks like the problem is the extra unqualified __packed annotation
>> inside of 'struct rb_entry'.
> yes, I agree, but this modification is about the following commit:
> f2fs: fix memory alignment to support 32bit
> (48046cb55d208eae67259887b29b3097bcf44caf)
Ah, I see. So in this case, the line
en = (struct extent_node *)f2fs_lookup_rb_tree_ret(&et->root,
requires the second field of 'struct extent_node' to be
in the same place as the corresponding field of 'struct rb_entry'.
This seems harmless then, though I would have put the __packed
annotation on the 'key' member instead of the union to
better document what is going on. Ideally the casts between
structures should not be used at all, but I don't know if
changing f2fs for this would involve a major rewrite of that
code.
> so I think is the following modifiction more better?
>
> @@ -68,7 +68,7 @@ struct victim_entry {
>
> unsigned int segno; /* segment No. */
>
> };
>
> struct victim_info vi; /* victim info */
>
> - };
>
> + } __packed;
So here is the construct with
ve = (struct victim_entry *)re;
that relies on vi->mtime to overlay re->key, right?
I'm not sure why there is a union in victim_entry, it would
be a little easier without that. Clearly both sides
of the union need the same alignment constraints, so
you could annotate the two 'mtime' members as __packed,
which gives the anonymous struct and the struct victim_info
32-bit alignment and avoids the warning. Having the
__packed at the end of the structure or union would
result in only single-byte alignment for structure
and not solve the problem that the compiler warns about.
The other alternative is to revert rb_entry back to
having 64-bit alignment on the key, but then also mark
extent_node as requiring the same alignment on the
'extent_info' member for consistency:
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -580,11 +580,11 @@ struct rb_entry {
unsigned int len; /* length of the entry */
};
unsigned long long key; /* 64-bits key */
- } __packed;
+ };
};
struct extent_info {
- unsigned int fofs; /* start offset in a file */
+ unsigned int fofs __aligned(8); /* start offset in a file */
unsigned int len; /* length of the extent */
u32 blk; /* start block address of the extent */
#ifdef CONFIG_F2FS_FS_COMPRESSION
Arnd
next prev parent reply other threads:[~2022-11-10 13:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-08 6:40 zhiguo.niu
2022-11-09 18:34 ` kernel test robot
2022-11-10 8:33 ` kernel test robot
2022-11-10 9:07 ` Arnd Bergmann
[not found] ` <CAHJ8P3+g7dr3PBZFQCD5HQLZ2b0WHe=b6Jt7ha1o7mqZJ7_-BQ@mail.gmail.com>
2022-11-10 13:45 ` Arnd Bergmann [this message]
[not found] ` <CAHJ8P3KU4NBr9ftqp1J_QWxGUjusoUZo6JjefPN-4YazD4mrUQ@mail.gmail.com>
2022-11-11 9:57 ` Arnd Bergmann
[not found] ` <CAHJ8P3JHVu=Qy0ft9Sorq2Zxvu7whFV72OU+NVMhvK8SK6+6MA@mail.gmail.com>
2022-11-14 10:17 ` Arnd Bergmann
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=97c529f2-c5a2-4ed6-89eb-c79f020e9d0c@app.fastmail.com \
--to=arnd@arndb.de \
--cc=chao@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=llvm@lists.linux.dev \
--cc=niuzhiguo84@gmail.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=zhiguo.niu@unisoc.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 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®