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: <20250614114514.808-1-khaliidcaliy@gmail.com>
Date: Sat, 14 Jun 2025 11:42:56 +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

> Nothing is redone. All call sites of syscall_enter_from_user_mode() have
> to:
>
>    1) invoke enter_from_user_mode()
>
>    2) enable interrupts
>
> in that very order.
>
> syscall_enter_from_user_mode_prepare() is a helper function which
> combines both. It was more widely used in the early implementations of
> this infrastructure, but it's usage got reduced to one call site.

Please try to understand me before you make malformed responses too.

My point is simple and it is, why?

Currently neither you nor the documentation explained the technical reasons why 
syscall_enter_from_user_mode_prepare() was ommited and i was trying my best to understand
why?
If syscall_enter_from_user_mode() is doing #1 #2 when syscall_enter_from_user_mode_prepare()
already doing it then why it is not calling it. This is why i said it was redone.

> All other call sites invoke enter_from_user_mode() and then enable
> interrupts before calling syscall_enter_from_user_mode().

Honestly, my patch and my discussion doesn't involve about it's call sites.
My discussion is simple, either we update the comment if you disagree with me and the reason,
or we can simply use syscall_enter_from_user_mode_prepare() on syscall_enter_from_user_mode()
if you don't have strong reason to avoid it, then nothing happens because syscall_enter_from_user_mode_prepare()
internally calls enter_from_user_mode() and enables interrupts. syscall_enter_from_user_mode() also calls
enter_from_user_mode() directly also enables interrups, so if you don't know please check on your side also.

> That has nothing to do with instrumentation_end(). See
> Documentation/core-api/entry.rst for an explanation of noinstr and
> instrumentation_begin/end().

This one i was wrong, and i understand now. So forget about it.

My point was clear, the two steps already syscall_enter_from_user_mode_prepare() did and 
unless you tell me a clear reason instead of "we ommited for a reason" which you repeatly telling me.

> Did you read what I wrote: 
Again, my point is clear so try to understand as it is, then refuse or accept with clear reasons.

> ?

I don't know if what i asked you is hard and shouldn't be asked.

You must understand i didn't come here to argue with you or to annoy you. If you disagree with me these points i 
proposed to you and also disagree with the doc patch i said to you change enter_from_user_mode() instead 
of which makes up to date as i think because you didn't tell me why neither the doc you provided did. I think maybe 
about the doc just good English is enough instead of putting unused functions on the doc.

what are you proposing then, maybe you already have some way better than mine? OR
Tell me what are you expecting from me then?
Do i leave it like that, outdated and let mislead document readers?

Thanks,
Khalid Ali

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ