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 X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 42D42C433DB for ; Mon, 22 Mar 2021 16:51:43 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 D1BC961972 for ; Mon, 22 Mar 2021 16:51:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D1BC961972 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=uT0W6j0ILu74VwrN6giQrAqLo43apJQp7TmC8LWIcfw=; b=HequqTLAhZniojekXXTZtSFIG QK02Wz4D5pHh4wzCNTVVv+L0viaISgdE2JNmxdM5+NECUPsv7Qos+xfBDAzJPlMM9Wg5uz2hvBUCo rzWsgNliNctQ4z9Y1NbuoAl3xOSFPkJ/5RGUyLsR8rCn0/AxUf/v2LslSSJsYZd1kezqNgt2xItBo NfoAh3Suctcea0yafmKrkSoyOBmY2X6i3oYuadqVFxhlXDBavqZ75Sd/3QGwXeZX3UkmDx0d5/DiX A4gkgZTv2kuZ/yiex/axxNOB3xZHuNCI/e9pZwZXSa55DBoAuO50kn8e3QLjL0khCkBgpxmiScs05 I6Si7Lidw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lONkc-00C5EL-KQ; Mon, 22 Mar 2021 16:49:59 +0000 Received: from mail-ej1-x633.google.com ([2a00:1450:4864:20::633]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lONkW-00C5Ca-RG for linux-arm-kernel@lists.infradead.org; Mon, 22 Mar 2021 16:49:55 +0000 Received: by mail-ej1-x633.google.com with SMTP id hq27so22413130ejc.9 for ; Mon, 22 Mar 2021 09:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jXJ5Sar/Ifz6JJAimj38gRVDAr3OzSV/gaJ8wXJmb9M=; b=LW9du4C9WPfXG+G3KZi3P6ozsF9gt4VrbAR4Z62UoD7bHlHwHdeQB3vQ53Ci/uZrnM MCj6yCTpxhDpbCzv7Huqey/XxpEVNrkqnz+LIJg8hRLGIeATT4Jyu5l3a98TeAgR0aOk Eqx37cgwY3RQze7KoCi4XrLF3XH19tHN5MKZVnCnB9OD/Nd/fkkpUT54zJ0KEONLiCNy ubuzzVqkcvIrVQgwmRwnPKLJzTtyUzZL5Kmvm57shs3hdriNL/IV6SXe49tenbBIZB6+ kfe2MdDtVqw245DnHwSXblRbUr9RjfFer7rM588aqSzblIgHPG0vU12qMtyRTWM/TiJL JDmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jXJ5Sar/Ifz6JJAimj38gRVDAr3OzSV/gaJ8wXJmb9M=; b=UEWGGkr4WXJexeJMgFAeijRt9+Sg7e5pKkbArr0ujI087OMQN2iR26ndaLt7l6tfWd zNkayNuqgaMp2ABhn7Rk0H9PH06TWTy7mS2/ygZ9z8VV2XhSHeqRZ9M4v6CCqj2GZwDB bQm6pFKS251CK+8YY5JccjtJU2J1xKOUKBJx+pkFnS5jiguzFMxnrEQxvAArEzkUApmh qrO4U4dHe+tKAYQcwRHMmPaH8uIIROluaGM2lEdZWGLAkNpyOfv7S5TAlHmb1n1KAQeK bPyhtDFRAuSkilZMqDkv3Gl33oAxQUpCqtF0RJjD1dhUZBgkFp8+MtgAU/36PgYiKCZV DNcg== X-Gm-Message-State: AOAM533xhPPJ+nOjE3GUNFGabqTBr3ZNRRAZYg6c1t6cCzMnvaiWcV+Q H24hScf502311UYsNhHfMSRdEy7uUCNEEX7MZ0uWgA== X-Google-Smtp-Source: ABdhPJwMTly+dnvGOZCcyUiuvTg4XNpbJvl0rmYqw0PzBbiRyF066Lh4cY57dwH0UfNGxEzShtwgHYkpi8rizqlJ3j4= X-Received: by 2002:a17:906:8a65:: with SMTP id hy5mr753913ejc.250.1616431792272; Mon, 22 Mar 2021 09:49:52 -0700 (PDT) MIME-Version: 1.0 References: <771d89a8-b7e0-6095-b101-e7ae91bcdc85@huawei.com> In-Reply-To: <771d89a8-b7e0-6095-b101-e7ae91bcdc85@huawei.com> From: Peter Maydell Date: Mon, 22 Mar 2021 16:49:24 +0000 Message-ID: Subject: Re: arm64 syzbot instances To: John Garry Cc: Arnd Bergmann , Dmitry Vyukov , Mark Rutland , Marc Zyngier , Will Deacon , Ard Biesheuvel , Linux ARM , syzkaller , LKML , =?UTF-8?B?QWxleCBCZW5uw6ll?= X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210322_164952_973038_AB909180 X-CRM114-Status: GOOD ( 20.26 ) 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 Mon, 22 Mar 2021 at 16:36, John Garry wrote: > > >> > >> There's apparently a bit in the PCI spec that reads: > >> The host bus bridge, in PC compatible systems, must return all > >> 1's on a read transaction and discard data on a write transaction > >> when terminated with Master-Abort. > >> > >> which obviously applies only to "PC compatible systems". > > > > Right. As far as I can tell, all ARMv8 and most ARMv7 based SoCs > > do this to be more compatible with PC style operating systems like > > Linux, but you are right that the specification here does not > > mandate that, and the older ARMv5 SoCs seem to be compliant > > as well based on this. > >> TBH I'm having difficulty seeing why the kernel should be doing > >> this at all, though. The device tree tells you you have a PCI > >> controller; PCI supports enumeration of devices; you know exactly > >> where everything is mapped because the BARs tell you that. > >> I don't see anything that justifies the kernel in randomly > >> dereferencing areas of the IO or memory windows where it hasn't > >> mapped anything. > > BIOS has described a CPU-addressable PIO region in the PCI hostbridge, > and the kernel has mapped it: > > [ 3.974309][ T1] pci-host-generic 4010000000.pcie: IO > 0x003eff0000..0x003effffff -> 0x0000000000 > > So I don't see why any accesses there should fault. As requested above, do you have the PCI spec reference for why the PIO region is supposed to do -1/discard for parts of the PIO region where the kernel hasn't mapped any devices ? For classic PCI, at least, the spec does not seem to mandate it. thanks -- PMM _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel