On Thu, Sep 24, 2020 at 5:06 AM Gerald Schaefer
wrote:
>
> It's all good now, no more occurrences with unlock_page() before
> wp_page_reuse().
Thanks for the confirmation. When you pointed at that unlock_page()
change, I was pretty sure that was it ("D'oh!"), but it's always good
to have that
ed), see below, or
>> (referenced|uptodate|dirty|swapbacked) in the original report. But IIUC,
>> that should not qualify for the "PAGE_FLAGS_CHECK_AT_FREE flag(s) set"
>> reason. So it seems that the flags have changed between check_free_page()
>> and __dump_page()
On Thu, 24 Sep 2020 00:02:26 +0200
Gerald Schaefer wrote:
> On Wed, 23 Sep 2020 14:50:36 -0700
> Linus Torvalds wrote:
>
> > On Wed, Sep 23, 2020 at 2:33 PM Gerald Schaefer
> > wrote:
> > >
> > > Thanks, very nice walk-through, need some time to digest this. The TLB
> > > aspect is
between check_free_page()
> and __dump_page(), which would be very odd. Or maybe some issue with
> compound pages, because __dump_page() looks at head->flags.
>
> [ 1863.237707] BUG: Bad page state in process dirtyc0w_child pfn:58527d
> [ 1863.237721] page:886695
On Wed, 23 Sep 2020 14:50:36 -0700
Linus Torvalds wrote:
> On Wed, Sep 23, 2020 at 2:33 PM Gerald Schaefer
> wrote:
> >
> > Thanks, very nice walk-through, need some time to digest this. The TLB
> > aspect is interesting, and we do have our own __tlb_remove_page_size(),
> > which directly calls
On Wed, Sep 23, 2020 at 2:33 PM Gerald Schaefer
wrote:
>
> Thanks, very nice walk-through, need some time to digest this. The TLB
> aspect is interesting, and we do have our own __tlb_remove_page_size(),
> which directly calls free_page_and_swap_cache() instead of the generic
> batched approach.
On Wed, 23 Sep 2020 13:00:45 -0700
Linus Torvalds wrote:
[...]
>
> Ooh. One thing that is *very* different about s390 is that it frees
> the page directly, and doesn't batch things up to happen after the TLB
> flush.
>
> Maybe THAT is the difference? Not that I can tell why it should
> matter,
On Wed, Sep 23, 2020 at 6:39 AM Gerald Schaefer
wrote:
>
> OK, I can now reproduce this, and unfortunately also with the gup_fast
> fix, so it is something different. Bisecting is a bit hard, as it will
> not always show immediately, sometimes takes up to an hour.
>
> Still, I think I found the
g:
> > > https://gitlab.com/cailca/linux-mm/-/blob/master/s390.config
> > >
> > > [ 6970.253173] LTP: starting dirtyc0w
> > > [ 6971.599102] BUG: Bad page state in process dirtyc0w_child pfn:8865d
> > > [ 6971.599867] page:1a8328d7 refcount:0 mapcount:0
>
0x72/0x98
> > [ 6971.600047] [<73b1cce4>] system_call+0xdc/0x278
> > [ 6971.600053] 2 locks held by dirtyc0w_child/65238:
> > [ 6971.600058] #0: 00013442fa18 (>mmap_lock){}-{3:3}, at:
> > do_madvise+0x17a/0x1270
> > [ 6971.600432] #
/blob/master/testcases/kernel/security/dirtyc0w/dirtyc0w_child.c
>
> this .config:
> https://gitlab.com/cailca/linux-mm/-/blob/master/s390.config
>
> [ 6970.253173] LTP: starting dirtyc0w
> [ 6971.599102] BUG: Bad page state in process dirtyc0w_child pfn:8865d
> [ 6971.599867]
:
https://gitlab.com/cailca/linux-mm/-/blob/master/s390.config
[ 6970.253173] LTP: starting dirtyc0w
[ 6971.599102] BUG: Bad page state in process dirtyc0w_child pfn:8865d
[ 6971.599867] page:1a8328d7 refcount:0 mapcount:0
mapping: index:0x0 pfn:0x8865d
[ 6971.599876] flags
12 matches
Mail list logo
