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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 44B59C3DA7A for ; Thu, 5 Jan 2023 12:06:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232873AbjAEMF6 (ORCPT ); Thu, 5 Jan 2023 07:05:58 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46856 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232700AbjAEMFz (ORCPT ); Thu, 5 Jan 2023 07:05:55 -0500 Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 570B95471F; Thu, 5 Jan 2023 04:05:53 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id BB1615C0153; Thu, 5 Jan 2023 07:05:52 -0500 (EST) Received: from imap51 ([10.202.2.101]) by compute6.internal (MEProxy); Thu, 05 Jan 2023 07:05:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1672920352; x=1673006752; bh=UhZB23ikgg upzfYjMRU5YJTnDOqqv+WR2zf5S9u612M=; b=RS4DcE88H2bSZhCoHSBnFauHLI iBC3nX2sj/ud09rEeqkh7ALUK2+vJlNREh/g8XdJcaG+kAhrVR6CKwuzuB1MCx2E Fd64uqrJ/zNqGXSf/cffjs61K1WY5KqXxX3tJP0Ky+bvozO/KNcSf/waz4N6ollD G/5Q5PKyhM686OqNqyPvpMU6a5D+1TDYtqua1dvkfUaVXRg5/SPfLEqQSlRKhJP8 3QjrIr2FCb6ie9mz4X7dvpzhtQiMlFhm2IhyzSVlBOjygSOCeocgaGES8JPsAf22 KW4ZMmq6cWH7gGqpOpkPQDzzRpwe+HlgYEAxcdKKq5OFQXwSp7+V/UXO7/EQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1672920352; x=1673006752; bh=UhZB23ikggupzfYjMRU5YJTnDOqq v+WR2zf5S9u612M=; b=Sr04uMptHAnE4rxGGbbE3gGANmQXNawSH5VJVMuhRPJo 7sOz5iB7b8B3KY1JcnwE1J7eHomLLVlkcQC3m/NIDkr6OhW77G2TR4hnm/dclZwN m/8Sat0FZVDEM2ggTTy8qPGr8hx9Odws7QLwpt90XoUyFqpSm7bQ8L30EJ2MNlWL 184gGj+kN9mBMn3xBMdccDAos+EcZpKJdohCICDIjfZd/kk5rc7Sm461pIEH3Pe1 pHhmXZ0oLWoMQbXd239AJTqhGTOGyUctE/Lq6/s/ON4qu24ox5vSrqErYNXvPZK7 Oq/3hpF9V8NglYnLd+ZiWWByYq8By36AlzxbrVESTw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrjeekgdefjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdetrhhn ugcuuegvrhhgmhgrnhhnfdcuoegrrhhnugesrghrnhgusgdruggvqeenucggtffrrghtth gvrhhnpeevhfffledtgeehfeffhfdtgedvheejtdfgkeeuvefgudffteettdekkeeufeeh udenucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomheprghrnhgusegrrhhnuggsrdguvg X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id E6BA2B60086; Thu, 5 Jan 2023 07:05:51 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1185-g841157300a-fm-20221208.002-g84115730 Mime-Version: 1.0 Message-Id: <5b69db0b-9eed-42ce-8e93-4b656022433f@app.fastmail.com> In-Reply-To: <20230105104019.GA7446@tellis.lin.mbt.kalray.eu> References: <20230103164359.24347-1-ysionneau@kalray.eu> <7c531595-e987-422b-bcf7-48ad0ba49ce6@app.fastmail.com> <20230105104019.GA7446@tellis.lin.mbt.kalray.eu> Date: Thu, 05 Jan 2023 13:05:32 +0100 From: "Arnd Bergmann" To: "Jules Maselbas" Cc: "Yann Sionneau" , "Albert Ou" , "Alexander Shishkin" , "Andrew Morton" , "Aneesh Kumar" , "Ard Biesheuvel" , "Arnaldo Carvalho de Melo" , "Boqun Feng" , bpf@vger.kernel.org, "Christian Brauner" , devicetree@vger.kernel.org, "Eric W. Biederman" , "Eric Paris" , "Ingo Molnar" , "Jan Kiszka" , "Jason Baron" , "Jiri Olsa" , "Jonathan Corbet" , "Josh Poimboeuf" , "Kees Cook" , "Kieran Bingham" , "Krzysztof Kozlowski" , Linux-Arch , linux-arm-kernel@lists.infradead.org, linux-audit@redhat.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-perf-users@vger.kernel.org, linux-pm@vger.kernel.org, linux-riscv@lists.infradead.org, "Marc Zyngier" , "Mark Rutland" , "Masami Hiramatsu" , "Namhyung Kim" , "Nicholas Piggin" , "Oleg Nesterov" , "Palmer Dabbelt" , "Paul Moore" , "Paul Walmsley" , "Peter Zijlstra" , "Rob Herring" , "Sebastian Reichel" , "Steven Rostedt" , "Thomas Gleixner" , "Waiman Long" , "Will Deacon" , "Alex Michon" , "Ashley Lesdalons" , "Benjamin Mugnier" , "Clement Leger" , "Guillaume Missonnier" , "Guillaume Thouvenin" , "Jean-Christophe Pince" , "Jonathan Borne" , "Julian Vetter" , "Julien Hascoet" , "Julien Villette" , "Louis Morhet" , "Luc Michel" , =?UTF-8?Q?Marc_Poulhi=C3=A8s?= , "Marius Gligor" , "Samuel Jones" , "Thomas Costis" , "Vincent Chardon" Subject: Re: [RFC PATCH 00/25] Upstream kvx Linux port Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 5, 2023, at 11:40, Jules Maselbas wrote: > On Wed, Jan 04, 2023 at 04:58:25PM +0100, Arnd Bergmann wrote: >> On Tue, Jan 3, 2023, at 17:43, Yann Sionneau wrote: >> I commented on the syscall patch directly, I think it's >> important to stop using the deprecated syscalls as soon >> as possible to avoid having dependencies in too many >> libc binaries. Almost everything else can be changed >> easily as you get closer to upstream inclusion. >> >> I did not receive most of the other patches as I'm >> not subscribed to all the mainline lists. For future >> submissions, can you add the linux-arch list to Cc for >> all patches? > > We misused get_maintainers.pl, running it on each patch instead > of using it on the whole series. next time every one will be in > copy of every patch in the series and including linux-arch. Be careful not to make the list too long though, there is usually a limit of 1024 characters for the entire Cc list, above this your mails may get dropped by the mailing lists. >> Reading the rest of the series through lore.kernel.org, >> most of the comments I have are for improvements that >> you may find valuable rather than serious mistakes: >> >> - the {copy_to,copy_from,clear}_user functions are >> well worth optimizing better than the byte-at-a-time >> version you have, even just a C version built around >> your __get_user/__put_user inline asm should help, and >> could be added to lib/usercopy.c. > > right, we are using memcpy for {copy_to,copy_from}_user_page > which has a simple optimized version introduced in > (kvx: Add some library functions). > I wonder if it is possible to do the same for copy_*_user functions. copy_from_user_page() is only about managing cache aliases, not user access, and it's not used anywhere in the fast path, so it's a bit different. arch/arm/lib/copy_template.S has an example for how you can share the same assembler implementation between memcpy() and copy_from_user(), but it's not very intuitive. The tricky bit with copy_from_user() is the partial copy that relies on copying the exact amount of data that can be accessed including the last byte before the end of the mapping, and returning the correct count of non-copied bytes. If you want a C version, you can probably use the copy_from_kernel_nofault implementation mm/maccess.c as a template, but have to add code for the correct return value. 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 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 88DCDC54E76 for ; Thu, 5 Jan 2023 13:38:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1672925924; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=f0vKzCo63PxihTc5DJ+3VaLutNkcgvNjbp6QRnJQobs=; b=feVM1hqSxvVrLobyAgYBiF7UAkbE8nOLLhVKNJRFCEyzRYm+Qh+SvgG4afoZEN2eaSmzSp wZK8b7cUayVd1FshviM3wFij+MDnqB14ucHaemKecQoAuoKNPysKByUD47OUn/p6arR6LG TKUb0pt9+IpsxpVFnRHz4SpOlU4x4mU= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-52-UfHA6Ik4PB6Bu7Y8WRqyYw-1; Thu, 05 Jan 2023 08:38:41 -0500 X-MC-Unique: UfHA6Ik4PB6Bu7Y8WRqyYw-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0145F1802D41; Thu, 5 Jan 2023 13:38:40 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id D856940104C; Thu, 5 Jan 2023 13:38:39 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id A06BC19465B7; Thu, 5 Jan 2023 13:38:39 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id B08801946586 for ; Thu, 5 Jan 2023 12:05:57 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 7615C2026D68; Thu, 5 Jan 2023 12:05:57 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast04.extmail.prod.ext.rdu2.redhat.com [10.11.55.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6E1BD2026D4B for ; Thu, 5 Jan 2023 12:05:57 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4F897101A521 for ; Thu, 5 Jan 2023 12:05:57 +0000 (UTC) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-461-XwSRfJ5NMpKH6qXOPxaetQ-1; Thu, 05 Jan 2023 07:05:53 -0500 X-MC-Unique: XwSRfJ5NMpKH6qXOPxaetQ-1 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id BB1615C0153; Thu, 5 Jan 2023 07:05:52 -0500 (EST) Received: from imap51 ([10.202.2.101]) by compute6.internal (MEProxy); Thu, 05 Jan 2023 07:05:52 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrjeekgdefjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdetrhhn ugcuuegvrhhgmhgrnhhnfdcuoegrrhhnugesrghrnhgusgdruggvqeenucggtffrrghtth gvrhhnpeevhfffledtgeehfeffhfdtgedvheejtdfgkeeuvefgudffteettdekkeeufeeh udenucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomheprghrnhgusegrrhhnuggsrdguvg X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id E6BA2B60086; Thu, 5 Jan 2023 07:05:51 -0500 (EST) User-Agent: Cyrus-JMAP/3.7.0-alpha0-1185-g841157300a-fm-20221208.002-g84115730 Mime-Version: 1.0 Message-Id: <5b69db0b-9eed-42ce-8e93-4b656022433f@app.fastmail.com> In-Reply-To: <20230105104019.GA7446@tellis.lin.mbt.kalray.eu> References: <20230103164359.24347-1-ysionneau@kalray.eu> <7c531595-e987-422b-bcf7-48ad0ba49ce6@app.fastmail.com> <20230105104019.GA7446@tellis.lin.mbt.kalray.eu> Date: Thu, 05 Jan 2023 13:05:32 +0100 From: "Arnd Bergmann" To: "Jules Maselbas" Subject: Re: [RFC PATCH 00/25] Upstream kvx Linux port X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 X-Mailman-Approved-At: Thu, 05 Jan 2023 13:38:37 +0000 X-BeenThere: linux-audit@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Audit Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , =?UTF-8?Q?Marc_Poulhi=C3=A8s?= , linux-doc@vger.kernel.org, Alexander Shishkin , Jan Kiszka , Sebastian Reichel , Marius Gligor , Oleg Nesterov , linux-mm@kvack.org, Louis Morhet , Krzysztof Kozlowski , Luc Michel , linux-riscv@lists.infradead.org, Ashley Lesdalons , Will Deacon , Ard Biesheuvel , Linux-Arch , Marc Zyngier , Thomas Costis , Jonathan Corbet , Jonathan Borne , Aneesh Kumar , Samuel Jones , Peter Zijlstra , Ingo Molnar , Steven Rostedt , Jean-Christophe Pince , Waiman Long , Clement Leger , Masami Hiramatsu , devicetree@vger.kernel.org, Albert Ou , Kees Cook , linux-pm@vger.kernel.org, Yann Sionneau , Boqun Feng , Guillaume Thouvenin , Julian Vetter , Arnaldo Carvalho de Melo , Julien Hascoet , Jason Baron , Rob Herring , Nicholas Piggin , Paul Walmsley , Namhyung Kim , Thomas Gleixner , Josh Poimboeuf , linux-arm-kernel@lists.infradead.org, Julien Villette , Christian Brauner , Andrew Morton , Benjamin Mugnier , Vincent Chardon , Guillaume Missonnier , linux-kernel@vger.kernel.org, Eric Paris , Alex Michon , linux-perf-users@vger.kernel.org, linux-audit@redhat.com, Palmer Dabbelt , "Eric W. Biederman" , Jiri Olsa , Kieran Bingham , bpf@vger.kernel.org Errors-To: linux-audit-bounces@redhat.com Sender: "Linux-audit" X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Thu, Jan 5, 2023, at 11:40, Jules Maselbas wrote: > On Wed, Jan 04, 2023 at 04:58:25PM +0100, Arnd Bergmann wrote: >> On Tue, Jan 3, 2023, at 17:43, Yann Sionneau wrote: >> I commented on the syscall patch directly, I think it's >> important to stop using the deprecated syscalls as soon >> as possible to avoid having dependencies in too many >> libc binaries. Almost everything else can be changed >> easily as you get closer to upstream inclusion. >> >> I did not receive most of the other patches as I'm >> not subscribed to all the mainline lists. For future >> submissions, can you add the linux-arch list to Cc for >> all patches? > > We misused get_maintainers.pl, running it on each patch instead > of using it on the whole series. next time every one will be in > copy of every patch in the series and including linux-arch. Be careful not to make the list too long though, there is usually a limit of 1024 characters for the entire Cc list, above this your mails may get dropped by the mailing lists. >> Reading the rest of the series through lore.kernel.org, >> most of the comments I have are for improvements that >> you may find valuable rather than serious mistakes: >> >> - the {copy_to,copy_from,clear}_user functions are >> well worth optimizing better than the byte-at-a-time >> version you have, even just a C version built around >> your __get_user/__put_user inline asm should help, and >> could be added to lib/usercopy.c. > > right, we are using memcpy for {copy_to,copy_from}_user_page > which has a simple optimized version introduced in > (kvx: Add some library functions). > I wonder if it is possible to do the same for copy_*_user functions. copy_from_user_page() is only about managing cache aliases, not user access, and it's not used anywhere in the fast path, so it's a bit different. arch/arm/lib/copy_template.S has an example for how you can share the same assembler implementation between memcpy() and copy_from_user(), but it's not very intuitive. The tricky bit with copy_from_user() is the partial copy that relies on copying the exact amount of data that can be accessed including the last byte before the end of the mapping, and returning the correct count of non-copied bytes. If you want a C version, you can probably use the copy_from_kernel_nofault implementation mm/maccess.c as a template, but have to add code for the correct return value. Arnd -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit 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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 54F99C4708E for ; Thu, 5 Jan 2023 22:57:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Subject:Cc:To:From:Date:References: In-Reply-To:Message-Id:Mime-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=HBz2THSheliXKnfy+mzEjctdQCVJlYfHNWRTQhuugdw=; b=c7tJp0pOd5a9Ai NVCx97Uas/ERr8FfRCC9JdCsCzexByVqeZYkrnPkE8A3fVxTU2jgqk1FhzGZ5JRqZMH/fBreb+n7R 2dAdlLP8vfKQ2TFFgNGQBJ8QbG+tF3oPTN07S7ai1JVDJEDo1rslUdQAPscvPy0j0pZ5vTEyHJHgS OuDKEbzTvwndGCXQp31FIziGvxonlBKldED5zx4m1HgETRXNvsKIy9CcfTVjvWggTnMeJgMY003/Q RQFDkXWAbqeoCK9Ja0W3LDdFA51vgJLO16Hgqzn7QDHBQvSyD2aobmyosatytgnross2V45oE2wz7 uTIFrjfYeSlt/yZd2gfg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pDZAR-00FqyR-Ci; Thu, 05 Jan 2023 22:56:59 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pDVPy-00DtB1-K8; Thu, 05 Jan 2023 18:56:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=Content-Type:Subject:Cc:To:From:Date: References:In-Reply-To:Message-Id:Mime-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=UhZB23ikggupzfYjMRU5YJTnDOqqv+WR2zf5S9u612M=; b=KHoQqVe6xAPjlQ8ohNFqL0+o84 MGeBXy0Pt4rg2T0EGtZPoVr1UEQYCyGvEUZD0UcMSvGK8nj/J0fmFHbcwRi1a69BkP1mkz+TYYxMX FVpEELOzcGc+MDsTVcg0A8DCYghAu2BcFj2+zpYRGD3q6+pgN8r6YRPjSjbdai4oZx3NpX3oOP/yY WHKFmJ+9MdbYZjuFD8PlxjrE+EN4tiM6B3QuCwWTg3MJ0IiTx72SVRRLAQYVJn5XtNkkWfS+S2hEp yn+M2kFr0/E2WmfEKB7tJzZhZKO2lSTL3FG41Dk4yrACfkaYlPBjz/w6hpRAGosG7WyI1okxITDKu cyEpOgbg==; Received: from new3-smtp.messagingengine.com ([66.111.4.229]) by desiato.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pDP0N-001IlU-24; Thu, 05 Jan 2023 12:06:00 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 0B263581B7D; Thu, 5 Jan 2023 07:05:53 -0500 (EST) Received: from imap51 ([10.202.2.101]) by compute6.internal (MEProxy); Thu, 05 Jan 2023 07:05:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1672920353; x=1672927553; bh=UhZB23ikgg upzfYjMRU5YJTnDOqqv+WR2zf5S9u612M=; b=FJXChScYkJolw+hfqvehLDIFUK 5Cg8CQlycAieHhINtFVxj5zsts7SunrKUwOEwJrQi0IRPZJ6d686tiLX3qYCN+Ov peuj6uacGf5FJWSmfyO2xgvyukwsPBYdmwGGKl/FCOaIqCaOlwZQEGEZGkV4sNWV 5GbEZuqyimzsav1KXI29aDE0cEfszY+sjgC8OhIHTCpbPFyk65mnUchZBh+glxcQ QKFSN61tZJBYwsPh/9n5W9JUxb8Xr7KNrU2ShThyrZAnX0Ggjaw1dbnENvXcTVJX gpYDFjgJuWamA0e7zeMFeKRN0V2IUzFpaJ1lRJWXKcKXZppVhfB02RfJNRbw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1672920353; x=1672927553; bh=UhZB23ikggupzfYjMRU5YJTnDOqq v+WR2zf5S9u612M=; b=NFfyIaQ0qjdgH1MxPldB9drAERMIhtMbPrqmyan05qhK cdl62dHKpKYVGS/fQCW/+4OaWjDrJNyiuE/rRhW22vCtMKy5Y8IiwmTApPd74seJ V1qPeKqGdTaJv1gQVC1vxuVXaCchfiicOfcTUiopp2DVFYz3grYYwGnb+qAPE/QT 5+wnMcpSAq9TWGW0zSGQGIBKK0BNtt4d4QWon+tBB6fvuMQBrxJlewFiwT/sdOjq VHX6MaNR2DL1QeEPK/cqbJGB6yjFVY3Ae53VYVDzNcHsGOhvZkQ/hga13+7lMojr GKpTfqYlbOPf+NdcSybgTXgDZETFX1qKxGLZxfmb2w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrjeekgdefjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdetrhhn ugcuuegvrhhgmhgrnhhnfdcuoegrrhhnugesrghrnhgusgdruggvqeenucggtffrrghtth gvrhhnpeevhfffledtgeehfeffhfdtgedvheejtdfgkeeuvefgudffteettdekkeeufeeh udenucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomheprghrnhgusegrrhhnuggsrdguvg X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id E6BA2B60086; Thu, 5 Jan 2023 07:05:51 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1185-g841157300a-fm-20221208.002-g84115730 Mime-Version: 1.0 Message-Id: <5b69db0b-9eed-42ce-8e93-4b656022433f@app.fastmail.com> In-Reply-To: <20230105104019.GA7446@tellis.lin.mbt.kalray.eu> References: <20230103164359.24347-1-ysionneau@kalray.eu> <7c531595-e987-422b-bcf7-48ad0ba49ce6@app.fastmail.com> <20230105104019.GA7446@tellis.lin.mbt.kalray.eu> Date: Thu, 05 Jan 2023 13:05:32 +0100 From: "Arnd Bergmann" To: "Jules Maselbas" Cc: "Yann Sionneau" , "Albert Ou" , "Alexander Shishkin" , "Andrew Morton" , "Aneesh Kumar" , "Ard Biesheuvel" , "Arnaldo Carvalho de Melo" , "Boqun Feng" , bpf@vger.kernel.org, "Christian Brauner" , devicetree@vger.kernel.org, "Eric W. Biederman" , "Eric Paris" , "Ingo Molnar" , "Jan Kiszka" , "Jason Baron" , "Jiri Olsa" , "Jonathan Corbet" , "Josh Poimboeuf" , "Kees Cook" , "Kieran Bingham" , "Krzysztof Kozlowski" , Linux-Arch , linux-arm-kernel@lists.infradead.org, linux-audit@redhat.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-perf-users@vger.kernel.org, linux-pm@vger.kernel.org, linux-riscv@lists.infradead.org, "Marc Zyngier" , "Mark Rutland" , "Masami Hiramatsu" , "Namhyung Kim" , "Nicholas Piggin" , "Oleg Nesterov" , "Palmer Dabbelt" , "Paul Moore" , "Paul Walmsley" , "Peter Zijlstra" , "Rob Herring" , "Sebastian Reichel" , "Steven Rostedt" , "Thomas Gleixner" , "Waiman Long" , "Will Deacon" , "Alex Michon" , "Ashley Lesdalons" , "Benjamin Mugnier" , "Clement Leger" , "Guillaume Missonnier" , "Guillaume Thouvenin" , "Jean-Christophe Pince" , "Jonathan Borne" , "Julian Vetter" , "Julien Hascoet" , "Julien Villette" , "Louis Morhet" , "Luc Michel" , =?UTF-8?Q?Marc_Poulhi=C3=A8s?= , "Marius Gligor" , "Samuel Jones" , "Thomas Costis" , "Vincent Chardon" Subject: Re: [RFC PATCH 00/25] Upstream kvx Linux port X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230105_120556_545684_EF08E675 X-CRM114-Status: GOOD ( 25.07 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Thu, Jan 5, 2023, at 11:40, Jules Maselbas wrote: > On Wed, Jan 04, 2023 at 04:58:25PM +0100, Arnd Bergmann wrote: >> On Tue, Jan 3, 2023, at 17:43, Yann Sionneau wrote: >> I commented on the syscall patch directly, I think it's >> important to stop using the deprecated syscalls as soon >> as possible to avoid having dependencies in too many >> libc binaries. Almost everything else can be changed >> easily as you get closer to upstream inclusion. >> >> I did not receive most of the other patches as I'm >> not subscribed to all the mainline lists. For future >> submissions, can you add the linux-arch list to Cc for >> all patches? > > We misused get_maintainers.pl, running it on each patch instead > of using it on the whole series. next time every one will be in > copy of every patch in the series and including linux-arch. Be careful not to make the list too long though, there is usually a limit of 1024 characters for the entire Cc list, above this your mails may get dropped by the mailing lists. >> Reading the rest of the series through lore.kernel.org, >> most of the comments I have are for improvements that >> you may find valuable rather than serious mistakes: >> >> - the {copy_to,copy_from,clear}_user functions are >> well worth optimizing better than the byte-at-a-time >> version you have, even just a C version built around >> your __get_user/__put_user inline asm should help, and >> could be added to lib/usercopy.c. > > right, we are using memcpy for {copy_to,copy_from}_user_page > which has a simple optimized version introduced in > (kvx: Add some library functions). > I wonder if it is possible to do the same for copy_*_user functions. copy_from_user_page() is only about managing cache aliases, not user access, and it's not used anywhere in the fast path, so it's a bit different. arch/arm/lib/copy_template.S has an example for how you can share the same assembler implementation between memcpy() and copy_from_user(), but it's not very intuitive. The tricky bit with copy_from_user() is the partial copy that relies on copying the exact amount of data that can be accessed including the last byte before the end of the mapping, and returning the correct count of non-copied bytes. If you want a C version, you can probably use the copy_from_kernel_nofault implementation mm/maccess.c as a template, but have to add code for the correct return value. Arnd _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv