From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f175.google.com (mail-pg1-f175.google.com [209.85.215.175]) (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 8DB2D3DB33A for ; Wed, 20 May 2026 11:28:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779276502; cv=none; b=BHU5Fh3RLDaPflc98VopdrAOAuBcRsU1QmLtkXqhTU14JtiPVEX5nz8okEJg3QmRH0zkW1/g7dytaG3JUBppNMnqnhLZ5LMvk5EfkSI3Z6MsZQVFbRTPsGC/wUyBHhzDu3HnygdJFFMY116kJ+jZpSorZE562z0BmibwUHA2jNQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779276502; c=relaxed/simple; bh=lSODUcihMPhasEzGYqEilcoX1z3BGVXfwHegaMftWQ4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KsKZYP/k5JUb9Bq/sqsZHo+3LA0gC/Fut6rYjsP1vZvMA8J9KsMSS3oxePjB4UyKch2dSOyL94UlAsFZ7mmckeu9HDbcBaQ0cN6+9Vs2CxaH3o4nhdtjEVCZi9I47Ljd1519DIKuNZxgpkC+iFtNHoGNLnd6Z3/N9R2kezy1lnk= 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=bsSpUs7w; arc=none smtp.client-ip=209.85.215.175 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="bsSpUs7w" Received: by mail-pg1-f175.google.com with SMTP id 41be03b00d2f7-c80227b1f6cso1805174a12.1 for ; Wed, 20 May 2026 04:28:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779276501; x=1779881301; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=DGlAMC0+vUyGnnTWD5G/AeIQvVwPR0Xnk62RWklWM+o=; b=bsSpUs7wvd/vutdN6d4WtYoGEymZXrI2syV7cSwqb8Pvs0dOSiuaFiWhM1KTqBPUTf SIVrn3GhHOped7ajDUn3WkMV0Kami7MMuOZUzB88QN0rQ9e4S2T5qXoZa+iaFJgI3XLC wPnHalz0j+QwGmsWs33csK0LTxVhRiC2K4C9BcJsa1s6XAW2kcHSRcvY6VoTK6ymA5kQ lwvBi418eY3UN+9XGzSiRxsbPcrU8eEtr7UgEDaqnwO6cL3bqoJekFvNG6H6RNCPcrK7 oPryB+HFQ2YhRqt0CNrFNFtFTOBuA4NzCW2s33+GdvYTP1gN1/qdX2P0bhUf1BqA/49W zCLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779276501; x=1779881301; h=in-reply-to: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=DGlAMC0+vUyGnnTWD5G/AeIQvVwPR0Xnk62RWklWM+o=; b=a2uMdlR+swKBhXx/Lc2Wpk3+NGehvUTmfQq+Zt3Mt9H68FLwQ2SMGSAPLxqLqnWI5G prNVhTwTDNbZrFHooe4xdvdMHCTnX7OblSIn6AeEopwAMrL006ud799+b4ECHr501pS7 3PIQ5GPMjQrGhVuPDMr+oe/uQ8GIyO2dY5uXsLy30tv+2J24EJeisRcRXxvUj5dP3Y6P cxG81h0I79Ar6pSmxQMVeIJ0sSb9H89933dd1EyBRG6DvknleOr//JHzvZ180VhQc5LJ 2b8X2v1ZwDHn1lch6PlOgZO1iorY8s4UREoWy44c9Qfm1b52/HheW9m3wBav9SRUDtxb OxoA== X-Forwarded-Encrypted: i=1; AFNElJ8YYVvmdYmlgfTDayPNZknB45szOOP8mfC7Z4PeeTVpDj5AchBDoJmgv6Wy5nUTStgoUcXikmTKbXe6Tao=@vger.kernel.org X-Gm-Message-State: AOJu0Yx1wgCNi1oX6N9YBZS3wQh9AcL2pIYNfknlAz5L8UN9p9MT8ToB V/8IHGVNRLjz/QfUWnMAqCBdQFnI7SaykKwdO40JbZ6gm0gpyRCPcGlT X-Gm-Gg: Acq92OHnglCyQXdaMkWANP2Tf3qd/1ulfp5MPzoMYSKSwdzO5yWAND4zlVukYYqSjS+ wqAax4fD5QW8jMnJaBF0Ix8mmeStBHfifFhYIeaRu969uAg6ZZ2AxNQJ+1pgE43jz0K0nAYWoBg 2Oueo5leBn7LXO+4wBK8Iypgl39EARSrVTiNv07zK097/gdHsm1NGsmk/RmDsUuEZy1qalnqyE3 bhX649LaRAhLWg0vJh1/PfMhntjryjC1WOtFR25F6eqTJWOmFFOjyCYYY51L1hnlwyXKxYNPqMZ A4zpeBKZv+FprpAO7cpVgG61ctRrIc3ywAqAe/Or6LLYlBtdZ3r9AbH6zuFB8kP3bRHcDQXwyfU JlWSjiFJEECCRjdhwkboc769tqmE2HJ9wuQsFzwTwAZHvSWotmFNIMrx57f7EU2YfHtRPKRmRI0 Cl5Rl7d5myxtCK9QppGlJykuGMceqDUsJBJQGRoSVk0eRknYpkHFVojA== X-Received: by 2002:a05:6a20:c31b:b0:3b2:924f:41e0 with SMTP id adf61e73a8af0-3b2924f447emr10563301637.3.1779276500695; Wed, 20 May 2026 04:28:20 -0700 (PDT) Received: from rigel (106-68-217-148.tpgi.com.au. [106.68.217.148]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c82bb0ff4easm18504863a12.18.2026.05.20.04.28.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 May 2026 04:28:19 -0700 (PDT) Date: Wed, 20 May 2026 19:28:06 +0800 From: Kent Gibson To: Bartosz Golaszewski Cc: Bartosz Golaszewski , Linus Walleij , linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] gpio: cdev: check if uAPI v2 config attributes are correctly zeroed Message-ID: <20260520112806.GA69947@rigel> References: <20260520-gpio-cdev-attr-padding-check-v2-1-0010daf8059f@oss.qualcomm.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=us-ascii Content-Disposition: inline In-Reply-To: <20260520-gpio-cdev-attr-padding-check-v2-1-0010daf8059f@oss.qualcomm.com> On Wed, May 20, 2026 at 09:42:10AM +0200, Bartosz Golaszewski wrote: > We check the padding of other uAPI v2 structures but not that of line > config attributes. For used attributes: check if their padding is > zeroed, for unused: check if the entire structure is zeroed. > > Fixes: 3c0d9c635ae2 ("gpiolib: cdev: support GPIO_V2_GET_LINE_IOCTL and GPIO_V2_LINE_GET_VALUES_IOCTL") > Signed-off-by: Bartosz Golaszewski > --- > Changes in v2: > - Make checking even stricter: check if padding is zeroed for used > attributes, for unused ones: check if the entire struct is zeroed > - Link to v1: https://patch.msgid.link/20260519-gpio-cdev-attr-padding-check-v1-1-a0c6d4a698bf@oss.qualcomm.com > --- > drivers/gpio/gpiolib-cdev.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c > index f36b7c06996d70b2286edbd181899e4c572b9086..edbcc86e4b26f88036ed12c13055bb2c371fb6a3 100644 > --- a/drivers/gpio/gpiolib-cdev.c > +++ b/drivers/gpio/gpiolib-cdev.c > @@ -1194,6 +1194,15 @@ static int gpio_v2_line_config_validate(struct gpio_v2_line_config *lc, > if (!mem_is_zero(lc->padding, sizeof(lc->padding))) > return -EINVAL; > > + for (i = 0; i < lc->num_attrs; i++) { > + if (lc->attrs[i].attr.padding != 0) > + return -EINVAL; > + } > + That works for me - the explict test against 0 makes the intent as clear as a mem_is_zero() call. For me anyway. > + if (!mem_is_zero(&lc->attrs[i], > + (GPIO_V2_LINE_NUM_ATTRS_MAX - lc->num_attrs) * sizeof(*lc->attrs))) > + return -EINVAL; > + Dislike the use of i here. lc->num_attrs would remove the implicit dependency on the preceeding loop. I'm also uncomfortable with the lc->num_attrs == GPIO_V2_LINE_NUM_ATTRS_MAX case as the pointer is out of range. The size is 0 so it probably wont get dereferenced, but just passing it around makes my skin crawl. Perhaps put the size in a var and only call mem_is_zero() if size > 0? Cheers, Kent.