From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [RFC][PATCH 0/2] fun with tlb flushing on s390 Date: Thu, 26 Jul 2012 21:42:50 +0200 Message-ID: <1343331770.32120.6.camel@twins> References: <1343317634-13197-1-git-send-email-schwidefsky@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1343317634-13197-1-git-send-email-schwidefsky@de.ibm.com> Sender: owner-linux-mm@kvack.org To: Martin Schwidefsky Cc: linux-arch@vger.kernel.org, linux-mm@kvack.org, Zachary Amsden , Benjamin Herrenschmidt , Paul Mackerras , Chris Metcalf , Thomas Gleixner , Ingo Molnar List-Id: linux-arch.vger.kernel.org On Thu, 2012-07-26 at 17:47 +0200, Martin Schwidefsky wrote: > A code review revealed another potential race in regard to TLB flushing > on s390. See patch #2 for the ugly details. To fix this I would like > to use the arch_enter_lazy_mmu_mode/arch_leave_lazy_mmu_mode but to do > that the pointer to the mm in question needs to be added to the functions= . > To keep things symmetrical arch_flush_lazy_mmu_mode should grow an mm > argument as well. >=20 > powerpc=20 I have a patch that makes sparc64 do the same thing. > and x86 have a non-empty implementation for the lazy mmu flush > primitives and tile calls the generic definition in the architecture > files (which is a bit strange because the generic definition is empty). > Comments? argh.. you're making my head hurt. I guess my first question is where is lazy_mmu_mode active crossing an mm? I thought it was only ever held across operations on a single mm. The second question would be if you could use that detach_mm thing I proposed a while back ( http://marc.info/?l=3Dlinux-mm&m=3D134090072917840 = ) or can we rework the active_mm magic in general to make all this easier? Your 2/2 patch makes me shiver.. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from casper.infradead.org ([85.118.1.10]:36722 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751965Ab2GZTnD convert rfc822-to-8bit (ORCPT ); Thu, 26 Jul 2012 15:43:03 -0400 Message-ID: <1343331770.32120.6.camel@twins> Subject: Re: [RFC][PATCH 0/2] fun with tlb flushing on s390 From: Peter Zijlstra Date: Thu, 26 Jul 2012 21:42:50 +0200 In-Reply-To: <1343317634-13197-1-git-send-email-schwidefsky@de.ibm.com> References: <1343317634-13197-1-git-send-email-schwidefsky@de.ibm.com> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Mime-Version: 1.0 Sender: linux-arch-owner@vger.kernel.org List-ID: To: Martin Schwidefsky Cc: linux-arch@vger.kernel.org, linux-mm@kvack.org, Zachary Amsden , Benjamin Herrenschmidt , Paul Mackerras , Chris Metcalf , Thomas Gleixner , Ingo Molnar Message-ID: <20120726194250.UihdYx3wP3cBZKtEDGPzkpxHrrzQclQflZLxthp-LCM@z> On Thu, 2012-07-26 at 17:47 +0200, Martin Schwidefsky wrote: > A code review revealed another potential race in regard to TLB flushing > on s390. See patch #2 for the ugly details. To fix this I would like > to use the arch_enter_lazy_mmu_mode/arch_leave_lazy_mmu_mode but to do > that the pointer to the mm in question needs to be added to the functions. > To keep things symmetrical arch_flush_lazy_mmu_mode should grow an mm > argument as well. > > powerpc I have a patch that makes sparc64 do the same thing. > and x86 have a non-empty implementation for the lazy mmu flush > primitives and tile calls the generic definition in the architecture > files (which is a bit strange because the generic definition is empty). > Comments? argh.. you're making my head hurt. I guess my first question is where is lazy_mmu_mode active crossing an mm? I thought it was only ever held across operations on a single mm. The second question would be if you could use that detach_mm thing I proposed a while back ( http://marc.info/?l=linux-mm&m=134090072917840 ) or can we rework the active_mm magic in general to make all this easier? Your 2/2 patch makes me shiver..