linux-kernel - Re: Problem with commit deda2e81961e96be4f2c09328baca4710a2fd1a0

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:	Fri, 13 Aug 2010 00:30:38 -0700
From:	john stultz <johnstul@...ibm.com>
To:	Larry Finger <Larry.Finger@...inger.net>
Cc:	Jason Wessel <jason.wessel@...driver.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Problem with commit deda2e81961e96be4f2c09328baca4710a2fd1a0

On Thu, 2010-08-12 at 22:17 -0500, Larry Finger wrote:
> On 08/12/2010 03:52 PM, john stultz wrote:
> > 
> > Ugh. I'm surprised it picks *this* loop to optimize instead of the
> > similar one right above. I'm guessing its the local raw_nsecs value, but
> > whatever.  Also surprised Jason's testing didn't hit this issue, but its
> > probably a gcc version thing.
> > 
> > Regardless, I clearly need to give i386 more love in my testing.
> > My profuse apologies.
> > 
> > As suggested by Linus, here's the do_div explicit version. It builds ok
> > on i386 & x86_64, but I have not yet tested it. 
> > 
> > Larry, Jason: Could you verify it works for you (and avoids the original
> > issue)?
> 
> This one builds for me with both compilers. It appears to run OK. As to the
> original issue - I don't think I ever saw the problem. I'll leave that question
> for Jason.

Thanks for the testing! 

I also managed to trigger the link issue with a 64bit gcc-4.3 cross
compiling to 32bit. However both 32bit and 64bit gcc-4.4 didn't trigger
the link issue, so it looks like its fixed in gcc.

Regardless, after my own testing, the change looks good to me. Raw time
is accumulating properly relative to monotonic time.

Assuming Jason has no complaints it should be able to be pushed in.

Thanks again for the quick reporting and verification.
-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/