linux-kernel - Re: PATCH - x86-64 signed-compare bug, was Re: select() setting ERESTARTNOHAND (514).

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: <17829.36029.240912.274302@notabene.brown>
Date:	Thu, 11 Jan 2007 12:02:53 +1100
From:	Neil Brown <neilb@...e.de>
To:	Andi Kleen <ak@...e.de>
Cc:	Neil Brown <neilb@...e.de>, Sean Reifschneider <jafo@...my.com>,
	linux-kernel@...r.kernel.org
Subject: Re: PATCH - x86-64 signed-compare bug, was Re: select() setting ERESTARTNOHAND (514).

On Thursday January 11, ak@...e.de wrote:
> > Just a 'me too' at this point. 
> > The X server on my shiny new notebook (Core 2 Duo) occasionally dies
> > with 'select' repeatedly returning ERESTARTNOHAND.  It is most
> > annoying!
> 
> Normally it should be only visible in strace. Did you see it without
> strace?

No, only in strace.

> 
> > 
> > You don't mention in the Email which kernel version you use but I see
> > from the web page you reference it is 2.6.19.1.  I'm using
> > 2.6.18.something.
> > 
> > I thought I'd have a quick look at the code, comparing i386 to x86-64
> > and guess what I found.....
> > 
> > On x86-64, regs->rax is "unsigned long", so the following is
> > needed....
> 
> regs->rax is unsigned long.
> I don't think your patch will make any difference. What do you think
> it will change?

If regs->rax is unsigned long, then I would think the compiler would
be allowed to convert

   switch (regs->rax) {
	case -514 : whatever;
   }

to a no-op, as regs->rax will never have a negative value.

However it appears that the current compiler doesn't make that
optimisation so I guess I was too hasty.

Still, I think it would be safer to have the cast, in case the compiler
decided to be clever.... or does the C standard ensure against that?

Sorry for the noise,

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