linux-kernel - Re: [PATCH] simplify update_times (avoid jiffies/jiffies

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-next>] [day] [month] [year] [list]

Date:	Sun, 30 Jul 2006 23:54:03 +0900 (JST)
From:	Atsushi Nemoto <anemo@....ocn.ne.jp>
To:	johnstul@...ibm.com
Cc:	akpm@...l.org, zippel@...ux-m68k.org, clameter@...r.sgi.com,
	linux-kernel@...r.kernel.org, ralf@...ux-mips.org, ak@....de
Subject: Re: [PATCH] simplify update_times (avoid jiffies/jiffies_64
 aliasing problem)

Let me restart this discussion after about 5 months interval.

On Sun, 05 Mar 2006 02:15:42 +0900 (JST), Atsushi Nemoto <anemo@....ocn.ne.jp> wrote:
> john> I'm not opposed to queuing it up as it seems like a logical
> john> cleanup. I'd be fine with it going in before my patch, however
> john> it still needs to address i386 lost tick compensation.  I worry
> john> that addressing that issue before my patchset (which makes the
> john> lost tick compensation unnecessary) might be a bit more
> john> complex. I think it would be easier going in after my patch. I
> john> do think the barrier fix (with a comment) is a good short term
> john> fix.
> 
> john> Atsushi: Your thoughts?
> 
> I agree.  I missed i386 lost tick case and it seems more complex than
> x86_64 case.  Your patchset looks to make this cleanup very easy.
> Then, here is an updated barrier fix patch.

Now it seems the conversion of the i386 timer code has been finished.
We can think this topic again.  Here is a patch against current git
tree.  How about this?  And I wonder if there are any point
maintaining wall_jiffies now.  It seems jiffies and wall_jiffies are
always synced.


[PATCH] simplify update_times

In kernel 2.6, update_times() is called directly from timer interrupt,
so there is no point calculating ticks here.  This also make a barrier
added by 5aee405c662ca644980c184774277fc6d0769a84 needless.

Also adjust x86_64 timer interrupt handler with this change.

Signed-off-by: Atsushi Nemoto <anemo@....ocn.ne.jp>

diff --git a/arch/x86_64/kernel/time.c b/arch/x86_64/kernel/time.c
index 7a9b182..298027f 100644
--- a/arch/x86_64/kernel/time.c
+++ b/arch/x86_64/kernel/time.c
@@ -423,7 +423,8 @@ #endif
 
 	if (lost > 0) {
 		handle_lost_ticks(lost, regs);
-		jiffies += lost;
+		while (lost--)
+			do_timer(regs);
 	}
 
 /*
diff --git a/kernel/timer.c b/kernel/timer.c
index 05809c2..3981cae 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -1267,12 +1267,9 @@ void run_local_timers(void)
  */
 static inline void update_times(void)
 {
-	unsigned long ticks;
-
-	ticks = jiffies - wall_jiffies;
-	wall_jiffies += ticks;
+	wall_jiffies++;
 	update_wall_time();
-	calc_load(ticks);
+	calc_load(1);
 }
   
 /*
@@ -1284,8 +1281,6 @@ static inline void update_times(void)
 void do_timer(struct pt_regs *regs)
 {
 	jiffies_64++;
-	/* prevent loading jiffies before storing new jiffies_64 value. */
-	barrier();
 	update_times();
 }
 
-
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/