linux-kernel - Re: [PATCH] common implementation of iterative div/mod

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]

Message-ID: <482A95BB.1000001@goop.org>
Date:	Wed, 14 May 2008 08:33:15 +0100
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	Segher Boessenkool <segher@...nel.crashing.org>,
	Robert Hancock <hancockr@...w.ca>,
	Christian Kujau <lists@...dbynature.de>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	john stultz <johnstul@...ibm.com>,
	Andi Kleen <andi@...stfloor.org>
Subject: Re: [PATCH] common implementation of iterative div/mod

Andrew Morton wrote:
> On Thu, 08 May 2008 16:16:41 +0100 Jeremy Fitzhardinge <jeremy@...p.org> wrote:
>
>   
>> We have a few instances of the open-coded iterative div/mod loop, used
>> when we don't expcet the dividend to be much bigger than the divisor.
>> Unfortunately modern gcc's have the tendency to strength "reduce" this
>> into a full mod operation, which isn't necessarily any faster, and
>> even if it were, doesn't exist if gcc implements it in libgcc.
>>
>> The workaround is to put a dummy asm statement in the loop to prevent
>> gcc from performing the transformation.
>>
>> This patch creates a single implementation of this loop, and uses it
>> to replace the open-coded versions I know about.
>>     
>
> Believe it or not, this patch causes one of my test machines to fail to
> find its disk.
>
> good dmesg: http://userweb.kernel.org/~akpm/dmesg-t61p.txt
> bad dmesg: http://userweb.kernel.org/~akpm/dmesg-t61p-dead.txt
> config: http://userweb.kernel.org/~akpm/config-t61p.txt

Uh, OK.  Do your other test machines work with it?  Are there any 
relevant config differences (x86-64 vs 32?).

Hm, it's not that it can't find its disk, I think it's this:

init[1]: segfault at ffffffffff7008d2 ip ffffffffff7008d2 sp 7fff86e67488 error 14
init[1]: segfault at ffffffffff7008d2 ip 311ac07628 sp 7fff86e66cb0 error 4 in libgcc_s-4.1.2-20070925.so.1[311ac00000+d000]


Is it that the vsyscall page is trying to call into the kernel?

    notrace static noinline int do_realtime(struct timespec *ts)
    {
    	unsigned long seq, ns;
    	do {
    		seq = read_seqbegin(&gtod->lock);
    		ts->tv_sec = gtod->wall_time_sec;
    		ts->tv_nsec = gtod->wall_time_nsec;
    		ns = vgetns();
    	} while (unlikely(read_seqretry(&gtod->lock, seq)));
    	timespec_add_ns(ts, ns);
    	return 0;
    }
      

timespec_add_ns() used to be entirely inlined, but now it contains the 
call to iter_div_u64_rem().

arch/x86/vdso/vclock_gettime.c has its own copies of other kernel 
functions which it can't directly call.  We could add 
timespec_add_ns()/iter_div_u64_rem() to that list, though its pretty 
hacky.  Could we link lib/div64.o into the vdso?

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