Hi yashi,
You are right. There are a series of the same problems about
can_put_echo_skb.
This issue was discovered while I was discussing a incorrect patch with
Marc. You can check this in
https://lore.kernel.org/all/20220225060019.21220-1-hbh25y@xxxxxxxxx/
So i submitted a new patch. This was the first place where the problem
occurs. You can check this in
[1] https://lore.kernel.org/all/20220228083639.38183-1-hbh25y@xxxxxxxxx/
After a week, I realized it could be a series of problems. So
i submitted the following patches
[2]
https://lore.kernel.org/all/0d2f9980-fb1d-4068-7868-effc77892a97@xxxxxxxxx/
[3]
https://lore.kernel.org/all/de416319-c027-837d-4b8c-b8c3c37ed88e@xxxxxxxxx/
[4] https://lore.kernel.org/all/20220317081305.739554-1-mkl@xxxxxxxxxxxxxx/
I think this is all affected. None of the four have been merged
upstream. Do i need to remake all these four patches?
Thanks,
Hangyu
On 2022/3/23 07:08, Yasushi SHOJI wrote:
Hi Hangyu,
On Fri, Mar 11, 2022 at 5:02 PM Hangyu Hua <hbh25y@xxxxxxxxx> wrote:
There is no need to call dev_kfree_skb when usb_submit_urb fails beacause
can_put_echo_skb deletes original skb and can_free_echo_skb deletes the cloned
skb.
So, it's more like, "we don't need to call dev_kfree_skb() after
can_put_echo_skb()
because can_put_echo_skb() consumes the given skb.". It seems it doesn't depend
on the condition of usb_submit_urb(). Plus, we don't see the "cloned
skb" at the
call site.
Would you mind adding a comment on can_put_echo_skb(), in a separate patch,
saying the fact that it consumes the skb?
ems_usb.c, gs_usb.c and possibly some others seem to call
dev_kfree_skb() as well.
Are they affected?
Best,
