On (22/11/21 17:56), Andrew Morton wrote:
> > zswap_frontswap_load() should be called from preemptible
> > context (we even call mutex_lock() there) and it does not
> > look like we need to do GFP_ATOMIC allocaion for temp
> > buffer there. Use GFP_KERNEL instead.
> >
> > ...
> >
> > --- a/mm/zswap.c
> > +++ b/mm/zswap.c
> > @@ -1314,7 +1314,7 @@ static int zswap_frontswap_load(unsigned type, pgoff_t offset,
> > }
> >
> > if (!zpool_can_sleep_mapped(entry->pool->zpool)) {
> > - tmp = kmalloc(entry->length, GFP_ATOMIC);
> > + tmp = kmalloc(entry->length, GFP_KERNEL);
> > if (!tmp) {
> > ret = -ENOMEM;
> > goto freeentry;
>
> It seems strange to do
It does indeed.
> if (! can sleep)
> do something which can sleep
Some allocators enter the non-preemptible context in ->map callback and
exit that context in ->unmap. zswap uses async compression and needs to
wait for crypto to finish decompression of the mapped object, which it
cannot do when allocator disables preemption in ->map. So for allocators
that do this zswap allocates a temp buffer, then maps the object, copies
it to that temp buffer and unmaps the objects. So now it can wait for
async crypto because we are in preemptible context and we use the temp
copy of the object.
> or am I misreading the intent of zpool_driver.sleep_mapped? If so,
> perhaps some explanatory code comments will help.
I can add one. I assume at mm/zpool.c zpool_can_sleep_mapped() would be
the right place.
