From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751486AbbE0FJi (ORCPT ); Wed, 27 May 2015 01:09:38 -0400 Received: from e28smtp04.in.ibm.com ([122.248.162.4]:46017 "EHLO e28smtp04.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750959AbbE0FJe convert rfc822-to-8bit (ORCPT ); Wed, 27 May 2015 01:09:34 -0400 From: "Aneesh Kumar K.V" To: j.glisse@gmail.com, akpm@linux-foundation.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Linus Torvalds , joro@8bytes.org, Mel Gorman , "H. Peter Anvin" , Peter Zijlstra , Andrea Arcangeli , Johannes Weiner , Larry Woodman , Rik van Riel , Dave Airlie , Brendan Conoboy , Joe Donohue , Duncan Poole , Sherry Cheung , Subhash Gutti , John Hubbard , Mark Hairgrove , Lucien Dunning , Cameron Buschardt , Arvind Gopalakrishnan , Haggai Eran , Shachar Raindel , Liran Liss , Roland Dreier , Ben Sander , Greg Stoner , John Bridgman , Michael Mantor , Paul Blinzer , Laurent Morichetti , Alexander Deucher , Oded Gabbay , =?utf-8?B?SsOpcsO0bWU=?= Glisse Subject: Re: [PATCH 02/36] mmu_notifier: keep track of active invalidation ranges v3 In-Reply-To: <1432236705-4209-3-git-send-email-j.glisse@gmail.com> References: <1432236705-4209-1-git-send-email-j.glisse@gmail.com> <1432236705-4209-3-git-send-email-j.glisse@gmail.com> User-Agent: Notmuch/0.19+103~g294bb6d (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 27 May 2015 10:39:23 +0530 Message-ID: <871ti2mwsc.fsf@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15052705-0013-0000-0000-00000570C09B Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org j.glisse@gmail.com writes: > From: Jérôme Glisse > > The mmu_notifier_invalidate_range_start() and mmu_notifier_invalidate_range_end() > can be considered as forming an "atomic" section for the cpu page table update > point of view. Between this two function the cpu page table content is unreliable > for the address range being invalidated. > > Current user such as kvm need to know when they can trust the content of the cpu > page table. This becomes even more important to new users of the mmu_notifier > api (such as HMM or ODP). I don't see kvm using the new APIs in this patch. Also what is that HMM use this for, to protect walking of mirror page table ?. I am sure you are covering that in the later patches. May be you may want to mention the details here too. > > This patch use a structure define at all call site to invalidate_range_start() > that is added to a list for the duration of the invalidation. It adds two new > helpers to allow querying if a range is being invalidated or to wait for a range > to become valid. > > For proper synchronization, user must block new range invalidation from inside > there invalidate_range_start() callback, before calling the helper functions. > Otherwise there is no garanty that a new range invalidation will not be added > after the call to the helper function to query for existing range. > > Changed since v1: > - Fix a possible deadlock in mmu_notifier_range_wait_valid() > > Changed since v2: > - Add the range to invalid range list before calling ->range_start(). > - Del the range from invalid range list after calling ->range_end(). > - Remove useless list initialization. > -aneesh