Ultimate problem in Linux kernel source code analysis

The name of the article is very good. Here is just an interesting record of what I encountered when studying the Linux kernel source code, but I do not know what the problem is.

*****

1) Why can't interrupt handler sleep, or, more strictly, be scheduled (rescheduled)

Currently, the most widely cited and easiest to understand is: 1) interrupt context is time-critical because the interrupt handler interrupts the other code. Code shocould be quick and simple. 2) interrupt context is not associated with a process.CurrentMacro is not relevant
(Although it points to the interrupted process). Without a backing process, interrupt context cannot sleep --- How wocould it ever reschedule?

From my personal point of view, these two interpretations are at most considered as suggestions, that is, they suggest you not to sleep in interrupt handler, but you may not be able to sleep. Since the schedler of the kernel stores all the states of the CPU, the interrupt handler can be scheduled in terms of technical implementation feasibility. In fact, as long as the process is interrupted by the interrupt handler, that is, as mentioned in the second explanation aboveCurrentThe process that is not related to interrupt handler. Of course, this will affect the speed of the system, but only emphasize the feasibility of technical implementation.

This idea should be well verified.

****

2) Why does read/write memory barrier fail to guarantee transitivity, while general barrier can ensure

The conclusion in documentation/memory_barriers.txt is unknown. In my opinion, read/write memory barrier should be able to guarantee the transmission.