linux-kernel - RE: [PATCH] qed: Fix a sleep-in-interrupt bug in qed_int_sp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 31 May 2017 17:59:58 +0000
From:   "Mintz, Yuval" <Yuval.Mintz@...ium.com>
To:     Jia-Ju Bai <baijiaju1990@....com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] qed: Fix a sleep-in-interrupt bug in qed_int_sp_dpc

> The driver may sleep in interrupt handling, and the function call path is:
> qed_int_sp_dpc (tasklet_init indicates it handles interrupt)
>   qed_int_attentions
>     qed_mcp_handle_events
>       qed_mcp_handle_link_change
>         qed_link_update
>           qed_fill_link
>             qed_mcp_get_media_type
>               qed_ptt_acquire
>                 usleep_range --> may sleep
> 
> To fix it, the "usleep_range" is replaced with "udelay".

Thanks for pointing this out, but I believe the fix isn't the right one.

The better option would be to propagate the PTT from the outside
instead of acquiring a new one - in the call stack you've shared
qed_mcp_link_change() held a PTT entry and we could have propagated
it all the way through.

I'll try sending a fix for this in the next couple of days.