Re: [PATCH v3] mtd: spi-nor: use guard() in spi_nor_rww_start_exclusive

[Tudor Ambarus]

On 8/11/26 6:38 PM, Miquel Raynal wrote:
>>> Have you seen sashiko's review at 
>>> https://sashiko.dev/#/patchset/20260811083111.403453-1-runyu.xiao%40seu.edu.cn?
>>>
>>> Both concerns look valid to me. Do you think you can allocate time to
>>> fix them?
>> Sashiko is becoming a nightmare. I'll add this to my todo list, but if
>> someone in lack of technical challenge wants to propose fixes, be my
>> guest.
> Actually, the might_sleep() warning seems to be an hallucination. It
> mixes different concepts in its explanation (might_sleep() is not a
> problem here, we are in process context) and I believe it got mislead by
> the current state of the code which lacks a mutex_unlock().

I haven't tested but sashiko seems sane on this.

wait_event_killable()
  __wait_event_killable()
    ___wait_event(wq, condition, TASK_KILLABLE, 0, 0, schedule())  <- TASK_KILLABLE!

Here there's a for loop where it calls prepare_to_wait_event() which calls
set_current_state(TASK_KILLABLE), setting current->__state = TASK_KILLABLE and
storing the callsite in current->task_state_change.

After prepare_to_wait_event(), ___wait_event() evaluates condition
spi_nor_rww_start_exclusive(nor) which calls mutex_lock().
mutex_lock() calls might_sleep(). You hit the WARN_ONCE in __might_sleep() because
state == TASK_KILLABLE. You should catch this if you enable CONFIG_DEBUG_ATOMIC_SLEEP.

Cheers,
ta