Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp1546645ybh; Tue, 14 Jul 2020 00:13:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxtkH3z2z9PasMVkYWbG3rM7xzrxbn37BsbdohjavYLOqQPIRyenr5Kch4bM2LuiB4yqbgZ X-Received: by 2002:a50:8c06:: with SMTP id p6mr3019321edp.146.1594710789794; Tue, 14 Jul 2020 00:13:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594710789; cv=none; d=google.com; s=arc-20160816; b=F1WB8FJbAqw44fH/exE8cO4cp7494+Qa+KVGZ7IszXCGMHP68yzR8UzB/Yxt2yH1xr ZnzQ2Aht/RxLgay1DOoAkx6DrE9WIswkCRR9ZoqBOqMv00vTPisEMISZ4qRYY/U1p6sB IV2GfMoQaTB+iP/taAFmDKcDPaDXSVBMayNzPsByOBy0Ax/R9JbOtIlbTeISirXXCCad sBAZKJ4SdurdMhbZfXQpzNRONBX5dwVXxKagZOoinF5bzEA8M5ukuyFqa2PTCm7A33kV wbzEz59OLGmvDGOvE0QlCD+oESl4eLE/qBXrALoy0EElOF7Nr/L7PGDXUAaszFIA62E9 ShaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=/GuFhI8L4KGpWHmoyIRXYrgkGTmgfHnfG1uAIRxfZuQ=; b=UEv4i3u8tF7R843lAEinLBD73amcm0CSZ5HEwQmcwp1/drTUag6zQ9ezGKsANK2d8A +dKH0t/KQijhz3ETeTAsjIUCYB0nVabmUmEgropm6hyhI70YtFj5brSguaoAGNzCqaQ0 P4xCIONCPXuycSxR7YM39lkbRgISvsXadNSfXyfCoYfhk15l8N9xPQ+gTc/OoWbA+3P3 hYTw2ignRRsUUWKURt+AlcHgNLj0QpfFZezkgKBDsBP/EkLsP7bmyYUkSyPPhYx659zv wnCozFRZmL6pjC6ILNMKgKk1e5UJV46tLlYDbdv5CszPjgUKNI4YjhIpX0JM45Zc+Pjh Pkuw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v13si10372463ejw.696.2020.07.14.00.12.47; Tue, 14 Jul 2020 00:13:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726892AbgGNHMP (ORCPT + 99 others); Tue, 14 Jul 2020 03:12:15 -0400 Received: from verein.lst.de ([213.95.11.211]:53045 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725876AbgGNHMP (ORCPT ); Tue, 14 Jul 2020 03:12:15 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id DB14B68CFE; Tue, 14 Jul 2020 09:12:11 +0200 (CEST) Date: Tue, 14 Jul 2020 09:12:11 +0200 From: Christoph Hellwig To: Geert Uytterhoeven Cc: Mark Rutland , Christoph Hellwig , Nick Hu , Greentime Hu , Vincent Chen , Paul Walmsley , Palmer Dabbelt , Andrew Morton , Linus Torvalds , linux-riscv , Linux-Arch , Linux Kernel Mailing List Subject: Re: [PATCH 5/6] uaccess: add force_uaccess_{begin,end} helpers Message-ID: <20200714071211.GC776@lst.de> References: <20200710135706.537715-1-hch@lst.de> <20200710135706.537715-6-hch@lst.de> <20200713122148.GA51007@lakrids.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 13, 2020 at 03:19:42PM +0200, Geert Uytterhoeven wrote: > > This used to set KERNEL_DS, and now it sets USER_DS, which looks wrong > > superficially. > > Thanks for noticing, and sorry for missing that myself. > > The same issue is present for SuperH: > > - set_fs(KERNEL_DS); > + oldfs = force_uaccess_begin(); > > So the patch description should be: > > "Add helpers to wraper the get_fs/set_fs magic for undoing any damage > done by set_fs(USER_DS)." > > and leave alone users setting KERNEL_DS? Yes, this was broken. Fixed for the next version. > > If the new behaviour is fine it suggests that the old behaviour was > > wrong, or that this is superfluous and could go entirely. > > > > Geert? > > Nope, on m68k, TLB cache operations operate on the current address space. > Hence to flush a kernel TLB entry, you have to switch to KERNEL_DS first. > > If we're guaranteed to be already using KERNEL_DS, I guess the > address space handling can be removed. But can we be sure? We can't be sure yet. But with a lot of my pending work we should be able to get there in the not too far future.