linux-kernel - Re: [PATCH] [v2] smp: fix smp_call_function_single

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 06 May 2021 20:03:38 +0800
From:   "Huang, Ying" <ying.huang@...el.com>
To:     Arnd Bergmann <arnd@...nel.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Jens Axboe <axboe@...nel.dk>, Jian Cai <jiancai@...gle.com>,
        Guenter Roeck <linux@...ck-us.net>,
        Peter Zijlstra <peterz@...radead.org>,
        Borislav Petkov <bp@...e.de>,
        Eric Dumazet <eric.dumazet@...il.com>,
        Juergen Gross <jgross@...e.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Thomas Gleixner <tglx@...utronix.de>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Ingo Molnar <mingo@...nel.org>,
        Frederic Weisbecker <frederic@...nel.org>,
        He Ying <heying24@...wei.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>
Subject: Re: [PATCH] [v2] smp: fix smp_call_function_single_async prototype

Arnd Bergmann <arnd@...nel.org> writes:

> On Thu, May 6, 2021 at 10:14 AM Huang, Ying <ying.huang@...el.com> wrote:
>>
>> Arnd Bergmann <arnd@...nel.org> writes:
>>
>> > On Thu, May 6, 2021 at 3:20 AM Huang, Ying <ying.huang@...el.com> wrote:
>> >>
>> >> Arnd Bergmann <arnd@...nel.org> writes:
>> >>
>> >> > From: Arnd Bergmann <arnd@...db.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