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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D839BC433EF for ; Wed, 16 Feb 2022 13:07:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233303AbiBPNHl (ORCPT ); Wed, 16 Feb 2022 08:07:41 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:53460 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233564AbiBPNHk (ORCPT ); Wed, 16 Feb 2022 08:07:40 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B1DDF12858A; Wed, 16 Feb 2022 05:07:27 -0800 (PST) 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 22C32B81EDA; Wed, 16 Feb 2022 13:07:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2436C340FA; Wed, 16 Feb 2022 13:07:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1645016838; bh=1AijW/WQHr1DB1sxEAf5u6qv337FtGM78rBteqtJsFc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=iN729W8eTzLUmDGyJvEI0HE0OkfEC9ALEUXFXgdGhQXPvSwBAbGx4Bm4JUzW2PC8s BUMcbAlGBg1oLv2VeML280237jVmEo5gaC6UDs56p3vjvFXfFS/uKYdSKjDuePRk1L ktHY4DZBfIfbMM+DZtBJsD1tLcjqddiWlefZ3tjDhL0ZaU2r/dIUVsti11RXTBoqeV Fv+44VNG8OJe97by5ltQ4+nZVecfzeBcTyXFP1Nn1XVJH9wwXssVksGeqND4hscY9C RdLVWj/y1SlCH/eoBwY9xia343UtnPrsFJT6xH3Aw2TalwP1wcgKbcKqShewHfbFGA MgV75zhrtRvrQ== Received: by mail-wm1-f54.google.com with SMTP id k127-20020a1ca185000000b0037bc4be8713so3698012wme.3; Wed, 16 Feb 2022 05:07:18 -0800 (PST) X-Gm-Message-State: AOAM5313k6us+SjiT6l/QYoYSQj7CpHbnSMbdaqLH+8TbhtBWeAt+bOx J7/aSvJdNAsjrY9EEFSBwBH6pyX39LSPgGMQUeY= X-Google-Smtp-Source: ABdhPJwloTGuyJt/Hdm31OFklwbHVE+n23OzkTYnWy+HDNvimUM0g1FM9pYMdMLaGtlr03PBtziLgSkYqMH3Naa88b4= X-Received: by 2002:a05:600c:1d27:b0:37c:74bb:2b4d with SMTP id l39-20020a05600c1d2700b0037c74bb2b4dmr1594630wms.82.1645016837028; Wed, 16 Feb 2022 05:07:17 -0800 (PST) MIME-Version: 1.0 References: <20220214163452.1568807-1-arnd@kernel.org> <20220214163452.1568807-12-arnd@kernel.org> In-Reply-To: From: Arnd Bergmann Date: Wed, 16 Feb 2022 14:07:00 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 11/14] sparc64: remove CONFIG_SET_FS support To: Al Viro Cc: Linus Torvalds , Christoph Hellwig , linux-arch , Linux-MM , Linux API , Arnd Bergmann , Linux Kernel Mailing List , Russell King - ARM Linux , Will Deacon , Guo Ren , Brian Cain , Geert Uytterhoeven , Michal Simek , Thomas Bogendoerfer , Nick Hu , Greentime Hu , Dinh Nguyen , Stafford Horne , Helge Deller , Michael Ellerman , Peter Zijlstra , Ingo Molnar , Mark Rutland , Heiko Carstens , Rich Felker , David Miller , Richard Weinberger , "the arch/x86 maintainers" , Max Filippov , "Eric W . Biederman" , Andrew Morton , Ard Biesheuvel , alpha , "open list:SYNOPSYS ARC ARCHITECTURE" , Linux ARM , linux-csky@vger.kernel.org, "open list:QUALCOMM HEXAGON..." , linux-ia64@vger.kernel.org, linux-m68k , "open list:BROADCOM NVRAM DRIVER" , Openrisc , Parisc List , linuxppc-dev , linux-riscv , linux-s390 , Linux-sh list , sparclinux , linux-um , "open list:TENSILICA XTENSA PORT (xtensa)" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Tue, Feb 15, 2022 at 1:48 AM Al Viro wrote: > > On Mon, Feb 14, 2022 at 05:34:49PM +0100, Arnd Bergmann wrote: > > > -/* > > - * Sparc64 is segmented, though more like the M68K than the I386. > > - * We use the secondary ASI to address user memory, which references a > > - * completely different VM map, thus there is zero chance of the user > > - * doing something queer and tricking us into poking kernel memory. > > Actually, this part of comment probably ought to stay - it is relevant > for understanding what's going on (e.g. why is access_ok() always true, etc.) Ok, I've put it back now. Arnd