Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH] kvm: change KVM_REQUEST_MASK to reflect vcpu.requests
 size
To:     Rik van Riel <riel@surriel.com>
Cc:     kernel-team@fb.com, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= <rkrcmar@redhat.com>
References: <20190521132200.2b45c029@imladris.surriel.com>
From:   Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <ae5402e2-b748-b144-c1ea-715357529621@redhat.com>
Date:   Tue, 21 May 2019 20:28:36 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <20190521132200.2b45c029@imladris.surriel.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 21/05/19 19:22, Rik van Riel wrote:
> The code using KVM_REQUEST_MASK uses a pattern reminiscent of a bitmask:
> 
> 	set_bit(req & KVM_REQUEST_MASK, &vcpu->requests);
> 
> However, the first argument passed to set_bit, test_bit, and clear_bit
> is a bit number, not a bitmask. That means the current definition would
> allow users of kvm_make_request to overflow the vcpu.requests bitmask,
> and is confusing to developers examining the code.

This is true, but the meaning of the masking is that bits above 7 define
extra things to do when sending a request (wait for acknowledge, kick
the recipient CPU).  The fact that the "request number" field is 8 bits
rather than 5 or 6 is just an implementation detail.

If you change it to BITS_PER_LONG-1, the obvious way to read the code
would be that requests 0, 64, 128 are all valid and map to the same request.

Paolo

> Redefine KVM_REQUEST_MASK to reflect the number of bits that actually
> fit inside an unsigned long, and add a comment explaining set_bit and
> friends take bit numbers, not a bitmask.