linux-kernel - Re: [x86] BUG: unable to handle kernel paging request at 00740060

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:	Mon, 7 Oct 2013 11:47:39 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Fengguang Wu <fengguang.wu@...el.com>,
	Oleg Nesterov <oleg@...hat.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [x86] BUG: unable to handle kernel paging request at 00740060

On Sat, Oct 5, 2013 at 4:44 PM, Fengguang Wu <fengguang.wu@...el.com> 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 trigger a compiler bug - there aren't
that many "asm goto" users, and using them for the bitops adds a lot
of new cases.

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->func()" ends up being bad. I'm adding Oleg to the
participants anyway, just in case there is some race. The comment says
that it can race with task_work_cancel() playing with *work. Oleg,
comments?

However, I don't see any actual bit-op code in task_work_run() itself,
so it's something else that got miscompiled and corrupted memory. In
that respect, the oops you have looks more like the oopses you got
with DEBUG_KOBJECT_RELEASE. Are you sure that wasn't set?

That said, Fengguang, can you try two things just to check:

 - add "cc" to the clobbers list for the asm goto (technically it
should be on the non-asm-goto as well, but we never had that, and
maybe the fact that gcc always ends up testing a register afterwards
hides the need for the clobber).

So it would look like this in arch/x86/include/asm/rmwcc.h

  #define __GEN_RMWcc(fullop, var, cc, ...) \
  do { \
      asm volatile goto (fullop "; j" cc " %l[cc_label]" \
          : : "m" (var), ## __VA_ARGS__ \
          : "memory", "cc" : cc_label); \
      return 0; \
  cc_label: \
      return 1; \

(where that "cc" thing is new). I'm not sure if "cc" really matters on
x86 at all (it didn't use to, long long ago), but maybe it does these
days..

If that makes no difference, please just verify that the non-asm-goto
version works fine, by changing the

  #ifdef CC_HAVE_ASM_GOTO

into a simple "#if 0" to disable the asm-goto version.

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