Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 19 Sep 2022 13:12:22 +0300
From:   Dan Carpenter <dan.carpenter@oracle.com>
To:     Nam Cao <namcaov@gmail.com>
Cc:     forest@alittletooquiet.net, gregkh@linuxfoundation.org,
        philipp.g.hortmann@gmail.com, linux-kernel@vger.kernel.org,
        linux-staging@lists.linux.dev
Subject: Re: [RFC PATCH 5/5] staging: vt6655: implement allocation failure
 handling
Message-ID: <YyhAhiUlclk7HxE3@kadam>
References: <cover.1663273218.git.namcaov@gmail.com>
 <dd63998765f1ea1bf507a94c2d49317b36b5f32c.1663273218.git.namcaov@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <dd63998765f1ea1bf507a94c2d49317b36b5f32c.1663273218.git.namcaov@gmail.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?tABB5xx7UMCheA53PuRm1o3z8ntiymbGVPotVqmZ9XuWJ6Xlq7kByv1m72c1?=
 =?us-ascii?Q?Tzd5L7xZQMhb14ruMBvG2ZWMcgIe8mMIGN0YlqURQwMSWUD86dCil0bp9zci?=
 =?us-ascii?Q?qCiFsVOuXYC3K1dRgsVN4dGKw7QA+pChtM4QkQ4oSpY1cfGZ9cgOt75L5onV?=
 =?us-ascii?Q?BN7/Pq1tUohuiXdXICuqRItY7sxW7I3DsebML5aG383w0xrbXjJPivM+JA1d?=
 =?us-ascii?Q?AETGwTGuVlykZL6vxdyjENLykhi5mSnL+f0mc0MtW5Y/lTwJVyqV78OmER+g?=
 =?us-ascii?Q?jmeK64ogSBU8Bih2XTg32sooDL4i4jEewE2HbahRhRr3dIcGbry2R5p2s3Ym?=
 =?us-ascii?Q?cijQXPNYjcWWjrbqYB/YXNqj/bvAk8Y9+bVfGOUArs+YHI5fCMOOvRhgs47u?=
 =?us-ascii?Q?bIdInctOeQshV25FlRGpM1JFOEGhRj8ylaXFFnEKpx8JkIVhO709suZweTRj?=
 =?us-ascii?Q?5fh614SVwP8mDqMCCtjbcU1v3GE0VLDPYemjNgwbBsNy7eyO5HR2mwr7am6D?=
 =?us-ascii?Q?6zTcge6Lbr1wewj46aPHuXrpfVTOR4u0QnPIRwlQ0aCS/xyCHVvoRXRbyzH7?=
 =?us-ascii?Q?ZCHKEgjGNHB2+FIbWfEsyeKKdBBtxoLh1Q0FTZVn2GSilft1gKXeIWeX6dPb?=
 =?us-ascii?Q?+3jepqhtqCs4+eNqtK4775EcIfHTnGwNe3Vv/cUPs4nkou8FAlctqnSfageY?=
 =?us-ascii?Q?NOLEEpuOoOr6ejyO0I5/94NprJzwsyO6uKTXquS9x+VCarknx87FtP66GEOo?=
 =?us-ascii?Q?kvg/N9WJ+gbsADYh3VbvV4f7+cvQKCTBkc2eGFX54YpvFO7FVScofwLLdWFh?=
 =?us-ascii?Q?no47n5OI0EwFXol3xyVKdleiz+m6dD+n1CPNbOrRNDcQU5MD+atMGJZ86okN?=
 =?us-ascii?Q?+QQP6BUvXIf754u5Puaj6qvNSk2rsiBLNqsLWWMpvD8mlsmOi/akP0PtxfEh?=
 =?us-ascii?Q?tgbe5d2q7ss6QsHaKnwu+QudpBH6pk58Ps4UDrBfGd2ikYFcVt1CJJ2weFnC?=
 =?us-ascii?Q?rW/sKFO9G/rrPfU3XP5W8k6t7pPlWxZjiu3BBX+jjXwNFYIkwm5DF8zZUHXS?=
 =?us-ascii?Q?DwN1Y3rZrFDlXdk+rb9ppxIuLvT5BI+sh/hBYnZAfVfXQh6+Z+Y8Qcm4YUHX?=
 =?us-ascii?Q?MNETRcRt+GzgsM9e93z6+GRth+IOoNUOAtwNC3J957tuUiFit5g2MhYPQ+LP?=
 =?us-ascii?Q?Hj2o8u9qIrNf4JgdEvqciDCgugX+5zuc3+RfbSBXcYlbk2fF8Wb3io6r9If7?=
 =?us-ascii?Q?MRroBy4RfqMCp3kcg4yOOW1IWh56MDCbHPpANj47/7wb3OxyuEYKvoRw2Qcs?=
 =?us-ascii?Q?XwY3wja99/XmnvL2K9/2ITPfKWAfDXJvxBE/dYY7MzDdybHoQwWee30EyceZ?=
 =?us-ascii?Q?+XJ74BLH3Qv0YU4nQDZkKqI8q/fVxRuaxy+duETgDRlA4SZex9ZEXfbE02Rw?=
 =?us-ascii?Q?23PuOfR+C1pzghN4wOVCIXx2d9/B4XR8Sfp6goLBOkUhm53kcEM9YaU3raHi?=
 =?us-ascii?Q?EV7S6b/yKou7BrfYA6iQfL5D/EU/bZ1FTIXjv7Se5wfRuwxUsLcthq9wm50q?=
 =?us-ascii?Q?mounc8eIC6xXkEqUeGOlZTw60qF0qWQT8XWh+Z+IfqOXEPJ8GGsyExCXP8ut?=
 =?us-ascii?Q?6Q=3D=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ae6ae19a-35f2-4648-29f0-08da9a2782c7
X-MS-Exchange-CrossTenant-AuthSource: MWHPR1001MB2365.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Sep 2022 10:12:52.6869
 (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: wdPehHO3nLKmsi4JP0h5aOiKRNBc3Lstvk6CCT21rEGMg4Wl5nyjiV1wKI0dlcqspdHE3i88tgWZ0/Mxl0JEoCHr8mpVqgf1WjrE7Q8vapE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR10MB5741
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1
 definitions=2022-09-19_05,2022-09-16_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 spamscore=0
 bulkscore=0 mlxscore=0 malwarescore=0 suspectscore=0 mlxlogscore=999
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000
 definitions=main-2209190068
X-Proofpoint-ORIG-GUID: vRouj5ZJdc2rwvG_Xive7ja5oHWI61kf
X-Proofpoint-GUID: vRouj5ZJdc2rwvG_Xive7ja5oHWI61kf
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham
        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

On Thu, Sep 15, 2022 at 10:29:36PM +0200, Nam Cao wrote:
> The function device_rx_srv does not handle allocation failure very well.
> Currently, it performs these steps:
>         - Unmap DMA buffer and hand over the buffer to mac80211

Does the unmapping happens in vnt_receive_frame();?

>         - Allocate and dma-map new buffer

Is the new buffer for the next frame?  So in your patch if we don't
have space for the next frame then we do not process the current frame?
(Rhetorical questions are a bad idea on development lists.  I genuinely
don't know the answers to these questions).

>         - If allocation fails, abort
> 
> The problem is that, it aborts while still marking the buffer as
> OWNED_BY_HOST. So when this function is called again in the future, it
> incorrectly perceives the same buffer as valid and dma-unmap and hand
> over this buffer to mac80211 again.

Where is it supposed to get marked as OWNED_BY_HOST?

> 
> Re-implement this function to do things in a different order:
>         - Allocate and dma-map new buffer
>         - If allocation fails, abort and give up the ownership of the
>           buffer (so that the device can re-use this buffer)
>         - If allocation does not fail: unmap dma buffer and hand over
>           the buffer to mac80211
> 
> Thus, when the driver cannot allocate new buffer, it simply discards the
> received data and re-use the current buffer.
> 
> Signed-off-by: Nam Cao <namcaov@gmail.com>
> ---
>  drivers/staging/vt6655/device_main.c | 13 ++++++++-----
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/vt6655/device_main.c b/drivers/staging/vt6655/device_main.c
> index ca6c4266f010..8ae4ecca2ee3 100644
> --- a/drivers/staging/vt6655/device_main.c
> +++ b/drivers/staging/vt6655/device_main.c
> @@ -826,6 +826,7 @@ static void device_free_td1_ring(struct vnt_private *priv)
>  static int device_rx_srv(struct vnt_private *priv, unsigned int idx)
>  {
>  	struct vnt_rx_desc *rd;
> +	struct vnt_rd_info new_info;
>  	int works = 0;
>  
>  	for (rd = priv->pCurrRD[idx];
> @@ -837,16 +838,18 @@ static int device_rx_srv(struct vnt_private *priv, unsigned int idx)
>  		if (!rd->rd_info->skb)
>  			break;
>  
> -		vnt_receive_frame(priv, rd);
> -
> -		if (!device_alloc_rx_buf(priv, rd->rd_info)) {
> +		if (!device_alloc_rx_buf(priv, &new_info)) {
>  			dev_err(&priv->pcid->dev,
>  				"can not allocate rx buf\n");
> +			rd->rd0.owner = OWNED_BY_NIC;
>  			break;
> -		} else {
> -			device_init_rx_desc(priv, rd);
>  		}
>  
> +		vnt_receive_frame(priv, rd);
> +
> +		memcpy(rd->rd_info, &new_info, sizeof(new_info));
> +		device_init_rx_desc(priv, rd);
> +
>  		rd->rd0.owner = OWNED_BY_NIC;
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The device_init_rx_desc() function sets it to OWNED_BY_NIC so this line
can be deleted.

regards,
dan carpenter