Received-SPF: pass (google.com: domain of linux-kernel+bounces-206652-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <CAHk-=wjHf6C_74VQPxmge-sMmu5yuhmNor1TaO0Uq--zrA13HA@mail.gmail.com>
 <28c74739-e775-4813-b2f1-b588e14b3674@rasmusvillemoes.dk>
In-Reply-To: <28c74739-e775-4813-b2f1-b588e14b3674@rasmusvillemoes.dk>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Fri, 7 Jun 2024 12:15:05 -0700
Message-ID: <CAHk-=wjf-8ko=w7SyGWRLZ5bL_iwgw8mky8cxvYzF3xHDHoCMQ@mail.gmail.com>
Subject: Re: objtool query: section start/end symbols?
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>, Peter Zijlstra <peterz@infradead.org>, 
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"

On Fri, 7 Jun 2024 at 02:52, Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote:
>
> FWIW, I did a POC some years ago but either never managed to send it, or
> never got a response. It did boot in virtme and I managed to get gdb to
> do disassembly to show that the dentry hash lookup did become a 'shift
> immediate'.
>
> https://github.com/Villemoes/linux/tree/rai

Looks conceptually very similar to what I do, except I literally
_only_ rewrite the constant itself in the instruction stream.

You end up using these replacement sequences, which certainly works,
but limits your instruction scheduling a bit (ie the minimal size ends
up being a full branch to the thunk.

I started out wanting to literally replace a single 8-bit constant in
a shift-instruction that might be smaller than the jump.

That said, you then made your approach work just fine by just
combining the shift with the address load, so it's not a single small
instruction that gets replaced any more.

And honestly, I think your approach may be better than mine.

The "replace constant in one instruction" approach works fine in my
tests, and gcc in particular seems to actually take advantage of the
instruction scheduling freedom (clang less so).

But your thunking approach would probably be much easier on
architectures like arm64 where the "load a constant" thing can be a
lot less convenient than one single contiguous value in memory.

Would you be willing to resurrect your thing for a modern kernel? I'll
certainly try it out next to mine?

                    Linus