[Intel-gfx] [PATCH 1/5] shmemfs: Report ENOMEM for page allocation failures outside of tmpfs faults

[Hugh Dickins]

On Wed, 5 Mar 2014, Chris Wilson wrote:

> The intention of returning ENOSPC for a page allocation failure due to
> memory exhausstion in shmem_getpage_gfp() is purely "so that a failure
> on a sparse tmpfs mapping will give SIGBUS not OOM." However, for other
> callers, for example i915.ko, we want to distinguish the error message
> reported to userspace between ENOSPC (meaning that we were unable to fit
> the object/execbuffer into the aperture) and ENOMEM (meaning that we
> were unable to allocate pages for the object).
> 
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> Cc: Hugh Dickins <hughd at google.com>

I'm not keen on this: perhaps because it looks like a hack of yours -
and draws attention to what might be thought a hack of mine ;)

Nor am I thrilled by what was there before (we have three cases which
ought to be distinguished, but only ENOMEM and ENOSPC to distinguish
between them); but would rather it stay as is, than change what's
reported to the user after all these years.

But I do see your point, and asking you to convert ENOSPC to ENOMEM
in all your drivers/gpu calls might be tiresome.

I think we have a reasonable compromise: shmem_read_mapping_page_gfp()
is already the wrapper provided just for you guys, how about posting
a patch to map ENOSPC to ENOMEM there?

(You're using the MS_KERNMOUNT, so won't hit a max_blocks limit.)

Hugh

> ---
>  mm/shmem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 1f18c9d0d93e..142b0bc085e1 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -1179,7 +1179,7 @@ repeat:
>  
>  	} else {
>  		if (shmem_acct_block(info->flags)) {
> -			error = -ENOSPC;
> +			error = fault_type ? -ENOSPC : -ENOMEM;
>  			goto failed;
>  		}
>  		if (sbinfo->max_blocks) {
> -- 
> 1.9.0