linux-kernel - Re: [RFC][PATCH 5/6] Cleanup hrtimer.c's direct access to wall_to

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]

Date:	Sat, 05 Jun 2010 11:01:45 -0700
From:	john stultz <johnstul@...ibm.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC][PATCH 5/6] Cleanup hrtimer.c's direct access to
 wall_to_monotonic

On Sat, 2010-06-05 at 12:23 +0200, Arnd Bergmann wrote:
> On Saturday 05 June 2010, John Stultz wrote:
> >         do {
> >                 seq = read_seqbegin(&xtime_lock);
> >                 xts = __current_kernel_time();
> > -               tom = wall_to_monotonic;
> > +               tom = __get_wall_to_monotonic();
> >         } while (read_seqretry(&xtime_lock, seq));
> >  
> 
> Would it make sense to also limit the use of xtime_lock to the
> timekeeping code? I suppose you could merge the various accessors
> (current_kernel_time, get_monotonic_coarse, __current_kernel_time,
> __get_wall_to_monotonic) with a single function doing

Yep. I hope to keep chipping at it to get there. 

However xtime_lock protects a bit more then just the timekeeping
internals, and its currently not limiting the rework I'm hoping to do
with the timekeeping internal structures. So little bits at a time. :)

thanks
-john




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/