[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABbzaOUQC_nshtuZaNJk48JiuYOY0pPxK9i3fW=SsTsFM1Sk9w@mail.gmail.com>
Date: Tue, 30 Sep 2025 19:03:31 +0530
From: Deepak Sharma <deepak.sharma.472935@...il.com>
To: Paolo Abeni <pabeni@...hat.com>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
horms@...nel.org, pwn9uin@...il.com, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-kernel-mentees@...ts.linux.dev,
david.hunter.linux@...il.com, skhan@...uxfoundation.org,
syzbot+740e04c2a93467a0f8c8@...kaller.appspotmail.com,
syzbot+07b635b9c111c566af8b@...kaller.appspotmail.com
Subject: Re: [PATCH net v2] atm: Fix the cleanup on alloc_mpc failure in atm_mpoa_mpoad_attach
On Tue, Sep 30, 2025 at 2:15 PM Paolo Abeni <pabeni@...hat.com> wrote:
> AFAICS the mpc_timer can rearm itself, so this the above is not enough
> and you should use timer_shutdown_sync() instead.
Hi,
As I understand it, `timer_shutdown_sync` will prevent any further
re-arming of the timer. I think this is not what we want here; since even if
we somehow fail to allocate our first MPOA client object on our first
ioctl call,
and hence end up wanting to disarm the timer, maybe on next call we can
allocate it successfully, and we would want that caches are processed
(which are processed for every time out). So we still want it to be
possible that
we can re-arm it.
And as I understand, `timer_delete_sync` will wait for the callback to
finish, so
deleting the timer after that should do the job
Thanks,
Deepak
Powered by blists - more mailing lists