| Message ID | 20150721134441.d69e4e1099bd43e56835b3c5@linux-foundation.org (mailing list archive) |
|---|---|
| State | Awaiting Upstream |
| Headers | show |
On Tue, 2015-07-21 at 13:44 -0700, Andrew Morton wrote: > On Tue, 21 Jul 2015 15:59:37 -0400 Eric B Munson <emunson@akamai.com> 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. Yeah I think so. You haven't wired it up properly on powerpc, but I haven't mentioned it because I'd rather we did it. cheers -- 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
On Wed, 22 Jul 2015, Michael Ellerman wrote: > On Tue, 2015-07-21 at 13:44 -0700, Andrew Morton wrote: > > On Tue, 21 Jul 2015 15:59:37 -0400 Eric B Munson <emunson@akamai.com> 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. > > Yeah I think so. > > You haven't wired it up properly on powerpc, but I haven't mentioned it because > I'd rather we did it. > > cheers It looks like I will be spinning a V5, so I will drop all but the x86 system calls additions in that version.
On Wed, Jul 22, 2015 at 10:15:01AM -0400, Eric B Munson wrote: > > > > You haven't wired it up properly on powerpc, but I haven't mentioned it because > > I'd rather we did it. > > > > cheers > > It looks like I will be spinning a V5, so I will drop all but the x86 > system calls additions in that version. The MIPS bits are looking good however, so Acked-by: Ralf Baechle <ralf@linux-mips.org> With my ack, will you keep them or maybe carry them as a separate patch? Cheers, Ralf -- 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
On Thu, 23 Jul 2015, Ralf Baechle wrote: > On Wed, Jul 22, 2015 at 10:15:01AM -0400, Eric B Munson wrote: > > > > > > > You haven't wired it up properly on powerpc, but I haven't mentioned it because > > > I'd rather we did it. > > > > > > cheers > > > > It looks like I will be spinning a V5, so I will drop all but the x86 > > system calls additions in that version. > > The MIPS bits are looking good however, so > > Acked-by: Ralf Baechle <ralf@linux-mips.org> > > With my ack, will you keep them or maybe carry them as a separate patch? I will keep the MIPS additions as a separate patch in the series, though I have dropped two of the new syscalls after some discussion. So I will not include your ack on the new patch. Eric
On 07/24/2015 07:39 AM, Eric B Munson wrote: > On Thu, 23 Jul 2015, Ralf Baechle wrote: > >> On Wed, Jul 22, 2015 at 10:15:01AM -0400, Eric B Munson wrote: >> >>>> >>>> You haven't wired it up properly on powerpc, but I haven't mentioned it because >>>> I'd rather we did it. >>>> >>>> cheers >>> >>> It looks like I will be spinning a V5, so I will drop all but the x86 >>> system calls additions in that version. >> >> The MIPS bits are looking good however, so >> >> Acked-by: Ralf Baechle <ralf@linux-mips.org> >> >> With my ack, will you keep them or maybe carry them as a separate patch? > > I will keep the MIPS additions as a separate patch in the series, though > I have dropped two of the new syscalls after some discussion. So I will > not include your ack on the new patch. > > Eric > Hi Eric, next-20150724 still has some failures due to this patch set. Are those being looked at (I know parisc builds fail, but there may be others) ? Thanks, Guenter -- 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
On Fri, 24 Jul 2015, Guenter Roeck wrote: > On 07/24/2015 07:39 AM, Eric B Munson wrote: > >On Thu, 23 Jul 2015, Ralf Baechle wrote: > > > >>On Wed, Jul 22, 2015 at 10:15:01AM -0400, Eric B Munson wrote: > >> > >>>> > >>>>You haven't wired it up properly on powerpc, but I haven't mentioned it because > >>>>I'd rather we did it. > >>>> > >>>>cheers > >>> > >>>It looks like I will be spinning a V5, so I will drop all but the x86 > >>>system calls additions in that version. > >> > >>The MIPS bits are looking good however, so > >> > >>Acked-by: Ralf Baechle <ralf@linux-mips.org> > >> > >>With my ack, will you keep them or maybe carry them as a separate patch? > > > >I will keep the MIPS additions as a separate patch in the series, though > >I have dropped two of the new syscalls after some discussion. So I will > >not include your ack on the new patch. > > > >Eric > > > > Hi Eric, > > next-20150724 still has some failures due to this patch set. Are those > being looked at (I know parisc builds fail, but there may be others) ? > > Thanks, > Guenter Guenter, Yes, the next respin will drop all new arch syscall entries except x86[_64] and MIPS. I will leave it up to arch maintainers to add the entries. Eric
--- 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 <heiko.carstens@de.ibm.com> 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 <heiko.carstens@de.ibm.com> Cc: Eric B Munson <emunson@akamai.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> --- 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)