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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7E6FAC4332F for ; Tue, 18 Oct 2022 09:25:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229552AbiJRJZK (ORCPT ); Tue, 18 Oct 2022 05:25:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60724 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229717AbiJRJZJ (ORCPT ); Tue, 18 Oct 2022 05:25:09 -0400 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A506138448 for ; Tue, 18 Oct 2022 02:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1666085099; x=1697621099; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=UMCO5mJkxdgXG8Vg18aqKASsvHeMgG5yqkmJ96uzOXg=; b=EJZhXAlsGmLmg3CVfzqPko+rPHMmjjvi0aC/J1Daaz3YzKs1vc0jpXPb HOqVy/XXmOnNnlVmuipyIQfaxxoeiZXorCsAwL+MAWm1jmKwB+smRV4co kkNYDSVestiB6OvhCEem6JE1oJXNWjiQlUKeNvEVxu7KcINuaUv5PJk7Z DM6zNvM/dV2CoN57RbCynJseyNhvkbf8s3wGFVh00ucltC6vHvF0dXarE eqLXa9VjmaRH0yQ17juH3ziyC0SLb9sgoOvVyXsmlVg5vCTpsQdojslmb SDT+Ge3V5AFOV8ym7O/7JPLuK937wqZZCnjZoMHx8E+0CxB9MkT3Jcgxq g==; X-IronPort-AV: E=McAfee;i="6500,9779,10503"; a="303663486" X-IronPort-AV: E=Sophos;i="5.95,193,1661842800"; d="scan'208";a="303663486" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Oct 2022 02:24:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10503"; a="771119489" X-IronPort-AV: E=Sophos;i="5.95,193,1661842800"; d="scan'208";a="771119489" Received: from stinkpipe.fi.intel.com (HELO stinkbox) ([10.237.72.191]) by fmsmga001.fm.intel.com with SMTP; 18 Oct 2022 02:24:54 -0700 Received: by stinkbox (sSMTP sendmail emulation); Tue, 18 Oct 2022 12:24:53 +0300 Date: Tue, 18 Oct 2022 12:24:53 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Simon Ser Cc: dri-devel@lists.freedesktop.org, Daniel Vetter , Jonas =?iso-8859-1?Q?=C5dahl?= , stable@vger.kernel.org Subject: Re: [PATCH 2/2] drm/connector: send hotplug uevent on connector cleanup Message-ID: References: <20221017153150.60675-1-contact@emersion.fr> <20221017153150.60675-2-contact@emersion.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20221017153150.60675-2-contact@emersion.fr> X-Patchwork-Hint: comment Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Mon, Oct 17, 2022 at 03:32:01PM +0000, Simon Ser wrote: > A typical DP-MST unplug removes a KMS connector. However care must > be taken to properly synchronize with user-space. The expected > sequence of events is the following: > > 1. The kernel notices that the DP-MST port is gone. > 2. The kernel marks the connector as disconnected, then sends a > uevent to make user-space re-scan the connector list. > 3. User-space notices the connector goes from connected to disconnected, > disables it. > 4. Kernel handles the the IOCTL disabling the connector. On success, > the very last reference to the struct drm_connector is dropped and > drm_connector_cleanup() is called. > 5. The connector is removed from the list, and a uevent is sent to tell > user-space that the connector disappeared. > > The very last step was missing. As a result, user-space thought the > connector still existed and could try to disable it again. Since the > kernel no longer knows about the connector, that would end up with > EINVAL and confused user-space. So is the uevent sent by the mst delayed destroy work useless now, or what is going on there? > > Fix this by sending a hotplug uevent from drm_connector_cleanup(). > > Signed-off-by: Simon Ser > Cc: stable@vger.kernel.org > Cc: Daniel Vetter > Cc: Lyude Paul > Cc: Jonas Ådahl > --- > drivers/gpu/drm/drm_connector.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > index e3142c8142b3..90dad87e9ad0 100644 > --- a/drivers/gpu/drm/drm_connector.c > +++ b/drivers/gpu/drm/drm_connector.c > @@ -582,6 +582,9 @@ void drm_connector_cleanup(struct drm_connector *connector) > mutex_destroy(&connector->mutex); > > memset(connector, 0, sizeof(*connector)); > + > + if (dev->registered) > + drm_sysfs_hotplug_event(dev); > } > EXPORT_SYMBOL(drm_connector_cleanup); > > -- > 2.38.0 > -- Ville Syrjälä Intel 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 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DFE5BC433FE for ; Tue, 18 Oct 2022 09:25:05 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 2F72410E102; Tue, 18 Oct 2022 09:25:03 +0000 (UTC) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by gabe.freedesktop.org (Postfix) with ESMTPS id D077D10E102 for ; Tue, 18 Oct 2022 09:24:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1666085098; x=1697621098; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=UMCO5mJkxdgXG8Vg18aqKASsvHeMgG5yqkmJ96uzOXg=; b=l5SorvrEMSVPQEkHbidCeLQkxoJsRSKKV2rf3F3IF2b8Hyji3FYPEsqv sA7AbdZeypjvn1SeNcoDZOS/Evztp8SmVPBfywVBSRXZqR+pJhH4JLwGn ugMy0tpNYJQ8Dvj5JPIO7/KdYuLCAXgT553AQzKFSMgFOK2eBVBtg42Ih OF12srV2qtRwg/Pf4L99oudETV4pOF0SZpBz0rsfxFlVB20Yd8CjDwYQF 75eEr+om2koqz2b95k3jvAR8jA6s/16GxwT/gsMheAnCbMWcuAVx0QH7m mUik5zpmYiQ8ua1UdthdAYmOiwDoqsX4cRANWGOVBsZIQYFIBY+Ix+UUU Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10503"; a="306033084" X-IronPort-AV: E=Sophos;i="5.95,193,1661842800"; d="scan'208";a="306033084" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Oct 2022 02:24:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10503"; a="771119489" X-IronPort-AV: E=Sophos;i="5.95,193,1661842800"; d="scan'208";a="771119489" Received: from stinkpipe.fi.intel.com (HELO stinkbox) ([10.237.72.191]) by fmsmga001.fm.intel.com with SMTP; 18 Oct 2022 02:24:54 -0700 Received: by stinkbox (sSMTP sendmail emulation); Tue, 18 Oct 2022 12:24:53 +0300 Date: Tue, 18 Oct 2022 12:24:53 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Simon Ser Subject: Re: [PATCH 2/2] drm/connector: send hotplug uevent on connector cleanup Message-ID: References: <20221017153150.60675-1-contact@emersion.fr> <20221017153150.60675-2-contact@emersion.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20221017153150.60675-2-contact@emersion.fr> X-Patchwork-Hint: comment X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Daniel Vetter , Jonas =?iso-8859-1?Q?=C5dahl?= , stable@vger.kernel.org, dri-devel@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Mon, Oct 17, 2022 at 03:32:01PM +0000, Simon Ser wrote: > A typical DP-MST unplug removes a KMS connector. However care must > be taken to properly synchronize with user-space. The expected > sequence of events is the following: > > 1. The kernel notices that the DP-MST port is gone. > 2. The kernel marks the connector as disconnected, then sends a > uevent to make user-space re-scan the connector list. > 3. User-space notices the connector goes from connected to disconnected, > disables it. > 4. Kernel handles the the IOCTL disabling the connector. On success, > the very last reference to the struct drm_connector is dropped and > drm_connector_cleanup() is called. > 5. The connector is removed from the list, and a uevent is sent to tell > user-space that the connector disappeared. > > The very last step was missing. As a result, user-space thought the > connector still existed and could try to disable it again. Since the > kernel no longer knows about the connector, that would end up with > EINVAL and confused user-space. So is the uevent sent by the mst delayed destroy work useless now, or what is going on there? > > Fix this by sending a hotplug uevent from drm_connector_cleanup(). > > Signed-off-by: Simon Ser > Cc: stable@vger.kernel.org > Cc: Daniel Vetter > Cc: Lyude Paul > Cc: Jonas Ådahl > --- > drivers/gpu/drm/drm_connector.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > index e3142c8142b3..90dad87e9ad0 100644 > --- a/drivers/gpu/drm/drm_connector.c > +++ b/drivers/gpu/drm/drm_connector.c > @@ -582,6 +582,9 @@ void drm_connector_cleanup(struct drm_connector *connector) > mutex_destroy(&connector->mutex); > > memset(connector, 0, sizeof(*connector)); > + > + if (dev->registered) > + drm_sysfs_hotplug_event(dev); > } > EXPORT_SYMBOL(drm_connector_cleanup); > > -- > 2.38.0 > -- Ville Syrjälä Intel