linux-kernel - Re: print_vma_addr possible deadlock (was Re: Jeste jeden bug)

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: <200802131813.47136.ak@suse.de>
Date:	Wed, 13 Feb 2008 18:13:46 +0100
From:	Andi Kleen <ak@...e.de>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Zdenek Kabelac <zdenek.kabelac@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: print_vma_addr possible deadlock (was Re: Jeste jeden bug)

> > in commit 03252919 you introduced print_vma_addr(), but this funcion for 
> > obvious reasons takes mmap_sem, so it is not safe to call it from atomic 
> > context (i.e. do_trap(), for example), which is behavior your patch 
> > introduced.

Ah yes -- this behaviour of int3 do_trap was always a source of bugs. I remember
fixing such things in this area several times (last time in the RT kernel), but 
I keep forgetting it. Sorry.

The correct fix is to run the int3 and debug handlers on the process stack 
when the fault originated from user space. Then they can run preemptive
and it's ok to schedule for the lock too.

I'll fix that tomorrow.

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