> On Sep 30, 2019, at 7:04 AM, Kirill A. Shutemov wrote:
>
> Looks like Power also uses the hook. Have you check that this patch will
> not affect Power?
Yes, I did. Although I did only test radix memory which seems just return
immediately in arch_free_page(), I code-review the non-radix
On Fri, Sep 27, 2019 at 03:47:03PM -0400, Qian Cai wrote:
> On architectures like s390, arch_free_page() could mark the page unused
> (set_page_unused()) and any access later would trigger a kernel panic.
> Fix it by moving arch_free_page() after all possible accessing calls.
Looks like Power
On Fri 27-09-19 15:47:03, Qian Cai wrote:
> On architectures like s390, arch_free_page() could mark the page unused
> (set_page_unused()) and any access later would trigger a kernel panic.
> Fix it by moving arch_free_page() after all possible accessing calls.
>
> Hardware name: IBM 2964 N96 400
On Fri, Sep 27, 2019 at 05:15:08PM -0400, Qian Cai wrote:
> On Fri, 2019-09-27 at 13:48 -0700, Andrew Morton wrote:
> > On Fri, 27 Sep 2019 15:47:03 -0400 Qian Cai wrote:
> > > --- a/mm/page_alloc.c
> > > +++ b/mm/page_alloc.c
> > > @@ -1175,11 +1175,11 @@ static __always_inline bool
> > >
On 27.09.19 23:59, Andrew Morton wrote:
> On Fri, 27 Sep 2019 17:28:06 -0400 Qian Cai wrote:
>
>>>
>>> So I think you've moved the arch_free_page() to be after the final
>>> thing which can access page contents, yes? If so, we should have a
>>> comment in free_pages_prepare() to attmept to
On 28.09.19 11:06, David Hildenbrand wrote:
> On 28.09.19 00:17, Alexander Duyck wrote:
>> On Fri, Sep 27, 2019 at 2:59 PM Andrew Morton
>> wrote:
>>>
>>> On Fri, 27 Sep 2019 17:28:06 -0400 Qian Cai wrote:
>>>
>
> So I think you've moved the arch_free_page() to be after the final
On 28.09.19 00:17, Alexander Duyck wrote:
> On Fri, Sep 27, 2019 at 2:59 PM Andrew Morton
> wrote:
>>
>> On Fri, 27 Sep 2019 17:28:06 -0400 Qian Cai wrote:
>>
So I think you've moved the arch_free_page() to be after the final
thing which can access page contents, yes? If so, we
On Fri, Sep 27, 2019 at 2:59 PM Andrew Morton wrote:
>
> On Fri, 27 Sep 2019 17:28:06 -0400 Qian Cai wrote:
>
> > >
> > > So I think you've moved the arch_free_page() to be after the final
> > > thing which can access page contents, yes? If so, we should have a
> > > comment in
On Fri, 27 Sep 2019 17:28:06 -0400 Qian Cai wrote:
> >
> > So I think you've moved the arch_free_page() to be after the final
> > thing which can access page contents, yes? If so, we should have a
> > comment in free_pages_prepare() to attmept to prevent this problem from
> > reoccurring as
On Fri, 2019-09-27 at 14:02 -0700, Andrew Morton wrote:
> On Fri, 27 Sep 2019 15:47:03 -0400 Qian Cai wrote:
>
> > On architectures like s390, arch_free_page() could mark the page unused
> > (set_page_unused()) and any access later would trigger a kernel panic.
> > Fix it by moving
On Fri, 2019-09-27 at 13:48 -0700, Andrew Morton wrote:
> On Fri, 27 Sep 2019 15:47:03 -0400 Qian Cai wrote:
>
> > On architectures like s390, arch_free_page() could mark the page unused
> > (set_page_unused()) and any access later would trigger a kernel panic.
> > Fix it by moving
On Fri, 27 Sep 2019 15:47:03 -0400 Qian Cai wrote:
> On architectures like s390, arch_free_page() could mark the page unused
> (set_page_unused()) and any access later would trigger a kernel panic.
> Fix it by moving arch_free_page() after all possible accessing calls.
>
> Hardware name: IBM
On Fri, 27 Sep 2019 15:47:03 -0400 Qian Cai wrote:
> On architectures like s390, arch_free_page() could mark the page unused
> (set_page_unused()) and any access later would trigger a kernel panic.
> Fix it by moving arch_free_page() after all possible accessing calls.
>
> Hardware name: IBM
On architectures like s390, arch_free_page() could mark the page unused
(set_page_unused()) and any access later would trigger a kernel panic.
Fix it by moving arch_free_page() after all possible accessing calls.
Hardware name: IBM 2964 N96 400 (z/VM 6.4.0)
Krnl PSW : 0404e0018000
14 matches
Mail list logo
