Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp790470pxa; Wed, 12 Aug 2020 13:27:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy875vNMmuy0J9+9ZaaPp/BorF/vfyiGD8ssXx1fBKfA9ZGbBgp+NlAYtqvb+jf4awvA3c8 X-Received: by 2002:a17:906:4007:: with SMTP id v7mr746090ejj.197.1597264036904; Wed, 12 Aug 2020 13:27:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597264036; cv=none; d=google.com; s=arc-20160816; b=adQSaK3GQ1NHw5JWHMcO/mrknd+nKCcxnAql+IegE53ttB43l4azB52fe/mwbQ4tpF cF4J8cqfcAs+lL9i+esCG6nzwe74p2ldsWEYzSlMZWDjgAP+XJk7OMP6jBy+ksH2bvK9 Ya6pto5k3WhAyZztOTWPqajPT0D9zZD5IVA9Ci+rU6XmKFFMsPHu/aAllWAUdLUwNAQj Ko3dvtpCq0UCYMipU2KS4MLqJ7Z6r767/GUcrkPSYgTuMmlcSqD0Litbh57xFpnUB2Yu 7Nm96QbftkdYfF2f/LbtXji9ZMrCetHh7+WFdGqPhmv7cktkjo1ly6U6s09wI3hxSm8V 9mqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=8H8TVBEAPEQ/WHPW1Sh/X30DQj6ryKYwYWZd0y5wUzs=; b=zCimvPW1+8LzYoFpxTMr/E80yHY2G9cjUTkfR4/XUW98jUwxxRzs7n17caTAGIYb4q DkxG7zDJYz965iofw/vc7eLC7ZSdw5FNB1Ld5FdicmCFuOh6MK79TdvaZSrZFLF5rncg Ggvj5wX0thCqn1f9/4VIoatUQxQBaBNtdcd+kbT98YvYYyMKmvDc7EsvrSefqt7/fVgT SrDDcAJh0T0VoX++lNQ/9sBmQSqAbePUls45t5BgV1E7/ZKJbhvLb6z9Z6G3WWgPRMgj svl/3eSWE3y0/EB3bEY2fMH/XKryfGiAYo2f72I2h0mKPyWG2ObIijl0Rzx3HnGMWPiv nviQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j3si1943260edt.444.2020.08.12.13.26.52; Wed, 12 Aug 2020 13:27:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726685AbgHLUVV (ORCPT + 99 others); Wed, 12 Aug 2020 16:21:21 -0400 Received: from cmta20.telus.net ([209.171.16.93]:58207 "EHLO cmta20.telus.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726030AbgHLUVU (ORCPT ); Wed, 12 Aug 2020 16:21:20 -0400 Received: from montezuma.home ([154.5.226.127]) by cmsmtp with SMTP id 5xFLkg3D9ljNx5xFNkm9WQ; Wed, 12 Aug 2020 14:21:18 -0600 X-Telus-Authed: none X-Authority-Analysis: v=2.3 cv=Z8aS40ZA c=1 sm=1 tr=0 a=f8b3WT/FcTuUJCJtQO1udw==:117 a=f8b3WT/FcTuUJCJtQO1udw==:17 a=kj9zAlcOel0A:10 a=x7bEGLp0ZPQA:10 a=COSDN44dAAMA:10 a=pGLkceISAAAA:8 a=e5mUnYsNAAAA:8 a=XlkWa5Bfyw0YRDVwgmMA:9 a=CjuIK1q_8ugA:10 a=Vxmtnl_E_bksehYqCbjh:22 Date: Wed, 12 Aug 2020 13:21:15 -0700 (PDT) From: Zwane Mwaikambo To: Lyude Paul cc: Daniel Vetter , tcamuso@redhat.com, dkwon@redhat.com, Linux Kernel , dri-devel Subject: Re: [PATCH] drm: assure aux_dev is nonzero before using it In-Reply-To: Message-ID: References: <20200811085830.GZ2352366@phenom.ffwll.local> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-CMAE-Envelope: MS4wfIACCZgqsl7hQ/V5ALQdJOX5hoBiAWLWNHcOudD4WTPn27pItJZX8X3z7CohxBXrrnmVbaVKJ1vkhU+4zZjJ7AKb9xusq0tvYU4/rd2IBBDl2UckdrVI 8Fy3wRp8q91bY639t572MU5EMXzTonJlR0SP1ZBm3WkW4m9cxTOa755+52hL/qtPe8VatsObSBwi0IYiXFl5m0VkbUeK+JRa3LgnLbaTQuHiaamaLErspTaL /JkCF/m7hGoZQ7Nl1tzZNCrwB3nOzSHMaRd90owBpWkoBRY1EEbRf5UK/C4Ca3W1gL/9xOqK/8rIp2CYd/+E209mTSyDzQvFRISQ5GXohls= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 12 Aug 2020, Lyude Paul wrote: > On Wed, 2020-08-12 at 16:10 +0200, Daniel Vetter wrote: > > On Wed, Aug 12, 2020 at 12:16 AM Zwane Mwaikambo wrote: > > > On Tue, 11 Aug 2020, Daniel Vetter wrote: > > > > > > > On Mon, Aug 10, 2020 at 10:11:50AM -0700, Zwane Mwaikambo wrote: > > > > > Hi Folks, > > > > > I know this thread eventually dropped off due to not identifying > > > > > the underlying issue. It's still occuring on 5.8 and in my case it > > > > > happened because the udev device nodes for the DP aux devices were not > > > > > cleaned up whereas the kernel had no association with them. I can > > > > > reproduce the bug just by creating a device node for a non-existent > > > > > minor > > > > > device and calling open(). > > > > > > > > Hm I don't have that thread anymore, but generally these bugs are solved > > > > by not registering the device before it's ready for use. We do have > > > > drm_connector->late_register for that stuff. Just a guess since I'm not > > > > seeing full details here. > > > > > > In this particular case, the physical device disappeared before the nodes > > > were cleaned up. It involves putting a computer to sleep with a monitor > > > plugged in and then waking it up with the monitor unplugged. > > > > We also have early_unregister for the reverse, but yes this sounds > > more tricky ... Adding Lyude who's been working on way too much > > lifetime fun around dp recently. > > -Daniel > > > Hi-I think just checking whether the auxdev is NULL or not is a reasonable > fix, although I am curious as to how exactly the aux dev's parent is getting > destroyed before it's child, which I would have thought would be the only way > you could hit this? Here is what it looks like without (1) and with (2) monitor connected. In the case where the monitor disappears during suspend, the device nodes aux3,4 are still around 1) No monitor connected ls -l /dev/drm* crw------- 1 root root 238, 0 Aug 6 22:32 /dev/drm_dp_aux0 crw------- 1 root root 238, 1 Aug 6 22:32 /dev/drm_dp_aux1 2) Monitor connected crw------- 1 root root 238, 0 Aug 6 22:32 /dev/drm_dp_aux0 crw------- 1 root root 238, 1 Aug 6 22:32 /dev/drm_dp_aux1 crw------- 1 root root 238, 2 Aug 11 14:51 /dev/drm_dp_aux2 crw------- 1 root root 238, 3 Aug 11 14:51 /dev/drm_dp_aux3 crw------- 1 root root 238, 4 Aug 11 14:51 /dev/drm_dp_aux4 > > > > > > > > > To me it still makes sense to just check aux_dev because the chardev > > > > > has > > > > > no way to check before calling. > > > > > > > > > > (gdb) list *drm_dp_aux_dev_get_by_minor+0x29 > > > > > 0x17b39 is in drm_dp_aux_dev_get_by_minor > > > > > (drivers/gpu/drm/drm_dp_aux_dev.c:65). > > > > > 60 static struct drm_dp_aux_dev > > > > > *drm_dp_aux_dev_get_by_minor(unsigned index) > > > > > 61 { > > > > > 62 struct drm_dp_aux_dev *aux_dev = NULL; > > > > > 63 > > > > > 64 mutex_lock(&aux_idr_mutex); > > > > > 65 aux_dev = idr_find(&aux_idr, index); > > > > > 66 if (!kref_get_unless_zero(&aux_dev->refcount)) > > > > > 67 aux_dev = NULL; > > > > > 68 mutex_unlock(&aux_idr_mutex); > > > > > 69 > > > > > (gdb) p/x &((struct drm_dp_aux_dev *)(0x0))->refcount > > > > > $8 = 0x18 > > > > > > > > > > static int auxdev_open(struct inode *inode, struct file *file) > > > > > { > > > > > unsigned int minor = iminor(inode); > > > > > struct drm_dp_aux_dev *aux_dev; > > > > > > > > > > aux_dev = drm_dp_aux_dev_get_by_minor(minor); > > > > > if (!aux_dev) > > > > > return -ENODEV; > > > > > > > > > > file->private_data = aux_dev; > > > > > return 0; > > > > > } > > > > > > > > > > > > > > > _______________________________________________ > > > > > dri-devel mailing list > > > > > dri-devel@lists.freedesktop.org > > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > >