On Tue, 15 Sep 2020 at 09:56, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Sep 14, 2020 at 11:45 PM Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > I mean, I did find one case that didn't set it (cb710-mmc.c), but > > pattern-matching to the other mmc cases, that one looks like it > > _should_ have set the atomic flag like everybody else did. > > Oh, and immediately after sending that out I notice > nvmet_bdev_execute_rw(), which does seem to make allocations inside > that sg_miter loop. > > So those non-atomic cases do clearly exist. > > It does make the case for why kmap_atomic() wants to have the > debugging code. It will "just work" on 64-bit to do it wrong, because > the address doesn't become invalid just because you sleep or get > rescheduled. But then the code that every developer tests (since > developers tend to run on good hardware) might be completely broken on > bad old hardware. > If we want code that is optimal on recent hardware, and yet still correct on older 32-bit hardware, kmap() is definitely a better choice here than kmap_atomic(), since it is a no-op on !HIGHMEM, and tolerates sleeping on 32-bit. /That/ is why I wrote the code this way. The problem is of course that kmap() itself might sleep. So I would argue that the semantics in the name of kmap_atomic() are not about the fact that it starts a non-preemptible section, but that it can be *called from* a non-preemptible section. And starting a non-preemptible section is unnecessary on !HIGHMEM, and should be avoided if possible. > Maybe we could hide it behind a debug option, at least. > > Or, alterantively, introduce a new "debug_preempt_count" that doesn't > actually disable preemption, but warns about actual sleeping > operations.. > > Linus
