[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <842178473.10219645.1393447292444.JavaMail.zimbra@redhat.com>
Date: Wed, 26 Feb 2014 15:41:32 -0500 (EST)
From: Paolo Bonzini <pbonzini@...hat.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Alex Thorlton <athorlton@....com>,
Peter Zijlstra <peterz@...radead.org>,
Christian Borntraeger <borntraeger@...ibm.com>,
akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
viro@...iv.linux.org.uk, schwidefsky@...ibm.com,
rientjes@...gle.com, riel@...hat.com, mingo@...nel.org,
mgorman@...e.de, kirill shutemov <kirill.shutemov@...ux.intel.com>,
heiko carstens <heiko.carstens@...ibm.com>, hannes@...xchg.org,
gerald schaefer <gerald.schaefer@...ibm.com>,
ebiederm@...ssion.com, aarcange@...hat.com
Subject: Re: + mm-revert-thp-make-madv_hugepage-check-for-mm-def_flags.patch
added to -mm tree
> +#ifdef CONFIG_S390
> + /*
> + * MADV_HUGEPAGE is broken after s390_enable_sie(), qemu
> + * blindly does madvise(MADV_HUGEPAGE) for for all kvm pages
> + * and expects it must fail on s390. Avoid a possible SIGSEGV
> + * until qemu is changed.
> + */
> + if (mm_has_pgste(vma->vm_mm))
> + return -EINVAL;
> +#endif
The comment is not quite true. QEMU doesn't expect that the madvise fails.
It simply expects that the madvise doesn't cause SIGSEGVs or later
malfunctioning, because (quoting tha man page) madvise "does not influence
the semantics of the application".
There's nothing to fix in QEMU, in fact I believe this should return 0
rather than -EINVAL. It's perfectly legal for the kernel to ignore an madvise,
and this is what should happen here.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists