Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1350620 > unrolled thread

Re: [PATCH] mm/hugetlb: use EOPNOTSUPP in hugetlb sysctl handlers

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] mm/hugetlb: use EOPNOTSUPP in hugetlb sysctl handlers Andrew Morton <akpm@linux-foundation.org> - 2016-03-04 22:40 +0100
    Re: [PATCH] mm/hugetlb: use EOPNOTSUPP in hugetlb sysctl handlers Jan Stancek <jstancek@redhat.com> - 2016-03-05 09:20 +0100
      Re: [PATCH] mm/hugetlb: use EOPNOTSUPP in hugetlb sysctl handlers Andrew Morton <akpm@linux-foundation.org> - 2016-03-08 01:20 +0100

#1350620 — Re: [PATCH] mm/hugetlb: use EOPNOTSUPP in hugetlb sysctl handlers

On Thu,  3 Mar 2016 11:02:51 +0100 Jan Stancek <jstancek@redhat.com> wrote:

> Replace ENOTSUPP with EOPNOTSUPP. If hugepages are not supported,
> this value is propagated to userspace. EOPNOTSUPP is part of uapi
> and is widely supported by libc libraries.

hm, what is the actual user-visible effect of this change?  Does it fix
some misbehaviour?

[toc] | [next] | [standalone]

#1350833

----- Original Message -----
> From: "Andrew Morton" <akpm@linux-foundation.org>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, n-horiguchi@ah.jp.nec.com, "mike kravetz"
> <mike.kravetz@oracle.com>, "hillf zj" <hillf.zj@alibaba-inc.com>, "kirill shutemov"
> <kirill.shutemov@linux.intel.com>, "dave hansen" <dave.hansen@linux.intel.com>, "paul gortmaker"
> <paul.gortmaker@windriver.com>
> Sent: Friday, 4 March, 2016 10:38:07 PM
> Subject: Re: [PATCH] mm/hugetlb: use EOPNOTSUPP in hugetlb sysctl handlers
> 
> On Thu,  3 Mar 2016 11:02:51 +0100 Jan Stancek <jstancek@redhat.com> wrote:
> 
> > Replace ENOTSUPP with EOPNOTSUPP. If hugepages are not supported,
> > this value is propagated to userspace. EOPNOTSUPP is part of uapi
> > and is widely supported by libc libraries.
> 
> hm, what is the actual user-visible effect of this change?  Does it fix
> some misbehaviour?
> 

It gives nicer message to user, rather than:
# cat /proc/sys/vm/nr_hugepages
cat: /proc/sys/vm/nr_hugepages: Unknown error 524

And also LTP's proc01 test was failing because this ret code (524)
was unexpected:
proc01      1  TFAIL  :  proc01.c:396: read failed: /proc/sys/vm/nr_hugepages: errno=???(524): Unknown error 524
proc01      2  TFAIL  :  proc01.c:396: read failed: /proc/sys/vm/nr_hugepages_mempolicy: errno=???(524): Unknown error 524
proc01      3  TFAIL  :  proc01.c:396: read failed: /proc/sys/vm/nr_overcommit_hugepages: errno=???(524): Unknown error 524

Regards,
Jan

[toc] | [prev] | [next] | [standalone]

#1352363

On Sat, 5 Mar 2016 03:09:50 -0500 (EST) Jan Stancek <jstancek@redhat.com> wrote:

> > > Replace ENOTSUPP with EOPNOTSUPP. If hugepages are not supported,
> > > this value is propagated to userspace. EOPNOTSUPP is part of uapi
> > > and is widely supported by libc libraries.
> > 
> > hm, what is the actual user-visible effect of this change?  Does it fix
> > some misbehaviour?
> > 
> 
> It gives nicer message to user, rather than:
> # cat /proc/sys/vm/nr_hugepages
> cat: /proc/sys/vm/nr_hugepages: Unknown error 524
> 
> And also LTP's proc01 test was failing because this ret code (524)
> was unexpected:
> proc01      1  TFAIL  :  proc01.c:396: read failed: /proc/sys/vm/nr_hugepages: errno=???(524): Unknown error 524
> proc01      2  TFAIL  :  proc01.c:396: read failed: /proc/sys/vm/nr_hugepages_mempolicy: errno=???(524): Unknown error 524
> proc01      3  TFAIL  :  proc01.c:396: read failed: /proc/sys/vm/nr_overcommit_hugepages: errno=???(524): Unknown error 524
> 

Ah, OK, thanks.  "Unknown error 524" is rather rude.  I'll queue this
for 4.5.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web