linux-kernel - Re: [PATCH] include/linux: Fix outdated comment on entry-common.h

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20250613205810.773-1-khaliidcaliy@gmail.com>
Date: Fri, 13 Jun 2025 20:58:09 +0000
From: Khalid Ali <khaliidcaliy@...il.com>
To: tglx@...utronix.de,
	peterz@...radead.org,
	luto@...nel.org
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH] include/linux: Fix outdated comment on entry-common.h

> 'include/linux:' is not a valid prefix. See the documentation I pointed
> you to in the other reply.
>
> > From: Khalid Ali <khaliidcaliy@...il.com>
> >
> > On most calls to this function, syscall_enter_from_user_mode_prepare()
> > never get called as the comment indicates.
> >
> > Privious kernel version i used to see things happen as the function documentation
> > indicated (syscall_enter_from_user_mode_prepare() called before
> > syscall_enter_from_user_mode_work), however it seems now some things
> > have changed which makes that point irrevelant. Most preparations that
> > function does is handled manually by enter_from_user_mode() and
> > some other places. So this makes it misleading.
> >
> > The point is remove strict function call indication on documentation as might be outdated
> > one day in the future. There multiple places currently called
> > syscall_enter_from_user_mode_work() without
> > syscall_enter_from_user_mode_prepare() get called so that will make it
> > condition not met.
>
> That's again incomprehensible word salad.
>
> You are right that the comment is not longer accurate, but your fixup
> makes it even worse.
>
> The real condition for calling this function is:
>
>    1) enter_from_user_mode() has been invoked
>
>    2) interrupts have been enabled
>
>    3) Architecture specific work has been done
>
> #1 must be the first thing. #2 and #3 have no ordering requirements.
>
> syscall_enter_from_user_mode_prepare() does #1 and #2 together and in
> the original implementation this was used in more places. So yes, the
> comment is outdated, but it needs to describe the above requirements and
> not something pulled out of thin air.
>
> Thanks,
>
>       tglx

Thanks and noted, however just asking why syscall_enter_from_user_mode() isn't calling
syscall_enter_from_user_mode_prepare() i don't get it why #1 and #2 is redone, is it because
of instrumentations since syscall_enter_from_user_mode_prepare() is calling instrumentation_end()?

Maybe we need to determine if instrumentation_end() is neccessary for syscall_enter_from_user_mode_prepare().
As i know the only place where syscall_enter_from_user_mode_prepare() is called is arch/x86/entry/syscall_32.c,
on that source when the function returns they begin the instrumentation again using instrumentation_begin(). So i think
with little adjusment of that source file and removing instrumentation_end() on syscall_enter_from_user_mode_prepare()
then we can use syscall_enter_from_user_mode_prepare() as we did. Yet don't know the reason, however suspect some duplication.

Another thing i should indicate if you don't agree with me is, can we change the comment the function to enter_from_user_mode(), 
and with little adjusment make steps as you mentioned.

Let me know if these ideas above right and whether i should keep going on updating the comment.
Thanks, Khalid ALi