linux-kernel - Re: [PATCH] Introduce jiffies_32 and related compare functions

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

Date:	Tue, 12 Dec 2006 05:09:23 +0100
From:	Eric Dumazet <dada1@...mosbay.com>
To:	David Miller <davem@...emloft.net>
Cc:	akpm@...l.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Introduce jiffies_32 and related compare functions

David Miller a écrit :
> From: Eric Dumazet <dada1@...mosbay.com>
> Date: Tue, 12 Dec 2006 04:47:14 +0100
> 
>> I doubt being able to extend the expiration of a dst above 2^32
>> ticks (49 days if HZ=1000, 198 days if HZ=250) is worth the ram
>> wastage.
> 
> And this doesn't apply for all jiffies uses because? :-)
> 
> That's the point I'm trying to make and get a discussion on.
> 
> 

Ah ok :)

Maybe my intentions were not clear :

I am not suggesting replacing all jiffies to jiffies_32. Just *selected* ones :)

BTW, the real limit is 2^31 ticks, so its 24 days.

We definitly *like* being able to use bigger timeouts on 64bits platforms.

Not that they are mandatory since the same application should run fine on 
32bits kernel. But as the standard type for 'tick timestamps' is 'unsigned 
long', a change would be invasive.

Maybe some applications are now relying on being able to 
sleep()/select()/poll() for periods > 30 days and only run on 64 bits kernels.

Eric
-
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/