All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: Jarmo Tiitto <jarmo.tiitto@gmail.com>,
	Sami Tolvanen <samitolvanen@google.com>,
	Bill Wendling <wcw@google.com>, Kees Cook <keescook@chromium.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	clang-built-linux@googlegroups.com, linux-kernel@vger.kernel.org
Cc: morbo@google.com
Subject: Re: [PATCH v2 1/1] pgo: Fix allocate_node() v2
Date: Thu, 3 Jun 2021 14:14:24 -0700	[thread overview]
Message-ID: <d7e94352-0b24-1ab1-8b54-b6ffd4347963@kernel.org> (raw)
In-Reply-To: <20210603133853.5383-1-jarmo.tiitto@gmail.com>

On 6/3/2021 6:38 AM, Jarmo Tiitto wrote:
> Based on Kees and others feedback here is v2 patch
> that clarifies why the current checks in allocate_node()
> are flawed. I did fair amount of KGDB time on it.
> 
> When clang instrumentation eventually calls allocate_node()
> the struct llvm_prf_data *p argument tells us from what section
> we should reserve the vnode: It either points into vmlinux's
> core __llvm_prf_data section or some loaded module's
> __llvm_prf_data section.
> 
> But since we don't have access to corresponding
> __llvm_prf_vnds section(s) for any module, the function
> should return just NULL and ignore any profiling attempts
> from modules for now.
> 
> Signed-off-by: Jarmo Tiitto <jarmo.tiitto@gmail.com>

I agree with Nick on the comments about the commit message. A few more 
small nits below, not sure they necessitate a v3, up to you. Thank you 
for the patch!

Reviewed-by: Nathan Chancellor <nathan@kernel.org>

> ---
>   kernel/pgo/instrument.c | 21 ++++++++++++---------
>   1 file changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/kernel/pgo/instrument.c b/kernel/pgo/instrument.c
> index 0e07ee1b17d9..afe9982b07a3 100644
> --- a/kernel/pgo/instrument.c
> +++ b/kernel/pgo/instrument.c
> @@ -23,6 +23,7 @@
>   #include <linux/export.h>
>   #include <linux/spinlock.h>
>   #include <linux/types.h>
> +#include <asm-generic/sections.h>

Not sure that it actually matters but I think this should be

#include <asm/sections.h>

instead. Might be nice to keep this sorted by moving it to the top as well.

>   #include "pgo.h"
>   
>   /*
> @@ -55,17 +56,19 @@ void prf_unlock(unsigned long flags)
>   static struct llvm_prf_value_node *allocate_node(struct llvm_prf_data *p,
>   						 u32 index, u64 value)
>   {
> -	if (&__llvm_prf_vnds_start[current_node + 1] >= __llvm_prf_vnds_end)
> -		return NULL; /* Out of nodes */
> -
> -	current_node++;
> -
> -	/* Make sure the node is entirely within the section */
> -	if (&__llvm_prf_vnds_start[current_node] >= __llvm_prf_vnds_end ||
> -	    &__llvm_prf_vnds_start[current_node + 1] > __llvm_prf_vnds_end)
> +	const int max_vnds = prf_vnds_count();

A blank line between this variable and the comment below would look nice.

> +	/* Check that p is within vmlinux __llvm_prf_data section. > +	 * If not, don't allocate since we can't handle modules yet.
> +	 */

For every subsystem except for netdev, there should be a blank line at 
the beginning of a comment. In other works:

/*
  * Check that p is within vmlinux __llvm_prf_data section.
  * If not, don't allocate since we can't handle modules yet.
  */

> +	if (!memory_contains(__llvm_prf_data_start,
> +		__llvm_prf_data_end, p, sizeof(*p)))
>   		return NULL;
>   
> -	return &__llvm_prf_vnds_start[current_node];
> +	if (WARN_ON_ONCE(current_node >= max_vnds))
> +		return NULL; /* Out of nodes */
> +
> +	/* reserve vnode for vmlinux */
> +	return &__llvm_prf_vnds_start[current_node++];
>   }
>   
>   /*
> 
> base-commit: 5d0cda65918279ada060417c5fecb7e86ccb3def
> 


  parent reply	other threads:[~2021-06-03 21:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-03 13:38 [PATCH v2 1/1] pgo: Fix allocate_node() v2 Jarmo Tiitto
2021-06-03 20:50 ` Nick Desaulniers
2021-06-03 20:52   ` Nathan Chancellor
2021-06-03 21:00     ` Nick Desaulniers
2021-06-03 21:14 ` Nathan Chancellor [this message]
2021-06-03 21:36   ` Kees Cook
2021-06-04  9:40     ` Jarmo Tiitto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d7e94352-0b24-1ab1-8b54-b6ffd4347963@kernel.org \
    --to=nathan@kernel.org \
    --cc=clang-built-linux@googlegroups.com \
    --cc=jarmo.tiitto@gmail.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=morbo@google.com \
    --cc=ndesaulniers@google.com \
    --cc=samitolvanen@google.com \
    --cc=wcw@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.