From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C52B5C433F5 for ; Sat, 2 Oct 2021 05:13:03 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7FAE861AAC for ; Sat, 2 Oct 2021 05:13:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7FAE861AAC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Qyc2HH9MyWg4SsH7zxp76M1480eoFUA78xU6eo/vNKY=; b=U1tto8qo3+x5B9 Kcpgvss/4g7+EUekXsL6oXwPstuo7fcVQt4MOymbQMt7FbozTznHVUQbbXexAXl5Mmb3Jb3Y8brCP Vm9aPNUfn+/Qi07zBuzQJdZWM58geSneSNFXA8/NICffQgZScUg8H3tiwAti60hI8t8PpokSl1DYc frBd9xTPW7Sbz8aR+wc+uwEWpj0H+3tYcUluSrSRKKN3wlw6U2UEr1hgfa7wmTAtV7KZn39EU3aUe mltcChkaM+k47piVWFydw7LVZtH1yxRRwnD+dAwhDYbn6abkNoxDME3MSr9TcsVRYtkypByg6OVkw BUCzXJ2KtG6Gd7CuI6YQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mWXID-001nET-OW; Sat, 02 Oct 2021 05:10:37 +0000 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mWXI9-001nDe-JG for linux-arm-kernel@lists.infradead.org; Sat, 02 Oct 2021 05:10:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1633151431; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2llZTC7o2LsdAZtu4bkMyBA1hnJDlag5HFNAp4HjTvs=; b=eaU4vH6EXvLDESduRn8bcBR+AsvAY/sazGN1M1EYvw3LlX24LqhDU8spy/qH3gyWCgj4f1 xKjDXyM0Y7un7LpB+v1Kgu1vQoO2r7SEYL86Jph5A3c6umIsfKiMH8gZQMX0XEEJ8iq0dD ephDT0ZfoFE7icFsSJCSFEDa2PMAQcY= Received: from mail-oo1-f71.google.com (mail-oo1-f71.google.com [209.85.161.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-351-6s-jKKrtNC2etvaXJ3Wn9Q-1; Sat, 02 Oct 2021 01:10:30 -0400 X-MC-Unique: 6s-jKKrtNC2etvaXJ3Wn9Q-1 Received: by mail-oo1-f71.google.com with SMTP id x23-20020a4a3957000000b0029aff3ae536so8611735oog.0 for ; Fri, 01 Oct 2021 22:10:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=2llZTC7o2LsdAZtu4bkMyBA1hnJDlag5HFNAp4HjTvs=; b=5a1pCJN3Dc5AWAp1i1aTs7XQmX2EPKHJkfEkWJZA7CJrXqLM+34NlBwDWkl8JnAa2o NwHOlzxVQ2Xh6P2dH+u5kzNQw8bCd7atB7WvKHavwkr5A5F6JhjXa/ylp84M4Z9745zL oa6E530XGBXm8NWTQCvakdGmta07WNvowq4OPS6PRNFnxgxKEzMKEbC/LG9yaLAeR2oB LZ9XYqQdg6uZGwNxdOTH282gx4s9ueJUJmveTBzAIDx7k4o77czuaerD2rfenXOhmhcs nDHP6/MXvUW974JX8n/eecdo3OQ+ybIRLPgRQOs0KFANOIbLvBf8vzGLs/y9wGKNtOij G6DQ== X-Gm-Message-State: AOAM530DMxKcatJu8F71aKODV3WUXmr/J+ufEQoUj0nbxd3G54Y+Db9O htizPUXEG2Y0D3mqA4bHp2hiXVi6f2VMIqZ4xSwHXpq2xzbgoYd03/fma3AxrG4JiqGFE2MKu5N rET+aX6kr5nYloNebiNPWYF9nXqQYwZO2Ew0= X-Received: by 2002:a05:6820:548:: with SMTP id n8mr1494826ooj.2.1633151429203; Fri, 01 Oct 2021 22:10:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzMZBKsU0l2A3zI3qrE5E96ZbV26roVRCXpLzW4En0hQYpxaJDCLcDEsPcOAys9BDWAL5EOCA== X-Received: by 2002:a05:6820:548:: with SMTP id n8mr1494777ooj.2.1633151427993; Fri, 01 Oct 2021 22:10:27 -0700 (PDT) Received: from treble ([2600:1700:6e32:6c00::15]) by smtp.gmail.com with ESMTPSA id q2sm1579594ooe.12.2021.10.01.22.10.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Oct 2021 22:10:27 -0700 (PDT) Date: Fri, 1 Oct 2021 22:10:24 -0700 From: Josh Poimboeuf To: Mark Rutland Cc: Peter Zijlstra , Dmitry Vyukov , syzbot , Linux ARM , 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 Subject: Re: [syzbot] upstream test error: KASAN: invalid-access Read in __entry_tramp_text_end Message-ID: <20211002051024.bddvcr44eb4zuoxk@treble> References: <20210928103543.GF1924@C02TD0UTHF1T.local> <20210929013637.bcarm56e4mqo3ndt@treble> <20210929085035.GA33284@C02TD0UTHF1T.local> <20210929103730.GC33284@C02TD0UTHF1T.local> <20210930192638.xwemcsohivoynwx3@treble> <20211001122706.GA66786@C02TD0UTHF1T.local> MIME-Version: 1.0 In-Reply-To: <20211001122706.GA66786@C02TD0UTHF1T.local> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=jpoimboe@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211001_221033_947170_801459B3 X-CRM114-Status: GOOD ( 27.18 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel