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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 31265C433DF for ; Wed, 3 Jun 2020 08:08:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0B3F820734 for ; Wed, 3 Jun 2020 08:08:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726345AbgFCIIb convert rfc822-to-8bit (ORCPT ); Wed, 3 Jun 2020 04:08:31 -0400 Received: from eu-smtp-delivery-151.mimecast.com ([207.82.80.151]:30513 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726099AbgFCIIa (ORCPT ); Wed, 3 Jun 2020 04:08:30 -0400 Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-172-_4y6Z0HxOsCLflypv4x5zQ-1; Wed, 03 Jun 2020 09:08:17 +0100 X-MC-Unique: _4y6Z0HxOsCLflypv4x5zQ-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) by AcuMS.aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 3 Jun 2020 09:08:17 +0100 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Wed, 3 Jun 2020 09:08:17 +0100 From: David Laight To: 'Al Viro' CC: "'Michael S. Tsirkin'" , Linus Torvalds , Jason Wang , "Linux Kernel Mailing List" , Netdev Subject: RE: [PATCH RFC] uaccess: user_access_begin_after_access_ok() Thread-Topic: [PATCH RFC] uaccess: user_access_begin_after_access_ok() Thread-Index: AQHWOR0GBiAzsIPf10apeP3ZClgqcqjFyCZAgAAGv4CAALncwA== Date: Wed, 3 Jun 2020 08:08:17 +0000 Message-ID: References: <20200602084257.134555-1-mst@redhat.com> <20200602163306.GM23230@ZenIV.linux.org.uk> <20200602162931-mutt-send-email-mst@kernel.org> <950896ceff2d44e8aaf6f9f5fab210e4@AcuMS.aculab.com> <20200602215827.GP23230@ZenIV.linux.org.uk> In-Reply-To: <20200602215827.GP23230@ZenIV.linux.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Al Viro On Behalf Of Al Viro > Sent: 02 June 2020 22:58 > On Tue, Jun 02, 2020 at 08:41:38PM +0000, David Laight wrote: > > > In which case you need a 'user_access_begin' that takes the mm > > as an additional parameter. > > What does any of that have to do with mm? Details, please. Actually probably nothing. I was sort of thinking that maybe the user process's memory map (mm?) would be temporarily 'attached' to the kernel thread so that it used the normal copy_to/from_user() fault handling to access the 'other' process. In which case you'd want to do the bound check against the limit of the user addresses in the mm rather than those of the current process. But later posts probably imply that it is all done differently. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)