From mboxrd@z Thu Jan 1 00:00:00 1970 From: SF Markus Elfring Subject: Re: KVM: s390: Move two error code assignments in kvm_vm_ioctl_get_dirty_log() Date: Mon, 23 Jan 2017 12:08:12 +0100 Message-ID: <01d581bb-9db6-cba1-e476-49c814c3ebf0@users.sourceforge.net> References: <70f41e59-d8a4-de42-6064-80ecf6acc065@users.sourceforge.net> <35411200-2bd6-1c65-7d7f-21a6353875ea@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Cornelia Huck , Heiko Carstens , Martin Schwidefsky , Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , LKML , kernel-janitors@vger.kernel.org To: =?UTF-8?Q?Christian_Borntr=c3=a4ger?= , kvm@vger.kernel.org, linux-s390@vger.kernel.org Return-path: In-Reply-To: <35411200-2bd6-1c65-7d7f-21a6353875ea@de.ibm.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org > Patches that changes open coded things to common helpers or things like > kmalloc_array where appropriate or things that make the code more robust > are fine and welcome, but I am not going to take this as it just shuffles > things around. Thanks for such information. > It does not fix anything and it does not improve the code, I have got an other expectation for the shown implementation detail. > but it certainly carries the risk of breaking something This is usual in software development, isn't it? > (yes in this case it looks perfectly fine, though). Thanks for this bit of positive feedback. > Due to the locking requirements we cannot do such a simplification here. I find this detail strange. Would you like to check run time consequences for the shown error code settings once more? Regards, Markus