From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (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 9C3502E282B for ; Tue, 18 Nov 2025 06:17:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763446650; cv=none; b=E4HfQfIRzd7EVohcL9dJCu1ISkhz/RjrGoT8Ao/WkzCiLdksw33VItKmzIfNdG6r1oUzXNfsezWRfiQEDHZ68lEPPgOI0Tnuq+isl9qHXp/FLPtPucbYjEG4XyU/z2ybAH3cZsxISl2I/J7l/gz+d6ikEBNmXOEwnCXE6f2K1Zw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763446650; c=relaxed/simple; bh=/Hl0SyaQKq7MXxmBS18GDEuFsU+H8ICOxIkyP0l5OZY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=r0oTHDAh9VUJuqa4AySuelWDGrG1K0nZD773nXGcDwIIL8K3nya8HvxnjrlUv1hoDvEQEMg7P63RtPZfXP73m+NNsBigmH6QKvYAcAlrl6NIeMxCVy9NH9GPSGqKmTa6WEhRSAbOT+j1sGzZ+BXbrOk/zd6gROL4UWk7CYR8Pcs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=DhmQmLK6; arc=none smtp.client-ip=209.85.221.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="DhmQmLK6" Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-42b32900c8bso2869920f8f.0 for ; Mon, 17 Nov 2025 22:17:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1763446647; x=1764051447; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=QhKA75k+Zw8gzay9nDZLfcMI74InQfiHryR7d9dLK1M=; b=DhmQmLK6AWNEsu7r05+MZ635VhN6qeYrE4d3TgvPnFc7dsB+PTnK0LW/oQD0jAi9Gk HWPcM3lyh+LNmPtNCpofdLt21D3GtDe4Gp4l/RTiXgOl+xHbmeZFHXVlATlT3f4mwNBC 6Bf7t+MkpUkNv94vnml+P5EorrjMCKnMX/EPIJdroJKhBDmv2xBagb0Ae3o7f5up54w3 WuPLiUgC93bb94CWlXNAf38w7snkPcpQgQTHTW/XEVnaZaCtZGVx5H/ba+B1zymN67vF uHgmPwRkGPf1AIdYlID5to+RNmprixTMJD5na/dsVWAtbxCoWhLWDOIZ6JIwF4XzIBX7 68Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763446647; x=1764051447; h=in-reply-to:content-transfer-encoding:content-disposition :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; bh=QhKA75k+Zw8gzay9nDZLfcMI74InQfiHryR7d9dLK1M=; b=SGFQx8DDHg7TW58XytVhXpsGZ7616tX2cfrL0QbxFIdqJEsQl8v/QKmotOMwxzBE9K t4LgKhDCen7RY7Fi8ZEdURrloe1/Y8NcR0nzTrwTUleV52DfW29jo/ITwsP/AwwygQ3a DWPxeghkXQxKm8+ssv8Agvcq4prdmPHsZ+s10g0q7SUCZdlE+6nbP8BqzfUu2DKPahxg 5FbSorP9HfzX23BtzYxEWrWI5xsazD0WkeJGBAlF4d/F/QGlFD3jsibjLceHIj8Vm7zz Kos1vPMpTUvYrcFVHBcV6B5CIroFNmK+oAuJ7N37C5+0LikavqMB4VrygeXl72C24XE+ YIjg== X-Forwarded-Encrypted: i=1; AJvYcCXXMSLoceNTJ6btwU+yn09z+vLBGdJa94VcmXWEEAw1rVz9157tnISKoe8+3aafxddZYMDGmOPhaejn6wo=@vger.kernel.org X-Gm-Message-State: AOJu0YyHrhAR0bfjQ6w7Xe98ScmI4ZOlMBj8OXKnZ9lFPB5oS2/HRl2g QvyvJJhh9OcCQcO15v7Uc/VxrFOryqpYGv3al9MjmYhyT87Wg4xJHhF45IhlEGrct6E= X-Gm-Gg: ASbGncvxZWHcBMh3ElgHrHXVjuSLWWu13kZwLI84CJrZHyVWwuXUU7Owc2/ZUe+wihI ehuFC2WhmgC719n4EEludtzD9EtT3Pm34vr1oVT4sRZ4Y9rwALo/lx0Y9Y8aHPkH1DlgM0vlaU7 yHiYmA9v5Sd7juIgQqb0CeI9DJZgs/A/KzjECPY6oKjDnCXabU8Q+5eYjapp0KqIWNwgimEyD4U pG30+LCnkpObLvAKyC+4eAtUqn7BTl6avCGaOTuodZ1GxX5oAkI8kEaNsHhn032QbOHyAoAnGlt jlih6jlty42RS1Al9MTBRJ40NPq7I3UmD9NfSmywFro4hxF8MnLyAhiXnOC0QWf/Pmq63aT88QD w3TxT1JhVhMXL4QCGd6BOAkNijgsNtWdO56YBIcXEfBdPmwfmyCxxFTsWUoX6MWV/ogVOLxpt4K ITwrwjaQ== X-Google-Smtp-Source: AGHT+IEHpZGS4hYZGqTOsvKogsPZXoWir9+8fCWoV/jfwArZND55RBtGjjXc5CkVEdyW6tfv9aqUsw== X-Received: by 2002:a05:6000:1a8d:b0:42b:3746:3b86 with SMTP id ffacd0b85a97d-42b5938aab5mr15512287f8f.54.1763446646736; Mon, 17 Nov 2025 22:17:26 -0800 (PST) Received: from localhost ([196.207.164.177]) by smtp.gmail.com with UTF8SMTPSA id ffacd0b85a97d-42b53f0b62dsm30231845f8f.24.2025.11.17.22.17.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Nov 2025 22:17:25 -0800 (PST) Date: Tue, 18 Nov 2025 09:17:22 +0300 From: Dan Carpenter To: James Bottomley Cc: Ally Heev , "Martin K. Petersen" , linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] scsi: fix uninitialized pointers with free attr Message-ID: References: <20251105-aheev-uninitialized-free-attr-scsi-v1-1-d28435a0a7ea@gmail.com> <6d199d062b16abfbf083750820d7a39cb2ebf144.camel@HansenPartnership.com> <407aed0ff7be4fdcafebd09e58e25496b6b4fec0.camel@HansenPartnership.com> 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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, Nov 06, 2025 at 11:06:29AM -0500, James Bottomley wrote: > On Thu, 2025-11-06 at 17:46 +0300, Dan Carpenter wrote: > > On Wed, Nov 05, 2025 at 10:32:19AM -0500, James Bottomley wrote: > > > > > > diff --git a/drivers/scsi/scsi_debug.c > > > > > > b/drivers/scsi/scsi_debug.c > > > > > > index > > > > > > b2ab97be5db3d43d5a5647968623b8db72448379..89b36d65926bdd15c0a > > > > > > e93a > > > > > > 6bd2 > > > > > > ea968e25c0e74 100644 > > > > > > --- a/drivers/scsi/scsi_debug.c > > > > > > +++ b/drivers/scsi/scsi_debug.c > > > > > > @@ -2961,11 +2961,11 @@ static int resp_mode_sense(struct > > > > > > scsi_cmnd > > > > > > *scp, > > > > > >   int target_dev_id; > > > > > >   int target = scp->device->id; > > > > > >   unsigned char *ap; > > > > > > - unsigned char *arr __free(kfree); > > > > > >   unsigned char *cmd = scp->cmnd; > > > > > >   bool dbd, llbaa, msense_6, is_disk, is_zbc, is_tape; > > > > > >   > > > > > > - arr = kzalloc(SDEBUG_MAX_MSENSE_SZ, GFP_ATOMIC); > > > > > > + unsigned char *arr __free(kfree) = > > > > > > kzalloc(SDEBUG_MAX_MSENSE_SZ, GFP_ATOMIC); > > > > > > + > > > > > > > > > > Moving variable assignments inside code makes it way harder to > > > > > read. Given that compilers will eventually detect if we do a > > > > > return before initialization, can't you have smatch do the same > > > > > rather than trying to force something like this? > > > > > > > > This isn't a Smatch thing, it's a change to checkpatch. > > > > > > > > (Smatch does work as you describe). > > > > > > So why are we bothering with something like this in checkpatch if > > > we can detect the true problem condition and we expect compilers to > > > catch up?  Encouraging people to write code like the above isn't in > > > anyone's best interest. > > > > Initializing __free variables has been considered best practice for a > > long time.  Reviewers often will complain even if it doesn't cause a > > bug. > > Well, not responsible for the daft ideas other people have. > > However, why would we treat a __free variable any differently from one > without the annotation? The only difference is that a function gets > called on it before exit, but as long as something can detect calling > this on uninitialized variables their properties are definitely no > different from non-__free variables so the can be treated exactly the > same. > > To revisit why we do this for non-__free variables: most people > (although there are definitely languages where this isn't true and > people who think we should follow this) think that having variables at > the top of a function (or at least top of a code block) make the code > easier to understand. Additionally, keeping the variable uninitialized > allows the compiler to detect any use before set scenarios, which can > be somewhat helpful detecting code faults (I'm less persuaded by this, > particularly given the number of false positive warnings we've seen > that force us to add annotations, although this seems to be getting > better). > > So either we throw out the above for everything ... which I really > wouldn't want, or we enforce it for *all* variables. > Yeah. You make a good point... On the other hand, a bunch of maintainers are convinced that every free variable should be initialized to a valid value at declaration time and will reject patches which don't do that. I see checkpatch as a way of avoiding this round trip where a patch is automatically rejected because of something trivial. The truth is that the cleanup.h stuff is really new and I don't think we've necessarily figured out all the best practices yet. regards, dan carpenter