From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Mar 2017 17:19:12 +0100 (CET) Received: from mail-wm0-x242.google.com ([IPv6:2a00:1450:400c:c09::242]:33207 "EHLO mail-wm0-x242.google.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S23993411AbdCNQTF2Lkde (ORCPT ); Tue, 14 Mar 2017 17:19:05 +0100 Received: by mail-wm0-x242.google.com with SMTP id n11so611849wma.0; Tue, 14 Mar 2017 09:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=from:date:to:cc:subject:message-id:mail-followup-to:mime-version :content-disposition:in-reply-to:user-agent; bh=+6H+T1ojThgGAdaNMUOtropB7bl8aLDEx/QCCOeIdEg=; b=CoVN3kv/AUdJXSgkJWNYeIjSVamB9btqVoURw+t8JJgHP1a766xzdtVxAYVCldO8Qm Zxx4ABq6Dm2XNYZ/Vmj+X2iaHb2kEPPkJOl1BTswLReICleF5q59sY8v9Av72ngHSQpS c+cF1HUFDzky3hOyd6JfADNoPY0MmqhRU565axT+e8tMCe/2x5l1TGs8vq2ap9lKtNZN GiGLGl9XDH5q+/uMkpfZU8jYHm2lOyU81eagJE34KfFf9WGZhZ+4f4oeG/bd/PM0b70l zcOUtzfr9NqNcdpuDabZp2lrt9CJx86cGsG+CKkT6sYMnMPG80ZQrP3uzawTzz6HaP7+ K9oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id :mail-followup-to:mime-version:content-disposition:in-reply-to :user-agent; bh=+6H+T1ojThgGAdaNMUOtropB7bl8aLDEx/QCCOeIdEg=; b=KNGWidZj/X50P8+UhkcRZQOds+YCPWCVOmUUxWPQ0sQAQjXbiQ3muZ4GVSW+/anSm1 qw4DYUSiCB3Qjxcak2xmajDFvtTM6Cc19w6nD96C7PV6M3Pgw4qKus7TtpA9ixlJeDs9 8bwtuah4dcAAdJA1r+ovp2W4kwKOD/Og5kv9BxmlwYXnoxiYatAh9IzJfVWND14Y9Dz6 uIJo/FH4XoaGFkbmrdKUK/7Wexkocq39cnwd8qppbhRmu3ENhwqRHp+ugtu17YdYEMaj bT/p1wNDAI0jI0s5QmA81DLlbpu0b7HykkHu1OYoWZXVPvMSQe0/QDP+/bc+KgdHri7v RDpg== X-Gm-Message-State: AFeK/H3nyXRmMbBsgkEIw0Rp9fyuapoRuiqHOBSxP5ikN5LpzvSCGtQ4RpyPxLlNdzDfFQ== X-Received: by 10.28.151.142 with SMTP id z136mr17267815wmd.20.1489508339431; Tue, 14 Mar 2017 09:18:59 -0700 (PDT) Received: from localhost (login1.zih.tu-dresden.de. [141.76.16.140]) by smtp.googlemail.com with ESMTPSA id p12sm29898173wrb.46.2017.03.14.09.18.57 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 14 Mar 2017 09:18:58 -0700 (PDT) From: Till Smejkal X-Google-Original-From: Till Smejkal Date: Tue, 14 Mar 2017 09:18:55 -0700 To: David Laight Cc: 'Till Smejkal' , Richard Henderson , Ivan Kokshaysky , Matt Turner , Vineet Gupta , Russell King , Catalin Marinas , Will Deacon , Steven Miao , Richard Kuo , Tony Luck , Fenghua Yu , James Hogan , Ralf Baechle , "James E.J. Bottomley" , Helge Deller , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Martin Schwidefsky , Heiko Carstens , Yoshinori Sato , Rich Felker , "David S. Miller" , Chris Metcalf , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , "x86@kernel.org" , Andy Lutomirski , Chris Zankel , Max Filippov , Arnd Bergmann , Greg Kroah-Hartman , Laurent Pinchart , Mauro Carvalho Chehab , Pawel Osciak , Marek Szyprowski , Kyungmin Park , David Woodhouse , Brian Norris , Boris Brezillon , Marek Vasut , Richard Weinberger , Cyrille Pitchen , Felipe Balbi , Alexander Viro , Benjamin LaHaise , Nadia Yvette Chambers , Jeff Layton , "J. Bruce Fields" , Peter Zijlstra , Hugh Dickins , Arnaldo Carvalho de Melo , Alexander Shishkin , Jaroslav Kysela , Takashi Iwai , "linux-mips@linux-mips.org" , "alsa-devel@alsa-project.org" , "linux-ia64@vger.kernel.org" , "linux-aio@kvack.org" , "linux-mm@kvack.org" , "linux-mtd@lists.infradead.org" , "sparclinux@vger.kernel.org" , "linux-arch@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-hexagon@vger.kernel.org" , "linux-sh@vger.kernel.org" , "linux-snps-arc@lists.infradead.org" , "linux-media@vger.kernel.org" , "linux-xtensa@linux-xtensa.org" , "adi-buildroot-devel@lists.sourceforge.net" , "linux-metag@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-parisc@vger.kernel.org" , "linux-api@vger.kernel.org" , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-alpha@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" Subject: Re: [RFC PATCH 07/13] kernel/fork: Split and export 'mm_alloc' and 'mm_init' Message-ID: <20170314161855.2g2gc3ff4ifj2lqt@arch-dev> Mail-Followup-To: David Laight , 'Till Smejkal' , Richard Henderson , Ivan Kokshaysky , Matt Turner , Vineet Gupta , Russell King , Catalin Marinas , Will Deacon , Steven Miao , Richard Kuo , Tony Luck , Fenghua Yu , James Hogan , Ralf Baechle , "James E.J. Bottomley" , Helge Deller , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Martin Schwidefsky , Heiko Carstens , Yoshinori Sato , Rich Felker , "David S. Miller" , Chris Metcalf , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , "x86@kernel.org" , Andy Lutomirski , Chris Zankel , Max Filippov , Arnd Bergmann , Greg Kroah-Hartman , Laurent Pinchart , Mauro Carvalho Chehab , Pawel Osciak , Marek Szyprowski , Kyungmin Park , David Woodhouse , Brian Norris , Boris Brezillon , Marek Vasut , Richard Weinberger , Cyrille Pitchen , Felipe Balbi , Alexander Viro , Benjamin LaHaise , Nadia Yvette Chambers , Jeff Layton , "J. Bruce Fields" , Peter Zijlstra , Hugh Dickins , Arnaldo Carvalho de Melo , Alexander Shishkin , Jaroslav Kysela , Takashi Iwai , "linux-mips@linux-mips.org" , "alsa-devel@alsa-project.org" , "linux-ia64@vger.kernel.org" , "linux-aio@kvack.org" , "linux-mm@kvack.org" , "linux-mtd@lists.infradead.org" , "sparclinux@vger.kernel.org" , "linux-arch@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-hexagon@vger.kernel.org" , "linux-sh@vger.kernel.org" , "linux-snps-arc@lists.infradead.org" , "linux-media@vger.kernel.org" , "linux-xtensa@linux-xtensa.org" , "adi-buildroot-devel@lists.sourceforge.net" , "linux-metag@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-parisc@vger.kernel.org" , "linux-api@vger.kernel.org" , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-alpha@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DCFFB03F4@AcuExch.aculab.com> User-Agent: NeoMutt/20170306 (1.8.0) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 57255 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: till.smejkal@googlemail.com Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips On Tue, 14 Mar 2017, David Laight wrote: > From: Linuxppc-dev Till Smejkal > > Sent: 13 March 2017 22:14 > > The only way until now to create a new memory map was via the exported > > function 'mm_alloc'. Unfortunately, this function not only allocates a new > > memory map, but also completely initializes it. However, with the > > introduction of first class virtual address spaces, some initialization > > steps done in 'mm_alloc' are not applicable to the memory maps needed for > > this feature and hence would lead to errors in the kernel code. > > > > Instead of introducing a new function that can allocate and initialize > > memory maps for first class virtual address spaces and potentially > > duplicate some code, I decided to split the mm_alloc function as well as > > the 'mm_init' function that it uses. > > > > Now there are four functions exported instead of only one. The new > > 'mm_alloc' function only allocates a new mm_struct and zeros it out. If one > > want to have the old behavior of mm_alloc one can use the newly introduced > > function 'mm_alloc_and_setup' which not only allocates a new mm_struct but > > also fully initializes it. > ... > > That looks like bugs waiting to happen. > You need unchanged code to fail to compile. Thank you for this hint. I can give the new mm_alloc function a different name so that code that uses the *old* mm_alloc function will fail to compile. I just reused the old name when I wrote the code, because mm_alloc was only used in very few locations in the kernel (2 times in the whole kernel source) which made identifying and changing them very easy. I also don't think that there will be many users in the kernel for mm_alloc in the future because it is a relatively low level data structure. But if it is better to use a different name for the new function, I am very happy to change this. Till From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm0-x242.google.com ([IPv6:2a00:1450:400c:c09::242]:33207 "EHLO mail-wm0-x242.google.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S23993411AbdCNQTF2Lkde (ORCPT ); Tue, 14 Mar 2017 17:19:05 +0100 From: Till Smejkal Date: Tue, 14 Mar 2017 09:18:55 -0700 Subject: Re: [RFC PATCH 07/13] kernel/fork: Split and export 'mm_alloc' and 'mm_init' Message-ID: <20170314161855.2g2gc3ff4ifj2lqt@arch-dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DCFFB03F4@AcuExch.aculab.com> Return-Path: Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-subscribe: List-owner: List-post: List-archive: To: David Laight Cc: 'Till Smejkal' , Richard Henderson , Ivan Kokshaysky , Matt Turner , Vineet Gupta , Russell King , Catalin Marinas , Will Deacon , Steven Miao , Richard Kuo , Tony Luck , Fenghua Yu , James Hogan , Ralf Baechle , "James E.J. Bottomley" , Helge Deller , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Martin Schwidefsky , Heiko Carstens , Yoshinori Sato , Rich Felker , "David S. Miller" , Chris Metcalf , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , "x86@kernel.org" , Andy Lutomirski , Chris Zankel , Max Filippov , Arnd Bergmann , Greg Kroah-Hartman , Laurent Pinchart , Mauro Carvalho Chehab , Pawel Osciak , Marek Szyprowski , Kyungmin Park , David Woodhouse , Brian Norris , Boris Brezillon , Marek Vasut , Richard Weinberger , Cyrille Pitchen , Felipe Balbi , Alexander Viro , Benjamin LaHaise , Nadia Yvette Chambers , Jeff Layton , "J. Bruce Fields" , Peter Zijlstra , Hugh Dickins , Arnaldo Carvalho de Melo , Alexander Shishkin , Jaroslav Kysela , Takashi Iwai , "linux-mips@linux-mips.org" , "alsa-devel@alsa-project.org" , "linux-ia64@vger.kernel.org" , "linux-aio@kvack.org" , "linux-mm@kvack.org" , "linux-mtd@lists.infradead.org" , "sparclinux@vger.kernel.org" , "linux-arch@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-hexagon@vger.kernel.org" , "linux-sh@vger.kernel.org" , "linux-snps-arc@lists.infradead.org" , "linux-media@vger.kernel.org" , "linux-xtensa@linux-xtensa.org" , "adi-buildroot-devel@lists.sourceforge.net" , "linux-metag@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-parisc@vger.kernel.org" , "linux-api@vger.kernel.org" , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-alpha@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" Message-ID: <20170314161855.-su8vx6XqAqqvcvTO_VpRWPvtWCke4JZdm1i72LJIOc@z> On Tue, 14 Mar 2017, David Laight wrote: > From: Linuxppc-dev Till Smejkal > > Sent: 13 March 2017 22:14 > > The only way until now to create a new memory map was via the exported > > function 'mm_alloc'. Unfortunately, this function not only allocates a new > > memory map, but also completely initializes it. However, with the > > introduction of first class virtual address spaces, some initialization > > steps done in 'mm_alloc' are not applicable to the memory maps needed for > > this feature and hence would lead to errors in the kernel code. > > > > Instead of introducing a new function that can allocate and initialize > > memory maps for first class virtual address spaces and potentially > > duplicate some code, I decided to split the mm_alloc function as well as > > the 'mm_init' function that it uses. > > > > Now there are four functions exported instead of only one. The new > > 'mm_alloc' function only allocates a new mm_struct and zeros it out. If one > > want to have the old behavior of mm_alloc one can use the newly introduced > > function 'mm_alloc_and_setup' which not only allocates a new mm_struct but > > also fully initializes it. > ... > > That looks like bugs waiting to happen. > You need unchanged code to fail to compile. Thank you for this hint. I can give the new mm_alloc function a different name so that code that uses the *old* mm_alloc function will fail to compile. I just reused the old name when I wrote the code, because mm_alloc was only used in very few locations in the kernel (2 times in the whole kernel source) which made identifying and changing them very easy. I also don't think that there will be many users in the kernel for mm_alloc in the future because it is a relatively low level data structure. But if it is better to use a different name for the new function, I am very happy to change this. Till