[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171213085006.7093c27e@xeon-e3>
Date: Wed, 13 Dec 2017 08:50:06 -0800
From: Stephen Hemminger <stephen@...workplumber.org>
To: Jia-Ju Bai <baijiaju1990@...il.com>
Cc: David Miller <davem@...emloft.net>, mlindner@...vell.com,
shemminger@...l.org, shemminger@...ux-foundation.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [BUG] skge: a possible sleep-in-atomic bug in skge_remove
On Wed, 13 Dec 2017 15:42:56 +0800
Jia-Ju Bai <baijiaju1990@...il.com> wrote:
> On 2017/12/13 13:18, Stephen Hemminger wrote:
> > On Tue, 12 Dec 2017 20:57:01 -0500 (EST)
> > David Miller <davem@...emloft.net> wrote:
> >
> >> From: Stephen Hemminger <stephen@...workplumber.org>
> >> Date: Tue, 12 Dec 2017 10:22:40 -0800
> >>
> >>> On Tue, 12 Dec 2017 08:34:45 -0500 (EST)
> >>> David Miller <davem@...emloft.net> wrote:
> >>>
> >>>> From: Jia-Ju Bai <baijiaju1990@...il.com>
> >>>> Date: Tue, 12 Dec 2017 16:38:12 +0800
> >>>>
> >>>>> According to drivers/net/ethernet/marvell/skge.c, the driver may sleep
> >>>>> under a spinlock.
> >>>>> The function call path is:
> >>>>> skge_remove (acquire the spinlock)
> >>>>> free_irq --> may sleep
> >>>>>
> >>>>> I do not find a good way to fix it, so I only report.
> >>>>> This possible bug is found by my static analysis tool (DSAC) and
> >>>>> checked by my code review.
> >>>> This was added by:
> >>>>
> >>>> commit a9e9fd7182332d0cf5f3e601df3e71dd431b70d7
> >>>> Author: Stephen Hemminger <shemminger@...tta.com>
> >>>> Date: Tue Sep 27 13:41:37 2011 -0400
> >>>>
> >>>> skge: handle irq better on single port card
> >>>>
> >>>> I think the free_irq() can be moved below the unlock.
> >>>>
> >>>> Stephen, please take a look.
> >>> The IRQ was being free twice.
> >>> How did you see it, I really doubt any multi-port SKGE cards
> >>> still exist.
> >> He sees it by reading the code, please take a look at this
> >> and move the free_irq() out of the spin locked section since
> >> it can sleep.
> > Thanks, I was hoping for some automated static analysis tool.
>
> This bug was found by an automated static analysis tool named DSAC,
> which is written by myself.
> Then I manually checked driver source code, and finally sent the bug report.
Thanks.
Would it be possible to put tool in tools directory and then have
it automated by kbuild robot?
Powered by blists - more mailing lists