[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87cy2rkuu9.ffs@tglx>
Date: Fri, 30 Jan 2026 16:01:50 +0100
From: Thomas Gleixner <tglx@...nel.org>
To: Kevin Brodsky <kevin.brodsky@....com>, Jinjie Ruan
<ruanjinjie@...wei.com>, catalin.marinas@....com, will@...nel.org,
oleg@...hat.com, peterz@...radead.org, luto@...nel.org, shuah@...nel.org,
kees@...nel.org, wad@...omium.org, deller@....de,
akpm@...ux-foundation.org, charlie@...osinc.com, mark.rutland@....com,
anshuman.khandual@....com, song@...nel.org, ryan.roberts@....com,
thuth@...hat.com, ada.coupriediaz@....com, broonie@...nel.org,
pengcan@...inos.cn, liqiang01@...inos.cn, kmal@...k.li,
dvyukov@...gle.com, reddybalavignesh9979@...il.com,
richard.weiyang@...il.com, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v11 09/14] entry: Rework
syscall_exit_to_user_mode_work() for arch reuse
On Fri, Jan 30 2026 at 14:27, Kevin Brodsky wrote:
> On 30/01/2026 11:16, Thomas Gleixner wrote:
>>> Agreed, the comments are essentially describing what each function
>>> calls; considering how short they are, directly reading the code is
>>> probably easier.
>> No. Please keep them. There is more information in them than just the
>> pure 'what's' called.
>
> That is true before this patch, where it made sense to highlight that
> exit_to_user_mode() must still be called after this function (without
> re-enabling interrupts). With this patch there is however much more that
> this function is lacking, and it feels very likely that comments will go
> out of sync with exactly what syscall_exit_to_user_mode() calls.
>
> I suppose we could simply point the reader to
> syscall_exit_to_user_mode() to find out what else is needed, and keep
> the comment about the calling convention being the same.
I've picked up _all_ four entry changes and reworked the comments and
changelogs already.
Those patches should have been bundled together at the start of the
series anyway so they can be picked up independently without going
through loops and hoops. When will people learn to think beyond the brim
of their architecture tea cup?
I'll go and apply them on top of 6.19-rc1 into core/entry and merge that
into the scheduler branch to resolve the resulting conflict.
ARM64 can either pull that branch or wait until the next rc1 comes out.
Thanks,
tglx
Powered by blists - more mailing lists