Hi, "Du, Changbin" <changbin...@intel.com> writes: >> right, and that was my point: if we copy more to userspace, then we have >> a real big problem. >> > Yes, we drop the data because we userspace buffer is not enough this time. > The problem here is that really can we just drop it silently? Maybe not.
Yeah, it probably deserves a pr_err() or pr_debug(), but host sending more data than it should, is another problem altogether which needs to be addressed at the host. Adding a print to aid debugging is a good idea, but bailing out on the peripheral side is not :-s >> > And this missed AIO path. This is identify to my patch after remove the >> >> right, it's more of a debug patch since I don't have the setup to >> trigger this (I'm assuming you're using adb?) >> > Right. And adb can detect this unexpected behavior(data mismatch) quickly > because it has some selfcheck for the data content. cool >> > Byw, we not need add the field "expected_len", we can get it from the >> > struct ffs_io_data. >> >> without expected_len we can copy more data to userspace, right ? If >> req->actual > data_len_before_aligning_to_maxpacket, then we will copy >> more data then we should to userspace and this was a regression caused >> by Al's commit, AFAICT. >> > No, expected_len equals to iov_iter_count(&io_data->data), right? So we > do not need a new field. /me goes read iov_iter_count() you're right, we don't need expected len at all ;-) in any case, did you figure out if the extra data host sends is important data at all or just garbage ? -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
