On Tue 17-02-15 07:53:15, Johannes Weiner wrote:
[...]
> diff --git a/fs/xfs/kmem.c b/fs/xfs/kmem.c
> index a7a3a63bb360..17ced1805d3a 100644
> --- a/fs/xfs/kmem.c
> +++ b/fs/xfs/kmem.c
> @@ -45,20 +45,12 @@ kmem_zalloc_greedy(size_t *size, size_t minsize, size_t maxsize)
> void *
> kmem_alloc(size_t size, xfs_km_flags_t flags)
> {
> - int retries = 0;
> gfp_t lflags = kmem_flags_convert(flags);
> - void *ptr;
>
> - do {
> - ptr = kmalloc(size, lflags);
> - if (ptr || (flags & (KM_MAYFAIL|KM_NOSLEEP)))
> - return ptr;
> - if (!(++retries % 100))
> - xfs_err(NULL,
> - "possible memory allocation deadlock in %s (mode:0x%x)",
> - __func__, lflags);
> - congestion_wait(BLK_RW_ASYNC, HZ/50);
> - } while (1);
> + if (!(flags & (KM_MAYFAIL | KM_NOSLEEP)))
> + lflags |= __GFP_NOFAIL;
> +
> + return kmalloc(size, lflags);
> }
>
> void *
Yes, I think this is the right thing to do (care to send a patch with
the full changelog?).
We really want to have __GFP_NOFAIL explicit. If for nothing else I hope
we can get lockdep checks for this flag. I am hopelessly unfamiliar with
lockdep but even warning from __lockdep_trace_alloc for this flag and
any lock held in the current's context might be helpful to identify
those places and try to fix them.
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>