From patchwork Tue Nov 22 17:44:45 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Thomas Gleixner X-Patchwork-Id: 13052592 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 ACC39C4321E for ; Tue, 22 Nov 2022 17:44:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234058AbiKVRou (ORCPT ); Tue, 22 Nov 2022 12:44:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58526 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232554AbiKVRos (ORCPT ); Tue, 22 Nov 2022 12:44:48 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1EB6365F0; Tue, 22 Nov 2022 09:44:48 -0800 (PST) Message-ID: <20221122173648.153480304@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1669139086; 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: content-transfer-encoding:content-transfer-encoding: references:references; bh=vPQpsKvWnASzU3gSCvd8QTllKFezKGed3DBwTOx2RsY=; b=N1JdlAq02OGh1ZaHD7YrDTYMYpCfJwds7yiy47sSsKrsscCku9ZeyGkFcuMMTvaOkg0mBh 9PIu/EEfwcpUmektmw8eBXUbRIeL8LPKNifLEOwbUcHavwajnrvmDsMNnGbo3IQyUdXZE3 fXSH56BsDR1kv3YQrZAOlJRGNJ8q8jTay1HWJcrtsqOAE21A2bq86Iwokid1/4lew92134 cPNG9iXt8FQIj+hPM3lAHZJwoMAl9wuPm0nhRlWwL8b6x5KNFx2wPUBvAez7rHjN+P+FEL y8gVeqCjwX8cKpL7sKtpszLaLpzT+tBYMn517QbefeK8K20Im7s8sN1ptBT8+g== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1669139086; 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: content-transfer-encoding:content-transfer-encoding: references:references; bh=vPQpsKvWnASzU3gSCvd8QTllKFezKGed3DBwTOx2RsY=; b=y93AMtrwboI4mg48ccrd69AeqcjYHNWmCsBPWMVYSOFh86bGLdI5qNWUx/E7AoaUQNIPQI 9P/jYXxtnLlR8WAA== From: Thomas Gleixner To: LKML Cc: Linus Torvalds , Steven Rostedt , Anna-Maria Behnsen , Peter Zijlstra , Stephen Boyd , Guenter Roeck , Andrew Morton , Julia Lawall , Arnd Bergmann , Viresh Kumar , Marc Zyngier , Marcel Holtmann , Johan Hedberg , Luiz Augusto von Dentz , linux-bluetooth@vger.kernel.org, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org Subject: [patch V2 01/17] Documentation: Remove bogus claim about del_timer_sync() References: <20221122171312.191765396@linutronix.de> MIME-Version: 1.0 Date: Tue, 22 Nov 2022 18:44:45 +0100 (CET) Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org del_timer_sync() does not return the number of times it tried to delete the timer which rearms itself. It's clearly documented: The function returns whether it has deactivated a pending timer or not. This part of the documentation is from 2003 where del_timer_sync() really returned the number of deletion attempts for unknown reasons. This code was rewritten in 2005, but the documentation was not updated. Signed-off-by: Thomas Gleixner --- Documentation/kernel-hacking/locking.rst | 3 +-- Documentation/translations/it_IT/kernel-hacking/locking.rst | 4 +--- 2 files changed, 2 insertions(+), 5 deletions(-) --- a/Documentation/kernel-hacking/locking.rst +++ b/Documentation/kernel-hacking/locking.rst @@ -1006,8 +1006,7 @@ Another common problem is deleting timer calling add_timer() at the end of their timer function). Because this is a fairly common case which is prone to races, you should use del_timer_sync() (``include/linux/timer.h``) to -handle this case. It returns the number of times the timer had to be -deleted before we finally stopped it from adding itself back in. +handle this case. Locking Speed ============= --- a/Documentation/translations/it_IT/kernel-hacking/locking.rst +++ b/Documentation/translations/it_IT/kernel-hacking/locking.rst @@ -1027,9 +1027,7 @@ Un altro problema è l'eliminazione dei da soli (chiamando add_timer() alla fine della loro esecuzione). Dato che questo è un problema abbastanza comune con una propensione alle corse critiche, dovreste usare del_timer_sync() -(``include/linux/timer.h``) per gestire questo caso. Questa ritorna il -numero di volte che il temporizzatore è stato interrotto prima che -fosse in grado di fermarlo senza che si riavviasse. +(``include/linux/timer.h``) per gestire questo caso. Velocità della sincronizzazione ===============================