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:	Tue, 8 Oct 2013 21:35:07 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Jakub Jelinek <jakub@...hat.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Fengguang Wu <fengguang.wu@...el.com>,
	Richard Henderson <rth@...ddle.net>,
	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 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 "; j" cc " %l[cc_label]" \
> > 	+ : : "m" (var), ## __VA_ARGS__ \
> > 	      ^^^^^^^^^
> >
> > don't we need
> >
> > 	"+m" (var)
> >
> > here?
>
> You actually can't have output operands with asm goto, only inputs
> and clobbers.  But the "memory" clobber should be enough here.

Thanks Jakub and Linus.

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"
			     "sbb %0,%0" : "=r" (oldbit), ADDR : "Ir" (nr) : "memory");

doesn't this mean that "ADDR" doesn't need "+" as well?


> 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 fine in the same kernel), ideally to a single
> routine if possible and post a preprocessed source + gcc command line
> + version of gcc?

Or at least, perhaps it makes sense to identify the include file which
makes the difference. Say, revert the changes in bitops.h, retest, then
in atomic.h if the kernel still fails, etc.

Oleg.

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