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 S932751AbcLHPn2 (ORCPT <rfc822;w@1wt.eu>);
        Thu, 8 Dec 2016 10:43:28 -0500
Received: from mout.web.de ([212.227.17.11]:56819 "EHLO mout.web.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S932507AbcLHPn0 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 8 Dec 2016 10:43:26 -0500
Subject: Re: staging: comedi: usbdux: Split a condition check in
 usbdux_alloc_usb_buffers()
To: Ian Abbott <abbotti@mev.co.uk>
References: <8cddc37d-4529-ada4-ac21-20e09e888d0d@users.sourceforge.net>
 <50c7beca-40ba-6d58-5e2d-568844382bfe@users.sourceforge.net>
 <c2ec3655-60c2-8fa6-f3f2-34842259ef2a@mev.co.uk>
Cc: devel@driverdev.osuosl.org, Chris Cesare <chris.cesare@gmail.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        H Hartley Sweeten <hsweeten@visionengravers.com>,
        LKML <linux-kernel@vger.kernel.org>, kernel-janitors@vger.kernel.org
From: SF Markus Elfring <elfring@users.sourceforge.net>
Message-ID: <0063f739-69e0-2cce-be06-ff3685609d93@users.sourceforge.net>
Date: Thu, 8 Dec 2016 16:43:13 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <c2ec3655-60c2-8fa6-f3f2-34842259ef2a@mev.co.uk>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:VjJ1fia9UR1k8o6/p5jAxOuzEc42J/flr+Dv+dwpqcyMrrY5gNk
 DyRbq61y9BCEVuyw6Ig4b67q+m8Gn5ecbgq+bmD12PL+nZhV3DtWDo7CcKCzl44E3iFn+Sn
 l5b3vZ1g7c17qnzMwkTyGElUCs6MkxA8R9VUjanhqg7wyF97PfUUqYouWxtIu5+6Civr0HI
 +VzqxH6G7f5MglZcYt7xA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:V4E9gBvKAdk=:DrOpPd0PcP84k1e6dBIAry
 1eTsCwA/KAuxWLV0hpqG2PSV6xRoWBYx9wKWUaaBlPihkdgOYa06phgBaBaZnegdYfuI/y7kG
 yFfEeqKlVyV4o/x4eNCn8zJdD6F6ARJy/OItUjbYkX/qGPLpuRYMNx8FrMo40hg2KsZJKmDWn
 vU1PQvqNrUqUYs1cgRcGooHt56a4nilLD1fcUuyB+clJpiT32SCWU9l7B9DjMAhoN/VwDCyr0
 sWOWTDlk+8EnyfSWGQOCR9ESlNWb1rnQtIbgkRc25gGJCVUplvv6mUyujSKS4Tv8b/NGLdHfK
 pjFbV1rviOuxE5dHV9DvSnE2KqPN0T7JtKwzmw5IMjovQDUY6FfsMDYk6C9RnpJ5HXF0+0abt
 J/P3fySA+8GT4tOU+lpllp++8Qb6BdC+/2pQeMN37Wo707OS3CQ4EsuB4MMTNav58B/YEpe4W
 o5bUXVMOuO7fWIDNpwE42gydgA3tpcB1qTItB9eqTWhSMOBpfd8hCxY1QV6iFUM58/S2DocBy
 8HRDHcmZc3bRwEnbNwdUE1oWAe9hBgUcKW/bmPXJCCGcy9P37VQpjzsMvk4CePmp5lWFH3GXd
 sp8pzoOluTp6nn98Pbp6bXVYJRIfU2ypIu+xE0uWw61VUxyaITG7ARemuHQbq4FggZ/79ayvJ
 +554RZzAWui5Ur2dct0+ZNSZhNm3vItLzTx2GDAdOiJpcP5ELoouGKnjqyowcm6NrmerGIeyA
 zmyt32o7ljZEMd3zE27Ye+ouwnjFR7gBVjQuDsG202eu1Q1otHp518gV5NCwIUg3ASbWEaYNv
 BMdMeWg
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> Actually, the original code worked fine,

I got my doubts when some memory allocations are attempted without checking
the desired success immediately.


> and these changes will result in an Oops if the allocations fail.  I'll explain why,
> since it isn't obvious without some knowledge of the clean-up strategy used by comedi drivers:

Thanks for your explanation.


> …, and all the other comedi drivers follow the same strategy of leaving clean-up
> to their comedi 'detach' handler.

Are there other source code parts worth for further considerations?

Regards,
Markus