All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko@kernel.org>
To: lkp@lists.01.org
Subject: Re: [PATCH] objtool, static_call: Don't emit static_call_site for .exit.text
Date: Wed, 17 Mar 2021 23:01:38 +0200	[thread overview]
Message-ID: <YFJuMi9ZSJk5Ctvw@kernel.org> (raw)
In-Reply-To: <YFH6BR61b5GK8ITo@hirez.programming.kicks-ass.net>

[-- Attachment #1: Type: text/plain, Size: 3532 bytes --]

On Wed, Mar 17, 2021 at 01:45:57PM +0100, Peter Zijlstra wrote:
> On Wed, Mar 17, 2021 at 05:25:48PM +0530, Sumit Garg wrote:
> > Thanks Peter for this fix. It does work for me on qemu for x86. Can
> > you turn this into a proper fix patch? BTW, feel free to add:
> 
> Per the below, the original patch ought to be fixed as well, to not use
> static_call() in __exit.
> 
> ---
> Subject: objtool,static_call: Don't emit static_call_site for .exit.text
> From: Peter Zijlstra <peterz@infradead.org>
> Date: Wed Mar 17 13:35:05 CET 2021
> 
> Functions marked __exit are (somewhat surprisingly) discarded at
> runtime when built-in. This means that static_call(), when used in
> __exit functions, will generate static_call_site entries that point
> into reclaimed space.
> 
> Simply skip such sites and emit a WARN about it. By not emitting a
> static_call_site the site will remain pointed at the trampoline, which
> is also maintained, so things will work as expected, albeit with the
> extra indirection.
> 
> The WARN is so that people are aware of this; and arguably it simply
> isn't a good idea to use static_call() in __exit code anyway, since
> module unload is never a performance critical path.
> 
> Reported-by: Sumit Garg <sumit.garg@linaro.org>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Tested-by: Sumit Garg <sumit.garg@linaro.org>


Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>

/Jarkko

> ---
>  tools/objtool/check.c |   32 ++++++++++++++++++++------------
>  1 file changed, 20 insertions(+), 12 deletions(-)
> 
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -850,6 +850,22 @@ static int add_ignore_alternatives(struc
>  	return 0;
>  }
>  
> +static inline void static_call_add(struct instruction *insn,
> +				   struct objtool_file *file)
> +{
> +	if (!insn->call_dest->static_call_tramp)
> +		return;
> +
> +	if (!strcmp(insn->sec->name, ".exit.text")) {
> +		WARN_FUNC("static_call in .exit.text, skipping inline patching",
> +			  insn->sec, insn->offset);
> +		return;
> +	}
> +
> +	list_add_tail(&insn->static_call_node,
> +		      &file->static_call_list);
> +}
> +
>  /*
>   * Find the destination instructions for all jumps.
>   */
> @@ -888,10 +904,7 @@ static int add_jump_destinations(struct
>  		} else if (insn->func) {
>  			/* internal or external sibling call (with reloc) */
>  			insn->call_dest = reloc->sym;
> -			if (insn->call_dest->static_call_tramp) {
> -				list_add_tail(&insn->static_call_node,
> -					      &file->static_call_list);
> -			}
> +			static_call_add(insn, file);
>  			continue;
>  		} else if (reloc->sym->sec->idx) {
>  			dest_sec = reloc->sym->sec;
> @@ -950,10 +963,7 @@ static int add_jump_destinations(struct
>  
>  				/* internal sibling call (without reloc) */
>  				insn->call_dest = insn->jump_dest->func;
> -				if (insn->call_dest->static_call_tramp) {
> -					list_add_tail(&insn->static_call_node,
> -						      &file->static_call_list);
> -				}
> +				static_call_add(insn, file);
>  			}
>  		}
>  	}
> @@ -2746,10 +2756,8 @@ static int validate_branch(struct objtoo
>  			if (dead_end_function(file, insn->call_dest))
>  				return 0;
>  
> -			if (insn->type == INSN_CALL && insn->call_dest->static_call_tramp) {
> -				list_add_tail(&insn->static_call_node,
> -					      &file->static_call_list);
> -			}
> +			if (insn->type == INSN_CALL)
> +				static_call_add(insn, file);
>  
>  			break;
>  
> 

WARNING: multiple messages have this Message-ID (diff)
From: Jarkko Sakkinen <jarkko@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Sumit Garg <sumit.garg@linaro.org>,
	Oliver Sang <oliver.sang@intel.com>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	jbaron@akamai.com, lkp@lists.01.org,
	kbuild test robot <lkp@intel.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] objtool,static_call: Don't emit static_call_site for .exit.text
Date: Wed, 17 Mar 2021 23:01:38 +0200	[thread overview]
Message-ID: <YFJuMi9ZSJk5Ctvw@kernel.org> (raw)
In-Reply-To: <YFH6BR61b5GK8ITo@hirez.programming.kicks-ass.net>

On Wed, Mar 17, 2021 at 01:45:57PM +0100, Peter Zijlstra wrote:
> On Wed, Mar 17, 2021 at 05:25:48PM +0530, Sumit Garg wrote:
> > Thanks Peter for this fix. It does work for me on qemu for x86. Can
> > you turn this into a proper fix patch? BTW, feel free to add:
> 
> Per the below, the original patch ought to be fixed as well, to not use
> static_call() in __exit.
> 
> ---
> Subject: objtool,static_call: Don't emit static_call_site for .exit.text
> From: Peter Zijlstra <peterz@infradead.org>
> Date: Wed Mar 17 13:35:05 CET 2021
> 
> Functions marked __exit are (somewhat surprisingly) discarded at
> runtime when built-in. This means that static_call(), when used in
> __exit functions, will generate static_call_site entries that point
> into reclaimed space.
> 
> Simply skip such sites and emit a WARN about it. By not emitting a
> static_call_site the site will remain pointed at the trampoline, which
> is also maintained, so things will work as expected, albeit with the
> extra indirection.
> 
> The WARN is so that people are aware of this; and arguably it simply
> isn't a good idea to use static_call() in __exit code anyway, since
> module unload is never a performance critical path.
> 
> Reported-by: Sumit Garg <sumit.garg@linaro.org>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Tested-by: Sumit Garg <sumit.garg@linaro.org>


Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>

/Jarkko

> ---
>  tools/objtool/check.c |   32 ++++++++++++++++++++------------
>  1 file changed, 20 insertions(+), 12 deletions(-)
> 
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -850,6 +850,22 @@ static int add_ignore_alternatives(struc
>  	return 0;
>  }
>  
> +static inline void static_call_add(struct instruction *insn,
> +				   struct objtool_file *file)
> +{
> +	if (!insn->call_dest->static_call_tramp)
> +		return;
> +
> +	if (!strcmp(insn->sec->name, ".exit.text")) {
> +		WARN_FUNC("static_call in .exit.text, skipping inline patching",
> +			  insn->sec, insn->offset);
> +		return;
> +	}
> +
> +	list_add_tail(&insn->static_call_node,
> +		      &file->static_call_list);
> +}
> +
>  /*
>   * Find the destination instructions for all jumps.
>   */
> @@ -888,10 +904,7 @@ static int add_jump_destinations(struct
>  		} else if (insn->func) {
>  			/* internal or external sibling call (with reloc) */
>  			insn->call_dest = reloc->sym;
> -			if (insn->call_dest->static_call_tramp) {
> -				list_add_tail(&insn->static_call_node,
> -					      &file->static_call_list);
> -			}
> +			static_call_add(insn, file);
>  			continue;
>  		} else if (reloc->sym->sec->idx) {
>  			dest_sec = reloc->sym->sec;
> @@ -950,10 +963,7 @@ static int add_jump_destinations(struct
>  
>  				/* internal sibling call (without reloc) */
>  				insn->call_dest = insn->jump_dest->func;
> -				if (insn->call_dest->static_call_tramp) {
> -					list_add_tail(&insn->static_call_node,
> -						      &file->static_call_list);
> -				}
> +				static_call_add(insn, file);
>  			}
>  		}
>  	}
> @@ -2746,10 +2756,8 @@ static int validate_branch(struct objtoo
>  			if (dead_end_function(file, insn->call_dest))
>  				return 0;
>  
> -			if (insn->type == INSN_CALL && insn->call_dest->static_call_tramp) {
> -				list_add_tail(&insn->static_call_node,
> -					      &file->static_call_list);
> -			}
> +			if (insn->type == INSN_CALL)
> +				static_call_add(insn, file);
>  
>  			break;
>  
> 

  parent reply	other threads:[~2021-03-17 21:01 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-15 14:23 [KEYS] 4a00e5e212: WARNING:at_arch/x86/kernel/static_call.c:#__static_call_validate kernel test robot
2021-03-16  8:04 ` Sumit Garg
2021-03-17  3:01   ` Oliver Sang
2021-03-17  7:25     ` Sumit Garg
2021-03-17  8:41       ` Peter Zijlstra
2021-03-17  8:59         ` Peter Zijlstra
2021-03-17  9:02           ` Peter Zijlstra
2021-03-17 11:55             ` Sumit Garg
2021-03-17 12:45               ` [PATCH] objtool, static_call: Don't emit static_call_site for .exit.text Peter Zijlstra
2021-03-17 12:45                 ` [PATCH] objtool,static_call: " Peter Zijlstra
2021-03-17 13:37                 ` [PATCH] objtool, static_call: " Sumit Garg
2021-03-17 13:37                   ` [PATCH] objtool,static_call: " Sumit Garg
2021-03-17 21:55                   ` [PATCH] objtool, static_call: " Jarkko Sakkinen
2021-03-17 21:55                     ` [PATCH] objtool,static_call: " Jarkko Sakkinen
2021-03-18  4:42                     ` [PATCH] objtool, static_call: " Sumit Garg
2021-03-18  4:42                       ` [PATCH] objtool,static_call: " Sumit Garg
2021-03-17 21:01                 ` Jarkko Sakkinen [this message]
2021-03-17 21:01                   ` Jarkko Sakkinen
2021-03-18  0:02                 ` [PATCH] objtool, static_call: " Josh Poimboeuf
2021-03-18  0:02                   ` [PATCH] objtool,static_call: " Josh Poimboeuf
2021-03-18  7:59                   ` [PATCH] objtool, static_call: " Peter Zijlstra
2021-03-18  7:59                     ` [PATCH] objtool,static_call: " Peter Zijlstra
2021-03-18  8:30                     ` [PATCH] objtool, static_call: " Peter Zijlstra
2021-03-18  8:30                       ` [PATCH] objtool,static_call: " Peter Zijlstra
2021-03-18  8:47                       ` [PATCH] objtool, static_call: " Peter Zijlstra
2021-03-18  8:47                         ` [PATCH] objtool,static_call: " Peter Zijlstra
2021-03-17 21:00               ` [KEYS] 4a00e5e212: WARNING:at_arch/x86/kernel/static_call.c:#__static_call_validate Jarkko Sakkinen
2021-03-18 10:25         ` Peter Zijlstra
2021-03-18 11:03           ` Sumit Garg

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=YFJuMi9ZSJk5Ctvw@kernel.org \
    --to=jarkko@kernel.org \
    --cc=lkp@lists.01.org \
    /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.