On Thu, Oct 10, 2013 at 08:51:04AM +0200, Jakub Jelinek wrote:
> @@ -8,6 +8,7 @@ foo (int a, int b)
>asm volatile goto ("bts $1, %0; jc %l[lab]" : : "m" (b) : "memory" : lab);
>return 0;
> lab:
> + asm ("");
>return 0;
> }
Or alternatively put the asm (""); right after asm goto,
a
On Thu, Oct 10, 2013 at 08:22:38AM +0200, Ingo Molnar wrote:
> > On Wed, Oct 09, 2013 at 09:02:31PM +0200, Peter Zijlstra wrote:
> > > On Wed, Oct 09, 2013 at 08:16:13PM +0200, Jakub Jelinek wrote:
> > >
> > > > Confirmed as gcc bug, filed http://gcc.gnu.org/PR58670 Seems all of
> > > > 4.[6-9] mi
* Jakub Jelinek wrote:
> On Wed, Oct 09, 2013 at 09:02:31PM +0200, Peter Zijlstra wrote:
> > On Wed, Oct 09, 2013 at 08:16:13PM +0200, Jakub Jelinek wrote:
> >
> > > Confirmed as gcc bug, filed http://gcc.gnu.org/PR58670 Seems all of
> > > 4.[6-9] miscompile it. Will have a look tomorrow unles
On Wed, 2013-10-09 at 19:18 +0200, Ingo Molnar wrote:
> * Ingo Molnar wrote:
>
> >
> > * Peter Zijlstra wrote:
> >
> > > On Wed, Oct 09, 2013 at 08:19:11PM +0800, Fengguang Wu wrote:
> > > > > > Fengguang, I do not think this will help, but just in case. Could
> > > > > > you
> > > > > > sho
On Wed, Oct 09, 2013 at 09:02:31PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 09, 2013 at 08:16:13PM +0200, Jakub Jelinek wrote:
> > Confirmed as gcc bug, filed http://gcc.gnu.org/PR58670
> > Seems all of 4.[6-9] miscompile it. Will have a look tomorrow
> > unless somebody beats me to it. But his
On Wed, Oct 09, 2013 at 08:16:13PM +0200, Jakub Jelinek wrote:
> Confirmed as gcc bug, filed http://gcc.gnu.org/PR58670
> Seems all of 4.[6-9] miscompile it. Will have a look tomorrow
> unless somebody beats me to it. But historically, the case where
> asm goto labels jump to fallthru basic block
On Wed, Oct 9, 2013 at 11:16 AM, Jakub Jelinek wrote:
>
> Confirmed as gcc bug, filed http://gcc.gnu.org/PR58670
> Seems all of 4.[6-9] miscompile it. Will have a look tomorrow
> unless somebody beats me to it. But historically, the case where
> asm goto labels jump to fallthru basic block had n
On Wed, Oct 09, 2013 at 04:46:56PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 09, 2013 at 04:33:59PM +0200, Peter Zijlstra wrote:
> > On Wed, Oct 09, 2013 at 04:07:34PM +0200, Peter Zijlstra wrote:
> > > Once I force a x86_64 build using the 'same' config it goes away and
> > > generates 'sensible'
On Wed, Oct 09, 2013 at 04:07:34PM +0200, Peter Zijlstra wrote:
> Once I force a x86_64 build using the 'same' config it goes away and
> generates 'sensible' code again (although I don't see why L9 isn't
> merged with L2):
i386-SMP also generates correct code afaict; a tad stupid but not wrong.
I
* Peter Zijlstra wrote:
> > This is what we are going to return. But note that -20(%ebp) was not
> > initialized if TIF_NOTIFY_RESUME was already set, "jc .L2" skips .L5
> > above. IOW, in this case we seem to return a random value from stack.
>
> I think you're quite right, and I can confirm I
OK, thanks...
I didn't notice Richard and Jakub were not cc'ed... Add them, perhaps
they can take a look.
On 10/09, Peter Zijlstra wrote:
>
> On Wed, Oct 09, 2013 at 02:43:10PM +0200, Oleg Nesterov wrote:
> > I'm afraid I am wrong, my asm skills are close to zero... but this
> > code looks wrong
On Wed, Oct 09, 2013 at 02:43:10PM +0200, Oleg Nesterov wrote:
> I'm afraid I am wrong, my asm skills are close to zero... but this
> code looks wrong to me, and this can explain the oopses.
>
> > task_work_add:
> > pushl %ebp#
> > movl%esp, %ebp #,
> > pushl %edi#
On Wed, Oct 09, 2013 at 02:27:05PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 09, 2013 at 08:19:11PM +0800, Fengguang Wu wrote:
> > > > Fengguang, I do not think this will help, but just in case. Could you
> > > > show the result of
> > > >
> > > > $ kernel/task_work.s
> >
> > Update: I r
* Peter Zijlstra wrote:
> On Wed, Oct 09, 2013 at 08:19:11PM +0800, Fengguang Wu wrote:
> > > > Fengguang, I do not think this will help, but just in case. Could you
> > > > show the result of
> > > >
> > > > $ kernel/task_work.s
> >
> > Update: I recompiled the kernel with gcc 4.4.7 a
Hi Fengguang,
On 10/09, Fengguang Wu wrote:
>
> Thanks for looking into this. Attached is the task_work.s for you.
Thanks a lot!
I'm afraid I am wrong, my asm skills are close to zero... but this
code looks wrong to me, and this can explain the oopses.
> task_work_add:
> pushl %ebp#
On Wed, Oct 09, 2013 at 08:19:11PM +0800, Fengguang Wu wrote:
> > > Fengguang, I do not think this will help, but just in case. Could you
> > > show the result of
> > >
> > > $ kernel/task_work.s
>
> Update: I recompiled the kernel with gcc 4.4.7 and find it booting fine!
> # 208 "/c/wfg
On Wed, Oct 09, 2013 at 08:19:11PM +0800, Fengguang Wu wrote:
> > > Fengguang, I do not think this will help, but just in case. Could you
> > > show the result of
> > >
> > > $ kernel/task_work.s
>
> Update: I recompiled the kernel with gcc 4.4.7 and find it booting fine!
>
> Attached is
> > Fengguang, I do not think this will help, but just in case. Could you
> > show the result of
> >
> > $ kernel/task_work.s
Update: I recompiled the kernel with gcc 4.4.7 and find it booting fine!
Attached is the new kernel/task_work.s.
Thanks,
Fengguang
.file "task_work.c"
Hi Oleg,
Thanks for looking into this. Attached is the task_work.s for you.
> Fengguang, I do not think this will help, but just in case. Could you
> show the result of
>
> $ kernel/task_work.s
>
> ?
Sorry I lost some emails and found it back in LKML. Opened up too many
mutt clients..
On Tue, 2013-10-08 at 21:05 +0200, Jakub Jelinek wrote:
> On Tue, Oct 08, 2013 at 08:51:54PM +0200, Oleg Nesterov wrote:
> > On 10/08, Linus Torvalds wrote:
> > >
> > > (not yet merged), see:
> > >
> > >
> > > http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=0c44c2d0f459cd7e
On Tue, Oct 8, 2013 at 12:35 PM, Oleg Nesterov wrote:
>
> Cough... sorry for off-topic question,
>
> static inline int test_and_set_bit(long nr, volatile unsigned long
> *addr)
> {
> int oldbit;
>
> asm volatile(LOCK_PREFIX "bts %2,%1\n\t"
>
On 10/08, Jakub Jelinek wrote:
>
> On Tue, Oct 08, 2013 at 08:51:54PM +0200, Oleg Nesterov wrote:
> >
> > I do not really understand inline assembly constraints, but I'll ask
> > anyway.
> >
> > +#define __GEN_RMWcc(fullop, var, cc, ...) \
> > +do { \
> > + asm volatile goto (fullop ";
On Tue, Oct 8, 2013 at 12:20 PM, Linus Torvalds
wrote:
>
> I'll try to see if I can reproduce this on my hardware
Yeah, doesn't reproduce here..
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
On Tue, Oct 8, 2013 at 12:05 PM, Jakub Jelinek wrote:
>
> If you suspect a compiler bug, can somebody please narrow it down to
> a single object file (if I've skimmed the patch right, it is just an
> optimization, where object files compiled without and with the patch
> should actually coexist fin
On Tue, Oct 08, 2013 at 08:51:54PM +0200, Oleg Nesterov wrote:
> On 10/08, Linus Torvalds wrote:
> >
> > (not yet merged), see:
> >
> >
> > http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=0c44c2d0f459cd7e275242b72f500137c4fa834d
>
> I do not really understand inline assembl
On Tue, Oct 8, 2013 at 11:51 AM, Oleg Nesterov wrote:
>
> I do not really understand inline assembly constraints, but I'll ask
> anyway.
>
> +#define __GEN_RMWcc(fullop, var, cc, ...) \
> +do { \
> + asm volatile goto (fullop "; j" cc " %l[cc_label]" \
> + : : "m" (
On 10/08, Linus Torvalds wrote:
>
> (not yet merged), see:
>
>
> http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=0c44c2d0f459cd7e275242b72f500137c4fa834d
I do not really understand inline assembly constraints, but I'll ask
anyway.
+#define __GEN_RMWcc(fullop, var,
On 10/08, Fengguang Wu wrote:
>
> Yeah, this will quiet the oops messages:
>
> -#ifdef CC_HAVE_ASM_GOTO
> +#if 0
Can't understand how this can affect task_work.c...
Well, task_work_add() does test_and_set_bit(), so that patch actually
changes this code, but still I can't see how this can lead to
[ Richard and Jakub added to cc, they can perhaps help or at least
point us to the right gcc person.
Richard, Jakub, the bug is triggered by kernel commit 0c44c2d0f459
(not yet merged), see:
http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=0c44c2d0f459cd7e275242b72f500137
I'll try to find other messages to understand what you are talking
about, just one note for now
On 10/07, Linus Torvalds wrote:
>
> Your oops makes very little sense, it looks like task_work_run() just
> called out to random crap, probably because the work was already
> released, so "work->fun
Hi Linus,
On Mon, Oct 07, 2013 at 11:47:39AM -0700, Linus Torvalds wrote:
> On Sat, Oct 5, 2013 at 4:44 PM, Fengguang Wu wrote:
> >
> > I got the below dmesg and the first bad commit is
> >
> > commit 0c44c2d0f459 ("x86: Use asm goto to implement better
> > modify_and_test() functions"
>
> Hmm.
On Sat, Oct 5, 2013 at 4:44 PM, Fengguang Wu wrote:
>
> I got the below dmesg and the first bad commit is
>
> commit 0c44c2d0f459 ("x86: Use asm goto to implement better modify_and_test()
> functions"
Hmm. I'm looking at the final version of that patch, and I'm not
seeing anything wrong. It may
On Mon, Oct 07, 2013 at 11:08:56AM +0200, Peter Zijlstra wrote:
> On Mon, Oct 07, 2013 at 10:55:33AM +0200, Peter Zijlstra wrote:
> > Wu, do you use the same compiler version for all the builds that crash
> > like this (I'm assuming the other email was this same commit)? Does a
> > different compil
On Mon, Oct 07, 2013 at 10:55:33AM +0200, Peter Zijlstra wrote:
> On Sun, Oct 06, 2013 at 07:44:30AM +0800, Fengguang Wu wrote:
> > Greetings,
> >
> > I got the below dmesg and the first bad commit is
> >
> > commit 0c44c2d0f459cd7e275242b72f500137c4fa834d
> > Author: Peter Zijlstra
> > Date:
On Mon, Oct 07, 2013 at 10:55:33AM +0200, Peter Zijlstra wrote:
> Wu, do you use the same compiler version for all the builds that crash
> like this (I'm assuming the other email was this same commit)? Does a
> different compiler make things work again?
OK, so in a further email you say you use gc
On Sun, Oct 06, 2013 at 07:44:30AM +0800, Fengguang Wu wrote:
> Greetings,
>
> I got the below dmesg and the first bad commit is
>
> commit 0c44c2d0f459cd7e275242b72f500137c4fa834d
> Author: Peter Zijlstra
> Date: Wed Sep 11 15:19:24 2013 +0200
>
> x86: Use asm goto to implement better mo
36 matches
Mail list logo
