[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160127012618.GA14613@hori1.linux.bs1.fc.nec.co.jp>
Date: Wed, 27 Jan 2016 01:26:20 +0000
From: Naoya Horiguchi <n-horiguchi@...jp.nec.com>
To: Andrew Morton <akpm@...ux-foundation.org>
CC: Chen Gong <gong.chen@...ux.intel.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Naoya Horiguchi <nao.horiguchi@...il.com>
Subject: Re: [PATCH v1] mm/madvise: pass return code of memory_failure() to
userspace
On Tue, Jan 26, 2016 at 03:27:58PM -0800, Andrew Morton wrote:
> On Fri, 22 Jan 2016 17:27:57 +0900 Naoya Horiguchi <n-horiguchi@...jp.nec.com> wrote:
>
> > Currently the return value of memory_failure() is not passed to userspace, which
> > is inconvenient for test programs that want to know the result of error handling.
> > So let's return it to the caller as we already do in MADV_SOFT_OFFLINE case.
>
> I updated this to mention that it's for madvise(MADV_HWPOISON):
>
> : Currently the return value of memory_failure() is not passed to userspace
> : when madvise(MADV_HWPOISON) is used. This is inconvenient for test
> : programs that want to know the result of error handling. So let's return
> : it to the caller as we already do in the MADV_SOFT_OFFLINE case.
Thank you.
> btw, MADV_SOFT_OFFLINE and MADV_HWPOISON are not documented in that
> comment block over sys_madvise(). Fixy please? You might want to
> check that no other MADV_foo values have been omitted.
OK, I posted the fix patch just now, which also updates about some other
madvices.
Thanks,
Naoya Horiguchi
Powered by blists - more mailing lists