Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp405992pxu; Tue, 5 Jan 2021 14:40:14 -0800 (PST) X-Google-Smtp-Source: ABdhPJxrhwicRnEiXwMLOOMJ7CJXc+9s21r/uUdQ01Tc16+6HEi5xhtECSIREF1AMFB31SRHtJ+m X-Received: by 2002:a17:907:414c:: with SMTP id od20mr1039804ejb.75.1609886414800; Tue, 05 Jan 2021 14:40:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609886414; cv=none; d=google.com; s=arc-20160816; b=DoS4KzucCcEZRD9KkA0wEMpWP4wKWON8D2ns7XauD52QucwQHYeINgFl+TGhFKdZQa y67mtR6d01YpqCFJfiQloH8RbKUtolcvgAi3u7h80PnXtq15zQMRxFM2Qj9psgxzuEf4 wQercwquTp6VTZwjuthyc/LlQDozJfi09uaRZ5y+E8ZVBo3HkmpERzM/VsPK1pUPfrdS /p9heDCnwg7ftldITqnNI8/P+GJfL8ENF8O0P+1Sc1Q7Kn4IXlYF9ztfpywqbxAzcgiX ZDWZL3x0riu//H9uZoIUpZdKEdVXAniNENUPY3vw1XLCJwHJl0W0jALsPsPKw5/TNPIk HbPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=MDQ3f1Bz+DgAubnbVzGBFyj256LtO1Sf/sJvuZ9kXFY=; b=uLScFrOeuBpFkwq5JlHr5oaxbovMUAgFa7Ui71g+yJrdgwjvrQt3upaOmsyGZYSUQl Y0KKqsayXbT/ByOgHs5qeD8kDeMxDhwvAW9SaXLRYyrsuEcerLMtCLl2drAnQoxq2nH/ FKljhc48mjuDTadEANQMs0m4r6VJjNDHAycok0d0M2KJ5CiNjjKFxST5mlkpr2bA5wrL DdmDN0ZLdNg6lV4z1ZCqJ/OkTzNBQB2DT3cnlc6VfthQpVidGn9NMpZnB/TdVFhJqsjj 7MAxg6doC7DYSHi7Exg3bpuGhZkm8syTsKib4UfBi+Y7dY9OHu95+AF2RMqJi6BQsiS8 oG6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=aTpmULom; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hp17si226094ejc.31.2021.01.05.14.39.51; Tue, 05 Jan 2021 14:40:14 -0800 (PST) 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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=aTpmULom; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730997AbhAETrY (ORCPT + 99 others); Tue, 5 Jan 2021 14:47:24 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:48717 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728630AbhAETrX (ORCPT ); Tue, 5 Jan 2021 14:47:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1609875957; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MDQ3f1Bz+DgAubnbVzGBFyj256LtO1Sf/sJvuZ9kXFY=; b=aTpmULomtJwGFllyI4EKtN9piqLRb1qfqAskJ189t1FmV2e9NIw6swqKGFLOTSI3mVcq5y pVKFRI8ts/m78Clj6tRhxUNFWTe6DUV8N/im7IRP2Eyvy1Xao0nSia0JgqHk+43mI7iYZ9 aACBJdh9jU3qVr8hcJTaNFCHzdnLGVU= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-590-3jSJ7scBN7G90PU-NrNdHA-1; Tue, 05 Jan 2021 14:45:53 -0500 X-MC-Unique: 3jSJ7scBN7G90PU-NrNdHA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D4203800D55; Tue, 5 Jan 2021 19:45:51 +0000 (UTC) Received: from mail (ovpn-112-76.rdu2.redhat.com [10.10.112.76]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EF2145D6CF; Tue, 5 Jan 2021 19:45:47 +0000 (UTC) Date: Tue, 5 Jan 2021 14:45:47 -0500 From: Andrea Arcangeli To: Nadav Amit Cc: Peter Xu , Peter Zijlstra , linux-mm , lkml , Yu Zhao , Andy Lutomirski , Pavel Emelyanov , Mike Kravetz , Mike Rapoport , Minchan Kim , Will Deacon , Mel Gorman Subject: Re: [RFC PATCH v2 1/2] mm/userfaultfd: fix memory corruption due to writeprotect Message-ID: References: <20201225092529.3228466-2-namit@vmware.com> <20210104122227.GL3021@hirez.programming.kicks-ass.net> <73EE9007-65AF-4416-9930-D992C74447A9@vmware.com> <2844ACC1-8908-494C-B411-3C69B27A1730@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.0.4 (2020-12-30) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 05, 2021 at 07:05:22PM +0000, Nadav Amit wrote: > > On Jan 5, 2021, at 10:45 AM, Andrea Arcangeli wrote: > > I just don't like to slow down a feature required in the future for > > implementing postcopy live snapshotting or other snapshots to userland > > processes (for the non-KVM case, also unprivileged by default if using > > bounce buffers to feed the syscalls) that can be used by open source > > hypervisors to beat proprietary hypervisors like vmware. > > Ouch, that’s uncalled for. I am sure that you understand that I have no > hidden agenda and we all have the same goal. Ehm I never said you had an hidden agenda, so I'm not exactly why you're accusing me of something I never said. I merely pointed out one relevant justification for increasing kernel complexity here by not slowing down clear_refs longstanding O(N) clear_refs/softdirty feature and the recent uffd-wp O(1) feature, is to be more competitive with proprietary software solutions, since at least for uffd-wp, postcopy live snapshotting that the #1 use case. I never questioned your contribution or your preference, to be even more explicit, it never crossed my mind that you have an hidden agenda. However since everyone already acked your patches and I'm not ok with your patches because they will give a hit to KVM postcopy live snapshotting and other container clear_refs users, I have to justify why I NAK your patches and remaining competitive with proprietary hypervisors is one of them, so I don't see what is wrong to state a tangible end goal here. Thanks, Andrea