Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp2278922pxp; Mon, 21 Mar 2022 15:43:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzt8VDv+KJsG/+vED3VowxqOiKSlIZ7O3jdns4nsXzWfqJNLAgll48eKAKFkPp/qfR5/stA X-Received: by 2002:a17:90a:bd04:b0:1bf:951d:5bf2 with SMTP id y4-20020a17090abd0400b001bf951d5bf2mr1488427pjr.18.1647902601181; Mon, 21 Mar 2022 15:43:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647902601; cv=none; d=google.com; s=arc-20160816; b=JFaxpbTmr6WjgFTjCFnFvU7svzZYEuDOd+H4mccUHcDa3RJ5DoTUWh/kdcrfIFjnAe tLt2E+kX5cqc++H2SPVKbQMVD7c3R7KRWfx24zL6MfpzoMLcGOk7bOyvWrcgaErr3IEe PG+PVp9RPJyzRjvW3Qxs+ryhpMhsQHFr0cNEKGKedKr6i44pa3/fUe/t4H8T6HPYToP8 ookltOup16jp9vzdnvov7Ux2hpDQUD87eCuqDanEg0VjOT6QIEzK0ZFxhSF6Bb9jG7CY 2Nx+hb1bmpYYiLICb1ltm6wDx65EbLR+xdytDSl8RhOqEZrVZK38K/MlgttzmVtpyy0l bpkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=M8FjeD1DGum4B4nLKZOltmyqsnGWI2wcV2WjtNoHI0s=; b=zEWthxTizI/9qb4L8MV6bDdO5XbaKgMZbc+HIPiUkzrwxPkkpGVa8Pvqx5HZxIuOCJ A90Q98eRv9joZRjOhtu19xjsCQiR9xLscGs+e66F89ixq951koHawMC/PpFkhZp4XSZd 2c7S+SvmU+Fh6lvx8DLnLThxDeyD0o/9UD/MAGc0o+4OhYZ8L/JExL4VCzFEcqMctGHn HaoTEQVWPw3GmopqNHcFpRI05dby0L1vgDUUtE6wXrHkavkO2i9sAA32KnwU5pXw1nLA OO0IBXEPHIOXmlngi1UYevZwsnOjM7GSUFi6Th9pp7r+SrV2b6qpHjw7K2WxdwvAkDJC tpqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Ig0yIp6n; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id x11-20020aa79a4b000000b004fa3a8dffa1si4339858pfj.88.2022.03.21.15.43.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Mar 2022 15:43:21 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Ig0yIp6n; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 65B153F44D3; Mon, 21 Mar 2022 14:57:26 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345958AbiCUJmt (ORCPT + 99 others); Mon, 21 Mar 2022 05:42:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46892 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244989AbiCUJms (ORCPT ); Mon, 21 Mar 2022 05:42:48 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 078C45B3FC; Mon, 21 Mar 2022 02:41:23 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id A6DA9B8117E; Mon, 21 Mar 2022 09:41:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3A6FCC36AE2; Mon, 21 Mar 2022 09:41:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1647855680; bh=PA5/9WnwkF/956PEUqe0HUC0jBHuB/WEpZFZAjgcOPo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Ig0yIp6nnvDCXMfOIfWkuqoa298Gqho8BLob4gl9UraOtx/IOf6QLLql5Fa2rPT7P rexB5w4Dm+yYA/YmqTLEVsK9Ik+VPEB6KOL5Y7dv7Zady4hgf83Crfc2sW6WpHWcwL n6sqTIauXgZSHNXybUCgM9WZn8kR8a9Nf6wNaaRyZu4nEYj/Cs+Tm+Irz/ObnzcPd+ NAqqUNouzsJ8R58YHwpr+XkU25t8RFmjZVdFAL5TEg1PkasnmX9t53XhfMnhhsuFSQ 7DAQcyoHIid5E+j93KzTuJHWyVZH1KSHticgdTZXtuvNf46KeUXti1P6XHpc1brATX RPBaJTsvyPWYA== Received: by mail-ua1-f45.google.com with SMTP id 34so5535051uao.13; Mon, 21 Mar 2022 02:41:20 -0700 (PDT) X-Gm-Message-State: AOAM531VSa1HlXnBgf5pSacTFSrtnv8NKyxS63PlKETJYBzY9XqrJhpE JN8RWZKKRY9S1Fu/wcxQK6ynDjG41DFwkcvTJZg= X-Received: by 2002:ab0:30b8:0:b0:356:c867:9283 with SMTP id b24-20020ab030b8000000b00356c8679283mr2197618uam.118.1647855679197; Mon, 21 Mar 2022 02:41:19 -0700 (PDT) MIME-Version: 1.0 References: <20220319142759.1026237-1-chenhuacai@loongson.cn> <20220319143817.1026708-1-chenhuacai@loongson.cn> <20220319143817.1026708-6-chenhuacai@loongson.cn> In-Reply-To: From: Huacai Chen Date: Mon, 21 Mar 2022 17:41:11 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH V8 13/22] LoongArch: Add system call support To: Arnd Bergmann Cc: Andy Lutomirski , Thomas Gleixner , Peter Zijlstra , Andrew Morton , David Airlie , Jonathan Corbet , Linus Torvalds , linux-arch , "open list:DOCUMENTATION" , Linux Kernel Mailing List , Xuefeng Li , Yanteng Si , Jiaxun Yang , Huacai Chen Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Arnd, On Mon, Mar 21, 2022 at 5:01 PM Arnd Bergmann wrote: > > On Sat, Mar 19, 2022 at 3:38 PM Huacai Chen wrote: > > > > This patch adds system call support and related uaccess.h for LoongArch. > > > > Q: Why keep __ARCH_WANT_NEW_STAT definition while there is statx: > > A: Until the latest glibc release (2.34), statx is only used for 32-bit > > platforms, or 64-bit platforms with 32-bit timestamp. I.e., Most 64- > > bit platforms still use newstat now. > > > > Q: Why keep _ARCH_WANT_SYS_CLONE definition while there is clone3: > > A: The latest glibc release (2.34) has some basic support for clone3 but > > it isn't complete. E.g., pthread_create() and spawni() have converted > > to use clone3 but fork() will still use clone. Moreover, some seccomp > > related applications can still not work perfectly with clone3. > > Please leave those out of the mainline kernel support though: Any users > of existing glibc binaries can keep using patched kernels for the moment, > and then later drop those pages when the proper glibc support gets > merged. The glibc commit d8ea0d0168b190bdf138a20358293c939509367f ("Add an internal wrapper for clone, clone2 and clone3") modified nearly everything in order to move to clone3(), except arch_fork() which used by fork(). And I cannot find any submitted patches to solve it. So I don't think this is just a forget, maybe there are other fundamental problems? > > > +#define __ua_size(size) \ > > + ((__builtin_constant_p(size) && (signed long) (size) > 0) ? 0 : (size)) > > + > > +/* > > + * access_ok: - Checks if a user space pointer is valid > > + * @addr: User space pointer to start of block to check > > + * @size: Size of block to check > > + * > > + * Context: User context only. This function may sleep if pagefaults are > > + * enabled. > > + * > > + * Checks if a pointer to a block of memory in user space is valid. > > + * > > + * Returns true (nonzero) if the memory block may be valid, false (zero) > > + * if it is definitely invalid. > > + * > > + * Note that, depending on architecture, this function probably just > > + * checks that the pointer is in the user space range - after calling > > + * this function, memory access functions may still return -EFAULT. > > + */ > > +static inline int __access_ok(const void __user *p, unsigned long size) > > +{ > > + unsigned long addr = (unsigned long)p; > > + unsigned long end = addr + size - !!size; > > + > > + return (__UA_LIMIT & (addr | end | __ua_size(size))) == 0; > > +} > > + > > +#define access_ok(addr, size) \ > > + likely(__access_ok((addr), (size))) > > I rewrote this bit a series that is currently queued for 5.18, so you > will have to adapt it to the new version, by just removing your > custom definitions. OK, this will be updated. > > > +#define __get_user(x, ptr) \ > > +({ \ > > + int __gu_err = 0; \ > > + \ > > + __chk_user_ptr(ptr); \ > > + __get_user_common((x), sizeof(*(ptr)), ptr); \ > > + __gu_err; \ > > +}) > > It would be good to also provide a > __kernel_kernel_nofault()/__put_kernel_nofault() > implementation, as the default based on __get_user()/__put_user is not > ideal. They are provided in this file below. Huacai > > Arnd