From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Date: Sun, 31 Mar 2019 16:28:18 +0000 Subject: Re: [PATCH 2/2] arch: add pidfd and io_uring syscalls everywhere Message-Id: List-Id: References: <20190325143521.34928-1-arnd@arndb.de> <20190325144737.703921-1-arnd@arndb.de> <87y34vl6ji.fsf@concordia.ellerman.id.au> In-Reply-To: <87y34vl6ji.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Michael Ellerman Cc: Rich Felker , linux-ia64@vger.kernel.org, Linux-sh list , Benjamin Herrenschmidt , Heiko Carstens , linux-mips@vger.kernel.org, "James E . J . Bottomley" , Max Filippov , Paul Mackerras , sparclinux , linux-s390 , Helge Deller , Russell King , Geert Uytterhoeven , Catalin Marinas , James Hogan , Firoz Khan , Matt Turner , Fenghua Yu , Will Deacon , linux-m68k , Ivan Kokshaysky , Linux ARM , Richard Henderson , Michal Simek , Tony Luck , Parisc List , Linux Kernel Mailing List , Ralf Baechle , Paul Burton , alpha , Martin Schwidefsky , Andrew Morton , linuxppc-dev , "David S . Miller" On Sun, Mar 31, 2019 at 5:47 PM Michael Ellerman wrote: > > Arnd Bergmann writes: > > 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 > > --- > > arch/alpha/kernel/syscalls/syscall.tbl | 4 ++++ > > arch/arm/tools/syscall.tbl | 4 ++++ > > arch/arm64/include/asm/unistd.h | 2 +- > > arch/arm64/include/asm/unistd32.h | 8 ++++++++ > > arch/ia64/kernel/syscalls/syscall.tbl | 4 ++++ > > arch/m68k/kernel/syscalls/syscall.tbl | 4 ++++ > > arch/microblaze/kernel/syscalls/syscall.tbl | 4 ++++ > > arch/mips/kernel/syscalls/syscall_n32.tbl | 4 ++++ > > arch/mips/kernel/syscalls/syscall_n64.tbl | 4 ++++ > > arch/mips/kernel/syscalls/syscall_o32.tbl | 4 ++++ > > arch/parisc/kernel/syscalls/syscall.tbl | 4 ++++ > > arch/powerpc/kernel/syscalls/syscall.tbl | 4 ++++ > > Have you done any testing? > > I'd rather not wire up syscalls that have never been tested at all on > powerpc. No, I have not. I did review the system calls carefully and added the first patch to fix the bug on x86 compat mode before adding the same bug on the other compat architectures though ;-) Generally, my feeling is that adding system calls is not fundamentally different from adding other ABIs, and we should really do it at the same time across all architectures, rather than waiting for each maintainer to get around to reviewing and testing the new calls first. This is not a problem on powerpc, but a lot of other architectures are less active, which is how we have always ended up with different sets of system calls across architectures. The problem here is that this makes it harder for the C library to know when a system call is guaranteed to be available. glibc still needs a feature test for newly added syscalls to see if they are working (they might be backported to an older kernel, or disabled), but whenever the minimum kernel version is increased, it makes sense to drop those checks and assume non-optional system calls will work if they were part of that minimum version. In the future, I'd hope that any new system calls get added right away on all architectures when they land (it was a bit tricky this time, because I still did a bunch of reworks that conflicted with the new calls). Bugs will happen of course, but I think adding them sooner makes it more likely to catch those bugs early on so we have a chance to fix them properly, and need fewer arch specific workarounds (ideally none) for system calls. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DB8F8C43381 for ; Sun, 31 Mar 2019 16:28:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AD66920857 for ; Sun, 31 Mar 2019 16:28:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731316AbfCaQ2h (ORCPT ); Sun, 31 Mar 2019 12:28:37 -0400 Received: from mail-qt1-f194.google.com ([209.85.160.194]:36460 "EHLO mail-qt1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731294AbfCaQ2g (ORCPT ); Sun, 31 Mar 2019 12:28:36 -0400 Received: by mail-qt1-f194.google.com with SMTP id s15so8128673qtn.3; Sun, 31 Mar 2019 09:28:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oSXHQsG3KOPg9vd5T+GCmFoc7Xf14JcZz1oGhypQBKw=; b=FywmAgQKw8GKWCgfqRIOXVZiz+XCIScercJxXlt4V7CB/ckYPgspOvIZBnestkgAoZ tlQ7eLDopNYdD2G3QKldeEvAsOTVXjVyI2s64F4k66jMI5vUPDt0olqTnFTN8jnKVy66 bi2eEg09BDzOBI5fD1LNSU6CgP/6ApsIl5BJy6XDbHsKWR94xBf/4sURAmJ/Rszqj+Cl 8ZJrnv7J7y0cVaB1HqzeBiswcBrU5tb0PuEGecjS8Ljdx+c3z/06cyxJ5wDe72s5U5H1 3FyTly8wXfx4Y02tsEHmRozyFLQRQ0l0nKd877n73gx//Eo9Tb+OBEzU3vPLmBG/4Xp+ o2fA== X-Gm-Message-State: APjAAAWGv29s3F0kbEr0MwXsrM6rHTiI4Ki8dw55BD/8AuVGXDlpLSmi AJQ0C5Itoq8vq15EICHRjOkPaUtT+JsTegKIfjM= X-Google-Smtp-Source: APXvYqx9e26flj4/DTUwCkm0QQZHO1TUNf4JZ4/rpFLAqXfyYImpebNZG5l1ed+kmdDk9YVAA0+XVhAQPMiHPduAVUU= X-Received: by 2002:ac8:3fbc:: with SMTP id d57mr47482205qtk.96.1554049715359; Sun, 31 Mar 2019 09:28:35 -0700 (PDT) MIME-Version: 1.0 References: <20190325143521.34928-1-arnd@arndb.de> <20190325144737.703921-1-arnd@arndb.de> <87y34vl6ji.fsf@concordia.ellerman.id.au> In-Reply-To: <87y34vl6ji.fsf@concordia.ellerman.id.au> From: Arnd Bergmann Date: Mon, 1 Apr 2019 00:28:18 +0800 Message-ID: Subject: Re: [PATCH 2/2] arch: add pidfd and io_uring syscalls everywhere To: Michael Ellerman Cc: Andrew Morton , Richard Henderson , Ivan Kokshaysky , Matt Turner , Russell King , Catalin Marinas , Will Deacon , Tony Luck , Fenghua Yu , Geert Uytterhoeven , Michal Simek , Ralf Baechle , Paul Burton , James Hogan , "James E . J . Bottomley" , Helge Deller , Benjamin Herrenschmidt , Paul Mackerras , Martin Schwidefsky , Heiko Carstens , Rich Felker , "David S . Miller" , Max Filippov , Firoz Khan , alpha , Linux Kernel Mailing List , Linux ARM , linux-ia64@vger.kernel.org, linux-m68k , linux-mips@vger.kernel.org, Parisc List , linuxppc-dev , linux-s390 , Linux-sh list , sparclinux Content-Type: text/plain; charset="UTF-8" Sender: linux-parisc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org On Sun, Mar 31, 2019 at 5:47 PM Michael Ellerman wrote: > > Arnd Bergmann writes: > > 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 > > --- > > arch/alpha/kernel/syscalls/syscall.tbl | 4 ++++ > > arch/arm/tools/syscall.tbl | 4 ++++ > > arch/arm64/include/asm/unistd.h | 2 +- > > arch/arm64/include/asm/unistd32.h | 8 ++++++++ > > arch/ia64/kernel/syscalls/syscall.tbl | 4 ++++ > > arch/m68k/kernel/syscalls/syscall.tbl | 4 ++++ > > arch/microblaze/kernel/syscalls/syscall.tbl | 4 ++++ > > arch/mips/kernel/syscalls/syscall_n32.tbl | 4 ++++ > > arch/mips/kernel/syscalls/syscall_n64.tbl | 4 ++++ > > arch/mips/kernel/syscalls/syscall_o32.tbl | 4 ++++ > > arch/parisc/kernel/syscalls/syscall.tbl | 4 ++++ > > arch/powerpc/kernel/syscalls/syscall.tbl | 4 ++++ > > Have you done any testing? > > I'd rather not wire up syscalls that have never been tested at all on > powerpc. No, I have not. I did review the system calls carefully and added the first patch to fix the bug on x86 compat mode before adding the same bug on the other compat architectures though ;-) Generally, my feeling is that adding system calls is not fundamentally different from adding other ABIs, and we should really do it at the same time across all architectures, rather than waiting for each maintainer to get around to reviewing and testing the new calls first. This is not a problem on powerpc, but a lot of other architectures are less active, which is how we have always ended up with different sets of system calls across architectures. The problem here is that this makes it harder for the C library to know when a system call is guaranteed to be available. glibc still needs a feature test for newly added syscalls to see if they are working (they might be backported to an older kernel, or disabled), but whenever the minimum kernel version is increased, it makes sense to drop those checks and assume non-optional system calls will work if they were part of that minimum version. In the future, I'd hope that any new system calls get added right away on all architectures when they land (it was a bit tricky this time, because I still did a bunch of reworks that conflicted with the new calls). Bugs will happen of course, but I think adding them sooner makes it more likely to catch those bugs early on so we have a chance to fix them properly, and need fewer arch specific workarounds (ideally none) for system calls. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 References: <20190325143521.34928-1-arnd@arndb.de> <20190325144737.703921-1-arnd@arndb.de> <87y34vl6ji.fsf@concordia.ellerman.id.au> In-Reply-To: <87y34vl6ji.fsf@concordia.ellerman.id.au> From: Arnd Bergmann Date: Mon, 1 Apr 2019 00:28:18 +0800 Message-ID: Subject: Re: [PATCH 2/2] arch: add pidfd and io_uring syscalls everywhere List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org List-Archive: To: Michael Ellerman Cc: Rich Felker , linux-ia64@vger.kernel.org, Linux-sh list , Benjamin Herrenschmidt , Heiko Carstens , linux-mips@vger.kernel.org, "James E . J . Bottomley" , Max Filippov , Paul Mackerras , sparclinux , linux-s390 , Helge Deller , Russell King , Geert Uytterhoeven , Catalin Marinas , James Hogan , Firoz Khan , Matt Turner , Fenghua Yu , Will Deacon , linux-m68k , Ivan Kokshaysky , Linux ARM , Richard Henderson , Michal Simek , Tony Luck , Parisc List , Linux Kernel Mailing List , Ralf Baechle , Paul Burton , alpha , Martin Schwidefsky , Andrew Morton , linuxppc-dev , "David S . Miller" List-ID: On Sun, Mar 31, 2019 at 5:47 PM Michael Ellerman wrote: > > Arnd Bergmann writes: > > 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 > > --- > > arch/alpha/kernel/syscalls/syscall.tbl | 4 ++++ > > arch/arm/tools/syscall.tbl | 4 ++++ > > arch/arm64/include/asm/unistd.h | 2 +- > > arch/arm64/include/asm/unistd32.h | 8 ++++++++ > > arch/ia64/kernel/syscalls/syscall.tbl | 4 ++++ > > arch/m68k/kernel/syscalls/syscall.tbl | 4 ++++ > > arch/microblaze/kernel/syscalls/syscall.tbl | 4 ++++ > > arch/mips/kernel/syscalls/syscall_n32.tbl | 4 ++++ > > arch/mips/kernel/syscalls/syscall_n64.tbl | 4 ++++ > > arch/mips/kernel/syscalls/syscall_o32.tbl | 4 ++++ > > arch/parisc/kernel/syscalls/syscall.tbl | 4 ++++ > > arch/powerpc/kernel/syscalls/syscall.tbl | 4 ++++ > > Have you done any testing? > > I'd rather not wire up syscalls that have never been tested at all on > powerpc. No, I have not. I did review the system calls carefully and added the first patch to fix the bug on x86 compat mode before adding the same bug on the other compat architectures though ;-) Generally, my feeling is that adding system calls is not fundamentally different from adding other ABIs, and we should really do it at the same time across all architectures, rather than waiting for each maintainer to get around to reviewing and testing the new calls first. This is not a problem on powerpc, but a lot of other architectures are less active, which is how we have always ended up with different sets of system calls across architectures. The problem here is that this makes it harder for the C library to know when a system call is guaranteed to be available. glibc still needs a feature test for newly added syscalls to see if they are working (they might be backported to an older kernel, or disabled), but whenever the minimum kernel version is increased, it makes sense to drop those checks and assume non-optional system calls will work if they were part of that minimum version. In the future, I'd hope that any new system calls get added right away on all architectures when they land (it was a bit tricky this time, because I still did a bunch of reworks that conflicted with the new calls). Bugs will happen of course, but I think adding them sooner makes it more likely to catch those bugs early on so we have a chance to fix them properly, and need fewer arch specific workarounds (ideally none) for system calls. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8694FC43381 for ; Sun, 31 Mar 2019 16:30:06 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BEDB92086C for ; Sun, 31 Mar 2019 16:30:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BEDB92086C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 44XLY7422dzDqSH for ; Mon, 1 Apr 2019 03:30:03 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gmail.com (client-ip=209.85.160.196; helo=mail-qt1-f196.google.com; envelope-from=arndbergmann@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=arndb.de Received: from mail-qt1-f196.google.com (mail-qt1-f196.google.com [209.85.160.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 44XLWV6hwYzDqMt for ; Mon, 1 Apr 2019 03:28:38 +1100 (AEDT) Received: by mail-qt1-f196.google.com with SMTP id v20so7829936qtv.12 for ; Sun, 31 Mar 2019 09:28:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oSXHQsG3KOPg9vd5T+GCmFoc7Xf14JcZz1oGhypQBKw=; b=TIcyQfuQJ5lgdEfKrkKENHFEdMY/dbCxJU0kdMdBlW++65L+x4Ij02wTgH4/vO3CfH ycWV6P67MvAkmsXcQFYGQloGZiMZM+Vnncebq7BKFCpM6zDD/KDLFJ+oX6kL4snxEt+D e/6fJr/uwImTezZYKIJ0bBJx4q21iiOEO0dRqnaEBNMuePgCJJc46vN9Hv2fDYj1HWGn zZMJVgRfOokTyLPENi1dyB2To7nKugUsm1FKf13rFOXwWKIgQGvXecopVD67c+OBQdJF QsPShOr0niK/M1h/WKNgAJ0LkL31Yz7Ei+LurwIKXFvnxlvUaocnr8Gu0HWSxOXYZKeY kA2Q== X-Gm-Message-State: APjAAAUcvTAZfqW4ryf/UeLfEdREItrC43KIAqUuEPDhFckKOwvNct8p Lb8TZ4eN6LXDnPPOCh0dK0Rn+KJK1ajrHVA20gs= X-Google-Smtp-Source: APXvYqx9e26flj4/DTUwCkm0QQZHO1TUNf4JZ4/rpFLAqXfyYImpebNZG5l1ed+kmdDk9YVAA0+XVhAQPMiHPduAVUU= X-Received: by 2002:ac8:3fbc:: with SMTP id d57mr47482205qtk.96.1554049715359; Sun, 31 Mar 2019 09:28:35 -0700 (PDT) MIME-Version: 1.0 References: <20190325143521.34928-1-arnd@arndb.de> <20190325144737.703921-1-arnd@arndb.de> <87y34vl6ji.fsf@concordia.ellerman.id.au> In-Reply-To: <87y34vl6ji.fsf@concordia.ellerman.id.au> From: Arnd Bergmann Date: Mon, 1 Apr 2019 00:28:18 +0800 Message-ID: Subject: Re: [PATCH 2/2] arch: add pidfd and io_uring syscalls everywhere To: Michael Ellerman Content-Type: text/plain; charset="UTF-8" X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Rich Felker , linux-ia64@vger.kernel.org, Linux-sh list , Heiko Carstens , linux-mips@vger.kernel.org, "James E . J . Bottomley" , Max Filippov , Paul Mackerras , sparclinux , linux-s390 , Helge Deller , Russell King , Geert Uytterhoeven , Catalin Marinas , James Hogan , Firoz Khan , Matt Turner , Fenghua Yu , Will Deacon , linux-m68k , Ivan Kokshaysky , Linux ARM , Richard Henderson , Michal Simek , Tony Luck , Parisc List , Linux Kernel Mailing List , Ralf Baechle , Paul Burton , alpha , Martin Schwidefsky , Andrew Morton , linuxppc-dev , "David S . Miller" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Sun, Mar 31, 2019 at 5:47 PM Michael Ellerman wrote: > > Arnd Bergmann writes: > > 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 > > --- > > arch/alpha/kernel/syscalls/syscall.tbl | 4 ++++ > > arch/arm/tools/syscall.tbl | 4 ++++ > > arch/arm64/include/asm/unistd.h | 2 +- > > arch/arm64/include/asm/unistd32.h | 8 ++++++++ > > arch/ia64/kernel/syscalls/syscall.tbl | 4 ++++ > > arch/m68k/kernel/syscalls/syscall.tbl | 4 ++++ > > arch/microblaze/kernel/syscalls/syscall.tbl | 4 ++++ > > arch/mips/kernel/syscalls/syscall_n32.tbl | 4 ++++ > > arch/mips/kernel/syscalls/syscall_n64.tbl | 4 ++++ > > arch/mips/kernel/syscalls/syscall_o32.tbl | 4 ++++ > > arch/parisc/kernel/syscalls/syscall.tbl | 4 ++++ > > arch/powerpc/kernel/syscalls/syscall.tbl | 4 ++++ > > Have you done any testing? > > I'd rather not wire up syscalls that have never been tested at all on > powerpc. No, I have not. I did review the system calls carefully and added the first patch to fix the bug on x86 compat mode before adding the same bug on the other compat architectures though ;-) Generally, my feeling is that adding system calls is not fundamentally different from adding other ABIs, and we should really do it at the same time across all architectures, rather than waiting for each maintainer to get around to reviewing and testing the new calls first. This is not a problem on powerpc, but a lot of other architectures are less active, which is how we have always ended up with different sets of system calls across architectures. The problem here is that this makes it harder for the C library to know when a system call is guaranteed to be available. glibc still needs a feature test for newly added syscalls to see if they are working (they might be backported to an older kernel, or disabled), but whenever the minimum kernel version is increased, it makes sense to drop those checks and assume non-optional system calls will work if they were part of that minimum version. In the future, I'd hope that any new system calls get added right away on all architectures when they land (it was a bit tricky this time, because I still did a bunch of reworks that conflicted with the new calls). Bugs will happen of course, but I think adding them sooner makes it more likely to catch those bugs early on so we have a chance to fix them properly, and need fewer arch specific workarounds (ideally none) for system calls. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH 2/2] arch: add pidfd and io_uring syscalls everywhere Date: Mon, 1 Apr 2019 00:28:18 +0800 Message-ID: References: <20190325143521.34928-1-arnd@arndb.de> <20190325144737.703921-1-arnd@arndb.de> <87y34vl6ji.fsf@concordia.ellerman.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=4hNBBPPQL7LkPlAGv7TLe53K2mCBJCvOwuLTuq8xzOY=; b=pKCZMzmeKoqsNc syilX1Zi03FFfEgZbDi4oPaHlNCIOLUKQJPv3cQh9V5k4/s07G+XtzzRXSfN0+W8G8ebtckQthN5H dTR4hPq5enOnaLFfFCl7z+UB+KvrV2HNTr4O06tE6ekkBGPlL4qMqa6lsqSGH2qHZ7aGrRN75383y lQTDWN5hS7UnoDDd0HOvpe1eodqLcBZ//lf25N2+BbwNhrPoyfpFVWWpNta7LKeUW1YwYJG7oCYZq rK8AOKQS3e6fZXcEeW//Rc4lz66kqVa+KVI6V4iXq/85GcgDSWeKAcwsvGYTPWK3YCdn7suOm4Tsr OFowxPTIJWzZCKmJP/QQ==; In-Reply-To: <87y34vl6ji.fsf@concordia.ellerman.id.au> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Michael Ellerman Cc: Rich Felker , linux-ia64@vger.kernel.org, Linux-sh list , Benjamin Herrenschmidt , Heiko Carstens , linux-mips@vger.kernel.org, "James E . J . Bottomley" , Max Filippov , Paul Mackerras , sparclinux , linux-s390 , Helge Deller , Russell King , Geert Uytterhoeven , Catalin Marinas , James Hogan , Firoz Khan , Matt Turner , Fenghua Yu , Will Deacon , linux-m68k , Ivan Kokshaysky , Linux ARM On Sun, Mar 31, 2019 at 5:47 PM Michael Ellerman wrote: > > Arnd Bergmann writes: > > 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 > > --- > > arch/alpha/kernel/syscalls/syscall.tbl | 4 ++++ > > arch/arm/tools/syscall.tbl | 4 ++++ > > arch/arm64/include/asm/unistd.h | 2 +- > > arch/arm64/include/asm/unistd32.h | 8 ++++++++ > > arch/ia64/kernel/syscalls/syscall.tbl | 4 ++++ > > arch/m68k/kernel/syscalls/syscall.tbl | 4 ++++ > > arch/microblaze/kernel/syscalls/syscall.tbl | 4 ++++ > > arch/mips/kernel/syscalls/syscall_n32.tbl | 4 ++++ > > arch/mips/kernel/syscalls/syscall_n64.tbl | 4 ++++ > > arch/mips/kernel/syscalls/syscall_o32.tbl | 4 ++++ > > arch/parisc/kernel/syscalls/syscall.tbl | 4 ++++ > > arch/powerpc/kernel/syscalls/syscall.tbl | 4 ++++ > > Have you done any testing? > > I'd rather not wire up syscalls that have never been tested at all on > powerpc. No, I have not. I did review the system calls carefully and added the first patch to fix the bug on x86 compat mode before adding the same bug on the other compat architectures though ;-) Generally, my feeling is that adding system calls is not fundamentally different from adding other ABIs, and we should really do it at the same time across all architectures, rather than waiting for each maintainer to get around to reviewing and testing the new calls first. This is not a problem on powerpc, but a lot of other architectures are less active, which is how we have always ended up with different sets of system calls across architectures. The problem here is that this makes it harder for the C library to know when a system call is guaranteed to be available. glibc still needs a feature test for newly added syscalls to see if they are working (they might be backported to an older kernel, or disabled), but whenever the minimum kernel version is increased, it makes sense to drop those checks and assume non-optional system calls will work if they were part of that minimum version. In the future, I'd hope that any new system calls get added right away on all architectures when they land (it was a bit tricky this time, because I still did a bunch of reworks that conflicted with the new calls). Bugs will happen of course, but I think adding them sooner makes it more likely to catch those bugs early on so we have a chance to fix them properly, and need fewer arch specific workarounds (ideally none) for system calls. Arnd