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 35CD2155C97 for ; Mon, 28 Oct 2024 08:58:43 +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=1730105925; cv=none; b=mUj+IQV0VN5b6A7VZnXcqNRPorga7JnWXDaCX0f1VYRHsRwADGyUyENbYcX2IvfG+lGrYQXmvpolIPlPg8VNp3pcfThqiT7lr7wVyUeLnTQRJDx9abdJAoTdWo85QR8is/xsUq5gpsaIo6rA4TXBlr2As0lgYsj1bIlAR+2cV0Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1730105925; c=relaxed/simple; bh=KIBZkEQKwG2vsUBvKGjwFPZYZDY9aZXu2ruXx2f15ho=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=W52LXGZdkSc1pueE9GysFTzi+QbJjSFMFOfSeK+iu8F0tbmcRVpPuYL1zMoehq5V2VtMTeoJcYvsqVT+edUQbYR9vfkvlLyXY8UZa28mz9WusY7dLOubggKneOTJRd5WtjqIKtgIzksRNUtP4xcePY9a98oUt5cPucLrOtN2Oq4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=BFucrraw; 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=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="BFucrraw" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1730105923; x=1761641923; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=KIBZkEQKwG2vsUBvKGjwFPZYZDY9aZXu2ruXx2f15ho=; b=BFucrraw4hmSPYR62eMbEwTVaaH0oeZq2XdjLGld6Xec9JN22GKcNUrQ i00IxQQe2e7+C64J1YzNl9dvUMmCSeBqv+JF9Ne9xdHQjBXJ2v28iQ4wr +tzPBmJe76revm7svVXjNFZE0vDyJRKwEP8N0KIH5q5WHbCaCPjTxqmnE ve9qj2W9dpbKRqUKrBYNN9cG7MbKZ+5+/6EcvGHGV/o2zQQJfMONxff9q uECFzaDgI1szI9t8cXCxJkdXyhlodf3WYF3IwYv8OInJlKnv1mjT4JqBR itA3QJyD94cKH77+eX2LnaMxNl/g216tHL2QYnCdz7/972XRDvtp6jBpB Q==; X-CSE-ConnectionGUID: 8w5CcSwXSxaCtwl04uNW5g== X-CSE-MsgGUID: o1hpaFeQSY2qZXv+Ll/fXA== X-IronPort-AV: E=McAfee;i="6700,10204,11238"; a="29904811" X-IronPort-AV: E=Sophos;i="6.11,238,1725346800"; d="scan'208";a="29904811" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by fmvoesa108.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Oct 2024 01:58:42 -0700 X-CSE-ConnectionGUID: 3xGqxhKITtGP8LFkIYidmQ== X-CSE-MsgGUID: yStzSllZQA6rLRRdaYPPSQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,238,1725346800"; d="scan'208";a="81657512" Received: from ubik.fi.intel.com (HELO localhost) ([10.237.72.184]) by fmviesa008.fm.intel.com with ESMTP; 28 Oct 2024 01:58:35 -0700 From: Alexander Shishkin To: Nam Cao , Anna-Maria Behnsen , Frederic Weisbecker , Thomas Gleixner , Andreas Hindborg , Alice Ryhl , Miguel Ojeda , Kees Cook , linux-kernel@vger.kernel.org Cc: Nam Cao , Greg Kroah-Hartman , "Martin K. Petersen" , Alexandre Belloni , "Rafael J. Wysocki" , Linus Walleij , Sebastian Reichel , Will Deacon , Jon Mason , Jaehoon Chung , Hans Verkuil , Jassi Brar , Pavel Machek , Dmitry Torokhov , Jonathan Cameron , Andi Shyti , Alex Deucher , Jani Nikula , Rob Clark , Lucas De Marchi , Zack Rusin , "Michael S. Tsirkin" , Jason Gunthorpe , Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Takashi Iwai , alexander.shishkin@linux.intel.com Subject: Re: [PATCH 00/44] hrtimers: Switch to new hrtimer interface functions (4/5) In-Reply-To: References: Date: Mon, 28 Oct 2024 10:58:34 +0200 Message-ID: <87y128txhh.fsf@ubik.fi.intel.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 Nam Cao writes: > This is the forth part of a 5-part series (split for convenience). All 5 > parts are: > > Part 1: https://lore.kernel.org/lkml/cover.1729864615.git.namcao@linutronix.de > Part 2: https://lore.kernel.org/lkml/cover.1729864823.git.namcao@linutronix.de > Part 3: https://lore.kernel.org/lkml/cover.1729865232.git.namcao@linutronix.de > Part 4: https://lore.kernel.org/lkml/cover.1729865485.git.namcao@linutronix.de > Part 5: https://lore.kernel.org/lkml/cover.1729865740.git.namcao@linutronix.de Which one do I need to click on to see the actual hrtimer_setup*() implementations? Why is it even a separate series? Please, don't make people click on things. > To use hrtimer, hrtimer_init() (or one of its variant) must be called, and > also the timer's callfack function must be setup separately. "callback", right? > That can cause misuse of hrtimer. For example, because: > - The callback function is not setup > - The callback function is setup while it is not safe to do so These are not examples, these are hypotheticals. Do either of these things actually happen in the codebase? > To prevent misuse of hrtimer, this series: > - Introduce new functions hrtimer_setup*(). These new functions are > similar to hrtimer_init*(), except that they also sanity-check and > initialize the callback function. No, it doesn't. This series only converts some drivers. I'd like to see the sanity-checking in question, since it's the big selling point. But IMO, "switching to a cleaner hrtimer API" or some words to that effect is a better justification than sanity checking. I'm not objecting to the idea, it's just carried out weirdly. > - Introduce hrtimer_update_function() which checks that it is safe to > change the callback function. The 'function' field of hrtimer is then > made private. Also not in this series. > - Convert all users to use the new functions. > - Some minor cleanups on the way. Thanks, -- Alex