linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Huang, Ying" <ying.huang@intel.com>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Jens Axboe <axboe@kernel.dk>, Jian Cai <jiancai@google.com>,
	Guenter Roeck <linux@roeck-us.net>,
	Peter Zijlstra <peterz@infradead.org>,
	Borislav Petkov <bp@suse.de>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Juergen Gross <jgross@suse.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Thomas Gleixner <tglx@linutronix.de>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Ingo Molnar <mingo@kernel.org>,
	Frederic Weisbecker <frederic@kernel.org>,
	He Ying <heying24@huawei.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	clang-built-linux <clang-built-linux@googlegroups.com>
Subject: Re: [PATCH] [v2] smp: fix smp_call_function_single_async prototype
Date: Thu, 06 May 2021 20:03:38 +0800	[thread overview]
Message-ID: <87pmy4qdb9.fsf@yhuang6-desk1.ccr.corp.intel.com> (raw)
In-Reply-To: <CAK8P3a3kZ9_VoKV+2eZh=WqncRqFKzRmRHUjAT9iFMtJpKzb1w@mail.gmail.com> (Arnd Bergmann's message of "Thu, 6 May 2021 10:30:49 +0200")

Arnd Bergmann <arnd@kernel.org> writes:

> On Thu, May 6, 2021 at 10:14 AM Huang, Ying <ying.huang@intel.com> wrote:
>>
>> Arnd Bergmann <arnd@kernel.org> writes:
>>
>> > On Thu, May 6, 2021 at 3:20 AM Huang, Ying <ying.huang@intel.com> wrote:
>> >>
>> >> Arnd Bergmann <arnd@kernel.org> writes:
>> >>
>> >> > From: Arnd Bergmann <arnd@arndb.de>
>> >> >
>> >> > As of commit 966a967116e6 ("smp: Avoid using two cache lines for struct
>> >> > call_single_data"), the smp code prefers 32-byte aligned call_single_data
>> >> > objects for performance reasons, but the block layer includes an instance
>> >> > of this structure in the main 'struct request' that is more senstive
>> >> > to size than to performance here, see 4ccafe032005 ("block: unalign
>> >> > call_single_data in struct request").
>> >> >
>> >> > The result is a violation of the calling conventions that clang correctly
>> >> > points out:
>> >> >
>> >> > block/blk-mq.c:630:39: warning: passing 8-byte aligned argument
>> >> > to 32-byte aligned parameter 2 of
>> >> > 'smp_call_function_single_async' may result in an unaligned
>> >> > pointer access [-Walign-mismatch]
>> >> >                 smp_call_function_single_async(cpu, &rq->csd);
>> >>
>> >> Can this be silenced by
>> >>
>> >>                 smp_call_function_single_async(cpu, (call_single_data_t *)&rq->csd);
>> >
>> > Probably, but casting from smaller alignment to larger alignment is undefined
>> > behavior
>>
>> We cannot avoid type cast in Linux kernel, such as container_of(), is
>> there some difference here?
>
> container_of() does not cause any alignment problems. Assuming the outer
> structure is aligned correctly, then the inner structure also is.

So you think that the compiler may generate different code depends on
the data structure alignment (8 vs. 32 here)?  I think that it doesn't
on x86.  Do you know it does that on any architecture?  But I understand
that this is possible at least in theory.

>> > and I'd rather not go there in case this triggers some runtime
>> > misbehavior or ubsan check in the future. Making the function accept a
>> > pointer with the smaller alignment avoids getting into undefined behavior
>> > and doesn't require a cast.
>>
>> In its raw form as above, this looks bad.  If we encapsulate it, it may
>> look better, for example,
>>
>> static inline int __smp_call_function_single_async(int cpu, struct __call_single_data *csd)
>> {
>>         smp_call_function_single_async(cpu, (call_single_data_t *)csd);
>> }
>>
>> Then, we can do
>>
>>         __smp_call_function_single_async(cpu, &rq->csd);
>
> Same problem, it's still calling a function that expects stricter alignment.
> It would work if we do it the other way around though:
>
> static inline int smp_call_function_single_async(int cpu,
> call_single_data_t *csd)
> {
>         return __smp_call_function_single_async(cpu, csd);
> }
>
> That should even work without the cast.

Yes.  This looks good!

Best Regards,
Huang, Ying

  reply	other threads:[~2021-05-06 12:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-05 21:12 [PATCH] [v2] smp: fix smp_call_function_single_async prototype Arnd Bergmann
2021-05-06  1:19 ` Huang, Ying
2021-05-06  7:54   ` Arnd Bergmann
2021-05-06  8:14     ` Huang, Ying
2021-05-06  8:30       ` Arnd Bergmann
2021-05-06 12:03         ` Huang, Ying [this message]
2021-05-06 14:30           ` Arnd Bergmann
2021-05-06 10:10 ` Peter Zijlstra
2021-05-06 13:48 ` [tip: locking/urgent] smp: Fix " tip-bot2 for 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=87pmy4qdb9.fsf@yhuang6-desk1.ccr.corp.intel.com \
    --to=ying.huang@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=bp@suse.de \
    --cc=clang-built-linux@googlegroups.com \
    --cc=eric.dumazet@gmail.com \
    --cc=frederic@kernel.org \
    --cc=heying24@huawei.com \
    --cc=jgross@suse.com \
    --cc=jiancai@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=mingo@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    /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;
as well as URLs for NNTP newsgroup(s).