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 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 1DBCAC33CB8 for ; Wed, 22 Jan 2020 17:43:43 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8AB052465B for ; Wed, 22 Jan 2020 17:43:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8AB052465B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 482t6z4tDTzDqRh for ; Thu, 23 Jan 2020 04:43:39 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=ftp.linux.org.uk (client-ip=195.92.253.2; helo=zeniv.linux.org.uk; envelope-from=viro@ftp.linux.org.uk; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=zeniv.linux.org.uk Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [195.92.253.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 482t4p2yQlzDqQq for ; Thu, 23 Jan 2020 04:41:46 +1100 (AEDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1iuK0P-000izi-Q7; Wed, 22 Jan 2020 17:41:29 +0000 Date: Wed, 22 Jan 2020 17:41:29 +0000 From: Al Viro To: Linus Torvalds Subject: Re: [PATCH v1 1/6] fs/readdir: Fix filldir() and filldir64() use of user_access_begin() Message-ID: <20200122174129.GH23230@ZenIV.linux.org.uk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Linux Kernel Mailing List , Linux-MM , Paul Mackerras , linux-fsdevel , Andrew Morton , linuxppc-dev Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Wed, Jan 22, 2020 at 08:13:12AM -0800, Linus Torvalds wrote: > On Wed, Jan 22, 2020 at 5:00 AM Christophe Leroy > wrote: > > > > Modify filldir() and filldir64() to request the real area they need > > to get access to. > > Not like this. > > This makes the situation for architectures like x86 much worse, since > you now use "put_user()" for the previous dirent filling. Which does > that expensive user access setup/teardown twice again. > > So either you need to cover both the dirent's with one call, or you > just need to cover the whole (original) user buffer passed in. But not > this unholy mixing of both unsafe_put_user() and regular put_user(). I would suggest simply covering the range from dirent->d_off to buf->current_dir->d_name[namelen]; they are going to be close to each other and we need those addresses anyway... 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 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 66594C2D0DB for ; Wed, 22 Jan 2020 17:41:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4BED624125 for ; Wed, 22 Jan 2020 17:41:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726083AbgAVRln (ORCPT ); Wed, 22 Jan 2020 12:41:43 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:38948 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725802AbgAVRlm (ORCPT ); Wed, 22 Jan 2020 12:41:42 -0500 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1iuK0P-000izi-Q7; Wed, 22 Jan 2020 17:41:29 +0000 Date: Wed, 22 Jan 2020 17:41:29 +0000 From: Al Viro To: Linus Torvalds Cc: Christophe Leroy , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Andrew Morton , Linux Kernel Mailing List , linuxppc-dev , linux-fsdevel , Linux-MM Subject: Re: [PATCH v1 1/6] fs/readdir: Fix filldir() and filldir64() use of user_access_begin() Message-ID: <20200122174129.GH23230@ZenIV.linux.org.uk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Wed, Jan 22, 2020 at 08:13:12AM -0800, Linus Torvalds wrote: > On Wed, Jan 22, 2020 at 5:00 AM Christophe Leroy > wrote: > > > > Modify filldir() and filldir64() to request the real area they need > > to get access to. > > Not like this. > > This makes the situation for architectures like x86 much worse, since > you now use "put_user()" for the previous dirent filling. Which does > that expensive user access setup/teardown twice again. > > So either you need to cover both the dirent's with one call, or you > just need to cover the whole (original) user buffer passed in. But not > this unholy mixing of both unsafe_put_user() and regular put_user(). I would suggest simply covering the range from dirent->d_off to buf->current_dir->d_name[namelen]; they are going to be close to each other and we need those addresses anyway...