[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200327041941.ykycltxtaulj4wqz@treble>
Date: Thu, 26 Mar 2020 23:19:41 -0500
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: tglx@...utronix.de, linux-kernel@...r.kernel.org, x86@...nel.org,
mhiramat@...nel.org, mbenes@...e.cz
Subject: Re: [PATCH v4 01/13] objtool: Remove CFI save/restore special case
On Thu, Mar 26, 2020 at 04:38:41PM +0100, Peter Zijlstra wrote:
> On Thu, Mar 26, 2020 at 08:44:48AM -0500, Josh Poimboeuf wrote:
> > On Thu, Mar 26, 2020 at 01:58:44PM +0100, Peter Zijlstra wrote:
> > > So instr_begin() / instr_end() have this exact problem, but worse. Those
> > > actually do nest and I've ran into the following situation:
> > >
> > > if (cond1) {
> > > instr_begin();
> > > // code1
> > > instr_end();
> > > }
> > > // code
> > >
> > > if (cond2) {
> > > instr_begin();
> > > // code2
> > > instr_end();
> > > }
> > > // tail
> > >
> > > Where objtool then finds the path: !cond1, cond2, which ends up at code2
> > > with 0, instead of 1.
> >
> > Hm, I don't see the nesting in this example, can you clarify?
>
> Indeed no nesting here, but because they can nest we have that begin as
> +1, end as -1 and then we sum it over the code flow.
>
> Then given that, the above, ends up as -1 + 1 in the !cond1,cond2 case,
> because that -1 escapes the cond1 block.
Ok, I see now. I wonder if you can take a similar approach to the
save/restore patch I sent out. Though I guess the nesting adds an
additional wrinkle I'm too tired to think about.
--
Josh
Powered by blists - more mailing lists