Re: [linus:master] [mm] efa7df3e3b: kernel_BUG_at_include/linux/page_ref.h

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



hi, Yang Shi,

On Wed, Jun 05, 2024 at 08:44:37PM -0700, Yang Shi wrote:
> Oliver Sang <oliver.sang@xxxxxxxxx>于2024年6月5日 周三19:16写道:
> 
> > hi, Yang Shi,
> >
> > On Tue, Jun 04, 2024 at 04:53:56PM -0700, Yang Shi wrote:
> > > On Mon, Jun 3, 2024 at 9:54 AM Yang Shi <shy828301@xxxxxxxxx> wrote:
> > > >
> > > > On Mon, Jun 3, 2024 at 7:02 AM Oliver Sang <oliver.sang@xxxxxxxxx>
> > wrote:
> > > > >
> > > > > hi, Yang Shi,
> > > > >
> > > > > On Fri, May 31, 2024 at 01:57:06PM -0700, Yang Shi wrote:
> > > > > > Hi Oliver,
> > > > > >
> > > > > > I just came up with a quick patch (just build test) per the
> > discussion
> > > > > > and attached, can you please to give it a try? Once it is
> > verified, I
> > > > > > will refine the patch and submit for review.
> > > > >
> > > > > what's the base of this patch? I tried to apply it upon efa7df3e3b or
> > > > > v6.10-rc2. both failed.
> > > >
> > > > Its base is mm-unstable. The head commit is 8e06d6b9274d ("mm: add
> > > > swappiness= arg to memory.reclaim"). Sorry for the confusion, I should
> > > > have mentioned this.
> > >
> > > I just figured out a bug in the patch. Anyway, we are going to take a
> > > different approach to fix the issue per the discussion. I already sent
> > > the series to the mailing list. Please refer to
> > >
> > https://lore.kernel.org/linux-mm/20240604234858.948986-1-yang@xxxxxxxxxxxxxxxxxxxxxx/
> >
> > got it. seems you will submit v2? should we wait v2 to do the tests?
> 
> 
> The real fix is patch #1, that doesn’t need v2. So you just need to test
> that.

we've finished tests and confirmed patch #1 fixed the issue.
we also tested upon patch #2, still clean.

our bot applied your patch upon 306dde9ce5c951 as below

5d45cc9b1beb57 mm: gup: do not call try_grab_folio() in slow path
fd3fc964468925 mm: page_ref: remove folio_try_get_rcu()
306dde9ce5c951 foo

on 306dde9ce5c951, we still observed the issue we reported. clean on both patch
#1 and #2

306dde9ce5c9516d fd3fc96446892528af48d6271a3 5d45cc9b1beb57386992c005669
---------------- --------------------------- ---------------------------
       fail:runs  %reproduction    fail:runs  %reproduction    fail:runs
           |             |             |             |             |
         47:50         -94%            :50         -94%            :50    dmesg.Kernel_panic-not_syncing:Fatal_exception
         47:50         -94%            :50         -94%            :50    dmesg.Oops:invalid_opcode:#[##]KASAN
         47:50         -94%            :50         -94%            :50    dmesg.RIP:try_get_folio
         47:50         -94%            :50         -94%            :50    dmesg.kernel_BUG_at_include/linux/page_ref.h


> 
> For patch #2, I haven’t received any comment yet and I’m going to travel so
> I’m not going to submit v2 soon .
> 
> And I heard if hugepd is going to be gone soon, so I may wait for that then
> rebase on top of it. Anyway it is just a clean up.
> 
> 
> 
> >
> > sorry that due to resource constraint, we cannot respond test request very
> > quickly now.
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > Thanks,
> > > > > > Yang
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Cheers,
> > > > > > > >
> > > > > > > > David / dhildenb
> > > > > > > >
> > > > >
> > > > >
> > >
> >




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux