From patchwork Tue Jul 21 20:44:41 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 6838201 Return-Path: X-Original-To: patchwork-linux-parisc@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id B74219F380 for ; Tue, 21 Jul 2015 20:45:30 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D657A20690 for ; Tue, 21 Jul 2015 20:45:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D315E2064B for ; Tue, 21 Jul 2015 20:45:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932958AbbGUUoq (ORCPT ); Tue, 21 Jul 2015 16:44:46 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:40842 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932206AbbGUUon (ORCPT ); Tue, 21 Jul 2015 16:44:43 -0400 Received: from akpm3.mtv.corp.google.com (unknown [216.239.45.65]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 284B740F; Tue, 21 Jul 2015 20:44:42 +0000 (UTC) Date: Tue, 21 Jul 2015 13:44:41 -0700 From: Andrew Morton To: Eric B Munson Cc: Michal Hocko , Vlastimil Babka , Heiko Carstens , Geert Uytterhoeven , Catalin Marinas , Stephen Rothwell , Guenter Roeck , linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, adi-buildroot-devel@lists.sourceforge.net, linux-cris-kernel@axis.com, linux-ia64@vger.kernel.org, linux-m68k@vger.kernel.org, linux-mips@linux-mips.org, linux-am33-list@redhat.com, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH V4 2/6] mm: mlock: Add new mlock, munlock, and munlockall system calls Message-Id: <20150721134441.d69e4e1099bd43e56835b3c5@linux-foundation.org> In-Reply-To: <1437508781-28655-3-git-send-email-emunson@akamai.com> References: <1437508781-28655-1-git-send-email-emunson@akamai.com> <1437508781-28655-3-git-send-email-emunson@akamai.com> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Sender: linux-parisc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org X-Spam-Status: No, score=-8.1 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Tue, 21 Jul 2015 15:59:37 -0400 Eric B Munson wrote: > With the refactored mlock code, introduce new system calls for mlock, > munlock, and munlockall. The new calls will allow the user to specify > what lock states are being added or cleared. mlock2 and munlock2 are > trivial at the moment, but a follow on patch will add a new mlock state > making them useful. > > munlock2 addresses a limitation of the current implementation. If a > user calls mlockall(MCL_CURRENT | MCL_FUTURE) and then later decides > that MCL_FUTURE should be removed, they would have to call munlockall() > followed by mlockall(MCL_CURRENT) which could potentially be very > expensive. The new munlockall2 system call allows a user to simply > clear the MCL_FUTURE flag. This is hard. Maybe we shouldn't have wired up anything other than x86. That's what we usually do with new syscalls. You appear to have missed mm-mlock-add-new-mlock-munlock-and-munlockall-system-calls-fix.patch: Acked-by: Ralf Baechle --- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- a/arch/arm64/include/asm/unistd.h~mm-mlock-add-new-mlock-munlock-and-munlockall-system-calls-fix +++ a/arch/arm64/include/asm/unistd.h @@ -44,7 +44,7 @@ #define __ARM_NR_compat_cacheflush (__ARM_NR_COMPAT_BASE+2) #define __ARM_NR_compat_set_tls (__ARM_NR_COMPAT_BASE+5) -#define __NR_compat_syscalls 388 +#define __NR_compat_syscalls 391 #endif #define __ARCH_WANT_SYS_CLONE And mm-mlock-add-new-mlock-munlock-and-munlockall-system-calls-fix-2.patch: From: Heiko Carstens Subject: mm-mlock-add-new-mlock-munlock-and-munlockall-system-calls-fix-2 can we just remove the s390 bits which cause the breakage? I will wire up the syscalls as soon as the patch set gets merged. Heiko Carstens Cc: Eric B Munson Cc: Stephen Rothwell Signed-off-by: Andrew Morton --- arch/s390/kernel/syscalls.S | 3 --- 1 file changed, 3 deletions(-) diff -puN arch/s390/kernel/syscalls.S~mm-mlock-add-new-mlock-munlock-and-munlockall-system-calls-fix-2 arch/s390/kernel/syscalls.S --- a/arch/s390/kernel/syscalls.S~mm-mlock-add-new-mlock-munlock-and-munlockall-system-calls-fix-2 +++ a/arch/s390/kernel/syscalls.S @@ -363,6 +363,3 @@ SYSCALL(sys_bpf,compat_sys_bpf) SYSCALL(sys_s390_pci_mmio_write,compat_sys_s390_pci_mmio_write) SYSCALL(sys_s390_pci_mmio_read,compat_sys_s390_pci_mmio_read) SYSCALL(sys_execveat,compat_sys_execveat) -SYSCALL(sys_mlock2,compat_sys_mlock2) /* 355 */ -SYSCALL(sys_munlock2,compat_sys_munlock2) -SYSCALL(sys_munlockall2,compat_sys_munlockall2)