Re: [PATCH 3/4] arch: define CONFIG_PAGE_SIZE_*KB on all architectures
On Mon, Feb 26, 2024 at 05:14:13PM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann > > Most architectures only support a single hardcoded page size. In order > to ensure that each one of these sets the corresponding Kconfig symbols, > change over the PAGE_SHIFT definition to the common one and allow > only the hardware page size to be selected. > > Signed-off-by: Arnd Bergmann > --- ... > arch/s390/Kconfig | 1 + > arch/s390/include/asm/page.h | 2 +- ... > diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig > index fe565f3a3a91..b61c74c10050 100644 > --- a/arch/s390/Kconfig > +++ b/arch/s390/Kconfig > @@ -199,6 +199,7 @@ config S390 > select HAVE_MOD_ARCH_SPECIFIC > select HAVE_NMI > select HAVE_NOP_MCOUNT > + select HAVE_PAGE_SIZE_4KB > select HAVE_PCI > select HAVE_PERF_EVENTS > select HAVE_PERF_REGS > diff --git a/arch/s390/include/asm/page.h b/arch/s390/include/asm/page.h > index 73b9c3bf377f..ded9548d11d9 100644 > --- a/arch/s390/include/asm/page.h > +++ b/arch/s390/include/asm/page.h > @@ -11,7 +11,7 @@ > #include > #include > > -#define _PAGE_SHIFT 12 > +#define _PAGE_SHIFT CONFIG_PAGE_SHIFT Acked-by: Heiko Carstens
Re: [PATCH v2 00/29] vmlinux.lds.h: Refactor EXCEPTION_TABLE and NOTES
On Thu, Oct 10, 2019 at 05:05:40PM -0700, Kees Cook wrote: > Arch maintainers: please send Acks (if you haven't already) for your > respective linker script changes; the intention is for this series to > land via -tip. > > v1: https://lore.kernel.org/lkml/20190926175602.33098-1-keesc...@chromium.org > v2: clean up commit messages, rename RO_EXCEPTION_TABLE (bp) > > > This series works to move the linker sections for NOTES and > EXCEPTION_TABLE into the RO_DATA area, where they belong on most > (all?) architectures. The problem being addressed was the discovery > by Rick Edgecombe that the exception table was accidentally marked > executable while he was developing his execute-only-memory series. When > permissions were flipped from readable-and-executable to only-executable, > the exception table became unreadable, causing things to explode rather > badly. :) Feel free to add Acked-by: Heiko Carstens to every patch in this series which touches s390.
Re: [PATCH v2 06/29] s390: Move RO_DATA into "text" PT_LOAD Program Header
On Thu, Oct 10, 2019 at 05:05:46PM -0700, Kees Cook wrote:
> In preparation for moving NOTES into RO_DATA, move RO_DATA back into the
> "text" PT_LOAD Program Header, as done with other architectures. The
> "data" PT_LOAD now starts with the writable data section.
>
> Signed-off-by: Kees Cook
> ---
> arch/s390/kernel/vmlinux.lds.S | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/s390/kernel/vmlinux.lds.S b/arch/s390/kernel/vmlinux.lds.S
> index 7e0eb4020917..13294fef473e 100644
> --- a/arch/s390/kernel/vmlinux.lds.S
> +++ b/arch/s390/kernel/vmlinux.lds.S
> @@ -52,7 +52,7 @@ SECTIONS
>
> NOTES :text :note
>
> - .dummy : { *(.dummy) } :data
> + .dummy : { *(.dummy) } :text
>
> RO_DATA_SECTION(PAGE_SIZE)
>
> @@ -64,7 +64,7 @@ SECTIONS
> .data..ro_after_init : {
>*(.data..ro_after_init)
> JUMP_TABLE_DATA
> - }
> + } :data
> EXCEPTION_TABLE(16)
> . = ALIGN(PAGE_SIZE);
> __end_ro_after_init = .;
Acked-by: Heiko Carstens
Re: [PATCH 2/2] arch: add pidfd and io_uring syscalls everywhere
On Mon, Mar 25, 2019 at 03:47:37PM +0100, Arnd Bergmann wrote: > Add the io_uring and pidfd_send_signal system calls to all architectures. > > These system calls are designed to handle both native and compat tasks, > so all entries are the same across architectures, only arm-compat and > the generic tale still use an old format. > > Signed-off-by: Arnd Bergmann > diff --git a/arch/s390/kernel/syscalls/syscall.tbl > b/arch/s390/kernel/syscalls/syscall.tbl > index 02579f95f391..3eb56e639b96 100644 > --- a/arch/s390/kernel/syscalls/syscall.tbl > +++ b/arch/s390/kernel/syscalls/syscall.tbl > @@ -426,3 +426,7 @@ > 421 32 rt_sigtimedwait_time64 - > compat_sys_rt_sigtimedwait_time64 > 422 32 futex_time64- > sys_futex > 423 32 sched_rr_get_interval_time64- > sys_sched_rr_get_interval > +424 common pidfd_send_signal sys_pidfd_send_signal > +425 common io_uring_setup sys_io_uring_setup > +426 common io_uring_enter sys_io_uring_enter > +427 common io_uring_register sys_io_uring_register I was just about to write that io_uring_enter is missing compat handling, but your first patch actually fixes that. Would have been good to be cc'ed on both patches :) For s390: Acked-by: Heiko Carstens
Re: CONFIG_ARCH_SUPPORTS_INT128: Why not mips, s390, powerpc, and alpha?
On Fri, Mar 29, 2019 at 01:07:07PM +, George Spelvin wrote: > (Cross-posted in case there are generic issues; please trim if > discussion wanders into single-architecture details.) > > I was working on some scaling code that can benefit from 64x64->128-bit > multiplies. GCC supports an __int128 type on processors with hardware > support (including z/Arch and MIPS64), but the support was broken on > early compilers, so it's gated behind CONFIG_ARCH_SUPPORTS_INT128. > > Currently, of the ten 64-bit architectures Linux supports, that's > only enabled on x86, ARM, and RISC-V. > > SPARC and HP-PA don't have support. > > But that leaves Alpha, Mips, PowerPC, and S/390x. > > Current mips64, powerpc64, and s390x gcc seems to generate sensible code > for mul_u64_u64_shr() in if I cross-compile them. > > I don't have easy access to an Alpha cross-compiler to test, but > as it has UMULH, I suspect it would work, too. > > Is there a reason it hasn't been enabled on these platforms? It hasn't been enabled on s390 simply because at least I wasn't aware of this config option. Feel free to send a patch, otherwise I will enable this. Whatever you prefer. Thanks for pointing this out!
Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures
On Fri, Jan 18, 2019 at 05:18:35PM +0100, Arnd Bergmann wrote: > This adds 21 new system calls on each ABI that has 32-bit time_t > today. All of these have the exact same semantics as their existing > counterparts, and the new ones all have macro names that end in 'time64' > for clarification. > > This gets us to the point of being able to safely use a C library > that has 64-bit time_t in user space. There are still a couple of > loose ends to tie up in various areas of the code, but this is the > big one, and should be entirely uncontroversial at this point. > > In particular, there are four system calls (getitimer, setitimer, > waitid, and getrusage) that don't have a 64-bit counterpart yet, > but these can all be safely implemented in the C library by wrapping > around the existing system calls because the 32-bit time_t they > pass only counts elapsed time, not time since the epoch. They > will be dealt with later. > > Signed-off-by: Arnd Bergmann > --- > arch/s390/kernel/syscalls/syscall.tbl | 20 + For the s390 bits: Acked-by: Heiko Carstens
Re: [PATCH v2 28/29] y2038: rename old time and utime syscalls
On Fri, Jan 18, 2019 at 05:18:34PM +0100, Arnd Bergmann wrote: > The time, stime, utime, utimes, and futimesat system calls are only > used on older architectures, and we do not provide y2038 safe variants > of them, as they are replaced by clock_gettime64, clock_settime64, > and utimensat_time64. > > However, for consistency it seems better to have the 32-bit architectures > that still use them call the "time32" entry points (leaving the > traditional handlers for the 64-bit architectures), like we do for system > calls that now require two versions. > > Note: We used to always define __ARCH_WANT_SYS_TIME and > __ARCH_WANT_SYS_UTIME and only set __ARCH_WANT_COMPAT_SYS_TIME and > __ARCH_WANT_SYS_UTIME32 for compat mode on 64-bit kernels. Now this is > reversed: only 64-bit architectures set __ARCH_WANT_SYS_TIME/UTIME, while > we need __ARCH_WANT_SYS_TIME32/UTIME32 for 32-bit architectures and compat > mode. The resulting asm/unistd.h changes look a bit counterintuitive. > > This is only a cleanup patch and it should not change any behavior. > > Signed-off-by: Arnd Bergmann ... > arch/s390/include/asm/unistd.h | 2 +- For the s390 bits: Acked-by: Heiko Carstens
Re: [PATCH v2 17/29] syscalls: remove obsolete __IGNORE_ macros
On Fri, Jan 18, 2019 at 05:18:23PM +0100, Arnd Bergmann wrote: > These are all for ignoring the lack of obsolete system calls, > which have been marked the same way in scripts/checksyscall.sh, > so these can be removed. > > Signed-off-by: Arnd Bergmann > --- > arch/mips/include/asm/unistd.h | 16 > arch/parisc/include/asm/unistd.h | 3 --- > arch/s390/include/asm/unistd.h | 2 -- > arch/xtensa/include/asm/unistd.h | 12 > 4 files changed, 33 deletions(-) For the s390 bits: Acked-by: Heiko Carstens
Re: [PATCH v2 14/29] arch: add pkey and rseq syscall numbers everywhere
On Fri, Jan 18, 2019 at 05:18:20PM +0100, Arnd Bergmann wrote: > Most architectures define system call numbers for the rseq and pkey system > calls, even when they don't support the features, and perhaps never will. > > Only a few architectures are missing these, so just define them anyway > for consistency. If we decide to add them later to one of these, the > system call numbers won't get out of sync then. > > Signed-off-by: Arnd Bergmann > --- > arch/alpha/include/asm/unistd.h | 4 > arch/alpha/kernel/syscalls/syscall.tbl | 4 > arch/ia64/kernel/syscalls/syscall.tbl | 4 > arch/m68k/kernel/syscalls/syscall.tbl | 4 > arch/parisc/include/asm/unistd.h| 3 --- > arch/parisc/kernel/syscalls/syscall.tbl | 4 > arch/s390/include/asm/unistd.h | 3 --- > arch/s390/kernel/syscalls/syscall.tbl | 3 +++ > arch/sh/kernel/syscalls/syscall.tbl | 4 > arch/sparc/include/asm/unistd.h | 5 - > arch/sparc/kernel/syscalls/syscall.tbl | 4 > arch/xtensa/kernel/syscalls/syscall.tbl | 1 + > 12 files changed, 28 insertions(+), 15 deletions(-) For the s390 bits: Acked-by: Heiko Carstens
Re: [PATCH v2 13/29] arch: add split IPC system calls where needed
On Fri, Jan 18, 2019 at 05:18:19PM +0100, Arnd Bergmann wrote: > The IPC system call handling is highly inconsistent across architectures, > some use sys_ipc, some use separate calls, and some use both. We also > have some architectures that require passing IPC_64 in the flags, and > others that set it implicitly. > > For the additon of a y2083 safe semtimedop() system call, I chose to only > support the separate entry points, but that requires first supporting > the regular ones with their own syscall numbers. > > The IPC_64 is now implied by the new semctl/shmctl/msgctl system > calls even on the architectures that require passing it with the ipc() > multiplexer. > > I'm not adding the new semtimedop() or semop() on 32-bit architectures, > those will get implemented using the new semtimedop_time64() version > that gets added along with the other time64 calls. > Three 64-bit architectures (powerpc, s390 and sparc) get semtimedop(). > > Signed-off-by: Arnd Bergmann > --- > One aspect here that might be a bit controversial is the use of > the same system call numbers across all architectures, synchronizing > all of them with the x86-32 numbers. With the new syscall.tbl > files, I hope we can just keep doing that in the future, and no > longer require the architecture maintainers to assign a number. > > This is mainly useful for implementers of the C libraries: if > we can add future system calls everywhere at the same time, using > a particular version of the kernel headers also guarantees that > the system call number macro is visible. > --- > arch/m68k/kernel/syscalls/syscall.tbl | 11 +++ > arch/mips/kernel/syscalls/syscall_o32.tbl | 11 +++ > arch/powerpc/kernel/syscalls/syscall.tbl | 13 + > arch/s390/kernel/syscalls/syscall.tbl | 12 > arch/sh/kernel/syscalls/syscall.tbl | 11 +++ > arch/sparc/kernel/syscalls/syscall.tbl| 12 > arch/x86/entry/syscalls/syscall_32.tbl| 11 +++ > 7 files changed, 81 insertions(+) For the s390 bits: Acked-by: Heiko Carstens
Re: [PATCH 19/21] treewide: add checks for the return value of memblock_alloc*()
On Wed, Jan 16, 2019 at 03:44:19PM +0200, Mike Rapoport wrote:
> Add check for the return value of memblock_alloc*() functions and call
> panic() in case of error.
> The panic message repeats the one used by panicing memblock allocators with
> adjustment of parameters to include only relevant ones.
>
> The replacement was mostly automated with semantic patches like the one
> below with manual massaging of format strings.
>
> @@
> expression ptr, size, align;
> @@
> ptr = memblock_alloc(size, align);
> + if (!ptr)
> + panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__,
> size, align);
>
> Signed-off-by: Mike Rapoport
...
> diff --git a/arch/s390/numa/toptree.c b/arch/s390/numa/toptree.c
> index 71a608c..0118c77 100644
> --- a/arch/s390/numa/toptree.c
> +++ b/arch/s390/numa/toptree.c
> @@ -31,10 +31,14 @@ struct toptree __ref *toptree_alloc(int level, int id)
> {
> struct toptree *res;
>
> - if (slab_is_available())
> + if (slab_is_available()) {
> res = kzalloc(sizeof(*res), GFP_KERNEL);
> - else
> + } else {
> res = memblock_alloc(sizeof(*res), 8);
> + if (!res)
> + panic("%s: Failed to allocate %zu bytes align=0x%x\n",
> + __func__, sizeof(*res), 8);
> + }
> if (!res)
> return res;
Please remove this hunk, since the code _should_ be able to handle
allocation failures anyway (see end of quoted code).
Otherwise for the s390 bits:
Acked-by: Heiko Carstens
Re: [PATCH 15/15] arch: add pkey and rseq syscall numbers everywhere
On Fri, Jan 11, 2019 at 06:30:43PM +0100, Arnd Bergmann wrote: > On Thu, Jan 10, 2019 at 9:36 PM Heiko Carstens > wrote: > > On Thu, Jan 10, 2019 at 05:24:35PM +0100, Arnd Bergmann wrote: > > > Since you only need/want the system call numbers, could you please > > change these lines to: > > > > > +384 common pkey_alloc - - > > > +385 common pkey_free - - > > > +386 common pkey_mprotect - - > > > > Otherwise it _looks_ like we would need compat wrappers here as well, > > even though all of them would just jump to sys_ni_syscall() in this > > case. Making this explicit seems to better. > > Ok, fair enough. I considered doing this originally and then > decided against it for consistency with the asm-generic file, > but I don't care much either way. > > Is this something you may want to add later? I'm not sure exactly > how pkey compares to s390 storage keys, or if this is something > completely unrelated. I don't think pkeys will ever work on s390, since they require a key per mapping, while the s390 storage keys are per physical page.
Re: [PATCH 07/11] y2038: syscalls: rename y2038 compat syscalls
On Thu, Jan 10, 2019 at 06:22:12PM +0100, Arnd Bergmann wrote: > diff --git a/arch/s390/kernel/syscalls/syscall.tbl > b/arch/s390/kernel/syscalls/syscall.tbl > index f84ea364a302..b3199a744731 100644 > --- a/arch/s390/kernel/syscalls/syscall.tbl > +++ b/arch/s390/kernel/syscalls/syscall.tbl > @@ -20,7 +20,7 @@ > 10 common unlink sys_unlink > compat_sys_unlink > 11 common execve sys_execve > compat_sys_execve > 12 common chdir sys_chdir > compat_sys_chdir > -13 32 time- > compat_sys_time > +13 32 time- > sys_time32 > 14 common mknod sys_mknod > compat_sys_mknod > 15 common chmod sys_chmod > compat_sys_chmod > 16 32 lchown - > compat_sys_s390_lchown16 > @@ -30,11 +30,11 @@ > 22 common umount sys_oldumount > compat_sys_oldumount > 23 32 setuid - > compat_sys_s390_setuid16 > 24 32 getuid - > compat_sys_s390_getuid16 > -25 32 stime - > compat_sys_stime > +25 32 stime - > sys_stime32 > 26 common ptrace sys_ptrace > compat_sys_ptrace > 27 common alarm sys_alarm > sys_alarm > 29 common pause sys_pause > sys_pause > -30 common utime sys_utime > compat_sys_utime > +30 common utime sys_utime > sys_utime32 ...(and more)... All of them need compat wrappers to clear the uppermost 33 bits of user space pointers. I assume there is no new *32 system call which takes u64/s64 arguments; so the pointers should be the only problem.
Re: [PATCH 15/15] arch: add pkey and rseq syscall numbers everywhere
On Thu, Jan 10, 2019 at 05:24:35PM +0100, Arnd Bergmann wrote: > Most architectures define system call numbers for the rseq and pkey system > calls, even when they don't support the features, and perhaps never will. > > Only a few architectures are missing these, so just define them anyway > for consistency. If we decide to add them later to one of these, the > system call numbers won't get out of sync then. > > Signed-off-by: Arnd Bergmann > diff --git a/arch/s390/include/asm/unistd.h b/arch/s390/include/asm/unistd.h > index a1fbf15d53aa..ed08f114ee91 100644 > --- a/arch/s390/include/asm/unistd.h > +++ b/arch/s390/include/asm/unistd.h > @@ -11,9 +11,6 @@ > #include > > #define __IGNORE_time > -#define __IGNORE_pkey_mprotect > -#define __IGNORE_pkey_alloc > -#define __IGNORE_pkey_free > > #define __ARCH_WANT_NEW_STAT > #define __ARCH_WANT_OLD_READDIR > diff --git a/arch/s390/kernel/syscalls/syscall.tbl > b/arch/s390/kernel/syscalls/syscall.tbl > index 428cf512a757..f84ea364a302 100644 > --- a/arch/s390/kernel/syscalls/syscall.tbl > +++ b/arch/s390/kernel/syscalls/syscall.tbl > @@ -391,6 +391,9 @@ > 381 common kexec_file_load sys_kexec_file_load > compat_sys_kexec_file_load > 382 common io_pgetevents sys_io_pgetevents > compat_sys_io_pgetevents > 383 common rseqsys_rseq > compat_sys_rseq > +384 common pkey_alloc sys_pkey_alloc > sys_pkey_alloc > +385 common pkey_free sys_pkey_free > sys_pkey_free > +386 common pkey_mprotect sys_pkey_mprotect > sys_pkey_mprotect Since you only need/want the system call numbers, could you please change these lines to: > +384 common pkey_alloc - - > +385 common pkey_free - - > +386 common pkey_mprotect - - Otherwise it _looks_ like we would need compat wrappers here as well, even though all of them would just jump to sys_ni_syscall() in this case. Making this explicit seems to better.
Re: [PATCH 14/15] arch: add split IPC system calls where needed
On Thu, Jan 10, 2019 at 05:24:34PM +0100, Arnd Bergmann wrote: > The IPC system call handling is highly inconsistent across architectures, > some use sys_ipc, some use separate calls, and some use both. We also > have some architectures that require passing IPC_64 in the flags, and > others that set it implicitly. > > For the additon of a y2083 safe semtimedop() system call, I chose to only > support the separate entry points, but that requires first supporting > the regular ones with their own syscall numbers. > > The IPC_64 is now implied by the new semctl/shmctl/msgctl system > calls even on the architectures that require passing it with the ipc() > multiplexer. > > I'm not adding the new semtimedop() or semop() on 32-bit architectures, > those will get implemented using the new semtimedop_time64() version > that gets added along with the other time64 calls. > Three 64-bit architectures (powerpc, s390 and sparc) get semtimedop(). > > Signed-off-by: Arnd Bergmann > --- > One aspect here that might be a bit controversial is the use of > the same system call numbers across all architectures, synchronizing > all of them with the x86-32 numbers. With the new syscall.tbl > files, I hope we can just keep doing that in the future, and no > longer require the architecture maintainers to assign a number. > > This is mainly useful for implementers of the C libraries: if > we can add future system calls everywhere at the same time, using > a particular version of the kernel headers also guarantees that > the system call number macro is visible. > diff --git a/arch/s390/kernel/syscalls/syscall.tbl > b/arch/s390/kernel/syscalls/syscall.tbl > index 022fc099b628..428cf512a757 100644 > --- a/arch/s390/kernel/syscalls/syscall.tbl > +++ b/arch/s390/kernel/syscalls/syscall.tbl > @@ -391,3 +391,15 @@ > 381 common kexec_file_load sys_kexec_file_load > compat_sys_kexec_file_load > 382 common io_pgetevents sys_io_pgetevents > compat_sys_io_pgetevents > 383 common rseqsys_rseq > compat_sys_rseq > +# room for arch specific syscalls > +392 64 semtimedop sys_semtimedop - > +393 common semget sys_semget > sys_semget ... > +395 common shmget sys_shmget > sys_shmget ... > +398 common shmdt sys_shmdt > sys_shmdt > +399 common msgget sys_msgget > sys_msgget These four need compat system call wrappers, unfortunately... (well, actually only shmget and shmdt require them, but let's add them for all four). See arch/s390/kernel/compat_wrapper.c I'm afraid this compat special handling will be even more annoying in the future, since s390 will be the only architecture which requires this special handling. _Maybe_ it would make sense to automatically generate a weak compat system call wrapper for s390 with the SYSCALL_DEFINE macros, but that probably won't work in all cases.
Re: [PATCH REBASED 3/6] s390: Add __down_read_killable()
On Sat, Sep 30, 2017 at 12:36:12PM +0200, Martin Schwidefsky wrote: > On Sat, 30 Sep 2017 11:20:02 +0200 > Heiko Carstens <heiko.carst...@de.ibm.com> wrote: > > > On Fri, Sep 29, 2017 at 07:06:18PM +0300, Kirill Tkhai wrote: > > > Similar to __down_write_killable(), and read killable primitive. > > > > > > Signed-off-by: Kirill Tkhai <ktk...@virtuozzo.com> > > > --- > > > arch/s390/include/asm/rwsem.h | 18 -- > > > 1 file changed, 16 insertions(+), 2 deletions(-) > > > > > > diff --git a/arch/s390/include/asm/rwsem.h > > > b/arch/s390/include/asm/rwsem.h > > > > FWIW, while looking into this patch I realized that we never optimized our > > rwsem primitives to make use of new atomic instructions. > > > > The generic rwsem header file however does, since it uses atomic ops which > > we did optimize. Even when compiling for old machines the generic version > > generates better code. Therefore I will remove the 15 years old s390 > > implementation and switch to the generic version instead. > > Take care not to conflict with the queued spinlock/rwlock patches on the > features branch. > > https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/commit/?h=features=eb3b7b848fb3dd00f7a57d633d4ae4d194aa7865 > > Me thinks that what you have in mind is already done. No, it's not done. You probably mixed up rwlocks and rwsems? -- To unsubscribe from this list: send the line "unsubscribe linux-alpha" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] futex: remove duplicated code
On Fri, Mar 03, 2017 at 01:27:10PM +0100, Jiri Slaby wrote:
> There is code duplicated over all architecture's headers for
> futex_atomic_op_inuser. Namely op decoding, access_ok check for uaddr,
> and comparison of the result.
>
> Remove this duplication and leave up to the arches only the needed
> assembly which is now in arch_futex_atomic_op_inuser.
>
> Note that s390 removed access_ok check in d12a29703 ("s390/uaccess:
> remove pointless access_ok() checks") as access_ok there returns true.
> We introduce it back to the helper for the sake of simplicity (it gets
> optimized away anyway).
>
> Signed-off-by: Jiri Slaby <jsl...@suse.cz>
> ---
> arch/s390/include/asm/futex.h | 23 -
> include/asm-generic/futex.h | 50
> +++--
> kernel/futex.c | 36 ++
Looks good to me and still boots on s390. Therefore for the s390 bits:
Acked-by: Heiko Carstens <heiko.carst...@de.ibm.com>
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
