linux-kernel - Re: [PATCH 6.6] membarrier: riscv: Add full memory barrier in switch

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] [day] [month] [year] [list]

Message-ID: <77d0f59f-554b-4cd9-ae1c-4c89a76058ef@ghiti.fr>
Date: Tue, 10 Sep 2024 20:59:08 +0200
From: Alexandre Ghiti <alex@...ti.fr>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: WangYuli <wangyuli@...ontech.com>, stable@...r.kernel.org,
 sashal@...nel.org, parri.andrea@...il.com, mathieu.desnoyers@...icios.com,
 palmer@...osinc.com, linux-kernel@...r.kernel.org, paul.walmsley@...ive.com,
 palmer@...belt.com, aou@...s.berkeley.edu, nathan@...nel.org,
 ndesaulniers@...gle.com, trix@...hat.com, linux-riscv@...ts.infradead.org,
 llvm@...ts.linux.dev, paulmck@...nel.org, mingo@...hat.com,
 peterz@...radead.org, juri.lelli@...hat.com, vincent.guittot@...aro.org,
 dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
 mgorman@...e.de, bristot@...hat.com, vschneid@...hat.com,
 brauner@...nel.org, arnd@...db.de
Subject: Re: [PATCH 6.6] membarrier: riscv: Add full memory barrier in
 switch_mm()

On 10/09/2024 15:25, Greg KH wrote:
> On Tue, Sep 10, 2024 at 02:35:06PM +0200, Alexandre Ghiti wrote:
>> On 10/09/2024 13:58, Greg KH wrote:
>>> On Tue, Sep 10, 2024 at 01:31:04PM +0200, Alexandre Ghiti wrote:
>>>> Hi Greg,
>>>>
>>>> On 10/09/2024 09:32, Greg KH wrote:
>>>>> On Mon, Sep 09, 2024 at 10:57:01AM +0800, WangYuli wrote:
>>>>>> From: Andrea Parri <parri.andrea@...il.com>
>>>>>>
>>>>>> [ Upstream commit d6cfd1770f20392d7009ae1fdb04733794514fa9 ]
>>>>>>
>>>>>> The membarrier system call requires a full memory barrier after storing
>>>>>> to rq->curr, before going back to user-space.  The barrier is only
>>>>>> needed when switching between processes: the barrier is implied by
>>>>>> mmdrop() when switching from kernel to userspace, and it's not needed
>>>>>> when switching from userspace to kernel.
>>>>>>
>>>>>> Rely on the feature/mechanism ARCH_HAS_MEMBARRIER_CALLBACKS and on the
>>>>>> primitive membarrier_arch_switch_mm(), already adopted by the PowerPC
>>>>>> architecture, to insert the required barrier.
>>>>>>
>>>>>> Fixes: fab957c11efe2f ("RISC-V: Atomic and Locking Code")
>>>>>> Signed-off-by: Andrea Parri <parri.andrea@...il.com>
>>>>>> Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
>>>>>> Link: https://lore.kernel.org/r/20240131144936.29190-2-parri.andrea@gmail.com
>>>>>> Signed-off-by: Palmer Dabbelt <palmer@...osinc.com>
>>>>>> Signed-off-by: WangYuli <wangyuli@...ontech.com>
>>>>>> ---
>>>>>>     MAINTAINERS                         |  2 +-
>>>>>>     arch/riscv/Kconfig                  |  1 +
>>>>>>     arch/riscv/include/asm/membarrier.h | 31 +++++++++++++++++++++++++++++
>>>>>>     arch/riscv/mm/context.c             |  2 ++
>>>>>>     kernel/sched/core.c                 |  5 +++--
>>>>>>     5 files changed, 38 insertions(+), 3 deletions(-)
>>>>>>     create mode 100644 arch/riscv/include/asm/membarrier.h
>>>>> Now queued up, thanks.
>>>> The original patch was merged in 6.9 and the Fixes tag points to a commit
>>>> introduced in v4.15. So IIUC, this patch should have been backported
>>>> "automatically" to the releases < 6.9 right? As stated in the documentation
>>>> (process/stable-kernel-rules.html):
>>>>
>>>> "Note, such tagging is unnecessary if the stable team can derive the
>>>> appropriate versions from Fixes: tags."
>>>>
>>>> Or did we miss something?
>>> Yes, you didn't tag cc: stable at all in this commit, which is why we
>>> did not see it.  The documentation says that :)
>>
>> Ok, some patches seem to make it to stable without the cc: stable tag (like
>> the one below for example), so I thought it was not necessary.
> Yes, they do, because many maintainers and developers don't follow the
> normal rules, so we sweep the tree when we have a chance and do a "best
> effort" backport at times.
>
> But again, it is NOT guaranteed that this will happen, and even if it
> does, you will NOT get emails saying the attempt-at-backporting fails,
> if it fails, as obviously the developers involved weren't explicitly
> asking for it to be backported.
>
> So in short, just properly tag things for stable, and all will be fine.


Great, thank you, I'll make sure we tag the fixes to backport properly!

Thanks again,

Alex


>
> thanks,
>
> greg k-h