Re: [PATCH v4] Bluetooth: virtio: Fix virtbt_probe() init and cleanup

[Michael S. Tsirkin]

On Thu, Jul 09, 2026 at 04:44:31PM +0300, Dan Carpenter wrote:
> 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.

Sure I agree - if I am refactoring kernel APIs I would often
compile the driver and that is it.
But that is different from poking at a driver specifically.
If I do that then yes I expect the patch to be tested.



> 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.

Exactly, agree on all points.

> regards,
> dan carpenter