Re: [syzbot] WARNING in unsafe_follow_pfn

[Jason Gunthorpe]

On Wed, Mar 31, 2021 at 07:29:22AM +0300, Dan Carpenter wrote:
> On Tue, Mar 30, 2021 at 07:04:30PM +0200, Paolo Bonzini wrote:
> > On 30/03/21 17:26, syzbot wrote:
> > > Hello,
> > > 
> > > syzbot found the following issue on:
> > > 
> > > HEAD commit:    93129492 Add linux-next specific files for 20210326
> > > git tree:       linux-next
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=169ab21ad00000
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=6f2f73285ea94c45
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=015dd7cdbbbc2c180c65
> > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=119b8d06d00000
> > > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=112e978ad00000
> > > 
> > > The issue was bisected to:
> > > 
> > > commit d40b9fdee6dc819d8fc35f70c345cbe0394cde4c
> > > Author: Daniel Vetter <daniel.vetter@xxxxxxxx>
> > > Date:   Tue Mar 16 15:33:01 2021 +0000
> > > 
> > >      mm: Add unsafe_follow_pfn
> > > 
> > > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=122d2016d00000
> > > final oops:     https://syzkaller.appspot.com/x/report.txt?x=112d2016d00000
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=162d2016d00000
> > > 
> > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > Reported-by: syzbot+015dd7cdbbbc2c180c65@xxxxxxxxxxxxxxxxxxxxxxxxx
> > > Fixes: d40b9fdee6dc ("mm: Add unsafe_follow_pfn")
> > 
> > This is basically intentional because get_vaddr_frames is broken, isn't it?
> > I think it needs to be ignored in syzkaller.
> 
> What?
> 
> The bisect is wrong (because it's blaming the commit which added the
> warning instead of the commit which added the buggy caller) but the
> warning is correct.
> 
> Plus users are going to be seeing this as well.  According to the commit
> message for 69bacee7f9ad ("mm: Add unsafe_follow_pfn") "Unfortunately
> there's some users where this is not fixable (like v4l userptr of iomem
> mappings)".  It sort of seems crazy to dump this giant splat and then
> tell users to ignore it forever because it can't be fixed...  0_0

I think the discussion conclusion was that this interface should not
be used by userspace anymore, it is obsolete by some new interface?

It should be protected by some kconfig and the kconfig should be
turned off for syzkaller runs.

Jason