Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp1404526ybm; Sat, 30 May 2020 07:55:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyDAgMKRw8Cm6Hp+I+he+JtzocagFCXNwR/fkRkTgUpG8GdJt8nQ5alFf0xcaH21Rjgpppw X-Received: by 2002:a17:906:11c4:: with SMTP id o4mr12612131eja.163.1590850505069; Sat, 30 May 2020 07:55:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590850505; cv=none; d=google.com; s=arc-20160816; b=qyea3ZcGtgDY/vuNqFhkK/FuseEWAo26p94dOH3pFa7he1bGYNJG2VfY2868s+rxo6 xWv3XcZF/kFC3BWkA95B/EP22T4P5mx6sB9bbN6K+rq18qJsUevGwNcvTaJrryOXOPtq EMAY+OnzzVmy59q8Vcz+YblQ7SzDnorzYoeY4J5SFUahoV7Wn6eMib/kWpV4qN7XChAY +4GFwRE6DSgmffX16uVfn8p19FIyVwBhb+eVT9tw1uri34pqGaruJsPD3WAlPACDyK/U HCltwdjiP1LFgYUFyjEDjKCmgfazDELNjJVHNvLaCmKd/kL7EVZi2jsy9vHPA9GbcATV 092g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=L82CdxGUjCjP/Si1CgphgDf2r95IBvYr9GiNwPJUSZ0=; b=HSxMMNV59V8Eh0mOL8oqOWpB0B3b352aAFbOttD1BU+Fn3IDYcyCcrlZJ88J8SYNCT kjst9SX8ApYSS+RAt3FCzA2tUl4Hrv3U+oAeB6jz7VNcDZF0kvNE7XV+fKHvQITCIZpF MQE+JGmfKDv/KXUEhF5BPmYkR9CsDInAg1xlgTaWvhlf0dJYuhNDwMESwuoBGnqUuhuS Z8apPjRJ8LuJRKUDXlAxdXHDziMrKQ6CPpa42tQbU4n7iUFZr+9LD/keIWi46HdRi/3F 2+qdhYVTmAeAb1FrV32oVZ6n+aAOi3Dn4ORCk4o3AIhKKPhe7eF2W8ADAxgCC8igEM0K WB5w== 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 e3si7104292edq.595.2020.05.30.07.54.42; Sat, 30 May 2020 07:55:05 -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 S1729138AbgE3Ow4 (ORCPT + 99 others); Sat, 30 May 2020 10:52:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42532 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728927AbgE3Ow4 (ORCPT ); Sat, 30 May 2020 10:52:56 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 40954C03E969; Sat, 30 May 2020 07:52:53 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.93 #3 (Red Hat Linux)) id 1jf2qv-000U2Z-8N; Sat, 30 May 2020 14:52:49 +0000 Date: Sat, 30 May 2020 15:52:49 +0100 From: Al Viro To: Linus Torvalds Cc: Paolo Bonzini , Linux Kernel Mailing List , linux-fsdevel , KVM list Subject: Re: [PATCH 8/9] x86: kvm_hv_set_msr(): use __put_user() instead of 32bit __clear_user() Message-ID: <20200530145249.GO23230@ZenIV.linux.org.uk> References: <20200528234025.GT23230@ZenIV.linux.org.uk> <20200529232723.44942-1-viro@ZenIV.linux.org.uk> <20200529232723.44942-8-viro@ZenIV.linux.org.uk> <20200530143147.GN23230@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200530143147.GN23230@ZenIV.linux.org.uk> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, May 30, 2020 at 03:31:47PM +0100, Al Viro wrote: > It's a bit trickier than that, but I want to deal with that at the same > time as the rest of kvm/vhost stuff. So for this series I just went > for minimal change. There's quite a pile of vhost and kvm stuff, > but it's not ready yet - wait for the next cycle. BTW, regarding uaccess plans for the next cycle: * regset mess (at least the ->get() side) * killing more compat_alloc_user_space() call sites (_maybe_ all of it, if we are lucky enough; v4l2 is a bitch in that respect, but I've some ideas on how to deal with that - need to discuss with mchehab) * sorting the remaining (harder) parts of i915 out * kvm/vhost * fault_in_pages_...() series That should get rid of almost all __... ones outside of arch/*; might actually kill copy_in_user() off as well. * finally lifting stac/clac out of raw_copy_{to,from}_user().