From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f65.google.com ([74.125.82.65]:56210 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753070AbeGEHDA (ORCPT ); Thu, 5 Jul 2018 03:03:00 -0400 Date: Thu, 5 Jul 2018 09:02:56 +0200 From: Ingo Molnar To: Dan Williams Cc: Al Viro , Andrew Morton , Andy Lutomirski , Borislav Petkov , Linus Torvalds , Peter Zijlstra , Thomas Gleixner , Tony Luck , Ross Zwisler , Linux Kernel Mailing List , linux-fsdevel , X86 ML Subject: Re: [PATCH] x86/asm/memcpy_mcsafe: Fix copy_to_user_mcsafe() exception handling Message-ID: <20180705070256.GA27603@gmail.com> References: <20180702165803.GB19488@linux.intel.com> <153056565378.3420.295180898468362039.stgit@dwillia2-desk3.amr.corp.intel.com> <20180703083040.GB971@gmail.com> <20180704223825.GZ30522@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: * Dan Williams wrote: > On Wed, Jul 4, 2018 at 3:38 PM, Al Viro wrote: > > On Tue, Jul 03, 2018 at 10:30:40AM +0200, Ingo Molnar wrote: > >> > >> * Dan Williams wrote: > >> > >> > Hi Ingo, > >> > > >> > Here is an additional copy_to_iter_mcsafe() fix to address the crash > >> > reported by Ross. This now passes xfstests:generic/323 on my system. > >> > >> The lib/iov_iter fix would need an Acked-by from Al. > > > > I can live with that; I would really like to see some documentation on > > the copy_to_iter_mcsafe(), but that's a separate story. Incidentally, > > are there any expectations of other callers appearing, or is that > > (and copy_from_iter_flushcache()) YASingleConsumerAPI? > > The current cpu architectural detail preventing conversion of the > standard copy_to_iter() path to use the mcsafe flavor is that we can't > use REP MOV for fast copies and instead need to use a software loop so > that any exceptions are recoverable. When / if that is addressed, and > there is no performance difference between the two, it might make > sense to convert more users. > > The _flushcache flavor, however, will likely stay limited to a single > consumer for the persistent memory use case. Could you please add the API documentation Al asked for, and update the changlog with the acks and tested-by's that people gave, and send out a v2 series? Thanks! Ingo