On Wed, 1 Nov 2023, Hannes Reinecke wrote: > And that is something I've been wondering (for quite some time now): > What _is_ the appropriate error handling for -ENOMEM? > At this time, we assume it to be a retryable error and re-run the queue > in the hope that things will sort itself out. > But if they don't we're stuck. > Can we somehow figure out if we make progress during submission, and (at > least) issue a warning once we detect a stall? The appropriate way is to use mempools. mempool_alloc (with __GFP_DIRECT_RECLAIM) can't ever fail. But some kernel code does GFP_NOIO allocations in the I/O path and the authors hope that they get away with it. Mikulas
- Re: Intermittent storage (dm-cryp... Jan Kara
- Re: Intermittent storage (dm-cryp... Ming Lei
- Re: Intermittent storage (dm-cryp... Marek Marczykowski-Górecki
- Re: Intermittent storage (dm-cryp... Marek Marczykowski-Górecki
- Re: Intermittent storage (dm-cryp... Marek Marczykowski-Górecki
- Re: Intermittent storage (dm-cryp... Ming Lei
- Re: Intermittent storage (dm-cryp... Hannes Reinecke
- Re: Intermittent storage (dm-cryp... Jan Kara
- Re: Intermittent storage (dm-cryp... Ming Lei
- Re: Intermittent storage (dm-cryp... Keith Busch
- Re: Intermittent storage (dm-cryp... Mikulas Patocka
- Re: Intermittent storage (dm-crypt?) freeze - ... Jan Kara
- Re: Intermittent storage (dm-crypt?) free... Mikulas Patocka
