From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 39E46137930 for ; Wed, 15 Jan 2025 16:04:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736957071; cv=none; b=p70MhAuucEVQLMT/1mVsNIMpGxJZPo5zIqI52qZIv2tjWL6t24TwRGnZ8JYC9pCvOmqwLlCh9KLW01eicZc55GmYVdA5s9hgHjENse7eti6DZk2M2eKskLWplUSl3+w+db09shRqFeTw6J2FR0tbd02jzqdo65CmIoITW5G8k6o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736957071; c=relaxed/simple; bh=KDGjH/NpADMnlIvf4pRo8649/Ty5dZm0PAySZwq7UtI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=RcK+Eg6RaFImYHPESla/j98WT3cheb6dhJebTUWs0ItPDSx/TD1E/SIczCtSNaV30t6jdpCW2TGa+pzT1ALB8cxzbfenifdZyAJNrL41RhxYZDoaLBEK7/tul7SIk1wASW40NpQiZYyflwfqUyXGG85DmnVfScpwu0YdreNSWYk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=PolPU5la; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=E39R93pc; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="PolPU5la"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="E39R93pc" From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1736957068; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uT5rl0RpQLuca3C83bG6Tm1fAunk8fUwuKvLySr+dSQ=; b=PolPU5lal91pPuj+ZHPp39hP/SGlRsWq57tSYLserh8bvaexX0wF8QDizk483HHjXIynr0 AFqCkmEF8S73X+nI8eeek/MdY2rISE59QUoHXGjyDyutZrHTkFY+FkW57lF/LwpdTD45gJ onCIzguJeF9K4sEW02KN0+ZJaz1FfyNvmJKbTvzF6D8tqRI4pnm1Ft4+ZQwngaGO/fvZHs eD7agb7ZQEPVujRkhMzw0aciB9y87i/T7epjw1cANWDIhmSnDtoQSepaidgI2EsuHWm5vX JKHLV8XkaBzIy6UIT8aHTvDrt7EfVfDGFuHA86yjSVUceRDYUuPT62M9lDI+Jw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1736957068; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uT5rl0RpQLuca3C83bG6Tm1fAunk8fUwuKvLySr+dSQ=; b=E39R93pcwAEesR7Ums62C6uZm5Cncyu1eck3TU190TYxFpwaFhpE/mxpiogIawrpa1P8m1 PAWOp0MNlwWEb0BQ== To: Imran Khan , anna-maria@linutronix.de, frederic@kernel.org Cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] timers: introduce timer_try_add_on_cpu. In-Reply-To: <20250115134111.2703089-3-imran.f.khan@oracle.com> References: <20250115134111.2703089-1-imran.f.khan@oracle.com> <20250115134111.2703089-3-imran.f.khan@oracle.com> Date: Wed, 15 Jan 2025 17:04:27 +0100 Message-ID: <87v7ugaws4.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Thu, Jan 16 2025 at 00:41, Imran Khan wrote: > + * Return: > + * * %true - If timer was started on an online cpu > + * * %false - If the specified cpu was offline or if its online status > + * could not be ensured due to unavailability of hotplug lock. > + */ > +bool timer_try_add_on_cpu(struct timer_list *timer, int cpu) > +{ > + bool ret = true; > + > + if (unlikely(!cpu_online(cpu))) > + ret = false; > + else if (cpus_read_trylock()) { > + if (likely(cpu_online(cpu))) > + add_timer_on(timer, cpu); > + else > + ret = false; > + cpus_read_unlock(); > + } else > + ret = false; > + > + return ret; Aside of the horrible coding style, that cpus_read_trylock() part does not make any sense. It's perfectly valid to queue a timer on a online CPU when the CPU hotplug lock is held write, which can have tons of reasons even unrelated to an actual CPU hotplug operation. Even during a hotplug operation adding a timer on a particular CPU is valid, whether that's the CPU which is actually plugged or not is irrelevant. So if we add such a function, then it needs to have very precisely defined semantics, which have to be independent of the CPU hotplug lock. The only way I can imagine is that the state is part of the per CPU timer base, but then I have to ask the question what is actually tried to solve here. As far as I understood that there is an issue in the RDS code, queueing a delayed work on a offline CPU, but that should have triggered at least the warning in __queue_delayed_work(), right? So the question is whether this try() interface is solving any of this and not papering over the CPU hotplug related issues in the RDS code in some way. Thanks, tglx