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 B4638C74A5B for ; Wed, 29 Mar 2023 15:17:11 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=wHfhBMyeKQ/B+cQJFH7jwQ6B/dWrdtRO0q+B6nHeeBk=; b=11gxRNdHzj6+Op MAQGYDouCn30n+arCqixOGMF9ulWG3KkiZMw8qVw4Qe3zzUoWd55X2fyl61WRleEctNVhlyosII1O LXTSZZpOJzxIyCtPE3fvWgmhl2tu9/WJ7Hypyquxg0Lq7G57fx0t0m/joawqV2+b4AQcCH4xgCpZn Okb93XPx2XyUf7hqi0HmgV7VA0xH0hnwjsPWdoHXpGaCA50t4IYOJx1EnWu0xL8OBlfYzRhyyu+US FOWtXlNtxh41XMdUiH7szD0yLCvsHSTgklW6WZkrcVUZz8mQhCm4zdV8/W1V0+ZzquUyKFrAv4qJc L3RzWGEQ1i2YMqe24xMA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1phXWx-000kcq-0N; Wed, 29 Mar 2023 15:16:07 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1phXWs-000kbh-1w for linux-arm-kernel@lists.infradead.org; Wed, 29 Mar 2023 15:16:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1680102960; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Yn7L6Gf5Ys1fnh23z7AVkJPW9NwbK9fjx3dyKcciMAc=; b=YowQ6lXfj5RcXccufUwz/b4MWOhexORkja0FVaKuKfrxAPZ+NwgCgUrNsKoB/8m/eay86m UdyuKbzuk9TyVsghnJS3TorIgIIN3W5mr5UlzDFzXb0Eq36Hz8sdKkN1AMTYZO0B9S9snj HYyaqXZYERS5zK1H8E6QmvmFzQtgFeE= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-264-EXRMXSF_PnSmrGoNDhg8iw-1; Wed, 29 Mar 2023 11:15:54 -0400 X-MC-Unique: EXRMXSF_PnSmrGoNDhg8iw-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 BB7092814247; Wed, 29 Mar 2023 15:15:28 +0000 (UTC) Received: from dhcp-27-174.brq.redhat.com (unknown [10.45.224.161]) by smtp.corp.redhat.com (Postfix) with SMTP id 8A94D492C3E; Wed, 29 Mar 2023 15:15:24 +0000 (UTC) Received: by dhcp-27-174.brq.redhat.com (nbSMTP-1.00) for uid 1000 oleg@redhat.com; Wed, 29 Mar 2023 17:15:21 +0200 (CEST) Date: Wed, 29 Mar 2023 17:15:16 +0200 From: Oleg Nesterov To: Gregory Price Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, avagin@gmail.com, peterz@infradead.org, luto@kernel.org, krisman@collabora.com, tglx@linutronix.de, corbet@lwn.net, shuah@kernel.org, catalin.marinas@arm.com, arnd@arndb.de, will@kernel.org, mark.rutland@arm.com, tongtiangen@huawei.com, robin.murphy@arm.com, Gregory Price Subject: Re: [PATCH v14 1/4] asm-generic,arm64: create task variant of access_ok Message-ID: <20230329151515.GA913@redhat.com> References: <20230328164811.2451-1-gregory.price@memverge.com> <20230328164811.2451-2-gregory.price@memverge.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230328164811.2451-2-gregory.price@memverge.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230329_081602_752619_2BD7F2E8 X-CRM114-Status: GOOD ( 17.13 ) X-BeenThere: linux-arm-kernel@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-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hmm. I am not comfortable with this change... I won't really argue because I don't have a better solution and because I think we don't really care as long as task_set_syscall_user_dispatch() is the only user of task_access_ok(), but still... OK, so this version changes set_syscall_user_dispatch() to use task_access_ok() instead of access_ok() because task != current. On 03/28, Gregory Price wrote: > > If the architecture does not implement task_access_ok, the operation > reduces to access_ok and the task argument is discarded. No, with this patch it reduces to __access_ok(). And this already doesn't look very good to me, but this is minor. > --- a/include/asm-generic/access_ok.h > +++ b/include/asm-generic/access_ok.h > @@ -45,4 +45,14 @@ static inline int __access_ok(const void __user *ptr, unsigned long size) > #define access_ok(addr, size) likely(__access_ok(addr, size)) > #endif > > +/* > + * Some architectures may have special features (such as ARM MTE) > + * that require handling if access_ok is called on a pointer from one > + * task in the context of another. On most architectures this operation > + * is equivalent to simply __access_ok. > + */ > +#ifndef task_access_ok > +#define task_access_ok(task, addr, size) likely(__access_ok(addr, size)) > +#endif Lets ignore arm64. This look as if access_ok() or __access_ok() doesn't depend on task, but this is not true in general. Say, TASK_SIZE_MAX can check is_32bit_task() test_thread_flag(TIF_32BIT...) and this uses "current". Again, we probably do not care, but I don't like the fact task_access_ok() looks as if task_access_ok(task) returns the same result as "task" calling access_ok(). Oleg. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel