From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Dmitry Vyukov <dvyukov@google.com>,
syzbot <syzbot+488ddf8087564d6de6e2@syzkaller.appspotmail.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
syzkaller-bugs@googlegroups.com, viro@zeniv.linux.org.uk,
will@kernel.org, x86@kernel.org, live-patching@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [syzbot] upstream test error: KASAN: invalid-access Read in __entry_tramp_text_end
Date: Fri, 1 Oct 2021 22:10:24 -0700 [thread overview]
Message-ID: <20211002051024.bddvcr44eb4zuoxk@treble> (raw)
In-Reply-To: <20211001122706.GA66786@C02TD0UTHF1T.local>
On Fri, Oct 01, 2021 at 01:27:06PM +0100, Mark Rutland wrote:
> > So we may need to get rid of .fixup altogether. Especially for arches
> > which support livepatch.
> >
> > We can replace some of the custom .fixup handlers with generic handlers
> > like x86 does, which do the fixup work in exception context. This
> > generally works better for more generic work like putting an error code
> > in a certain register and resuming execution at the subsequent
> > instruction.
>
> I reckon even ignoring the unwind problems this'd be a good thing since
> it'd save on redundant copies of the fixup logic that happen to be
> identical, and the common cases like uaccess all fall into this shape.
>
> As for how to do that, in the past Peter and I had come up with some
> assembler trickery to get the name of the error code register encoded
> into the extable info:
>
> https://lore.kernel.org/lkml/20170207111011.GB28790@leverpostej/
> https://lore.kernel.org/lkml/20170207160300.GB26173@leverpostej/
> https://lore.kernel.org/lkml/20170208091250.GT6515@twins.programming.kicks-ass.net/
>
> ... but maybe that's already solved on x86 in a different way?
That's really cool :-) But it might be overkill for x86's needs. For
the exceptions which rely on handlers rather than anonymous .fixup code,
the register assumptions are hard-coded in the assembler constraints. I
think that works well enough.
> > However a lot of the .fixup code is rather custom and doesn't
> > necessarily work well with that model.
>
> Looking at arm64, even where we'd need custom handlers it does appear we
> could mostly do that out-of-line in the exception handler. The more
> exotic cases are largely in out-of-line asm functions, where we can move
> the fixups within the function, after the usual return.
>
> I reckon we can handle the fixups for load_unaligned_zeropad() in the
> exception handler.
>
> Is there anything specific that you think is painful in the exception
> handler?
Actually, after looking at all the x86 .fixup usage, I think we can make
this two-pronged approach work. Either move the .fixup code to an
exception handler (with a hard-coded assembler constraint register) or
put it in the function (out-of-line where possible). I'll try to work
up some patches (x86 only of course).
--
Josh
prev parent reply other threads:[~2021-10-02 5:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-04 11:57 [syzbot] upstream test error: KASAN: invalid-access Read in __entry_tramp_text_end syzbot
2021-09-17 15:03 ` Dmitry Vyukov
2021-09-21 16:51 ` Mark Rutland
2021-09-27 14:27 ` Dmitry Vyukov
2021-09-27 14:30 ` Dmitry Vyukov
2021-09-27 17:01 ` Mark Rutland
2021-09-27 17:18 ` Mark Rutland
2021-09-28 10:19 ` Dmitry Vyukov
2021-09-28 10:35 ` Mark Rutland
2021-09-29 1:36 ` Josh Poimboeuf
2021-09-29 7:39 ` Peter Zijlstra
2021-09-29 8:50 ` Mark Rutland
2021-09-29 9:59 ` Peter Zijlstra
2021-09-29 10:37 ` Mark Rutland
2021-09-29 11:43 ` Peter Zijlstra
2021-09-30 19:26 ` Josh Poimboeuf
2021-10-01 12:27 ` Mark Rutland
2021-10-02 5:10 ` Josh Poimboeuf [this message]
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=20211002051024.bddvcr44eb4zuoxk@treble \
--to=jpoimboe@redhat.com \
--cc=dvyukov@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=peterz@infradead.org \
--cc=syzbot+488ddf8087564d6de6e2@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=tglx@linutronix.de \
--cc=viro@zeniv.linux.org.uk \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).