Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 31 Jan 2020 13:16:44 +0300
From:   Dan Carpenter <dan.carpenter@oracle.com>
To:     Hillf Danton <hdanton@sina.com>
Cc:     gregkh@linuxfoundation.org, Alan Stern <stern@rowland.harvard.edu>,
        syzbot <syzbot+1bc2c2afd44f820a669f@syzkaller.appspotmail.com>,
        andreyknvl@google.com, ingrassia@epigenesys.com,
        linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
        syzkaller-bugs@googlegroups.com
Subject: Re: [PATCH] usb: core: urb: change a dev_WARN() to dev_err() for
 syzbot
Message-ID: <20200131101644.GE11068@kadam>
References: <00000000000095e1d8059d4675ac@google.com>
 <20200131090510.7112-1-hdanton@sina.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200131090510.7112-1-hdanton@sina.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Jan 31, 2020 at 05:05:10PM +0800, Hillf Danton wrote:
> 
> On Fri, 31 Jan 2020 08:06:52 +0300 Dan Carpenter wrote:
> > We changed this from dev_err() to dev_WARN() in commit 0cb54a3e47cb
> > ("USB: debugging code shouldn't alter control flow").
> > 
> > The difference between dev_WARN() and dev_err() is that dev_WARN()
> > prints a stack trace and if you have panic on OOPS enabled then it leads
> > to a panic.  The dev_err() function just prints the error message.
> > 
> > Back in the day we didn't have usb emulators fuzz testing the kernel
> > so dev_WARN() didn't cause a problem for anyone, but these days the
> 
> Another free option is perhaps to keep the devoted bot agile if it's
> difficult to list anybody who was mauled by its articulate reports.

It's difficult to parse this email.  I get that you're being sarcastic
but I can't tell what you're being sarcastic about.  :P

I think you're basically saying that syzbot should maintain a white
list of ignored Oopses.  There are two problems with this:  1) Other
people run syzbot so everyone has to run into this bug and then add it
to their own white list.  2)  If the kernel OOpes here then we cannot
test what happens next so it could be hiding bugs.

One idea is that there could be a kernel function which generates a
stack trace but is not an Oops.

regards,
dan carpenter