From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oa1-f50.google.com (mail-oa1-f50.google.com [209.85.160.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6C1E82F549F for ; Thu, 9 Jul 2026 13:44:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783604680; cv=none; b=A/6jmZQ6CY54mlFVr+LkXX05wgsNYiS5+7fbn216snDVeQEJr1oON2BrgYPImKh9gIkGrQZ+sDMmD5cY8QFPSQGQTRXes9vQAm39gAmQa6tAqChbWZFImpqbeItdTmwVCs/riSzzdhwGZIdQmSVJM07CVE8gWIrGdgmcbndJk5E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783604680; c=relaxed/simple; bh=+e3rLnCPnclexU/TGq7To9ayodC+7dNeuVtCBIYlwpI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MNLagb9sjmsesxQFkureWpzlMEqoyAG6sPgE5QOW09TMM2ObtJojeFUBazQuMQVamUI9c6WmxP6L9g8eDtnSdKTkNNWOmatEMrUKeewCd17w8EsaDRrX4zR3YOd1+hIS55MmIem8gH2R9CvnLKmsRTqQYHpuwD0lyi5YHpTSFDk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=dPpD5sMT; arc=none smtp.client-ip=209.85.160.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="dPpD5sMT" Received: by mail-oa1-f50.google.com with SMTP id 586e51a60fabf-448cf99c133so805895fac.1 for ; Thu, 09 Jul 2026 06:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783604678; x=1784209478; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=7dGLWuFqFGELNIvjyOuEZBSnAuzpWLyUsbUpEnwxx1M=; b=dPpD5sMT4Uhem8FljfUpzaVxwWwcyJx4IU2C0jYPgDcK0NUcmwvVC30xi7VQ/eBLzB +ijSx//CSzntCqJGmSON5MhvF1c7EipZsLfNKyCEBTir94UL1PS9cTlthw6wUE8VilqG Zo8jXjNDrRgFQcZV5CLZfVOHgpL0czm6iVChspTdlV2J3Toc/EK8LX446b3r+7uE00ed vcDEZ07bp+NHGUz9OjJqYJ/OUepiM8ygg0g25WnH/YA76ooWCvGseyEAlLW6ag5SZucQ usQHX1W0dIbUBceFeN+pqkYdPwnWMF7wME/IgNl8UXIBxzXB2gsc90DfU3KuyOlrY/ZL Z0qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783604678; x=1784209478; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=7dGLWuFqFGELNIvjyOuEZBSnAuzpWLyUsbUpEnwxx1M=; b=tCm/dtzGjruzaIBbmRRJnKYLhhigsBvqWBtoTO3qVtgOTlXLqtP51e6n4RuJIbdn3s ZJ/uCUMBAKhWlbSM0sE3ee4KxoEIW+gVrpPDk6v3NwLVUgLmmwSlDlqeZlON9zFIJ/SZ ZcrnZ3KZXz5oIXIe1bqyjy2jPT/UHpgUJ8m+M+HSaWGFKYyfsLEYK6Vj5FTG/4/YKx4k E180pvngEGP6pdtVFufCNd0jJnqvRDRpphfh88iom+qiJeDvV/3gpfSRZeeVvVcfnDJR C49a2WyoR7JIRiASbdohMAkz59c05Z6Iy1ZXMiopeulAI3rk/ezYwq7OliDwbz+sYunL 7S/w== X-Forwarded-Encrypted: i=1; AFNElJ9A1S6j/45OhiLqzvS7wScy4niyZlAkwOpMkxWONJpUtvbQnFpKb5totQ8pTeCB/txyRZlQqSYVt8AFBHc=@vger.kernel.org X-Gm-Message-State: AOJu0YzVusZ4GyHVTBeG8zp/xvEGuT/Dx7jtgV00DxyyVsaJqPF+OC1g zZghL9YHGR1IRRDdWsyAEp2a9kwHAnpzZ97poqD0haY8YNgpOTj7ahx/ X-Gm-Gg: AfdE7ckhlXqL2sGsuXpITpLsDNUaUUqmOd04XPIdlSp8Qj0MHyE9t68VXaAVnGwCJge /csINvJ6du5GwmyoVwmFZqOl5Yp1NBa8oURv6Ws3he7q5OS+xBhofT6sVcuW53zcY23adS0lx8R V8Z2OIJGH0mfcqsNKPpVwxra8wGLTnbe4y5RQt3umg5YxpaCuhG9SG3rmkKp7B/zuSanl1U5Nx2 C+plqikz7X/A2ecfqrtg3XPwSRg0DAHelHxkIWyNHeRLjFi+k8WEKWpz2byR22ZA+O53TW4OAb/ rL7sNNDmdSFEKv48B/APz7pKR9KAques0nvpvHd/opbeQwCzJgSoApdLO+a77KmVFDtVkVJ0kOt wkrssTpCobNG3ObuadXwc9xsMkUEXApMfNLvFW5cvTBGgZE+1OOSjMPIiZ3VXCOLc5fWCuJgOqx tN2UEnSnN0qb0ASUU= X-Received: by 2002:a05:6808:4f0e:b0:495:ca1b:7865 with SMTP id 5614622812f47-4a34d9c8f64mr3213817b6e.11.1783604678277; Thu, 09 Jul 2026 06:44:38 -0700 (PDT) Received: from localhost ([74.80.182.70]) by smtp.gmail.com with ESMTPSA id 5614622812f47-4a1adca6bedsm3836998b6e.8.2026.07.09.06.44.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jul 2026 06:44:37 -0700 (PDT) Date: Thu, 9 Jul 2026 16:44:31 +0300 From: Dan Carpenter To: "Michael S. Tsirkin" Cc: Haoxiang Li , 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 Message-ID: References: <20260709114745.4030794-1-haoxiang_li2024@163.com> <20260709083606-mutt-send-email-mst@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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