From: Dan Carpenter <error27@gmail.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Haoxiang Li <haoxiang_li2024@163.com>,
marcel@holtmann.org, luiz.dentz@gmail.com,
yangyingliang@huawei.com, linux-bluetooth@vger.kernel.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v4] Bluetooth: virtio: Fix virtbt_probe() init and cleanup
Date: Thu, 9 Jul 2026 16:44:31 +0300 [thread overview]
Message-ID: <ak-lvwzHUfuFcRRa@stanley.mountain> (raw)
In-Reply-To: <20260709083606-mutt-send-email-mst@kernel.org>
On Thu, Jul 09, 2026 at 08:36:32AM -0400, Michael S. Tsirkin wrote:
>
> why make changes at all if no one can test. in fact, why have a driver
> then.
It would be interesting to see what proportion of kernel patches are
actually tested... Testing the code is often impossible because you
need the hardware.
In drivers/staging probably very few patches are tested. Every couple
years I look at the data from where the problems come from and it's
normally from complicated changes from the driver maintainer. The
number of bugs introduced by checkpatch and static checker fixes is
really tiny.
It's about risk vs reward. Fixing a security issue is a huge reward.
Cleaning up the code. Fixing obvious leaks and static checker issues.
Those things are all valuable because they raise the standards and
they prevent copy and paste bugs.
I consider a few things:
1. Is it a security fix? I recently fixed some memory corruption and
broke a driver. I tried to be careful, I wrote a long commit message
describing my thinking, but I still messed up. And that's okay
because fixing security bugs is important.
2. Is the code new? If it is then there are probably very few users,
and the original developer is still around so it's pretty safe to
change.
3. Is it an error path? Code on error paths is hard to test in the
best of times. The risk is very low.
4. Is the change small and obvious?
On the other hand, I often leave known bugs. In this case, we're talking
about a use after free if the driver fails to probe. That's not a
security thing. It's unlikely to ever affect anyone in real life. The
fix affects the success path so it could easily cause the driver to stop
working.
regards,
dan carpenter
next prev parent reply other threads:[~2026-07-09 13:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 11:47 [PATCH v4] Bluetooth: virtio: Fix virtbt_probe() init and cleanup Haoxiang Li
2026-07-09 12:28 ` Dan Carpenter
2026-07-09 12:36 ` Michael S. Tsirkin
2026-07-09 13:44 ` Dan Carpenter [this message]
2026-07-09 14:21 ` Michael S. Tsirkin
2026-07-09 12:35 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ak-lvwzHUfuFcRRa@stanley.mountain \
--to=error27@gmail.com \
--cc=haoxiang_li2024@163.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=marcel@holtmann.org \
--cc=mst@redhat.com \
--cc=stable@vger.kernel.org \
--cc=yangyingliang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox