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 06F28C6FA99 for ; Tue, 7 Mar 2023 22:32:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231392AbjCGWcB (ORCPT ); Tue, 7 Mar 2023 17:32:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55622 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229582AbjCGWbg (ORCPT ); Tue, 7 Mar 2023 17:31:36 -0500 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 198008F73C; Tue, 7 Mar 2023 14:31:07 -0800 (PST) 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 A9C3821A40; Tue, 7 Mar 2023 22:31:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1678228265; 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=0ESmXSz9yy8NQE1Zdwj05I8PsReeIvbUxMuWzbKRHyo=; b=JHn7IUaDYQ9uEJHQBIN3vr9Ew3dkYuJLs2rzcReEqI94IwxqeRBnTFmW2Uq74GMKy0rl+D kk9rk/2E2OTzdACo/+JZ8LRBCT2PFrcxiU74IgVrGOYlVaGpVpI4V5knBYlvvJKT2hK3kN /FDIsl9gJZKCWqK8aaO9iVzn/BEbg3I= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1678228265; 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=0ESmXSz9yy8NQE1Zdwj05I8PsReeIvbUxMuWzbKRHyo=; b=7QPid6JmP3fKPwlnQjLwyMO7bPK7nKZGxTZWmQIudpBoM9rJzOuCxaNkwCU4w/+W6OzzlQ KVMoHGLtZ95egEAQ== 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 4D0A613440; Tue, 7 Mar 2023 22:31:02 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 1HTeACa7B2SqAgAAMHmgww (envelope-from ); Tue, 07 Mar 2023 22:31:02 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 From: "NeilBrown" To: "Jerry Zhang" Cc: embedded@skydio.com, "Jerry Zhang" , "Chuck Lever" , "Jeff Layton" , "Trond Myklebust" , "Anna Schumaker" , "J. Bruce Fields" , linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] sunrpc: Fix incorrect parsing of expiry time In-reply-to: <20230307220525.54895-1-Jerry@skydio.com> References: <20230307220525.54895-1-Jerry@skydio.com> Date: Wed, 08 Mar 2023 09:30:59 +1100 Message-id: <167822825917.8008.11050193827453206272@noble.neil.brown.name> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 08 Mar 2023, Jerry Zhang wrote: > The expiry time field is mean to be expressed in seconds since boot. Correct. > The get_expiry() function parses a relative time value in seconds. Incorrect. It parses and absoulte wall-clock time. NeilBrown > In order to get the absolute time of seconds since boot that the given > message will expire, the right thing is to add seconds_since_boot() > to the given relative value. > > Previously this logic was subtracting boot.tv_sec from the relative > value, which was causing some confusing behavior. The return type of > time64_t could possibly underflow if time since boot is greater than > the passed in relative argument. Also several checks in nfs code compare > the return value to 0 to indicate failure, and this could spuriously > be tripped if seconds since boot happened to match the argument. > > Fixes: c5b29f885afe ("sunrpc: use seconds since boot in expiry cache") > Signed-off-by: Jerry Zhang > --- > include/linux/sunrpc/cache.h | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/include/linux/sunrpc/cache.h b/include/linux/sunrpc/cache.h > index ec5a555df96f..b96b1319c93d 100644 > --- a/include/linux/sunrpc/cache.h > +++ b/include/linux/sunrpc/cache.h > @@ -301,16 +301,14 @@ static inline int get_time(char **bpp, time64_t *time) > } > > static inline time64_t get_expiry(char **bpp) > { > time64_t rv; > - struct timespec64 boot; > > if (get_time(bpp, &rv)) > return 0; > if (rv < 0) > return 0; > - getboottime64(&boot); > - return rv - boot.tv_sec; > + return rv + seconds_since_boot(); > } > > #endif /* _LINUX_SUNRPC_CACHE_H_ */ > -- > 2.37.3 > >