Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1818141ybl; Thu, 19 Dec 2019 03:34:23 -0800 (PST) X-Google-Smtp-Source: APXvYqyOzDPvwqukgGmulqVLbnqY07KV8Hk/Ol6XhL58tyOmRUKm52IJ+drZ+5D3wACPZuc9NucW X-Received: by 2002:a05:6830:12d0:: with SMTP id a16mr8607818otq.8.1576755263812; Thu, 19 Dec 2019 03:34:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576755263; cv=none; d=google.com; s=arc-20160816; b=IAFBNb9eMe3jNuFYcqpwKTI1wfQny+v4JxlEpUe5qOIL8P7O63c80+8UslIRjz64b/ HwsNopDVIv8TXiT44chtTTP/3a0UKFAGsxmI0gCYLboJ0GAOkTedPOMqQQbt183iOZIf hyjArUgbHZV8rbkk6LwxibooVG1YO0Pcmxl1MWKQI2dFlULzkS9c/38LGz92n/oQwcdt ostl8zIj8qVIb9kgPMZxJjjQYnKmYZAmC/xk964gP+AfycUA6C8jkPsOPo4SVYXfqbcQ uxohlauwoicNTSyQyjN8eud89jiqbB8xiOmgYf+Rut/s4TCkJjgs+3koBfBbkKAqLBc6 yduQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=KQVy1060cIcwdmA+aV3D7jzIs8ekG/8Yaj3TYu2HIws=; b=GrMbMRe+9CVXmSKt87CpdYF1MI6FDQF9SAjvCexHtzLSkK3Rys6kPZjN+/EE/KH+5i SUCM6MgVhY73Yw1kNznXx3o2Rh7RCtq9HSLl1jUyFbE7E3tvHT0XG9f46nK+F7G8fanM WAhXlB0Ra0xloy2v5YEe5EQ0oAQgaJO6o7e1SAL9jq9EZRcHkndpJUqb5uO9q7MC3rxx 2EdtzdJ+w714ioQPsm3jlrWTpmqzsuXJutsveXiYf8C1k0uxT0SoDcZC3+qQ/4zQZJB7 jW9yIUIo8KdGHXiXj7kO1KeLR04CVTkYDh77oPjlk5bucZZH2186I8aqdut5jRIjn1Jg FfNw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=epPaeNaK; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k7si1473190otp.22.2019.12.19.03.34.12; Thu, 19 Dec 2019 03:34:23 -0800 (PST) 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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=epPaeNaK; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726769AbfLSLcJ (ORCPT + 99 others); Thu, 19 Dec 2019 06:32:09 -0500 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:54900 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726656AbfLSLcI (ORCPT ); Thu, 19 Dec 2019 06:32:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1576755127; 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=KQVy1060cIcwdmA+aV3D7jzIs8ekG/8Yaj3TYu2HIws=; b=epPaeNaKmi+ogpQYq5/P7IsgijAekT88f9uUs7Jlxm9egU3iGO8/xjnmxdwECe/dW9TtLQ MJ6Ff/rEuxiwLWn8uYVPEEYZKVZa6pNN+gook/kGqypSOsnFYE9OtF8TAMcAV5ZVPl1OnN LwUt73xBK3xdCjo3dd+bIPaM/Edus/o= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-177-1dfDxRcXPu6wUynMAn751g-1; Thu, 19 Dec 2019 06:32:02 -0500 X-MC-Unique: 1dfDxRcXPu6wUynMAn751g-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 34B2D803A4C; Thu, 19 Dec 2019 11:31:56 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-116-98.ams2.redhat.com [10.36.116.98]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3D99963B89; Thu, 19 Dec 2019 11:31:53 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id C695311AAA; Thu, 19 Dec 2019 12:31:51 +0100 (CET) Date: Thu, 19 Dec 2019 12:31:51 +0100 From: Gerd Hoffmann To: Daniel Vetter Cc: John Garry , Ezequiel Garcia , "kongxinwei (A)" , "Chenfeng (puck)" , "airlied@linux.ie" , Thomas Zimmermann , Linuxarm , "dri-devel@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , dbueso@suse.de Subject: Re: Warnings in DRM code when removing/unbinding a driver Message-ID: <20191219113151.sytkoi3m7rrxzps2@sirius.home.kraxel.org> References: <07899bd5-e9a5-cff0-395f-b4fb3f0f7f6c@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, > > Like I said, for most drivers > > > you can pretty much assume that their unload sequence has been broken > > > since forever. It's not often tested, and especially the hotunbind > > > from a device (as opposed to driver unload) stuff wasn't even possible > > > to get right until just recently. > > > > Do you think it's worth trying to fix this for 5.5 and earlier, or just > > switch to the device-managed interface for 5.6 and forget about 5.5 and > > earlier? > > I suspect it's going to be quite some trickery to fix this properly > and everywhere, even for just one driver. Lots of drm drivers > unfortunately use anti-patterns with wrong lifetimes (e.g. you can't > use devm_kmalloc for anything that hangs of a drm_device, like > plane/crtc/connector). Except when it's for a real hotunpluggable > device (usb) we've never bothered backporting these fixes. Too much > broken stuff unfortunately. While being at it: How would a driver cleanup properly cleanup gem objects created by userspace on hotunbind? Specifically a gem object pinned to vram? cheers, Gerd