Re: [Syzkaller & bisect] There is "try_grab_folio" WARNING in v6.3-rc2 kernel

[Pengfei Xu <pengfei.xu@intel.com>]

Hi Jason,

On 2023-03-31 at 09:24:42 -0300, Jason Gunthorpe wrote:
> On Wed, Mar 15, 2023 at 10:46:40AM +0800, Pengfei Xu wrote:
> > Hi Jason and kernel experts,
> > 
> > Greeting!
> > 
> > Platform: x86 platforms
> > There is "try_grab_folio" WARNING in v6.3-rc2 kernel:
> > 
> > All detailed info: https://github.com/xupengfe/syzkaller_logs/tree/main/230313_234302_try_grab_folio
> > Reproduced code: https://github.com/xupengfe/syzkaller_logs/blob/main/230313_234302_try_grab_folio/repro.c
> > v6.3-rc2 issue dmesg: https://github.com/xupengfe/syzkaller_logs/blob/main/230313_234302_try_grab_folio/eeac8ede17557680855031c6f305ece2378af326_dmesg.log
> > Bisect info: https://github.com/xupengfe/syzkaller_logs/blob/main/230313_234302_try_grab_folio/bisect_info.log
> > Kconfig: https://github.com/xupengfe/syzkaller_logs/blob/main/230313_234302_try_grab_folio/kconfig_origin
> 
> Do you have a syzkaller format reproducer for this? It is often
> informative.
> 
  Thanks for your suggestion! I will add the repro.prog for new report.
  Updated repro.prog in link: https://github.com/xupengfe/syzkaller_logs/blob/main/230313_234302_try_grab_folio/repro.prog
  I also new added machineInfo0, log0, report0, repro.report, repro.stats in
  link: https://github.com/xupengfe/syzkaller_logs/tree/main/230313_234302_try_grab_folio

> > If you don't need the following environment to reproduce the problem or if you
> > already have one, please ignore the following information.
> > 
> > How to reproduce:
> > git clone https://gitlab.com/xupengfe/repro_vm_env.git
> > cd repro_vm_env
> > tar -xvf repro_vm_env.tar.gz
> > cd repro_vm_env; ./start3.sh  // it needs qemu-system-x86_64 and I used v7.1.0
> >    // start3.sh will load bzImage_2241ab53cbb5cdb08a6b2d4688feb13971058f65 v6.2-rc5 kernel
> >    // You could change the bzImage_xxx as you want
> > You could use below command to log in, there is no password for root.
> > ssh -p 10023 root@localhost
> 
> These instructions did not result in a reproduction for me :(
> 
> Nor did the reproduction work in my usual test VM.
> 
> It must be timing sensitive?
> 
> The trace says it is touching a page with a corrupted refcount, which
> suggests a double free, but it is weird that it would trigger here and
> not at the point of the double free...
> 
> I don't have a guess what this is
> 
  Ah, seems to be related to platform independence, I can reproduce this
  problem on RPL-P platform vm in almost 3 seconds after executing bianry.

  And I could reproduce this issue on ADL-S vm in 3 seconds also, seems it
  could be reproduced on ATOM and big cores platforms.

  Thanks!
  BR.
> Jason