From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) (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 4D6A03955F3 for ; Wed, 3 Jun 2026 16:51:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780505497; cv=none; b=fH3ugDVIzifN1Y7df/C1/5FhAjKVkiky/YNLZ7ldqLBDl/rUxrUwJhPDlu++3CQsD5JQF4FIZ8WwVYXOA8erjca/OlrE3L4T7F8/GEUFb+nrbMRMf4QraLrdC5cjcGh4txU0d/B1JvqMnJHmci9YTJc1RxpV6NSRVcEyh0ZjE6w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780505497; c=relaxed/simple; bh=9zex/oZNw62OdeQiIgl4XFXCFGp0nqo8+vP08DCK6Z0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Iyw3NMYyeckkZLAPS6+Q7e3HHfw80H85vhXfeIzfRP7u4Fgum87E0gFpHMwcPhCcX+WdELaE9SfGucxxuwrz/HoA/PbdKnKHzI+V/dWFWUmb95KLrA+Kdlyvgzg3890ZVXYa6lLcVG9G2R5GBmigFlmZvgiAObjTo8FroZuyvPA= 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=U2o4IGrl; arc=none smtp.client-ip=209.85.208.43 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="U2o4IGrl" Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-68bd9fce347so10585006a12.2 for ; Wed, 03 Jun 2026 09:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780505495; x=1781110295; 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=tVUSNrgyJbcEG3S/mElelWcmLhgtsutmOseyskElsFw=; b=U2o4IGrlZguKkv9yhaElP/Qs72mYPMYPy+MnK9jUgQb1hSJd7bPg7tHQV8B8LBYUyb 7nnT0f3Ibhlug3sSXF3QXPE5LMcIUlM64Xu2N6WLkt5yFmTVpcVCm4Dwjrci9RbxJpbc P8S7gv+OrGZG8v4NBgzQ1673gLERdBoHpCfWYGDKY9zvtqS99m7IxAF7r5tNyLiXTfvd fJtR7M+Ek0Mnl6qq4/AS391oJxxOrGb8h2LCmEXGHKAaNy3OchTvaqS+y8Dg9NH4G5nn 9AFjX2L9PHCogUABiHRIptQT3LxYnTBUo/di7YsuM24oNh9Oi8vkUTSoq+sTZNKW2RmG 9uTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780505495; x=1781110295; 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=tVUSNrgyJbcEG3S/mElelWcmLhgtsutmOseyskElsFw=; b=iDy8oOT6lfJpK7ZHOxrnHttj8hACrH4jjimYwNabZrCFbDX/jQm/gX3BpZuIvObWks 0EXD+TVObEisbBu+x0hug9ThG1EHROhSdITwCoHWxpAOcWQadwxGb/HnRv0Lih6+qgAI kpL+8+8JGYaXsLwIPgaKcz1iAugOwVdJX93HXGQE9keg5qZn8VFBBDc3K8JJGmCk8Pve rUldmNoA4r09wsqNqzi6R5dbVBvvvrQRecm5U4ZRg9Mc1WJiIolZ+8Ltze56tPIIgQ+2 J58LEjmwpn1xGuPrwGHdcU25lAmR+XSdJXdHS9fZXO/PCUOOUfEBw9WhE0/KqIkU9Rhu fwIw== X-Forwarded-Encrypted: i=1; AFNElJ81NWFSThruz0mpxt/S0r0KqmDaqJOcqt9kMrl6iu2hFFuTAHNBpdO8oZTGFA08wgx+YeUyokzvvArNFO0=@vger.kernel.org X-Gm-Message-State: AOJu0YyrDkyFDgRqjdB8ogg6uMPOm10u6iJ9jKWr30X5s7zWTESnlQXf 9MdDxptvLYiS5H0RV5P3jORBnSl0shhnaX6ks5OXXB4NuZjT+TrBmCk1 X-Gm-Gg: Acq92OFn78LKmeB1cYe6pfiwngaCYHgyspZvJrux8GOPA1E+K9oi64DFIojRZJ2XPTz aZJe4LhR7sP0b8BFSKLRXT80xHrgrV7z592ArqFihZwIZK05/MECSyFMUXsFCMBJEr+pjrRndDP NP25gXAlMiMn6cZvT0LxOQODdhmEQ8PIkxF6BxNvmLT3j7FuD+3X131PTice2MhphHI5hjXnQBl 0a/BOtPWrWTA0Ec7NXwqgj0hsGFsq0Cd64Fjh8bELdBFcxXSqI6doh4nKw2tP3mtUNfzvoh09Go zMbFeqh3TDQX6UM7iGT4Pzo/xEuq/wolLe1zRjBDdTs+pcMSRikzvWy5zgcF6Ga1RFRDQ4d9oWc ESBV1+OKROL4Tj3IlVOGPAfX63N1r1Mu8g3PGdXZTGSkzepTuhFefaxKDbghtSpFwRlPwDrzM96 7E+6cFD6SPQwc6QMkxTh+g/H5mp40ugotJpkfFcUs3 X-Received: by 2002:a05:6402:249e:b0:68b:e0de:1386 with SMTP id 4fb4d7f45d1cf-68e714da6bcmr2214247a12.13.1780505494626; Wed, 03 Jun 2026 09:51:34 -0700 (PDT) Received: from localhost ([196.207.164.177]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-68e65027662sm1509422a12.11.2026.06.03.09.51.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2026 09:51:33 -0700 (PDT) Date: Wed, 3 Jun 2026 19:51:30 +0300 From: Dan Carpenter To: =?utf-8?B?Vm9qdMSbY2ggS3LDoXRrw70=?= Cc: gregkh@linuxfoundation.org, christian.gromm@microchip.com, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH] staging: most: video: Use min_t() macro for type safety Message-ID: References: <20260603131928.44274-1-vo.kratky@seznam.cz> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260603131928.44274-1-vo.kratky@seznam.cz> On Wed, Jun 03, 2026 at 03:19:28PM +0200, Vojtěch Krátký wrote: > Replace the open-coded ternary operator matching a minimum calculation > with the standard kernel min_t() macro. Because 'count' is a size_t > and 'rem' is a signed integer, comparing them directly introduces a > signed/unsigned comparison risk. Forcing both to size_t via min_t() > ensures safely typed comparison and fixes a build-time macro assertion. > > Signed-off-by: Vojtěch Krátký > --- > drivers/staging/most/video/video.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/most/video/video.c b/drivers/staging/most/video/video.c > index 04351f8ccccf..709f61ed0322 100644 > --- a/drivers/staging/most/video/video.c > +++ b/drivers/staging/most/video/video.c > @@ -178,7 +178,7 @@ static ssize_t comp_vdev_read(struct file *filp, char __user *buf, > while (count > 0 && data_ready(mdev)) { > struct mbo *const mbo = get_top_mbo(mdev); > int const rem = mbo->processed_length - fh->offs; This feels like an AI static analysis inspired patch. The concern here is that "mbo->processed_length - fh->offs" would result in a negative value. > - int const cnt = rem < count ? rem : count; > + int const cnt = min_t(size_t, rem, count); > > if (copy_to_user(buf, mbo->virt_address + fh->offs, cnt)) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ But if "fh->offs" is a crazy value then we're still using it here so it doesn't make sense as a real solution. So do some more analysis and figure out if the change is required or not and if it is then try to find a complete solution. These days we would tend to use minu() instead of min_t(), btw. regards, dan carpenter