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@xxxxxxxxxxxxxxxxxx>
> Cc: Hugh Dickins <hughd@xxxxxxxxxx>
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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
