linux-kernel - Re: [COUNTERPATCH] mm: avoid overflowing preempt_count() in mmu_take_all

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100401160008.GS5825@random.random>
Date:	Thu, 1 Apr 2010 18:00:08 +0200
From:	Andrea Arcangeli <aarcange@...hat.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Avi Kivity <avi@...hat.com>, Thomas Gleixner <tglx@...utronix.de>,
	Rik van Riel <riel@...hat.com>, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org,
	Kent Overstreet <kent.overstreet@...il.com>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [COUNTERPATCH] mm: avoid overflowing preempt_count() in
 mmu_take_all_locks()

On Thu, Apr 01, 2010 at 05:50:02PM +0200, Peter Zijlstra wrote:
> You also seem to move the tlb_gather stuff around, we have patches in

Well that patchset is years old, there are much more recent patches to
move tlb_gather around so that it will happen after the mmu_notifier
invalidate calls. That is only relevant to allow mmu notifier handlers
to schedule.

> -rt that make tlb_gather preemptible, once i_mmap_lock is preemptible we
> can do in mainline too.

Ok. However just moving it inside the mmu notifier range calls won't
slowdown anything or reduce its effectiveness, either ways will be
fine with XPMEM. This is only XPMEM material and tlb_gather is the
trivial part of it. The hard part is to make those locks schedule
capable, and I'm sure XPMEM developers will greatly appreciate such a
change. I thought initially it had to be conditional to XPMEM=y but
maintaining two different locks is a bit of a pain (especially for
distros that wants to ship a single kernel) but as this effort
started, it'd provide some minor latency improvement in that 1msec
when a new virtual machine starts or when a new taks registers itself
to GRU or XPMEM device drivers. I'm personally fine to make these
either mutexes or rwsem unconditionally as you prefer.
--
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/