Received: by 2002:a4a:301c:0:0:0:0:0 with SMTP id q28-v6csp391966oof; Mon, 24 Sep 2018 22:33:07 -0700 (PDT) X-Google-Smtp-Source: ACcGV62B952Xt3nbZ+XYSezXJkj9Ggh6GKqL7SQ2BheM8Q11pZWEBV57o4RovE1E+UyVuDSplYIy X-Received: by 2002:a17:902:46a4:: with SMTP id p33-v6mr1804537pld.205.1537853587001; Mon, 24 Sep 2018 22:33:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537853586; cv=none; d=google.com; s=arc-20160816; b=y41w9j87c40lXJjruItP+RK6Le0SusY9LSY6n3IHcY9x5GL9iGxKIuFnDLpbEsa4Fi /3Or8Z2KUsB64GVAIANsmcTDTkRoV1wp8RXrhKRbJwqAsKrk7SXQAFFpU+7Cda6jKKa7 y++nQ3Dw9BHsBN6vdbJDGYb/iDY5e4XtsYtUGhrZLYOtc80MvPdgW7YtFM3SyKE7dtFm sfo0UZCakjZNZVl6MIUzCaTWPY/1K2DMXdDETsNgq/CnQG/Bro0Q3fjp3dJKegd05wgT v7uI6HOB7ZVtlL3A6d9I24F8fLMK5yydkUqbs+1LLvbTMX36jGaei14s+IH+OUzFSR41 cFlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=oITY9A3MK6KRBHOl+0lAb5mZHK8/ci2mcYEKkYZAx2c=; b=r/tV+7eE79nY1PIqKk38+YqVeYetKhBaLtVySq2NwY/hCZrAPQP7dy3mW1+iO5WNvM nbUdeUWhdTWh2dSmCvDL1waNphHHem60lRizUKF+Ve/jhKYxsnHqXHRIHO7e7f6Y+pJ1 IHhUMXL4GxevheMoTf5WqerHCVYQjRstGIFq7VpoafPE5d/LAVELvq6yhOg8ZgIKMO7x GkZn3dNpmwmuniWVTLO97JSOLci+p/v8/dlfSi/s0slJVn6hRx6TBKxOd/iTyLyniyUq D9o+6+cffJV6lc93lfrG3dzKJO3tzw2l4vIGAS3vvH1fSGaCOtpXmN5+L1qggkBq2x8N 5zaw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a71-v6si1374624pge.281.2018.09.24.22.32.51; Mon, 24 Sep 2018 22:33:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727292AbeIYLiZ (ORCPT + 99 others); Tue, 25 Sep 2018 07:38:25 -0400 Received: from ozlabs.org ([203.11.71.1]:42129 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725959AbeIYLiZ (ORCPT ); Tue, 25 Sep 2018 07:38:25 -0400 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 42K8pm6Y4Nz9s47; Tue, 25 Sep 2018 15:32:32 +1000 (AEST) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au From: Michael Ellerman To: Guenter Roeck , Christoph Hellwig Cc: iommu@lists.linux-foundation.org, Greg Kroah-Hartman , Robin Murphy , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Marek Szyprowski , Bjorn Helgaas , linux-pci@vger.kernel.org, Benjamin Herrenschmidt , Paul Mackerras , linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 4/4] dma-mapping: clear dev->dma_ops in arch_teardown_dma_ops In-Reply-To: <20180922150119.GA14761@roeck-us.net> References: <20180827084711.23407-1-hch@lst.de> <20180827084711.23407-5-hch@lst.de> <20180922150119.GA14761@roeck-us.net> Date: Tue, 25 Sep 2018 15:32:30 +1000 Message-ID: <87r2hi3zwx.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Guenter Roeck writes: > Hi, > > On Mon, Aug 27, 2018 at 10:47:11AM +0200, Christoph Hellwig wrote: >> There is no reason to leave the per-device dma_ops around when >> deconfiguring a device, so move this code from arm64 into the >> common code. >> Signed-off-by: Christoph Hellwig >> Reviewed-by: Robin Murphy > > This patch causes various ppc images to crash in -next due to NULL > DMA ops in dma_alloc_attrs(). I finally remembered where you autobuilder is :) https://kerneltests.org/builders/qemu-ppc-next/builds/970/steps/qemubuildcommand_1/logs/stdio Looks like mac99 at least is failing. Just reproduced it on my setup. > Looking into the code, the macio driver tries to instantiate on > the 0000:f0:0d.0 PCI address (the driver maps to all Apple PCI IDs) > and fails. This results in a call to arch_teardown_dma_ops(). Later, > the same device pointer is used to instantiate ohci-pci, which > crashes in probe because the dma_ops pointer has been cleared. > > I don't claim to fully understand the code, but to me it looks like > the pci device is allocated and waiting for a driver to attach to. > See arch/powerpc/kernel/pci_of_scan.c:of_create_pci_dev(). > If attaching a driver (here: macio) fails, the same device pointer > is then reused for the next matching driver until a match is found > and the device is successfully instantiated. Of course this fails > quite badly if the device pointer has been scrubbed after the first > failure. > > I don't know if this is generic PCI behavior or ppc specific. > I am copying pci and ppc maintainers for additional input. I would guess this is some PPC special sauce O_o Will have a look. cheers