[lkml]   [2021]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] auxdisplay: Remove in_interrupt() usage.
    On 2021-02-08 23:26:57 [+0100], Miguel Ojeda wrote:
    > Thanks -- can you please add a Link: tag to a lore URL or the docs or
    > similar where more information can be found regarding the
    > proposal/discussion for removing `in_interrurt()` etc.? It is useful
    > to track why these things are happening around the kernel.

    If I post series with more than just one patch I have a cover letter

    |in the discussion about preempt count consistency across kernel
    |it was concluded that the usage of in_interrupt() and related context
    |checks should be removed from non-core code.
    |In the long run, usage of 'preemptible, in_*irq etc.' should be banned from
    |driver code completely.

    since this patch was small, simple and removing not required code I kept
    it out. Is this enough information for you?

    > Also, `hacking.rst` (and related documentation) should be updated
    > before this is done, so that we can link to it.

    The information is not wrong, it doesn't say you have to use it it your
    driver. It also does not mention that you should not. I will look into

    > > What I meant was GFP_KERNEL for context which can sleep vs GFP_ATOMIC for
    > > context which must not sleep. The commit above also eliminates the
    > > in_interrupt() usage within the driver (in multiple steps).
    > I was thinking something along those lines, but `in_interrupt()` nor
    > `cond_resched()` take an explicit context either, so I am confused.
    > Does `cond_reched()` always do the right thing regardless of context?
    > The docs are not really clear:
    > "cond_resched() and cond_resched_lock(): latency reduction via
    > explicit rescheduling in places that are safe."
    > It could be read as "it will only resched whenever safe" or "only to
    > be called if it is safe".

    You should keep track of the context you are in and not attempt to sleep
    if it is not allowed. If you are doing something that may monopolize the
    CPU then you should use cond_resched(). The difference compared to
    schedule() is that you don't blindly invoke the scheduler and that it is
    optimized away on a preemptible kernel. But as you noticed, you must not
    not use it if the context does not allow it (like in interrupt handler,
    disabled preemption and so on).

    > Cheers,
    > Miguel


     \ /
      Last update: 2021-02-09 10:11    [W:3.444 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site