Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 13 Dec 2022 12:52:20 +0000
From:   Will Deacon <will@kernel.org>
To:     Ard Biesheuvel <ardb@kernel.org>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org,
        linux-kernel@vger.kernel.org, kernel-team@android.com,
        maz@kernel.org
Subject: Re: [GIT PULL] arm64 updates for 6.2
Message-ID: <20221213125219.GC5719@willie-the-truck>
References: <20221209112500.GA3116@willie-the-truck>
 <CAHk-=wj-8gKB5SG0w_M2fK0KYyhZbNzDZ1W9H5pmisWzJ0XJEw@mail.gmail.com>
 <20221213121118.GB5719@willie-the-truck>
 <CAMj1kXFf0CYxL28T65WxXUbTwZHJET5Az+oDSxO04zsvkJqwSw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMj1kXFf0CYxL28T65WxXUbTwZHJET5Az+oDSxO04zsvkJqwSw@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On Tue, Dec 13, 2022 at 01:36:09PM +0100, Ard Biesheuvel wrote:
> On Tue, 13 Dec 2022 at 13:11, Will Deacon <will@kernel.org> wrote:
> > Ard -- do you think we could tweak the patching so that we patch the push
> > and the pop together (e.g. by tracking the two locations on a per-frame
> > basis and postponing the text poking until just before we return from
> > scs_handle_fde_frame())?
> >
> 
> The push and the pop are not necessarily balanced (there may be more
> than one pop for each push), and the opcode we look for
> (DW_CFA_negate_ra_state) may occur in places which are not actually a
> pop, so tracking these is not as straight-forward as this.

Duh, yes, of course. You only _execute_ one of the pops for a given run
through the function, but there could be numerous return points. So my
idea doesn't work at all :)

> What we could do is track the push and the first pop on a first pass,
> and if we don't encounter any unexpected opcodes, patch the push and
> do a second pass starting from the first pop. Or just simply run it
> twice and do no patching the first time around (the DWARF frames are
> not very big)

Doing a dry-run first sounds fairly easy to implement, so it would probably
be a good starting point. It also means that if anybody complains about the
overhead, then we can get them to work on doing it at build time instead!

Will