lkml.org 
[lkml]   [2022]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: staging: r8188eu: how to handle nested mutex under spinlock
    From
    On 4/3/22 12:49, Fabio M. De Francesco wrote:
    > On domenica 3 aprile 2022 12:43:04 CEST Fabio M. De Francesco wrote:
    >> On sabato 2 aprile 2022 22:47:27 CEST Michael Straube wrote:
    >>> Hi all,
    >>>
    >>> smatch reported a sleeping in atomic context.
    >>>
    >>> rtw_set_802_11_disassociate() <- disables preempt
    >>> -> _rtw_pwr_wakeup()
    >>> -> ips_leave()
    >>>
    >>> rtw_set_802_11_disassociate() takes a spinlock and ips_leave() uses a
    >>> mutex.
    >>>
    >>> I'm fairly new to the locking stuff, but as far as I know this is not a
    >>> false positive since mutex can sleep, but that's not allowed under a
    >>> spinlock.
    >>>
    >>> What is the best way to handle this?
    >>> I'm not sure if converting the mutex to a spinlock (including all the
    >>> other places where the mutex is used) is the right thing to do?
    >>>
    >>> thanks,
    >>> Michael
    >>>
    >> Hi Michael,
    >>
    >> No, this is a false positive: ips_leave is never called under spinlocks.
    >> Some time ago I blindly trusted Smatch and submitted a patch for what you
    >> are reporting just now again. Soon after submission I realized it and
    >> then I had to ask Greg to discard my patch.
    >>
    >> Please read the related thread:
    >>
    >> [PATCH] staging: r8188eu: Use kzalloc() with GFP_ATOMIC in atomic context
    >> https://lore.kernel.org/lkml/20220206225943.7848-1-fmdefrancesco@gmail.com/
    >>
    >> Thanks,
    >>
    >> Fabio
    >
    > I'm sorry, the correct link is the following:
    > [PATCH v2 2/2] staging: r8188eu: Use kzalloc() with GFP_ATOMIC in atomic context
    > https://lore.kernel.org/lkml/20220208180426.27455-3-fmdefrancesco@gmail.com/
    >
    > Fabio
    >

    Hi Fabio,

    Ah I see now, thanks. Well, I think the code is not very clear and easy
    to follow here. Perhaps we should refactor this area someday to avoid
    future confusions.

    regards,
    Michael

    \
     
     \ /
      Last update: 2022-04-03 13:09    [W:3.572 / U:1.324 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site