Re: [RFC PATCH 2/2] swsusp: make it possible to hibernate to device mapper devices
Askar Safin <[email protected]> Tue, 23 Dec 2025 08:29:52 +0300
| Newsgroups | dev.linux.lists.lvm-devel,dev.linux.lists.dm-devel,dev.linux.lists.linux-lvm,org.kernel.vger.linux-block,org.kernel.vger.linux-btrfs,org.kernel.vger.linux-crypto,org.kernel.vger.linux-pm,org.kernel.vger.linux-raid,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
Milan Broz <[email protected]>: > Anyway, my understanding is that all device-mapper targets use mempools, > which should ensure that they can process even under memory pressure. I used journal mode so far, but, as well as I understand, direct mode is okay for my use case. Okay, I spent some time carefully reading dm-integrity source code. I have read v6.12.48, because this is kernel I use. And I conclude that dm-integrity code never allocate (not even from mempool)... ...in main code paths (as opposed to initialization code paths)... ...in direct ('D') mode... ...if I/O doesn't fail and checksums match. (As I said in previous letter, mempools are bad, too, as well as I understand.) I found exactly one place, where we seem to allocate in main code path: https://elixir.bootlin.com/linux/v6.12.48/source/drivers/md/dm-integrity.c#L1789 (i. e. these two kmalloc's). But I think this okay, because: - we pass GFP_NOIO, so, as well as I understand, this should not lead to recursion - we pass __GFP_NORETRY, so, as well as I understand, we will not block in this kmalloc for too much time - we gracefully handle possible failure Other strange place I found is this: https://elixir.bootlin.com/linux/v6.12.48/source/drivers/md/dm-integrity.c#L1704 . But I think this is okay, because: - integrity_recheck is only ever called from here: https://elixir.bootlin.com/linux/v6.12.48/source/drivers/md/dm-integrity.c#L1857 - that integrity_recheck call is only ever happens if dm_integrity_rw_tag failed - as well as I understand, dm_integrity_rw_tag can only fail if we got actual I/O error or checksum mismatch So, this mempool_alloc call is okay for my use case. So: in 'D' mode everything should be okay for my use case. Another note: I used very stupid way to search functions, which allocate: if function has "alloc" in its name, then I consider it allocating. :) And final note: there is an elephant in a room: bufio. As well as I understand, when pages are swapped in my use case, they first will get to dm-integrity bufio cache, and only after that, they will actually hit disk. This, of course, defeats whole purpose of swap. And possibly can lead to deadlocks. Is there a way to disable bufio? Or maybe bufio is used for checksums and metadata only? -- Askar Safin