Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp976875ybh; Mon, 13 Jul 2020 06:20:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzmmoyAmK5W4S5fOMhq7qw+A5CwuCE2SKlUDSXP2VC9YhKO338iqg2JJ3e/Bf7yPO098rIv X-Received: by 2002:a17:906:7115:: with SMTP id x21mr71974764ejj.86.1594646431199; Mon, 13 Jul 2020 06:20:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594646431; cv=none; d=google.com; s=arc-20160816; b=erlKX9okHOQpZHkeaT2SrrJDr5M/RxvueYtXZ7Bgim/u0ESVvBA0sxJTQ9LQmQTlWJ kbapVvubYbN3fSnCDiFzXL8hcDVHWatlhJCTzU/RTLQpBN/brxcm9iF1cTUlKz/vI7v5 srX/zPOAxGncdp+j3NtWstVF+NMd5aGWpeKT/8UbKPyc3hrCIn9ZNDwD0Gu7gH4S9rAp jbOQZiimeHyDt/h+5ecdhAjNcKKvl2OW68PqQTCwtGd71DE2osdgYdwFkdWsQ+/6w/Az xq+KHcWBsJ9q2oFrWvH7G9dfjgpsNzMUALLLxYQZvxjKrds2atj95NHnnwN/6nQB0c5y UaVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=SATb1dq9lhpVtePq4rLhojB0Hr7gHjZG7fllFCUlzZU=; b=GrFVTpeCRieYQle5PfXsK7y4PomalFceIl8m6BNkYh81AeW+SRcPAj8M1f70kiFfYv qv7st9E/J2SexX0Sj+uk6l1kZj9nb+b7O5KY73jfAIzp+gZG2Pu9lA3O4YT8Gr08lxxc KME59OE5HBCESZ7b4DlfU6P4U1Jr8ss1PJtTGDdGXqhKluqHceEMqXSqKBlSMVYGnaFZ vWHZpMUQ4Uyi5CxcEQytwFn5Km0f6rNAlVz/piJy9KIcwVayCTBg2xBSn87OSI6Qk1F1 ZEuLJX1D+NY9QaN4ReP0Jhn6ackuh7MUXvr0OJ1TRwqEY9NojTNQVqC0OMWqsA+krMir F4TA== 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 gy14si8851480ejb.313.2020.07.13.06.20.07; Mon, 13 Jul 2020 06:20:31 -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 S1729735AbgGMNTy (ORCPT + 99 others); Mon, 13 Jul 2020 09:19:54 -0400 Received: from mail-ot1-f65.google.com ([209.85.210.65]:40381 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729523AbgGMNTy (ORCPT ); Mon, 13 Jul 2020 09:19:54 -0400 Received: by mail-ot1-f65.google.com with SMTP id c25so9465262otf.7; Mon, 13 Jul 2020 06:19:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SATb1dq9lhpVtePq4rLhojB0Hr7gHjZG7fllFCUlzZU=; b=f2YEiG3A91itYOB8sMDinMP/Z6LnlM8JlmpGB7lno6H2neYczPpYWa6/0pebzR2IfR waW7XkaIkFFL1viwxchFsKggdq2opuP/I17DqLEwloSKb1DK2EzARUk4ZQ2CsUZgqQ9B uxqVfm2ZYx548h+UfnxVcofAtCAl5PdcOzFxT0IhHaNqHZTgm/vFN9gyuyW45UOB6Kjr N6b0hmWisvbTzn0lmP1/SKTMtpB+jDWk4r+Fl5KvbYQCIxSpdzelI0UKgjSuJv3qMrK5 vlPk6swiN5ElZ9S7h8FPB3pHf1u5PjicYT+790J7bz1diEk5q3V116Q29ORjiaWm24Ae HBpQ== X-Gm-Message-State: AOAM530ejyjCCkaa4K1eqyi7pL5YG4CWM+QPlKnqQReZkkeAMVvnPlpR 0pTnvaVIVT/OWTA3Z8eR3EG0+Z5HauFNcVcjBvzCDd9K X-Received: by 2002:a05:6830:1451:: with SMTP id w17mr57441798otp.250.1594646393513; Mon, 13 Jul 2020 06:19:53 -0700 (PDT) MIME-Version: 1.0 References: <20200710135706.537715-1-hch@lst.de> <20200710135706.537715-6-hch@lst.de> <20200713122148.GA51007@lakrids.cambridge.arm.com> In-Reply-To: <20200713122148.GA51007@lakrids.cambridge.arm.com> From: Geert Uytterhoeven Date: Mon, 13 Jul 2020 15:19:42 +0200 Message-ID: Subject: Re: [PATCH 5/6] uaccess: add force_uaccess_{begin,end} helpers To: Mark Rutland Cc: Christoph Hellwig , Nick Hu , Greentime Hu , Vincent Chen , Paul Walmsley , Palmer Dabbelt , Andrew Morton , Linus Torvalds , linux-riscv , Linux-Arch , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mark, On Mon, Jul 13, 2020 at 2:21 PM Mark Rutland wrote: > On Fri, Jul 10, 2020 at 03:57:05PM +0200, Christoph Hellwig wrote: > > Add helpers to wraper the get_fs/set_fs magic for undoing any damange > > done by set_fs(KERNEL_DS). There is no real functional benefit, but this > > documents the intent of these calls better, and will allow stubbing the > > functions out easily for kernels builds that do not allow address space > > overrides in the future. > > > diff --git a/arch/m68k/include/asm/tlbflush.h b/arch/m68k/include/asm/tlbflush.h > > index 191e75a6bb249e..30471549e1e224 100644 > > --- a/arch/m68k/include/asm/tlbflush.h > > +++ b/arch/m68k/include/asm/tlbflush.h > > @@ -13,13 +13,13 @@ static inline void flush_tlb_kernel_page(void *addr) > > if (CPU_IS_COLDFIRE) { > > mmu_write(MMUOR, MMUOR_CNL); > > } else if (CPU_IS_040_OR_060) { > > - mm_segment_t old_fs = get_fs(); > > - set_fs(KERNEL_DS); > > + mm_segment_t old_fs = force_uaccess_begin(); > > + > > 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? > 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? > > __asm__ __volatile__(".chip 68040\n\t" > > "pflush (%0)\n\t" > > ".chip 68k" > > : : "a" (addr)); > > - set_fs(old_fs); > > + force_uaccess_end(old_fs); > > } else if (CPU_IS_020_OR_030) > > __asm__ __volatile__("pflush #4,#4,(%0)" : : "a" (addr)); > > > +/* > > + * Force the uaccess routines to be wired up for actual userspace access, > > + * overriding any possible set_fs(KERNEL_DS) still lingering around. Undone > > + * using force_uaccess_end below. > > + */ > > +static inline mm_segment_t force_uaccess_begin(void) > > +{ > > + mm_segment_t fs = get_fs(); > > + > > + set_fs(USER_DS); > > + return fs; > > +} > > + > > +static inline void force_uaccess_end(mm_segment_t oldfs) > > +{ > > + set_fs(oldfs); > > +} Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds