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=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 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 D6A4BC433E6 for ; Tue, 23 Feb 2021 19:25:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 31C3264E60 for ; Tue, 23 Feb 2021 19:25:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 31C3264E60 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5DF4C6B0005; Tue, 23 Feb 2021 14:25:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 58EC66B0006; Tue, 23 Feb 2021 14:25:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3DFCF6B006E; Tue, 23 Feb 2021 14:25:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0051.hostedemail.com [216.40.44.51]) by kanga.kvack.org (Postfix) with ESMTP id 25E556B0005 for ; Tue, 23 Feb 2021 14:25:11 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id E2C541802EF0E for ; Tue, 23 Feb 2021 19:25:10 +0000 (UTC) X-FDA: 77850510780.27.4BFEF89 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by imf09.hostedemail.com (Postfix) with ESMTP id 79184600249C for ; Tue, 23 Feb 2021 19:25:05 +0000 (UTC) IronPort-SDR: pb3HQs0hvpG6tbaL2GDHR2QAxqeMr1JERvu2bLd/ZSFoUFetOMTMzSlnp3D8R9ykjvXOlKDrK9 Nd223rR8yZHw== X-IronPort-AV: E=McAfee;i="6000,8403,9904"; a="172573290" X-IronPort-AV: E=Sophos;i="5.81,200,1610438400"; d="scan'208";a="172573290" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Feb 2021 11:25:07 -0800 IronPort-SDR: N18dsRoR7MTP+0xVTJhhotrFPCCEShC9WRMClXCTVmtJ8Qq15MYHnXj4DX9KrLBizZgO9ypEf8 6K6xBgVKofLw== X-IronPort-AV: E=Sophos;i="5.81,200,1610438400"; d="scan'208";a="403302299" Received: from iweiny-desk2.sc.intel.com (HELO localhost) ([10.3.52.147]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Feb 2021 11:25:07 -0800 Date: Tue, 23 Feb 2021 11:25:06 -0800 From: Ira Weiny To: Linus Torvalds Cc: David Sterba , David Sterba , Linux Kernel Mailing List , Linux-MM Subject: Re: [GIT PULL] Kmap conversions for 5.12 Message-ID: <20210223192506.GY3014244@iweiny-DESK2.sc.intel.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.1 (2018-12-01) X-Stat-Signature: 8xehw4h4ebtzzeprhh3y7tk5nwbej4cf X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 79184600249C Received-SPF: none (intel.com>: No applicable sender policy available) receiver=imf09; identity=mailfrom; envelope-from=""; helo=mga18.intel.com; client-ip=134.134.136.126 X-HE-DKIM-Result: none/none X-HE-Tag: 1614108305-95636 X-Bogosity: Ham, tests=bogofilter, spamicity=0.001862, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Feb 23, 2021 at 09:13:42AM -0800, Linus Torvalds wrote: > On Tue, Feb 23, 2021 at 7:03 AM David Sterba wrote: > > Ira Weiny (8): > > iov_iter: Remove memzero_page() in favor of zero_user() > > Ugh. I absolutely _detest_ this patch. Sorry. > > "zero_user()" is a completely horrendous function, and not at all the > same as memzero_page(). > > Just look at it. > > Yes, it's mis-used in a lot of places that really always wanted > "memzero_page()", but this conversion is going exactly the wrong way > around. Originally I lifted memzero_page()[1] but was pointed to zero_user_segments() which lead me astray to use zero_user(). I should have thought about it more rather than blindly changing to zero_user(). > > Existing users of that zero_user() should have been converted to > memzero_page(), rather than doing it this way. I can do that. No Problem. > > The "user" naming should have given it away. It's a very very magical > interface for user-mapped pages that have additional odd issues (ie > look at the dcache flushing etc). Agreed. > > I'll think some more about this pull request, but honestly, this one > broken is pretty much enough for me to say "No way in hell", because > it shows a complete disregard for sanity. Can we just drop the zero_user() patches? Christoph and others would like to see memcpy_[to|from]_page() lifted to the core for other work which is pending. Would you agree to those? > > The last commit in the series: > > > btrfs: convert to zero_user() > > is also very mixed up about whether it actually wants the dcache > flushing or not (and thus zero_user() or memzero_page()). Drop this patch too? > > Honestly, I suspect all the dcache flushing is totally pointless, > because any architecture with virtual caches that does kmap needs to > flush at kunmap anyway, afaik. Some of it is probably just voodoo > programming and copying a pattern. > > But in any case, zero_user() is not the same thing as memzero_page(), > and even if they *were* the same thing, zero_user() is objectively the > horribly much worse name. Sorry. I will change it. Ira > > Linus [1] https://lore.kernel.org/lkml/20201124141941.GB4327@casper.infradead.org/#t