lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170710144309.GC17720@madcap2.tricolour.ca>
Date:   Mon, 10 Jul 2017 10:43:09 -0400
From:   Richard Guy Briggs <rgb@...hat.com>
To:     Paul Moore <paul@...l-moore.com>
Cc:     Deepa Dinamani <deepa.kernel@...il.com>,
        Arnd Bergmann <arnd@...db.de>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Tony Jones <tonyj@...e.com>,
        LKML <linux-kernel@...r.kernel.org>, linux-audit@...hat.com
Subject: Re: [PATCH] audit: Reduce overhead using a coarse clock

On 2017-07-06 16:25, Paul Moore wrote:
> On Tue, Jul 4, 2017 at 3:41 PM, Deepa Dinamani <deepa.kernel@...il.com> wrote:
> > On Tue, Jul 4, 2017 at 12:20 PM, Arnd Bergmann <arnd@...db.de> wrote:
> >> On Tue, Jul 4, 2017 at 2:11 PM, Mel Gorman <mgorman@...hsingularity.net> wrote:
> >>>
> >>> Signed-off-by: Mel Gorman <mgorman@...hsingularity.net>
> >>
> >> Acked-by: Arnd Bergmann <arnd@...db.de>
> >
> > Acked-by: Deepa Dinamani <deepa.kernel@...il.com>
> >
> > As already Arnd pointed out, your patch should be fine as that is how
> > it was before my patch. Since nobody saw any problems before my patch,
> > lower granularity should be fine.
> 
> Agreed.  Mel's patch basically restores the previous behavior while
> keeping the 64-bit timestamp size.
> 
> Considering where we are at with the merge window, I'm going to merge
> this into the audit/next branch and not send this up to Linus during
> the current window; while the patch is small, I like to give things
> some time in linux-next before sending them up.

This looks fine to me.  Audit has its own event counter so the slightly
coarser granularity of this counter to avoid the overhead shouldn't be a
significant problem.

Reviewed-by: Richard Guy Briggs <rgb@...hat.com>

> paul moore

- RGB

--
Richard Guy Briggs <rgb@...hat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ