From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932882AbcFOVX0 (ORCPT ); Wed, 15 Jun 2016 17:23:26 -0400 Received: from mail-oi0-f65.google.com ([209.85.218.65]:33535 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753055AbcFOVXW (ORCPT ); Wed, 15 Jun 2016 17:23:22 -0400 MIME-Version: 1.0 X-Originating-IP: [108.49.39.189] In-Reply-To: <20160609235943.GL18488@madcap2.tricolour.ca> References: <1465448705-25055-1-git-send-email-deepa.kernel@gmail.com> <1465448705-25055-18-git-send-email-deepa.kernel@gmail.com> <15760445.1IAucOxmWy@x2> <20160609235943.GL18488@madcap2.tricolour.ca> From: Paul Moore Date: Wed, 15 Jun 2016 17:23:20 -0400 Message-ID: Subject: Re: [PATCH 17/21] audit: Use timespec64 to represent audit timestamps To: Deepa Dinamani , Richard Guy Briggs , Steve Grubb Cc: Arnd Bergmann , y2038@lists.linaro.org, linux-kernel@vger.kernel.org, linux-audit@redhat.com, Al Viro , linux-fsdevel@vger.kernel.org, Thomas Gleixner , Linus Torvalds Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 9, 2016 at 7:59 PM, Richard Guy Briggs wrote: > On 16/06/09, Steve Grubb wrote: >> On Wednesday, June 08, 2016 10:05:01 PM Deepa Dinamani wrote: >> > struct timespec is not y2038 safe. >> > Audit timestamps are recorded in string format into >> > an audit buffer for a given context. >> > These mark the entry timestamps for the syscalls. >> > Use y2038 safe struct timespec64 to represent the times. >> > The log strings can handle this transition as strings can >> > hold upto 1024 characters. >> >> Have you tested this with ausearch or any audit utilities? As an aside, a time >> stamp that is up to 1024 characters long is terribly wasteful considering how >> many events we get. > > Steve, > > I don't expect the size of the time stamp text to change since the > format isn't being changed and I don't expect the date stamp text length > to change until Y10K, but you never know what will happen in 8 > millenia... (Who knows, maybe that damn Linux server in my basement > will still be running then...) Yeah, I'm not really worried about the string date field growing; this is more an internal implementation detail to make sure we can keep the lights on in a few decades from now. Deepa, I'm not going to merge your patchset because I'm guessing all your timespec64 patches will likely go in at once, but you are free to add my ack if you need to respin. Acked-by: Paul Moore -- paul moore www.paul-moore.com