The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: xur@google.com
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
	linux-kernel@vger.kernel.org,
	Sriraman Tallam <tmsriram@google.com>,
	Han Shen <shenhan@google.com>,
	Krzysztof Pszeniczny <kpszeniczny@google.com>
Subject: Re: [PATCH 2/2] objtool: dead_end function change for split functions
Date: Mon, 3 Nov 2025 22:19:10 +0100	[thread overview]
Message-ID: <20251103211910.GK3245006@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20251103185154.1933872-2-xur@google.com>

On Mon, Nov 03, 2025 at 06:51:54PM +0000, xur@google.com wrote:
> From: Rong Xu <xur@google.com>
> 
> Function Splitting can potentially move all return instructions
> into the cold (infrequently executed) section of the function.
> If this happens, the original function might be incorrectly
> flagged as a dead-end function.
> 
> The consequence is an incomplete ORC table, which leads to an unwind
> error, and subsequently, a livepatch failure.
> 
> This patch adds the support of the dead_end_function check for
> split function.
> 
> Signed-off-by: Rong Xu <xur@google.com>
> Reviewed-by: Sriraman Tallam <tmsriram@google.com>
> Reviewed-by: Han Shen <shenhan@google.com>
> Reviewed-by: Krzysztof Pszeniczny <kpszeniczny@google.com>
> ---
>  tools/objtool/check.c | 88 +++++++++++++++++++++++++++++++++----------
>  1 file changed, 69 insertions(+), 19 deletions(-)
> 
> diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> index c2ee3c3a84a62..b752cf508d09a 100644
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -237,6 +237,73 @@ static bool is_rust_noreturn(const struct symbol *func)
>  		str_ends_with(func->name, "_fail"));
>  }
>  
> +static bool __dead_end_function(struct objtool_file *, struct symbol *, int);
> +
> +/*
> + * Check if the target of a sibling_call instruction is a dead_end function.
> + * Note insn must be a sibling call.
> + */
> +static inline bool __dead_end_sibling_call(struct objtool_file *file,
> +		struct instruction *insn, int recursion) {

Please: cino=(0:0
also for functions { on a new line.

> +	struct instruction *dest = insn->jump_dest;
> +
> +	if (!dest)
> +		/* sibling call to another file */
> +		return false;

I know this is just code movement, but this wants {} per coding style.

> +
> +	/* local sibling call */
> +	if (recursion == 5) {
> +		/*
> +		 * Infinite recursion: two functions have
> +		 * sibling calls to each other.  This is a very
> +		 * rare case.  It means they aren't dead ends.
> +		 */
> +		return false;
> +	}
> +
> +	return __dead_end_function(file, insn_func(dest), recursion+1);
> +}
> +
> +/*
> + * Handling split functions. Mimic the workflow in __dead_end_function.
> + */
> +static bool __dead_end_split_func(struct objtool_file *file,
> +			struct symbol *func, int recursion)

cino=(0:0

> +{
> +	char section_name[256];
> +	struct section *sec;
> +	struct instruction *insn;
> +
> +	/*
> +	 * Use a fixed-size buffer (max 256) to avoid malloc. If the section
> +	 * length exceeds this limit, we return a conservative value. This is
> +	 * a safe fallback and does not compromise functional correctness.
> +	 */
> +	if (snprintf(section_name, sizeof(section_name), ".text.split.%s",
> +		     func->name) >= sizeof(section_name)) {

That is a terribly confusing line-break to read. Might've been better to
split after the greate-or-equal sign.

> +		fprintf(stderr, "Error: Function name '%s' too long.\n", func->name);
> +		return false;
> +	}
> +
> +	sec = find_section_by_name(file->elf, section_name);
> +	if (!sec)
> +		return false;
> +
> +	sec_for_each_insn(file, sec, insn) {
> +		if (insn->type == INSN_RETURN)
> +			return false;
> +	}
> +
> +	sec_for_each_insn(file, sec, insn) {
> +		if (is_sibling_call(insn)) {
> +			if (!__dead_end_sibling_call(file, insn, recursion))
> +				return false;
> +		}
> +	}
> +
> +	return true;
> +}
> +
>  /*
>   * This checks to see if the given function is a "noreturn" function.
>   *
> @@ -298,33 +365,16 @@ static bool __dead_end_function(struct objtool_file *file, struct symbol *func,
>  	 */
>  	func_for_each_insn(file, func, insn) {
>  		if (is_sibling_call(insn)) {
> -			struct instruction *dest = insn->jump_dest;
> -
> -			if (!dest)
> -				/* sibling call to another file */
> -				return false;
> -
> -			/* local sibling call */
> -			if (recursion == 5) {
> -				/*
> -				 * Infinite recursion: two functions have
> -				 * sibling calls to each other.  This is a very
> -				 * rare case.  It means they aren't dead ends.
> -				 */
> -				return false;
> -			}
> -
>  			/*
>  			 * A function can have multiple sibling calls. All of
>  			 * them need to be dead ends for the function to be a
>  			 * dead end too.
>  			 */
> -			if (!__dead_end_function(file, insn_func(dest), recursion+1))
> +			if (!__dead_end_sibling_call(file, insn, recursion))
>  				return false;
>  		}
>  	}
> -
> -	return true;
> +	return __dead_end_split_func(file, func, recursion);
>  }

Aside from some coding style nits, this seems like it will do.


  reply	other threads:[~2025-11-03 21:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-03 18:51 [PATCH 1/2] objtool: fix the check for dead_end function with multiple sibliing calls xur
2025-11-03 18:51 ` [PATCH 2/2] objtool: dead_end function change for split functions xur
2025-11-03 21:19   ` Peter Zijlstra [this message]
2025-11-03 21:40     ` Rong Xu
2025-11-03 21:01 ` [PATCH 1/2] objtool: fix the check for dead_end function with multiple sibliing calls Peter Zijlstra
2025-11-03 21:11   ` Rong Xu

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=20251103211910.GK3245006@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=jpoimboe@kernel.org \
    --cc=kpszeniczny@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shenhan@google.com \
    --cc=tmsriram@google.com \
    --cc=xur@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox