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]
Message-ID: <f669eb1e-20af-4923-b328-f31bea4f7dbb@infradead.org>
Date: Sat, 23 Dec 2023 11:30:22 -0800
From: Randy Dunlap <rdunlap@...radead.org>
To: Matthew Cassell <mcassell411@...il.com>, corbet@....net
Cc: linux-doc@...r.kernel.org, trivial@...nel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Documentation/trace: Fixed typos in the ftrace FLAGS
 section



On 12/23/23 10:58, Matthew Cassell wrote:
> Fixed typos in the FTRACE_OPS_FL_RECURSION flag description.
> 
> Signed-off-by: Matthew Cassell <mcassell411@...il.com>

Reviewed-by: Randy Dunlap <rdunlap@...radead.org>

Thanks.

> ---
>  Documentation/trace/ftrace-uses.rst | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/trace/ftrace-uses.rst b/Documentation/trace/ftrace-uses.rst
> index f7d98ae5b885..e198854ace79 100644
> --- a/Documentation/trace/ftrace-uses.rst
> +++ b/Documentation/trace/ftrace-uses.rst
> @@ -182,7 +182,7 @@ FTRACE_OPS_FL_SAVE_REGS_IF_SUPPORTED
>  
>  FTRACE_OPS_FL_RECURSION
>  	By default, it is expected that the callback can handle recursion.
> -	But if the callback is not that worried about overehead, then
> +	But if the callback is not that worried about overhead, then
>  	setting this bit will add the recursion protection around the
>  	callback by calling a helper function that will do the recursion
>  	protection and only call the callback if it did not recurse.
> @@ -190,7 +190,7 @@ FTRACE_OPS_FL_RECURSION
>  	Note, if this flag is not set, and recursion does occur, it could
>  	cause the system to crash, and possibly reboot via a triple fault.
>  
> -	Not, if this flag is set, then the callback will always be called
> +	Note, if this flag is set, then the callback will always be called
>  	with preemption disabled. If it is not set, then it is possible
>  	(but not guaranteed) that the callback will be called in
>  	preemptable context.

-- 
#Randy
https://people.kernel.org/tglx/notes-about-netiquette
https://subspace.kernel.org/etiquette.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ