From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752486AbdCAQ7H (ORCPT <rfc822;w@1wt.eu>);
        Wed, 1 Mar 2017 11:59:07 -0500
Received: from mx1.redhat.com ([209.132.183.28]:44868 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751716AbdCAQ7F (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 1 Mar 2017 11:59:05 -0500
Date: Wed, 1 Mar 2017 17:58:02 +0100
From: Radim =?utf-8?B?S3LEjW3DocWZ?= <rkrcmar@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
        Paolo Bonzini <pbonzini@redhat.com>, Andrew Jones <drjones@redhat.com>,
        Marc Zyngier <marc.zyngier@arm.com>,
        Christian Borntraeger <borntraeger@de.ibm.com>,
        Cornelia Huck <cornelia.huck@de.ibm.com>,
        James Hogan <james.hogan@imgtec.com>,
        Paul Mackerras <paulus@ozlabs.org>,
        Christoffer Dall <christoffer.dall@linaro.org>
Subject: Re: [PATCH v2 2/5] KVM: add KVM request variants without barrier
Message-ID: <20170301165801.GC20547@potion>
References: <20170224195002.28030-1-rkrcmar@redhat.com>
 <20170224195002.28030-3-rkrcmar@redhat.com>
 <096685e0-925a-03af-f4d5-349ba244241c@redhat.com>
 <969967af-8acd-4c63-ee69-a453112d8434@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <969967af-8acd-4c63-ee69-a453112d8434@redhat.com>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 01 Mar 2017 16:58:07 +0000 (UTC)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

2017-02-27 11:18+0100, David Hildenbrand:
> Am 27.02.2017 um 11:02 schrieb David Hildenbrand:
>> Am 24.02.2017 um 20:49 schrieb Radim Krčmář:
>>> The leading underscores denote that the call is just a bitop wrapper.
>> 
>> Actually, the leading underscore is misleading
>> 
>> If we want to match the semantics of set/test/clear_bit, using a leading
>> underscore might feel like using the non-atomic variants like
>> __clear_bit and friends.
>> 
>> I'd prefer to simply drop the underscore.
>> 
> 
> Okay, this is not really possible for __kvm_request_set(). Hm.....

Yeah, requests are always atomic, but have some extra cruft on top of
bit operations and underscores are similar in the sense of doing less
that the non-underscored version.  Also, the underscores were something
to make its use look undesirable in the code.

kvm_request_set and kvm_request_test_and_clear use a barrier and
kvm_request_test could be expected to do so as well.

I think that a barrier makes no sense in kvm_request_clear, but called
it with underscores for consistency with others and also because I think
that some callers of could use a second thought.