Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752049AbdHIJd7 convert rfc822-to-8bit (ORCPT ); Wed, 9 Aug 2017 05:33:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57440 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751443AbdHIJd5 (ORCPT ); Wed, 9 Aug 2017 05:33:57 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7032FC01BD3A Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=dhowells@redhat.com Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: References: <8ac57c96bf5a0695ecc67fd230440b0b9d15740f.1502246502.git.baolin.wang@linaro.org> To: Arnd Bergmann Cc: dhowells@redhat.com, Baolin Wang , David Miller , james.l.morris@oracle.com, "Serge E. Hallyn" , marc.dionne@auristor.com, Dan Carpenter , "Jason A. Donenfeld" , Mark Brown , keyrings@vger.kernel.org, Linux Kernel Mailing List , LSM List , Networking Subject: Re: [PATCH 3/3] net: rxrpc: Replace time_t type with time64_t type MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6766.1502271233.1@warthog.procyon.org.uk> Content-Transfer-Encoding: 8BIT Date: Wed, 09 Aug 2017 10:33:53 +0100 Message-ID: <6767.1502271233@warthog.procyon.org.uk> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 09 Aug 2017 09:33:57 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1087 Lines: 27 Arnd Bergmann wrote: > > @@ -533,8 +536,9 @@ static int rxrpc_preparse_xdr_rxk5(struct key_preparsed_payload *prep, > > pptoken = &(*pptoken)->next) > > continue; > > *pptoken = token; > > - if (token->kad->expiry < prep->expiry) > > - prep->expiry = token->kad->expiry; > ... > > I'm still slightly puzzled by what this function does: it does have four > timestamps (authtime, starttime, endtime, renew_till) that are all > transferred as 64-bit values and won't expire, but then it also uses the > 32-bit expiry field in rxrpc_key_token->kad->expiry instead of the 64-bit > rxrpc_key_token->k5 fields. Good catch. This is a cut'n'paste error. It should be using token->k5->expiry here not token->kad->expiry. > This appears to overlay the first 32 bits of the > rxrpc_key_token->k5->starttime field, which is also a time value on > little-endian architectures by chance, but I would assume that it's always > in the past, meaning the keys would already be expired. Yeah - I'm not sure why it works. David