From: Ping-Ke Shih <pkshih@realtek.com>
To: Johannes Berg <johannes@sipsolutions.net>,
Masashi Honma <masashi.honma@gmail.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: RE: [PATCH v6 1/6] wifi: mac80211: Use struct instead of macro for PREQ frame
Date: Thu, 21 May 2026 00:42:50 +0000 [thread overview]
Message-ID: <d2c051127e384a918ff014da02e37e1e@realtek.com> (raw)
In-Reply-To: <965eff7ec3b928f093f7891e4307ec4e4a080ac4.camel@sipsolutions.net>
> > + orig_addr = preq_elem_top->orig_addr;
> > + orig_sn = get_unaligned_le32(&preq_elem_top->orig_sn);
> > + orig_lifetime = get_unaligned_le32(&preq_elem_bottom->lifetime);
> > + orig_metric = get_unaligned_le32(&preq_elem_bottom->metric);
>
> Ok, oops, I just realized my other thought on this was wrong - the
> previous PREQ_IE_LIFETIME() was u32_field_get() which loaded an entirely
> u32 from there using get_unaligned_le32().
>
> However, another comment: You don't need get_unaligned_le32() here since
> the struct is __packed, so you can simplify all of these to just
>
> orig_sn = le32_to_cpu(preq_elem_top->orig_sn);
>
I think the __packed can cause unaligned. Consider the offset below I added.
struct ieee80211_mesh_hwmp_preq_top {
u8 flags; // offset = 0
u8 hopcount; // offset = 1
u8 ttl; // offset = 2
__le32 preq_id; // offset = 3 (unaligned)
u8 orig_addr[ETH_ALEN]; // offset = 7
__le32 orig_sn; // offset = 13 (unaligned)
/* optional AE, lifetime, metric, target */
u8 variable[];
} __packed;
Not sure if the pointer preq_elem_top can adjust offset back to be aligned?
(But I think we don't make this assumption.)
Ping-Ke
next prev parent reply other threads:[~2026-05-21 0:43 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-15 23:38 [PATCH v6 1/6] wifi: mac80211: Use struct instead of macro for PREQ frame Masashi Honma
2026-05-15 23:38 ` [PATCH v6 2/6] wifi: mac80211: Use struct instead of macro for PREP frame Masashi Honma
2026-05-15 23:38 ` [PATCH v6 3/6] wifi: mac80211: Use struct instead of macro for PERR frame Masashi Honma
2026-05-15 23:38 ` [PATCH v6 4/6] wifi: mac80211: Fix overread in PREQ frame processing Masashi Honma
2026-05-20 11:15 ` Johannes Berg
2026-05-21 8:55 ` Masashi Honma
2026-05-15 23:38 ` [PATCH v6 5/6] wifi: mac80211: Fix overread in PREP " Masashi Honma
2026-05-20 11:16 ` Johannes Berg
2026-05-21 8:55 ` Masashi Honma
2026-05-15 23:38 ` [PATCH v6 6/6] wifi: mac80211: Fix PERR " Masashi Honma
2026-05-20 11:14 ` [PATCH v6 1/6] wifi: mac80211: Use struct instead of macro for PREQ frame Johannes Berg
2026-05-21 0:42 ` Ping-Ke Shih [this message]
2026-05-21 6:24 ` Johannes Berg
2026-05-21 7:38 ` Ping-Ke Shih
2026-05-21 7:42 ` Johannes Berg
2026-05-21 7:53 ` Ping-Ke Shih
2026-05-21 8:54 ` Masashi Honma
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=d2c051127e384a918ff014da02e37e1e@realtek.com \
--to=pkshih@realtek.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=masashi.honma@gmail.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