From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DFD5579CF for ; Tue, 2 Dec 2025 20:20:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764706860; cv=none; b=rOCxt0oCHTFNr9Xx8Ry4E2aRb7+TDA5Ak9yq++t5EKZppP+olIVrItqXmNswLeuqwu24ipXykFdZskiyJWXUDKvFS0YHPnK2HpHBipz87PtfZ9cRu5xP9RCbH0mF2DGs4jRhykmJHvUN83BqmoBxvtq1K4cb4CzPC12+wwclh00= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764706860; c=relaxed/simple; bh=5laB8oUfMzifrlMwdNdM3nBDv16NlInmXfwipi4OWoQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=BREfCP+0XiHe70puroG/7ozIomKDcA4CtUUjpS+9Lemmlu8H5e8Rz1bLsq6Am9qU9iBSb+D/HuJKbJv+qWbuVUzb9NASfRjJCoOxD5PPtwUmHGrAfID8heuP2/7EhBY8YiZJamsF05f+WXsXzmTRIBqyhQm4xX8ldElS21nIJN0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YXy3Mmmj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YXy3Mmmj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B1A81C4CEF1; Tue, 2 Dec 2025 20:20:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764706859; bh=5laB8oUfMzifrlMwdNdM3nBDv16NlInmXfwipi4OWoQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YXy3Mmmjsg6nSogcGWvQD06QvLHmq2fxaAyBFIJQz89RQb+u8l07sPo2oRtYXEtKe GRU7VoNouYJRj5mY5Pa3M+MDhHroN6luBI0noCygGEDdOd1HH/MNiYbyvTXHRSvZyL TDPnJwWtWwzxVGFaPyc0S/ot5MB94aM7pCw4lfwop8ptNqgA6+Dv1cPAitay/Np/kA NpaPZnoEP1f67QeMrahFEKiRn4rAeME9D3vn20Zgrz+bYZ5OohbE6mNqB5F4uDg0nM nnarTF6acYRNkgb6U5i5SZOZ7vtNIOUIJsdGhodwAI0IST0AL0CPlgu25Q6L1PaQAn 7qTJmLItpo19A== Date: Tue, 2 Dec 2025 21:20:55 +0100 From: Ingo Molnar To: Josh Poimboeuf Cc: x86@kernel.org, linux-kernel@vger.kernel.org, Nathan Chancellor , Peter Zijlstra , Alexandre Chartre , David Laight Subject: Re: [PATCH] objtool: Fix stack overflow in validate_branch() Message-ID: References: <21bb161c23ca0d8c942a960505c0d327ca2dc7dc.1764691895.git.jpoimboe@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: * Josh Poimboeuf wrote: > On Tue, Dec 02, 2025 at 09:11:50AM -0800, Josh Poimboeuf wrote: > > > > > That's weird - how can a user-space tool run into stack > > > > > limits, are they set particularly conservatively? > > > > > > > > On my Fedora system, "ulimit -s" is 8MB. You'd think that would be > > > > enough :-) > > > > > > > > In this case, objtool had over 20,000 stack frames caused by recursively > > > > following over 7,000(!) conditional jumps in a single function. > > > > > > Ouch ... > > > > > > ... which means that very likely we'll run into this problem again. :-/ > > > > > > Time to add stack overflow self-detection? > > > > > > I've attached a simple proof-of-concept that uses > > > sigaltstacks based SIGSEGV handler to catch a stack > > > overflow: > > > > > > starship:/s/stack-overflow> ./overflow > > > # Starting stack recursion: > > > > > > # WARNING: SIGSEGV received: Possible stack overflow detected! > > > > > > starship:/s/stack-overflow> > > > > > > Could we add something like this to objtool, with > > > perhaps a look at the interrupted stack pointer from > > > SIGSEGV_handler(), to make sure the SIGSEGV was due to > > > a stack overflow? > > > > Yes, I think that would be wise. I've been thinking objtool could use a > > SIGSEGV handler anyway, as it crashes more often than one would hope, > > with a cryptic non-helpful error message for the user. > > > > I'll work on it. > > Is something like the below sufficient? Or do you think we should add > logic to distinguish the stack overflow from other crashes? > > ---8<--- > > From: Josh Poimboeuf > Subject: [PATCH] objtool: Improve error message for SIGSEGV > > When the kernel build fails due to an objtool seg fault, the error > message is confusing: > > make[5]: *** [scripts/Makefile.build:503: drivers/scsi/qla2xxx/qla2xxx.o] Error 139 > make[5]: *** Deleting file 'drivers/scsi/qla2xxx/qla2xxx.o' > make[4]: *** [scripts/Makefile.build:556: drivers/scsi/qla2xxx] Error 2 > make[3]: *** [scripts/Makefile.build:556: drivers/scsi] Error 2 > make[2]: *** [scripts/Makefile.build:556: drivers] Error 2 > make[1]: *** [/home/jpoimboe/git/linux/Makefile:2013: .] Error 2 > make: *** [Makefile:248: __sub-make] Error 2 > > Add a signal handler which prints an error message like: > > drivers/scsi/qla2xxx/qla2xxx.o: error: objtool: SIGSEGV (Segmentation Fault) received at address 0x7ffc5f33bf30 > > ... and re-raises the signal so the core dump still gets triggered. Could we somehow determine that 0x7ffc5f33bf30 is off the end of the stack or so and that this is a stack overflow? Maybe objtool could have a look into /proc/self/maps: 7fc21a543000-7fc21a544000 rw-p 0003f000 103:02 96610309 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 7fc21a544000-7fc21a545000 rw-p 00000000 00:00 0 7ffd6a5a0000-7ffd6a5c1000 rw-p 00000000 00:00 0 [stack] ? Thanks, Ingo