Hi Andrew,
the whole thread started here: http://lkml.org/lkml/2014/1/6/217
I guess it makes sense to revert part of the already merged commit with
the following patch. If the BUG_ON triggers again then we should rather
find out why page_address_in_vma fails on anon_vma or f_mapping checks
and not
On Wed 08-01-14 21:10:29, Bob Liu wrote:
[...]
> >> > From 2d61421f26a3b63b4670d71b7adc67e2191b6157 Mon Sep 17 00:00:00 2001
> >> > From: Michal Hocko
> >> > Date: Wed, 8 Jan 2014 10:57:41 +0100
> >> > Subject: [PATCH] mm: new_vma_page cannot see NULL vma for hugetlb pages
> >> >
> >> > 11c731e81b
On Wed, Jan 8, 2014 at 8:42 PM, Michal Hocko wrote:
> On Wed 08-01-14 20:09:30, Bob Liu wrote:
>> On Wed, Jan 8, 2014 at 6:08 PM, Michal Hocko wrote:
>>
>> >
>> > If I was debugging this I would simply add printk into page_address_in_vma
>> > error paths.
>> >
>> > Anyway, I think that at least h
On Wed 08-01-14 20:09:30, Bob Liu wrote:
> On Wed, Jan 8, 2014 at 6:08 PM, Michal Hocko wrote:
>
> >
> > If I was debugging this I would simply add printk into page_address_in_vma
> > error paths.
> >
> > Anyway, I think that at least hugetlbfs part should be reverted because
> > it might paper o
On Wed, Jan 8, 2014 at 6:08 PM, Michal Hocko wrote:
>
> If I was debugging this I would simply add printk into page_address_in_vma
> error paths.
>
> Anyway, I think that at least hugetlbfs part should be reverted because
> it might paper over real bugs. Although the migration would fail for
> su
On Wed 08-01-14 08:56:44, Bob Liu wrote:
> On Wed, Jan 8, 2014 at 1:30 AM, Michal Hocko wrote:
> > On Tue 07-01-14 11:22:12, Michal Hocko wrote:
> >> On Tue 07-01-14 13:29:31, Bob Liu wrote:
> >> > On Mon, Jan 6, 2014 at 10:18 PM, Michal Hocko wrote:
> >> > > On Mon 06-01-14 20:45:54, Bob Liu wro
On Wed, Jan 8, 2014 at 1:30 AM, Michal Hocko wrote:
> On Tue 07-01-14 11:22:12, Michal Hocko wrote:
>> On Tue 07-01-14 13:29:31, Bob Liu wrote:
>> > On Mon, Jan 6, 2014 at 10:18 PM, Michal Hocko wrote:
>> > > On Mon 06-01-14 20:45:54, Bob Liu wrote:
>> > > [...]
>> > >> 544 if (PageAnon(
On Tue 07-01-14 11:22:12, Michal Hocko wrote:
> On Tue 07-01-14 13:29:31, Bob Liu wrote:
> > On Mon, Jan 6, 2014 at 10:18 PM, Michal Hocko wrote:
> > > On Mon 06-01-14 20:45:54, Bob Liu wrote:
> > > [...]
> > >> 544 if (PageAnon(page)) {
> > >> 545 struct anon_vma *page__
On Tue 07-01-14 13:29:31, Bob Liu wrote:
> On Mon, Jan 6, 2014 at 10:18 PM, Michal Hocko wrote:
> > On Mon 06-01-14 20:45:54, Bob Liu wrote:
> > [...]
> >> 544 if (PageAnon(page)) {
> >> 545 struct anon_vma *page__anon_vma = page_anon_vma(page);
> >> 546
On Tue 07-01-14 12:34:34, Wanpeng Li wrote:
> Cced Sasha,
> On Tue, Jan 07, 2014 at 12:26:13PM +0800, Wanpeng Li wrote:
> >Hi Michal,
> >On Mon, Jan 06, 2014 at 03:18:27PM +0100, Michal Hocko wrote:
> >>On Mon 06-01-14 20:45:54, Bob Liu wrote:
> >>[...]
> >>> 544 if (PageAnon(page)) {
> >>
On Mon, Jan 6, 2014 at 10:18 PM, Michal Hocko wrote:
> On Mon 06-01-14 20:45:54, Bob Liu wrote:
> [...]
>> 544 if (PageAnon(page)) {
>> 545 struct anon_vma *page__anon_vma = page_anon_vma(page);
>> 546 /*
>> 547 * Note: swapoff's unuse_v
On Mon 06-01-14 20:45:54, Bob Liu wrote:
[...]
> 544 if (PageAnon(page)) {
> 545 struct anon_vma *page__anon_vma = page_anon_vma(page);
> 546 /*
> 547 * Note: swapoff's unuse_vma() is more efficient with
> this
> 548 *
Hi Michal,
On Mon, Jan 6, 2014 at 7:24 PM, Michal Hocko wrote:
> Hi Wanpeng Li,
> I have just noticed 11c731e81bb0 (mm/mempolicy: fix !vma in
> new_vma_page()) and I am not sure I understand it. Your changelog claims
> "
> page_address_in_vma() may still return -EFAULT because of many other
>
Hi Wanpeng Li,
I have just noticed 11c731e81bb0 (mm/mempolicy: fix !vma in
new_vma_page()) and I am not sure I understand it. Your changelog claims
"
page_address_in_vma() may still return -EFAULT because of many other
conditions in it. As a result the while loop in new_vma_page() may end
14 matches
Mail list logo
