From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E2C1B29AB07 for ; Fri, 22 May 2026 18:11:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.14 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779473466; cv=none; b=p77gTcFN1tl9BTBlk6o81lPJ+E+LmMIyvTf/FLO2aPKrZ/s7Fgvr6S8YULEDbqnYS5/U+S2tpFx6lkXnzoGK+UVi39rqqZnAd/LgCFbxnCFMWTeL47lvytmINUdgdkyPSphvKnBI2pRs8LwqIDMsbURAN5Mrra4kfMlEyU1tTXM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779473466; c=relaxed/simple; bh=jrUMl5Pj6W1zeeKqO5bZT+4B5c7mV/TBAJjBOPt581E=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=DhUEi3J381MTUxf50J/pyiOCoZDl8vBvtypMOVxoG3Tyv14ujXavDMwkJdbn64+ToITZ6pzEhSZ57fx4lUGy8a2zbhrFfPb4eKQb8s39VOVWU/LPT8JpjsalBuPA5BVNt4HxJtGCRW4DfLyIb2/0FRsYOyDmv3eoj6iLR4KBn+M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=VUkyWFKR; arc=none smtp.client-ip=192.198.163.14 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="VUkyWFKR" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1779473464; x=1811009464; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=jrUMl5Pj6W1zeeKqO5bZT+4B5c7mV/TBAJjBOPt581E=; b=VUkyWFKRfLYgxfdQDv7vcHXzaFEX5AjTJZbqXDXcCpiMjt7MKJiRQYh9 3B3fmcCu6ES9ffwT98/1+bTa3gLTk/pB1hmxkuAnNffiEuMpWmT+9KOr9 g6M7101u6YhQtexgAzpGq2D0zV8WIPaQ+BYLFp1I8dCdrsoVP3EqZtovd xWjBqm9+NJ3r1edINKCwmIA9ctcPQ5/LlZqOweJkkJ8dhnRXxBNwbg8AN ddkVUZ7bbD4mX2lQRy3DyCOBA0jfieK4U/FHnqcpQPdra9jJ66FBbrZiI 6974RsdL2iSKH3bY+QKTy6aQk27O4VBS9SvTJ4ddUkB3144hDADMqN0ur A==; X-CSE-ConnectionGUID: a7ExD/oSR8isVrNhdhRH/A== X-CSE-MsgGUID: gmimGTxcQBWGYPgGqQMaug== X-IronPort-AV: E=McAfee;i="6800,10657,11794"; a="80440579" X-IronPort-AV: E=Sophos;i="6.24,162,1774335600"; d="scan'208";a="80440579" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa108.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 May 2026 11:11:04 -0700 X-CSE-ConnectionGUID: huksGKwGQyWmHQy4pAxRFA== X-CSE-MsgGUID: 5g2D4wElRq2SNhxXUH4rTg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,162,1774335600"; d="scan'208";a="271325699" Received: from amilburn-desk.amilburn-desk (HELO localhost) ([10.245.244.187]) by orviesa002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 May 2026 11:10:59 -0700 Date: Fri, 22 May 2026 21:10:55 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Daniel Stone Cc: Nicolas Frattaroli , Simona Vetter , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Stanislav Lisovskiy , Louis Chauvet , Haneen Mohammed , Melissa Wen , Daniel Stone , Ian Forbes , Dmitry Baryshkov , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, kernel@collabora.com, wayland-devel@lists.freedesktop.org, Marius Vlad Subject: Re: [PATCH v9 2/2] drm: Send per-connector hotplug events Message-ID: References: <20260422-hot-plug-passup-v9-0-aef804255986@collabora.com> <20260422-hot-plug-passup-v9-2-aef804255986@collabora.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Patchwork-Hint: comment Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs Bertel Jungin Aukio 5, 02600 Espoo, Finland On Fri, May 22, 2026 at 06:58:26PM +0100, Daniel Stone wrote: > On Fri, 22 May 2026 at 14:06, Nicolas Frattaroli > wrote: > > On Thursday, 21 May 2026 17:00:17 Central European Summer Time Daniel Stone wrote: > > > On Wed, 22 Apr 2026 at 19:24, Nicolas Frattaroli > > > wrote: > > > > + /* Pick up any changes detected by the probe functions. */ > > > > + if (dev->mode_config.delayed_event) { > > > > > > Not your doing, as it was just the same before, but doesn't this read > > > need to be protected by the mode_config mutex? > > > > It looks like the fuzzy meaning of the mode_config.mutex came to > > bite here. It is set to true with the lock held in > > drm_helper_probe_single_connector_modes(), but set to false in this > > function without the lock, and always read without the lock > > (drm_kms_helper_poll_enable(), reschedule_output_poll_work()). Some > > of these calls happen in paths where it might be inconvenient to take > > a lock this coarse. > > > > Specifically, drm_helper_probe_single_connector_modes() has this > > comment right before setting delayed_event to true: > > > > /* > > * The hotplug event code might call into the fb > > * helpers, and so expects that we do not hold any > > * locks. Fire up the poll struct instead, it will > > * disable itself again. > > */ > > > > So there was a problem with accessing parts under a lock before, > > so if we're reintroducing the coarse lock wherever the boolean is > > accessed we might be going backwards here. > > Yeah, that makes sense - those are definitely called from an IRQ > context so it wouldn't be safe to take the mode_config mutex. > > I wonder if the safest path which guarantees eventual consistency is > to change the !trylock(mode_config) { goto out } path in > output_poll_execute() to jump directly to the schedule_delayed_work()? > That way we could read and modify delayed_event under the mode_config > mutex; the if (changed) path will not be taken if it wasn't possible > to take the mode_config mutex. I've been cursing at this delayed_event hack a couple of times. Seems to me that the correct solution would be to make drm_client_dev_hotplug() schedule its own work and do the actual work there instead of this direct call we have right now. -- Ville Syrjälä Intel