[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACKFLi=ZV42LZqAC6_cWtLfwURyzd6DW9-BQddbozkBSfr31kg@mail.gmail.com>
Date: Thu, 7 Dec 2023 14:24:24 -0800
From: Michael Chan <michael.chan@...adcom.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
pabeni@...hat.com, gospo@...adcom.com,
Kalesh AP <kalesh-anakkur.purayil@...adcom.com>,
Vikas Gupta <vikas.gupta@...adcom.com>, Somnath Kotur <somnath.kotur@...adcom.com>
Subject: Re: [PATCH net v2 3/4] bnxt_en: Fix wrong return value check in bnxt_close_nic()
On Thu, Dec 7, 2023 at 10:27 AM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Wed, 6 Dec 2023 16:05:50 -0800 Michael Chan wrote:
> > The wait_event_interruptible_timeout() function returns 0
> > if the timeout elapsed, -ERESTARTSYS if it was interrupted
> > by a signal, and the remaining jiffies otherwise if the
> > condition evaluated to true before the timeout elapsed.
> >
> > Driver should have checked for zero return value instead of
> > a positive value.
>
> Not sure how this was not caught earlier, maybe there is a more
> complicated story behind it. Otherwise you should handle -ERESTARTSYS
> as well.
The code will always proceed to do the close when
wait_event_interruptible_timeout() returns for any reason. The check
is just to log a warning message that the wait has timed out and we're
closing anyway.
What I can do is to log another warning if the wait is interrupted by
a signal. Since we do the close no matter what, the error code should
not be returned to the caller and the function should be changed to
void. Does that sound reasonable?
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4209 bytes)
Powered by blists - more mailing lists