On (23/12/01 07:19), Jens Axboe wrote: > >> IOW, you have a slew of GFP_KERNEL allocations in there, and you > >> probably just patched the largest one. But the core issue remains. > >> > >> The whole handling of backing_dev_store() looks pretty broken. > >> > > > > Indeed, this patch only solves the biggest problem and does not > > fundamentally solve it, because there are many processes for holding > > zram->init_lock before allocation memory in backing_dev_store that > > need to be fully modified, and I did not consider it thoroughly. > > Obviously, a larger and better patch is needed to eliminate this risk, > > but it is currently not necessary. > > You agree that it doesn't fix the issue, it just happens to fix the one > that you hit. And then you jump to the conclusion that this is all > that's needed to fix it. Ehm, confused? Yeah. zram is very sensitive to memory - zsmalloc pool needs physical pages (allocated on demand) to keep data written to zram. zram probably simply should not be used on systems under such heavy memory pressure. Throwing GPF_ATOMICs at zram isn't going to fix anything. Jens, you said that zram's backing device handling is broken. Got a minute to elaborate?
