From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753153AbcA0B07 (ORCPT ); Tue, 26 Jan 2016 20:26:59 -0500 Received: from TYO201.gate.nec.co.jp ([210.143.35.51]:44089 "EHLO tyo201.gate.nec.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752551AbcA0B04 convert rfc822-to-8bit (ORCPT ); Tue, 26 Jan 2016 20:26:56 -0500 From: Naoya Horiguchi To: Andrew Morton CC: Chen Gong , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Naoya Horiguchi Subject: Re: [PATCH v1] mm/madvise: pass return code of memory_failure() to userspace Thread-Topic: [PATCH v1] mm/madvise: pass return code of memory_failure() to userspace Thread-Index: AQHRVO7ycrgEO8RsvEaF+M0ct5XjPp8N4aMAgAAhEAA= Date: Wed, 27 Jan 2016 01:26:20 +0000 Message-ID: <20160127012618.GA14613@hori1.linux.bs1.fc.nec.co.jp> References: <1453451277-20979-1-git-send-email-n-horiguchi@ah.jp.nec.com> <20160126152758.0638a764ba99ab215c44977c@linux-foundation.org> In-Reply-To: <20160126152758.0638a764ba99ab215c44977c@linux-foundation.org> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.128.101.9] Content-Type: text/plain; charset="iso-2022-jp" Content-ID: Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 26, 2016 at 03:27:58PM -0800, Andrew Morton wrote: > On Fri, 22 Jan 2016 17:27:57 +0900 Naoya Horiguchi 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