Messages in this thread | | | From | Felipe Balbi <> | Subject | RE: [PATCH] usb: gadget: f_fs: report error if excess data received | Date | Thu, 12 May 2016 14:22:44 +0300 |
| |
Hi,
"Du, Changbin" <changbin.du@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
| |