Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: general protection fault in percpu_ref_exit
To:     syzbot <syzbot+fd15ff734dace9e16437@syzkaller.appspotmail.com>,
        bcrl@kvack.org, hch@lst.de, linux-aio@kvack.org,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        ming.lei@redhat.com, syzkaller-bugs@googlegroups.com,
        tj@kernel.org, viro@zeniv.linux.org.uk, vkabatov@redhat.com
References: <000000000000b1412b05b12eab0a@google.com>
From:   Jens Axboe <axboe@kernel.dk>
Message-ID: <165db20c-bfc5-fca8-1ecf-45d85ea5d9e2@kernel.dk>
Date:   Thu, 8 Oct 2020 19:23:02 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <000000000000b1412b05b12eab0a@google.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 10/8/20 2:28 PM, syzbot wrote:
> syzbot has bisected this issue to:
> 
> commit 2b0d3d3e4fcfb19d10f9a82910b8f0f05c56ee3e
> Author: Ming Lei <ming.lei@redhat.com>
> Date:   Thu Oct 1 15:48:41 2020 +0000
> 
>     percpu_ref: reduce memory footprint of percpu_ref in fast path
> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=126930d0500000
> start commit:   8b787da7 Add linux-next specific files for 20201007
> git tree:       linux-next
> final oops:     https://syzkaller.appspot.com/x/report.txt?x=116930d0500000
> console output: https://syzkaller.appspot.com/x/log.txt?x=166930d0500000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=aac055e9c8fbd2b8
> dashboard link: https://syzkaller.appspot.com/bug?extid=fd15ff734dace9e16437
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=119a0568500000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=106c0a8b900000
> 
> Reported-by: syzbot+fd15ff734dace9e16437@syzkaller.appspotmail.com
> Fixes: 2b0d3d3e4fcf ("percpu_ref: reduce memory footprint of percpu_ref in fast path")
> 
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection

Ming, this looks like a call of percpu_ref_exit() on a zeroed refs (that
hasn't been initialized). Really a caller error imho, but might make sense
to be a bit safer there.

-- 
Jens Axboe