On Fri, 2022-10-14 at 11:37 -0700, Bart Van Assche wrote: > > pr_err("Max General LU supported by UFS isn't > > initialized\n"); > > return false; > > } > > - /* WB is available only for the logical unit from 0 to 7 */ > > - if (param_offset == UNIT_DESC_PARAM_WB_BUF_ALLOC_UNITS) > > - return lun < UFS_UPIU_MAX_WB_LUN_ID; > > return lun == UFS_UPIU_RPMB_WLUN || (lun < dev_info- > > >max_lu_supported); > > } > > Hi Bean, > > I think the above patch reintroduces the stack overflow issue fixed > by > commit a2fca52ee640 ("scsi: ufs: WB is only available on LUN #0 to > #7"). > > How about reverting commit a2fca52ee640 and fixing the stack overflow > issue in another way than by modifying ufs_is_valid_unit_desc_lun()? > > Thanks, > > Bart. Hi Bart, I double-checked the changelog and the stack overflow issue was double fixed by your commit: commit d3d9c4570285 ("scsi: ufs: Fix memory corruption by ufshcd_read_desc_param()"), For example, if the user wants to read wb_buf_alloc_units in the RPMB unit descriptor, parameter offset = 41, parameter size = 4, buff_len = 45; After ufshcd_query_descriptor_retry(), buff_len will be updated to 35. param_offset > buff_len, then -EINVAL will be returned. So we can safely remove this check, and if you still have concerns, I can verify when I get back to the office. Kind regards, Bean