[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGLTpnK=4Gd8S488osvrbttkMvtsPy8eCGspV4-=z2N3UGZ5rw@mail.gmail.com>
Date: Wed, 23 Mar 2022 08:08:16 +0900
From: Yasushi SHOJI <yashi@...cecubics.com>
To: Hangyu Hua <hbh25y@...il.com>
Cc: Wolfgang Grandegger <wg@...ndegger.com>,
Marc Kleine-Budde <mkl@...gutronix.de>,
David Miller <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Vincent Mailhol <mailhol.vincent@...adoo.fr>,
stefan.maetje@....eu, Pavel Skripkin <paskripkin@...il.com>,
remigiusz.kollataj@...ica.com,
linux-can <linux-can@...r.kernel.org>,
netdev <netdev@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] can: mcba_usb: fix possible double dev_kfree_skb in mcba_usb_start_xmit
Hi Hangyu,
On Fri, Mar 11, 2022 at 5:02 PM Hangyu Hua <hbh25y@...il.com> 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,
--
yashi
Powered by blists - more mailing lists