Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933015AbdGKOVf (ORCPT ); Tue, 11 Jul 2017 10:21:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59408 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932653AbdGKOVc (ORCPT ); Tue, 11 Jul 2017 10:21:32 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com BECC6C058EDD Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=rkrcmar@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com BECC6C058EDD Date: Tue, 11 Jul 2017 16:21:28 +0200 From: Radim =?utf-8?B?S3LEjW3DocWZ?= To: Christian Borntraeger Cc: Gleb Fotengauer-Malinovskiy , Paolo Bonzini , Claudio Imbrenda , "Dmitry V. Levin" , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] KVM: s390: Fix KVM_S390_GET_CMMA_BITS ioctl definition Message-ID: <20170711142127.GA3442@potion> References: <20170710144410.GA10359@glebfm.cloud.tilaa.com> <09c0760e-729d-548a-c3c4-b3afd9e67225@de.ibm.com> <20170710212321.GB2703@glebfm.cloud.tilaa.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 11 Jul 2017 14:21:31 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1939 Lines: 47 2017-07-11 10:21+0200, Christian Borntraeger: > On 07/10/2017 11:23 PM, Gleb Fotengauer-Malinovskiy wrote: > > On Mon, Jul 10, 2017 at 08:43:12PM +0200, Christian Borntraeger wrote: > >> On 07/10/2017 04:44 PM, Gleb Fotengauer-Malinovskiy wrote: > >>> This ioctl actually writes to parameter too. > >> > >> Maybe rephrase that to: > >> The kernel does not only read struct kvm_s390_cmma_log for KVM_S390_GET_CMMA_BITS, > >> it also writes back a return value making this _IOWR instead of _IOW. > > > > Ok, see v2. > > > >>> Fixes: 4036e387 ("KVM: s390: ioctls to get and set guest storage attributes") > >>> Signed-off-by: Gleb Fotengauer-Malinovskiy > >> Acked-by: Christian Borntraeger > >> > >> > >> Out of curiosity, how did you notice that? > > > > I regenerated strace's ioctl lists. It was obvious from the diff that > > *GET* and *SET* could not be both _IOC_WRITE. > > > > In fact we do have multiple GET/SET ioctls in KVM, where both provide a control > block that is _IOC_WRITE only. That control block then has an address that will > be read/written to depending on get/set. > E.g. look at > #define KVM_SET_DEVICE_ATTR _IOW(KVMIO, 0xe1, struct kvm_device_attr) > #define KVM_GET_DEVICE_ATTR _IOW(KVMIO, 0xe2, struct kvm_device_attr) > > but as far as I understand, the direction hints only qualify the referenced > struct and not the side effects. So for KVM_*_DEVICE_ATTR it is correct to have > IOW for both cases. > > But for GET_CMMA we do indeed write back data. > > Paolo, Radim, > > if we want to fix the direction hint, it would be good to merge this in as soon > as possible. The new interface was added during this merge window. Having correct hints would allow us to have one common copy_from_user/copy_to_user and I think it's not too late to rename it with the real behavior. Applied for the second merge-window pull request, thanks.