Received: by 2002:a05:6358:5282:b0:b5:90e7:25cb with SMTP id g2csp3794504rwa; Tue, 23 Aug 2022 10:12:07 -0700 (PDT) X-Google-Smtp-Source: AA6agR59riBEjbbwB3F+8Paqi1KVUQWymyk1F3+UdZJtokyHeyqZXl5k8771Rzg9UAouFZjMl6qD X-Received: by 2002:a65:5a0c:0:b0:429:c80e:959c with SMTP id y12-20020a655a0c000000b00429c80e959cmr21840921pgs.279.1661274727343; Tue, 23 Aug 2022 10:12:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661274727; cv=none; d=google.com; s=arc-20160816; b=i5ROMBFSCkAWL2QQhxGuOoWHrWYlqTNytnwu/EuxLMT83VLP5mml15ktaYKzylZUZr rQ1kGIPrrLn3hzoQ7ZGCaCcTAz3QQKVXh27qq/Eh6CKD3Fk32K5bG8iuflIEv6ywgLGC PoHyRw9P17RZx1s4VNNnCujVOnkJ/OpLZqJeoW1WTAemxcmV3HivvuUu+Wkf/CcKuZZ4 bBiAFagKjmFJaGhvd5/MVJwBy7u2rDMmtpo/j+FvKT/6C/2jxK4KkqoBDNRgpzenEmHM fNJQKf7X2JJWv8zw9r4Xf5b/rrF29e/YMvhVcoqKt1Ne2LtPNUqCeiJEdBSvA4w6AzdX nN3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:dkim-signature:dkim-signature; bh=SeCJBSVqOhAGWvX3rLkYeyZ0F7kVhjopz07El5TE35g=; b=yzKgijilsY7KPsxnI+rWn08s/SuT0dr0CJf93WGyIWRYltGneTpl2BoDpE5bFePOZb kVLUc9zvINw/SxY+5yeaUQlYCZQV/yojXaRTUQb04SqFg7O9X2OtqS1HZYNOvyERUdj9 5oFZwgxeovf8aHgXQXA08uSkYniwjIkRqPT/ZkdD2hIwLYkrZYnm6aElOekLxPzVvP24 JdMLkQyjIzDs6/zWPBWxqh3ZrmZzH6ZE1B+CQB69pJbsfj0ow4y7AK1huzS3gv09Jxnx AQdmjmm2JUmxxl4+KN+C4l2pOX7O66ECSPNR3nhn8j4k8p9cS8gALhWyY2Ti/yo52QLM +Cng== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=dTe0UjB0; dkim=neutral (no key) header.i=@suse.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r20-20020a6560d4000000b0041b8f2bd530si17837360pgv.217.2022.08.23.10.11.51; Tue, 23 Aug 2022 10:12:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=dTe0UjB0; dkim=neutral (no key) header.i=@suse.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244645AbiHWQbs (ORCPT + 99 others); Tue, 23 Aug 2022 12:31:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45278 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244928AbiHWQac (ORCPT ); Tue, 23 Aug 2022 12:30:32 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B533F183B7; Tue, 23 Aug 2022 06:00:07 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 42F3022AF8; Tue, 23 Aug 2022 13:00:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1661259606; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SeCJBSVqOhAGWvX3rLkYeyZ0F7kVhjopz07El5TE35g=; b=dTe0UjB0yIX4nY3F+zS/45UC/LYnMpG/bzHrG777J0GXX56UWfZAqtaLxrKBZ2xZdAipyW OPwm+hEPTUlKGJUqf8a4in/v5bPEpPl8WUIIRUKXyB2b/2b788rVR/9rQjKNxYy5GEyoo4 /qNFOoaTCBO3rgspBD74zkUFwuM71pM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1661259606; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SeCJBSVqOhAGWvX3rLkYeyZ0F7kVhjopz07El5TE35g=; b=1RnAL5TU+0iluQFJM11wgDO7i6gMipFzGf7G919num4t1EGMDljjFIXBOzonsjjpaw63iF z8jiEIzW0hE9SyAQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id D5A2D13A89; Tue, 23 Aug 2022 13:00:05 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id upyNMlXPBGMBVgAAMHmgww (envelope-from ); Tue, 23 Aug 2022 13:00:05 +0000 Date: Tue, 23 Aug 2022 15:00:03 +0200 From: Jean Delvare To: linux-watchdog@vger.kernel.org, LKML Cc: Wim Van Sebroeck , Guenter Roeck , Mika Westerberg , "Rafael J. Wysocki" , Liu Xinpeng Subject: Re: [PATCH v2] watchdog: wdat_wdt: Set the min and max timeout values properly Message-ID: <20220823150003.6199b8fd@endymion.delvare> In-Reply-To: <20220806081524.5636461a@endymion.delvare> References: <20220806081524.5636461a@endymion.delvare> Organization: SUSE Linux X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.32; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, On Sat, 6 Aug 2022 08:15:24 +0200, Jean Delvare wrote: > The wdat_wdt driver is misusing the min_hw_heartbeat_ms field. This > field should only be used when the hardware watchdog device should not > be pinged more frequently than a specific period. The ACPI WDAT > "Minimum Count" field, on the other hand, specifies the minimum > timeout value that can be set. This corresponds to the min_timeout > field in Linux's watchdog infrastructure. > > Setting min_hw_heartbeat_ms instead can cause pings to the hardware > to be delayed when there is no reason for that, eventually leading to > unexpected firing of the watchdog timer (and thus unexpected reboot). > (...) This patch no longer applies as it conflicts with: commit 6d72c7ac9fbe26a77800676507da980436b40b2f Author: Liu Xinpeng Date: Tue Apr 26 22:53:28 2022 +0800 which made it into kernel v5.19. Having reviewed the commit mentioned above, I must say I'm skeptical. I can't see how setting min_timeout to 1 arbitrarily has been considered a good thing. This allows setting timeout values lower than the ACPI WDAT "Minimum Count" field, while presumably the hardware does not support such short timeouts. Furthermore, calling watchdog_timeout_invalid() to validate the timeout value is a good idea in principle, however, given that min_timeout is now 1 and max_hw_heartbeat_ms is defined, the function is no longer checking much. My understanding is that the original code was checking the right limits (from the WDAT table's perspective) using the wrong fields (from the watchdog core's perspective). This fix from Liu is not really fixing the problem (min_hw_heartbeat_ms and max_hw_heartbeat_ms are still set, which enables watchdog core facilities that the driver doesn't need IMHO) and is adding a new problem (the timeout limits defined in the ACPI WDAT table are no longer checked). I will rebase my patch on top and address both problems. -- Jean Delvare SUSE L3 Support