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=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham 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 533EDC43381 for ; Wed, 13 Mar 2019 16:34:51 +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 22BE52146E for ; Wed, 13 Mar 2019 16:34:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="aYjeSuM7"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=nvidia.com header.i=@nvidia.com header.b="Vxsnr4Kv" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 22BE52146E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=nvidia.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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=bombadil.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=IpI845Yr9roQkveIDTwMSVXniAmDC+LZ26i5bfi+p6A=; b=aYjeSuM7nVSzQHfTYm5Nu0FJa Tgs4+Suywa6DnhD6T3M08/wg/XXD/aAbZYd9g+zGZsxM9PQJwKaEgHMTLscnbEuw6ymA3SN0TyHtw P4RhfgXiGjsUkjHc1dVrxeoGfs70+L/3DuNApDkE5c3En/PvBOixqSmgXRzi3e/EDW/ftjbZdDUUG ueDURtu/Lh7zdqRlUxVIKt32ijAL8sfUyJwB9P2sfBY+eMtcgMCRfK+dbrU9NRhcoOAgHuJURjLNF AxiFv4nFNatjJyOpltsjSkpSiCIRd1hhl2QllJGn5U2R9243CTVi8Lx37WDBpX8fRSy3swhJ0mYgj 1lr8uJwmg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h46q5-0001QI-N8; Wed, 13 Mar 2019 16:34:45 +0000 Received: from hqemgate15.nvidia.com ([216.228.121.64]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1h46q1-0001Or-2Y for linux-arm-kernel@lists.infradead.org; Wed, 13 Mar 2019 16:34:43 +0000 Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqemgate15.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Wed, 13 Mar 2019 09:34:28 -0700 Received: from hqmail.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Wed, 13 Mar 2019 09:34:40 -0700 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Wed, 13 Mar 2019 09:34:40 -0700 Received: from localhost (172.20.13.39) by HQMAIL101.nvidia.com (172.20.187.10) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 13 Mar 2019 16:34:39 +0000 Date: Wed, 13 Mar 2019 17:34:36 +0100 From: Thierry Reding To: Marc Zyngier Subject: Re: [PATCH 1/5] irqchip/gic-pm: add driver remove support Message-ID: <20190313163435.GA6926@ulmo> References: <1552474956-25513-1-git-send-email-spujar@nvidia.com> <0cd78fb7-4bcb-b735-54ca-24a179b9ff72@arm.com> MIME-Version: 1.0 In-Reply-To: X-NVConfidentiality: public User-Agent: Mutt/1.11.3 (2019-02-01) X-Originating-IP: [172.20.13.39] X-ClientProxiedBy: HQMAIL107.nvidia.com (172.20.187.13) To HQMAIL101.nvidia.com (172.20.187.10) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1552494868; bh=PCsiFwVufoorb6xcp9YrXnDDKZGGhPhm1u5gQIV8Zgk=; h=X-PGP-Universal:Date:From:To:CC:Subject:Message-ID:References: MIME-Version:In-Reply-To:X-NVConfidentiality:User-Agent: X-Originating-IP:X-ClientProxiedBy:Content-Type: Content-Disposition; b=Vxsnr4Kv3jY6CyWAAVxkZ6mhVCeEOya8fTeq6FF0jfPHKrlAvW5jL9G2zcxBvI0v+ rkkFMpavxKC5nFjba437QuynSoV7YU4biznXO+0FSx5qkKhzmIHtNSiR8pCIBBluUR cLPxyskXQ6ihwZJ7+UTYcn2GutT40MrW7/jomhSMFGqzkEEXYfnLUoq5iD9wRVDaZ4 +TPXyqvQy2DGlYac1vTybH8VLpzMSvokitqVL0BvV3wx8FqZ4NA81+KUT4PGDVmZ1k RBjo+/peUSu/AK7BuiY/6rLhqj8LesoQy1GlNyP5gQVuxk7SQ84jqynsr9GGSCwg3y 58EG7EkhL+/tw== X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190313_093441_127622_DB2F69CE X-CRM114-Status: GOOD ( 24.83 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: heiko@sntech.de, julien.thierry@arm.com, maxime.ripard@bootlin.com, catalin.marinas@arm.com, Sameer Pujar , will.deacon@arm.com, christoffer.dall@arm.com, stefan.wahren@i2se.com, jonathanh@nvidia.com, jagan@amarulasolutions.com, andy.gross@linaro.org, drjones@redhat.com, jason@lakedaemon.net, marc.w.gonzalez@free.fr, olof@lixom.net, linux-tegra@vger.kernel.org, horms+renesas@verge.net.au, tglx@linutronix.de, bjorn.andersson@linaro.org, ezequiel@collabora.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, enric.balletbo@collabora.com Content-Type: multipart/mixed; boundary="===============7478058630934964704==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============7478058630934964704== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 13, 2019 at 02:20:41PM +0000, Marc Zyngier wrote: > On 13/03/2019 13:50, Sameer Pujar wrote: > >=20 > > On 3/13/2019 4:52 PM, Marc Zyngier wrote: > >> First things first: > >> > >> - Where is the cover letter? > >> - This series should be flagged as v2, as it not the same as the one y= ou > >> sent last week. > > I had the dilemma whether to name this series as v2 or not, thought the= =20 > > commits > > in the series are different and v2 may not be necessary. >=20 > This is an iteration on the same theme. Please always bump up the > counter. Better do it more often than not. >=20 > > Also felt commit messages are descriptive enough and all belong to=20 > > irq-gic-pm, > > hence did not send cover letter. > > If you suggest so, I will send a cover letter next patch version(v2) >=20 > You should always send a cover letter if you have more than a single patc= h. >=20 > >> > >> On 13/03/2019 11:02, Sameer Pujar wrote: > >>> This is a preparatory patch for using irq-gic-pm driver as module and= thus > >>> implement remove() call for the driver. Details of remove() are as be= low, > >>> > >>> * pm_runtime_force_suspend() is added to balance runtime PM, otherw= ise > >>> following is seen: "agic-controller: Unbalanced pm_runtime_enable= !" > >>> * Function gic_teardown() is exported from gic driver and called in= remove > >>> to perform io unmap. > >>> * pm_clk_destroy() to free clock resources > >>> * irq is unmapped and freed with irq_dispose_mapping() > >>> > >> Let's be clear, I have no desire to export any GIC symbol at all. Why > >> should we do this? This "driver" is the tiniest thing, and making it > >> modular doesn't get us anything. > >> > >> So what's the rational for doing so? > > Reason for this was, the driver gets used for AGIC block and audio is n= ot > > boot critical and hence module option was preferred. >=20 > Sure, but look at the result: >=20 > - you remove your gic-pm module > - the MMIO mapping disappears > - the GIC data structures *are still live* > - a driver does a disable_irq() on an interrupt routed to this block > (because nothing has taken the interrupts away, as far as the kernel is > concerned) > - ... > - profit! (or kernel panic, your choice) I suppose we could use device links to model the dependency, but perhaps it's not worth it for something like the GIC. The AGIC is somewhat of an outlier because it serves a fairly encapsulated part of the system, so it would be manageable to make it unloadable. > Even better if something else in the system has mapped anything that > ends up in the same vmalloc range. Congratulations, you have now > corrupted unsuspecting memory. This reminds me of the e1000 corruption > bug. Great stuff. Can you elaborate on this point? How would unloading a driver cause memory corruption in another driver's mapped memory? I've never heard of this before, so I want to make sure I understand what to look out for in the future. > So for the whole thing, NAK. You don't pull an irqchip from under the > kernel's feet. Maybe we should also set the driver's .suppress_bind_attrs =3D true while at it, to prevent anyone from trying to force unbind the driver via sysfs? Thierry --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAlyJMRgACgkQ3SOs138+ s6HZUBAAhqhibTf2QlD1pmZBh0+EyimR5sRBhDhvjOhPJhCnBi3Qt4vhe8lBIcu4 ZZWIgrv4uUL6R98sqN7J9Q5sEpfANyI1cFogUTAlJRh8VdQDZRl6eUcuLFblfHIo q0U3hNbNO7Tol2mcq3t/cdxNWwXGgVsMxtpu1SrRI8eXGDoXp/7bq0K5aCSwfXhX VXYJrRwVKbB1g33Z6yNT3xJFdfNt4vyuYo2DsQ1nupzVfNwQNQizIM0G/Tmp2pOr wecewxKHCWv3c4iHCDrugyYDPPgrso8HkrRqOPUueZCh2Uz1XhG+Fsdx9qAXPavR b3r9PD27d8aiBhkV4Vs2nfGQY7J/LzyHCFbTtnUun+hFzCMo6ms3AP6SF5Xk867n 0Gf99xLgSG8K7AGDc19XrVY0JHTx8AWrIdI4GLpJHTRrWlx0x7UHA9THPCQkfgfb zc778BAcDPadKIstO9WZCB59jIHri5ZqLQ354SY93HqVmByFgXMEe6uei+/SxZ5x BY7fg6VllbS2zLonsUHEF7Vm+VN8azl6U/s3MGzVuGVwAv6LRk1Bxu0NvYtmNOVk AxWsZgu3QDzaYonvA/dKqTfC4lmmnLp8puBHvqAd3F1NW8dBUu2h1INf58XpKmI5 v+6fX0BxqbDJvJkRG/aewKs0bboglLFX0fHHnaz8LfwG+Cg8Ues= =H1Cm -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- --===============7478058630934964704== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============7478058630934964704==--