Re: change of behavior for madvise in 3.9-rc1

[CAI Qian]

----- Original Message -----
> From: "Hugh Dickins" <hughd@xxxxxxxxxx>
> To: "Shaohua Li" <shli@xxxxxxxxxx>
> Cc: "CAI Qian" <caiqian@xxxxxxxxxx>, "linux-mm" <linux-mm@xxxxxxxxx>, "linux-kernel" <linux-kernel@xxxxxxxxxxxxxxx>,
> "Rik van Riel" <riel@xxxxxxxxxx>, "Sasha Levin" <sasha.levin@xxxxxxxxxx>, "Andrew Morton"
> <akpm@xxxxxxxxxxxxxxxxxxxx>, "Linus Torvalds" <torvalds@xxxxxxxxxxxxxxxxxxxx>
> Sent: Friday, March 8, 2013 2:49:48 AM
> Subject: Re: change of behavior for madvise in 3.9-rc1
> 
> On Thu, 7 Mar 2013, Shaohua Li wrote:
> > On Wed, Mar 06, 2013 at 11:05:04PM -0500, CAI Qian wrote:
> > > Bisecting indicated that this commit,
> > > 1998cc048901109a29924380b8e91bc049b32951
> > > mm: make madvise(MADV_WILLNEED) support swap file prefetch
> > > 
> > > Caused an LTP test failure,
> > > http://goo.gl/1FVPy
> > > 
> > > madvise02    1  TPASS  :  failed as expected:
> > > TEST_ERRNO=EINVAL(22): Invalid argument
> > > madvise02    2  TPASS  :  failed as expected:
> > > TEST_ERRNO=EINVAL(22): Invalid argument
> > > madvise02    3  TPASS  :  failed as expected:
> > > TEST_ERRNO=EINVAL(22): Invalid argument
> > > madvise02    4  TPASS  :  failed as expected:
> > > TEST_ERRNO=ENOMEM(12): Cannot allocate memory
> > > madvise02    5  TFAIL  :  madvise succeeded unexpectedly
> > > 
> > > While it passed without the above commit
> > > madvise02    1  TPASS  :  failed as expected:
> > > TEST_ERRNO=EINVAL(22): Invalid argument
> > > madvise02    2  TPASS  :  failed as expected:
> > > TEST_ERRNO=EINVAL(22): Invalid argument
> > > madvise02    3  TPASS  :  failed as expected:
> > > TEST_ERRNO=EINVAL(22): Invalid argument
> > > madvise02    4  TPASS  :  failed as expected:
> > > TEST_ERRNO=ENOMEM(12): Cannot allocate memory
> > > madvise02    5  TPASS  :  failed as expected:
> > > TEST_ERRNO=EBADF(9): Bad file descriptor
> > 
> > I thought this is expected behavior. madvise(MADV_WILLNEED) to
> > anonymous memory
> > doesn't return -EBADF now, as now we support swap prefretch.
> 
> I agree with Shaohua: although the kernel strives for
> back-compatibility
> with userspace, I don't think that goes so far as to tell an
> arbitrary LTP
> test that it has failed, once the kernel has been enhanced to support
> new
> functionality.  We could never add or extend system calls if that
> were so.
Thanks for looking this. We will try to fix the LTP test instead.
> 
> Hugh
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/