From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.16]) (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 1041832E743 for ; Mon, 17 Aug 2026 15:44:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.16 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786981450; cv=none; b=EiVQV3FOcCjQNViFht05JDi5+9A/qTQY5tCgF94TABfa0Y4zHCjnDq9t2LblJGHPCgwEiHf0f/1H9Vm/I0qhXtgzSReHsNlA2rxqtV4uOQ83C89xT5b6hJvwdu3M5M3o+/TLoJujiVsi/RBdeAITtT5vHwDGNNgCWNMj4ETwwOw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786981450; c=relaxed/simple; bh=6px8fbU4NZnhaTI9qrdyDgi1GHxBKZMvRpwPVmhFheA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qZIwNO8D0CJK+aBKQmYnVSAp0tQPQofyzcU3kBqxNIQdF2hum9ZBOWhve+/V1LR7XLsgB4tCTdT6MvLmoMevXR6FJCurd0KhSCI6XV1sPpA4N6Y+FJpVDtXNqBOBDkCrWqWOyjwh4gvHB4KqxRVFm59E76wBJeJWSmg1e1Nv/9M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=ChbA1uwv; arc=none smtp.client-ip=192.198.163.16 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=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="ChbA1uwv" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1786981449; x=1818517449; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=6px8fbU4NZnhaTI9qrdyDgi1GHxBKZMvRpwPVmhFheA=; b=ChbA1uwv/o/x5jQKMlUYa9RAGpdh1AN1w8UaPbBJmzYnmtAJ/Yfv4t3k 8bmZaIY6WtmktA85I0SsKgAvhqcoox4fL5h2ayU8agZekx1fKU4b/JgMi BbLd520Jgl4NLAcqVvM4szOpoaOL+6xE7ecq1Y9NQQ7UifhUBQ37Hnd5O 8Qd2T3IpJcfOlr3eiWqIZkGfudkWfHNBpiRJ1+scB350EMOCIZ6BRxF0T roFHEgkaP6uMam6cFWZL+nS4ERmwdh2Haprqy/73uExMf3MjVmDAZ8267 pYcEfeBb8jygHcpyBLFKoHRLNH1csK48wwcdPVErAJjVPm7kjF4m57FFE Q==; X-CSE-ConnectionGUID: scj43cJ1QXWLaM+Ruly7cQ== X-CSE-MsgGUID: 03oJlzVuSdKVFzMrtQkVTQ== X-IronPort-AV: E=McAfee;i="6800,10657,11877"; a="74990814" X-IronPort-AV: E=Sophos;i="6.25,229,1779174000"; d="scan'208";a="74990814" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Aug 2026 08:44:08 -0700 X-CSE-ConnectionGUID: g8V1vOt8SJmAb6wAbmRJwQ== X-CSE-MsgGUID: +nlBgfWASUqSBbT2K/CAew== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,229,1779174000"; d="scan'208";a="264492297" Received: from klitkey1-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.245.67]) by orviesa008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Aug 2026 08:44:06 -0700 Date: Mon, 17 Aug 2026 18:44:04 +0300 From: Andy Shevchenko To: Surendra Singh Cc: Andy Shevchenko , andy@kernel.org, geert@linux-m68k.org, chris.packham@alliedtelesis.co.nz, linux-kernel@vger.kernel.org Subject: Re: [PATCH] auxdisplay: seg-led-gpio: fix work initialization race and convert to devm_add_action_or_reset() Message-ID: References: <20260724025524.12726-1-kr494167@gmail.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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo On Sun, Aug 02, 2026 at 04:30:16PM +0530, Surendra Singh wrote: > I checked the other drivers in drivers/auxdisplay/ and found that > drivers/auxdisplay/max6959.c has the exact same pattern: > > 1. INIT_DELAYED_WORK(&priv->work, max6959_disp_update) is called inside > max6959_linedisp_get_map_type() (map query callback). > 2. max6959_i2c_remove() calls cancel_delayed_work_sync(&priv->work) > before linedisp_unregister(&priv->linedisp). > > I can prepare a 2-patch series fixing max6959.c as well. Yes, please do. Or did I miss them? > Furthermore, we could add devm_linedisp_register() to line-display.c > to simplify linedisp teardown across all auxdisplay drivers. That's what we all are waiting for to avoid some UAF types of bugs. > On Sun, 2 Aug 2026 at 14:59, Andy Shevchenko wrote: > > On Fri, Jul 24, 2026 at 5:55 AM wrote: > > > INIT_DELAYED_WORK(&priv->work, seg_led_update) was previously called inside > > > seg_led_linedisp_get_map_type(), which is invoked during/after > > > linedisp_register(). Initializing a delayed_work structure inside a map > > > query callback can re-initialize an active work item or race with > > > seg_led_linedisp_update(). > > > > > > In addition, seg_led_remove() called cancel_delayed_work_sync(&priv->work) > > > before linedisp_unregister(&priv->linedisp), allowing sysfs updates to > > > reschedule work after cancel_delayed_work_sync() completed. > > > > > > Fix these by moving INIT_DELAYED_WORK() to probe() and using > > > devm_add_action_or_reset() for devm-managed cleanup. Registering > > > seg_led_unregister_linedisp after seg_led_cancel_work ensures proper LIFO > > > teardown order (sysfs interface unregistered first, followed by work > > > cancellation), allowing seg_led_remove() to be removed entirely. > > > > I think we have more drivers than this one with the same issue, no? If > > so, can we solve this once for all (the existing and possible future > > ones)? -- With Best Regards, Andy Shevchenko