Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Tue, 12 Apr 2022 10:24:58 +0300
From:   Dan Carpenter <dan.carpenter@oracle.com>
To:     Jaehee Park <jhpark1013@gmail.com>
Cc:     Johan Hovold <johan@kernel.org>, Alex Elder <elder@kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        greybus-dev@lists.linaro.org, linux-staging@lists.linux.dev,
        linux-kernel@vger.kernel.org, outreachy@lists.linux.dev
Subject: Re: [PATCH] staging: greybus: replace zero-element array with
 flexible-array
Message-ID: <20220412072458.GC3293@kadam>
References: <20220411211411.GA2796005@jaehee-ThinkPad-X1-Extreme>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220411211411.GA2796005@jaehee-ThinkPad-X1-Extreme>
User-Agent: Mutt/1.9.4 (2018-02-28)
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?eMF7O10USMZtnnONNk5FKkgjIW1n1AwdAoYwUWDQsrVSlXuPo7Yg0l/22sLu?=
 =?us-ascii?Q?Ek26r9vICUimvvprs+GG6N7pr+JR06B3p8k/CYEK0E7no2K1XglBTUsgWAlk?=
 =?us-ascii?Q?P3/KOLfSQ2XvE0iqcACuJjnLl/wjgzdtkwPcCBBwNyOgkEHFa1rEvtwlQQVm?=
 =?us-ascii?Q?Xjpn6293D2KOjV9jUplVE8Agr/XYX3n62lTp96wnZSjTDYGA379eWaaKsNZW?=
 =?us-ascii?Q?rMSWKAvIVfj6pKyJVHpbjutoLor/E/0XV13iLNBQCGE4TLSyKJM0a75UqbX9?=
 =?us-ascii?Q?BeKSbowXuiTXPbPnQecHkSWPApuDQqomCVuDaau86LIwHbV+8jxfBSnShgov?=
 =?us-ascii?Q?4HJjRO60AzXdEIr3WeX8EQDJ88GP4x2QgdbbwpPExLBHkc/hqMxxXmwCkcXc?=
 =?us-ascii?Q?xJ55ITuSNU8R9Ty5Cfxs6Egn9jvoxcU2cnyJrC2wPIujOIKR5TwudAEtZIRA?=
 =?us-ascii?Q?7HnmtZpzSq4DqwOkbU71vSyXcp7lcQHdn83Y+7yq/A8WJ2YjODwCEQF/s7ux?=
 =?us-ascii?Q?ipM7RFt/Oz6N3wuWB+XmsI3rU736bvjcnZvRVx4/JIiPKYwfGE8/CItng33W?=
 =?us-ascii?Q?2mGNPcGrD2m9LBkaNtPMhEqPM2By4Acn4OmLWwm14x64W7yBRoU7yfGi2j36?=
 =?us-ascii?Q?5/EwGn0hLJ0ZaMCklMzSbytH0sqBUnafvG7UIcdgLtuksAYh7QYDOAK+Xla1?=
 =?us-ascii?Q?7NWarUZvQCUW17Aa+oo79IVNzkEhQ+p5eJ2oNTqxYNO8nRSNsMni++flpXd0?=
 =?us-ascii?Q?V6czP+NttJElsCloE7n8eY+nKDnpPmMpz3P+9hGgFVf/765IA0t7Dn3nf5kV?=
 =?us-ascii?Q?gGCjBufBzx1pEG9nO/ypk2Znv1BCgCs8P+O2Ocjw+ipmceqKCoPmhSFnbisi?=
 =?us-ascii?Q?6RarGG9j6WFKt8MzjzyAx72rfx/tr18dWjj2l3ZfI00iVOUN1LQ/4aXad9Fi?=
 =?us-ascii?Q?VjHK7jMtTVsNykTXl+IxsG7Lowc7kvCcHChD6MYIpNDlQRAy3yxsF8hwy6ez?=
 =?us-ascii?Q?lC078qHdrpx5gSHr+Rw7pZc/E0o1gI/iIHxHWq0c4fTs2ES/UFU0GDoACiKR?=
 =?us-ascii?Q?m5iastVmkXMVbp+xJn9CoiYGJTfNDMfinc3JJ2DCslfU8TKJ4lN/TzZIqd76?=
 =?us-ascii?Q?3zBgawPrYHxW4dfWoN6ghttJ2WZ0GIGuya3ACRgyiwTYGwlQWxw8sH2ADrCb?=
 =?us-ascii?Q?oF21RQuxu/38V4DeWcxVa7XlkQetUdDkgMl38axU/xaTr88kp9gdjOcTOMl8?=
 =?us-ascii?Q?EYMvw109LWHzZb6rEs0epS4jj9AlX5zGd2HkSKZ7vFdTmBci6wyhlC9V3PAx?=
 =?us-ascii?Q?FpI+LE/ipXatOWdAlATGWYF0/NzS3aQCE63Y0iFEO5qpojg1XOTVKYYwBT/X?=
 =?us-ascii?Q?ygP0JkV4Xg4rjzhBhv+SUa4Lw6JFXYsVUyNFa1sTaATNo8v9eYbY3vhuM4PO?=
 =?us-ascii?Q?iVV/K+zd0GntdWyWExE2i9Fg/ZZVoX/ZMJaxpSL/lJyveVTP+QKueb/VHqL8?=
 =?us-ascii?Q?bdmXckcYtbFlbQZ90P9dIZKyf+rK205ZD0eiYzDHxKT6p+ya+qsZr4GmWfyO?=
 =?us-ascii?Q?G52+Jdau6I7/QbrwYm5PnL6jVIDrfNFRloJOyKioVyW0FyINWNMYxx0z1aVC?=
 =?us-ascii?Q?g9IrLk5cmef3qc4sfDADPxl/DeQGWUErjQNijr4JkVOqoqlu3qtOwPG+i5hV?=
 =?us-ascii?Q?SMwgPUgK+91nZpBgQYwO9d2+tnUI6Uxs2efdkuc2fZMOgV3TW+KvBg5XVuIa?=
 =?us-ascii?Q?92Ujbg+iGO+AM3JS/9JYrStSP/bNUPY=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4d1faf0b-2a34-4646-a0d2-08da1c5593de
X-MS-Exchange-CrossTenant-AuthSource: MWHPR1001MB2365.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Apr 2022 07:25:10.6391
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: h+ujZ3TZ6nCxU8g5bqqgv+N+YCGX0qbUvspOYeNE+O+gOhi9jjYS4Bm23jLpO5vZTSEfBFJDjSv8NTUPp6ETL1tFMVxE3gHxYOrVxNbXkcI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR10MB5403
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425,18.0.858
 definitions=2022-04-12_02:2022-04-11,2022-04-12 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxlogscore=770
 spamscore=0 suspectscore=0 malwarescore=0 adultscore=0 bulkscore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2202240000 definitions=main-2204120034
X-Proofpoint-ORIG-GUID: VZY1fsxj_w_u2y_cfWsZDq5UORath7Ep
X-Proofpoint-GUID: VZY1fsxj_w_u2y_cfWsZDq5UORath7Ep
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE
	autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

No, this patch is not right.

On Mon, Apr 11, 2022 at 05:14:11PM -0400, Jaehee Park wrote:
> diff --git a/drivers/staging/greybus/usb.c b/drivers/staging/greybus/usb.c
> index 8e9d9d59a357..d0b2422401df 100644
> --- a/drivers/staging/greybus/usb.c
> +++ b/drivers/staging/greybus/usb.c
> @@ -27,7 +27,8 @@ struct gb_usb_hub_control_request {
>  };
>  
>  struct gb_usb_hub_control_response {
> -	u8 buf[0];
> +	__le16 wLength;
> +	u8 buf[];
>  };
>  
>  struct gb_usb_device {
> @@ -102,16 +103,14 @@ static int hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue, u16 wIndex,
>  	struct gb_operation *operation;
>  	struct gb_usb_hub_control_request *request;
>  	struct gb_usb_hub_control_response *response;
> -	size_t response_size;
>  	int ret;
>  
>  	/* FIXME: handle unspecified lengths */
> -	response_size = sizeof(*response) + wLength;

You're mixing up the value of wLength with the size of wLength (2).

>  
>  	operation = gb_operation_create(dev->connection,
>  					GB_USB_TYPE_HUB_CONTROL,
>  					sizeof(*request),
> -					response_size,
> +					sizeof(*response),

In the original code response_size was equal to wLength.  But now you're
passing 2.

So, I mean the no brainer approach would be to just say:

-					response_size,
+					wLength,

And delete the gb_usb_hub_control_response completely along with the
reference to it.

But better to do a brainer approach and investigate how that response
buffer is used.  It's probably all fine.  So probably the no brainer
approach is the correct approach.  It makes the code look nicer, it
doesn't break anything and we will merge it.  But better to at least
look carefully at it first.

regards,
dan carpenter