From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1427712AbcBSLhX (ORCPT ); Fri, 19 Feb 2016 06:37:23 -0500 Received: from mail-wm0-f47.google.com ([74.125.82.47]:34057 "EHLO mail-wm0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1426675AbcBSLhU (ORCPT ); Fri, 19 Feb 2016 06:37:20 -0500 Subject: Re: [PATCH v3 05/11] KVM: page track: introduce kvm_page_track_{add,remove}_page To: Xiao Guangrong References: <1455449503-20993-1-git-send-email-guangrong.xiao@linux.intel.com> <1455449503-20993-6-git-send-email-guangrong.xiao@linux.intel.com> Cc: gleb@kernel.org, mtosatti@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, kai.huang@linux.intel.com, jike.song@intel.com From: Paolo Bonzini X-Enigmail-Draft-Status: N1110 Message-ID: <56C6FE6C.5050305@redhat.com> Date: Fri, 19 Feb 2016 12:37:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <1455449503-20993-6-git-send-email-guangrong.xiao@linux.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14/02/2016 12:31, Xiao Guangrong wrote: > + /* does tracking count wrap? */ > + WARN_ON((count > 0) && (val + count < val)); This doesn't work, because "val + count" is an int. > + /* the last tracker has already gone? */ > + WARN_ON((count < 0) && (val < !count)); Also, here any underflow should warn. You can actually use the fact that val + count is an int like this: WARN_ON(val + count < 0 || val + count > USHRT_MAX) and also please return if the warning fires. > +void kvm_page_track_add_page(struct kvm *kvm, gfn_t gfn, > + enum kvm_page_track_mode mode) > +{ > + struct kvm_memslots *slots; > + struct kvm_memory_slot *slot; > + int i; > + > + for (i = 0; i < KVM_ADDRESS_SPACE_NUM; i++) { > + slots = __kvm_memslots(kvm, i); > + > + slot = __gfn_to_memslot(slots, gfn); > + if (!slot) > + continue; > + > + spin_lock(&kvm->mmu_lock); > + kvm_slot_page_track_add_page_nolock(kvm, slot, gfn, mode); > + spin_unlock(&kvm->mmu_lock); > + } > +} I don't think it is right to walk all address spaces. The good news is that you're not using kvm_page_track_{add,remove}_page at all as far as I can see, so you can just remove them. Also, when you will need it, I think it's better to move the spin_lock/spin_unlock pair outside the for loop. With this change, perhaps it's better to leave it to the caller completely---but I cannot say until I see the caller. In the meanwhile, please leave out _nolock from the other functions' name. Paolo