All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lance Yang <lance.yang@linux.dev>
To: Finn Thain <fthain@linux-m68k.org>,
	David Laight <david.laight.linux@gmail.com>
Cc: akpm@linux-foundation.org, geert@linux-m68k.org,
	linux-kernel@vger.kernel.org, mhiramat@kernel.org,
	oak@helsinkinet.fi, peterz@infradead.org, stable@vger.kernel.org,
	will@kernel.org, Lance Yang <ioworker0@gmail.com>
Subject: Re: [PATCH] atomic: Specify natural alignment for atomic_t
Date: Mon, 25 Aug 2025 20:33:08 +0800	[thread overview]
Message-ID: <b199a90c-4a7f-42bf-9d17-d96f63bb5e62@linux.dev> (raw)
In-Reply-To: <20250825130715.3a1141ed@pumpkin>



On 2025/8/25 20:07, David Laight wrote:
> On Mon, 25 Aug 2025 15:46:42 +0800
> Lance Yang <lance.yang@linux.dev> wrote:
> 
>> On 2025/8/25 14:17, Finn Thain wrote:
>>>
>>> On Mon, 25 Aug 2025, Lance Yang wrote:
>>>    
>>>>
>>>> What if we squash the runtime check fix into your patch?
>>>
>>> Did my patch not solve the problem?
>>
>> Hmm... it should solve the problem for natural alignment, which is a
>> critical fix.
>>
>> But it cannot solve the problem of forced misalignment from drivers using
>> #pragma pack(1). The runtime warning will still trigger in those cases.
>>
>> I built a simple test module on a kernel with your patch applied:
>>
>> ```
>> #include <linux/module.h>
>> #include <linux/init.h>
>>
>> struct __attribute__((packed)) test_container {
>>       char padding[49];
>>       struct mutex io_lock;
>> };
>>
>> static int __init alignment_init(void)
>> {
>>       struct test_container cont;
>>       pr_info("io_lock address offset mod 4: %lu\n", (unsigned long)&cont.io_lock % 4);
> 
> Doesn't that give a compilation warning from 'taking the address of a packed member'?
> Ignore that at your peril.

Hmm, I don't see that acctully ...

> 
> More problematic is that, IIRC, m68k kmalloc() allocates 16bit aligned memory.
> This has broken other things in the past.
> I doubt that increasing the alignment to 32bits would make much difference
> to the kernel memory footprint.

@Finn Given this new information, how about we just apply the runtime check
fix for now?

Since we plan to remove the entire pointer-encoding scheme later anyway, a
minimal and targeted change could be the logical choice. It's easy and safe
to backport, and it cleanly stops the warnings from all sources without
introducing new risks - exactly what we need for stable kernels.

Cheers,
Lance

  reply	other threads:[~2025-08-25 12:33 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-25  2:03 [PATCH] atomic: Specify natural alignment for atomic_t Finn Thain
2025-08-25  2:03 ` Finn Thain
2025-08-25  3:27 ` Lance Yang
2025-08-25  3:59   ` Finn Thain
2025-08-25  4:22     ` Lance Yang
2025-08-25  4:07   ` Finn Thain
2025-08-25  5:00     ` Lance Yang
2025-08-25  6:17       ` Finn Thain
2025-08-25  7:46         ` Lance Yang
2025-08-25 10:49           ` Finn Thain
2025-08-25 11:19             ` Lance Yang
2025-08-25 11:36               ` Lance Yang
2025-08-27 23:43                 ` Finn Thain
2025-08-28  2:05                   ` Lance Yang
2025-09-01  8:45                     ` Geert Uytterhoeven
2025-09-02 13:30                       ` Lance Yang
2025-09-02 14:14                         ` Geert Uytterhoeven
2025-09-06 11:43                       ` David Laight
2025-08-25 12:07           ` David Laight
2025-08-25 12:33             ` Lance Yang [this message]
2025-08-27  8:00               ` Finn Thain
2025-08-27  9:34                 ` Lance Yang
2025-09-01  8:48             ` Geert Uytterhoeven
2025-08-25  7:12 ` Peter Zijlstra
2025-08-25  8:03   ` Finn Thain
2025-08-25 11:41     ` Peter Zijlstra
2025-08-27  7:17       ` Finn Thain
2025-08-27 11:54         ` Peter Zijlstra
2025-08-28  9:53           ` Finn Thain
2025-09-01  9:36             ` Peter Zijlstra
2025-09-01  9:40               ` Peter Zijlstra
2025-09-08  1:30                 ` Finn Thain
2025-08-26 15:22 ` Eero Tamminen
2025-08-26 17:33   ` Lance Yang
2025-09-01  8:51   ` Geert Uytterhoeven
2025-09-01 15:12     ` Eero Tamminen
2025-09-06 11:50       ` David Laight
2025-08-27  2:45 ` Masami Hiramatsu

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=b199a90c-4a7f-42bf-9d17-d96f63bb5e62@linux.dev \
    --to=lance.yang@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=david.laight.linux@gmail.com \
    --cc=fthain@linux-m68k.org \
    --cc=geert@linux-m68k.org \
    --cc=ioworker0@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=oak@helsinkinet.fi \
    --cc=peterz@infradead.org \
    --cc=stable@vger.kernel.org \
    --cc=will@kernel.org \
    /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.