[{"id":3686769,"web_url":"http://patchwork.ozlabs.org/comment/3686769/","msgid":"<20260505232704.A6F95C2BCB4@smtp.kernel.org>","list_archive_url":null,"date":"2026-05-05T23:27:04","subject":"Re: [PATCH v15 5/7] vfio-pci/zdev: Add a device feature for error\n information","submitter":{"id":93311,"url":"http://patchwork.ozlabs.org/api/people/93311/","name":null,"email":"sashiko-bot@kernel.org"},"content":"Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:\n- [High] UAPI structure `vfio_device_feature_zpci_err` uses non-portable bitfields and contains implicit padding, violating UAPI design guidelines.\n--\n\ncommit 9302e2545ccb75aab62ae8f60f8aba469ebfdf04\nAuthor: Farhan Ali \n\nvfio-pci/zdev: Add a device feature for error information\n\nThis commit adds a new device feature to expose zPCI platform specific error\ninformation to userspace. This allows userspace to take appropriate actions to\nhandle an error on the device and perform mediated recovery.\n\n> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h\n> index 5de618a3a5eee..3eead86a00ab2 100644\n> --- a/include/uapi/linux/vfio.h\n> +++ b/include/uapi/linux/vfio.h\n\n[ ... ]\n\n> +struct vfio_device_feature_zpci_err {\n> +\t__u32 feature_flags;\t\t/* Indicate future features */\n> +\t__u32 reserved1;\n> +\t__u32 fh;\t\t\t/* function handle */\n> +\t__u32 fid;\t\t\t/* function id */\n> +\t__u32 ett\t\t: 4;\t/* expected table type */\n> +\t__u32 mvn\t\t: 12;\t/* MSI vector number */\n> +\t__u32 dmaas\t\t: 8;\t/* DMA address space */\n> +\t__u32 reserved2\t\t: 6;\n> +\t__u32 q\t\t\t: 1;\t/* event qualifier */\n> +\t__u32 rw\t\t: 1;\t/* read/write */\n\nSince the memory layout, ordering, and packing of C bitfields are highly\ncompiler-dependent, could this compromise cross-platform ABI stability or\nbreak compatibility with other languages interacting with the kernel?\n\nUsing standard __u32 fields and bitmask macros instead might be a safer\napproach for a UAPI header.\n\n> +\t__u64 faddr;\t\t\t/* failing address */\n\nThe faddr member requires 8-byte alignment, but it appears to be positioned\nafter exactly 20 bytes of prior fields. Does this force 4 bytes of implicit\ncompiler padding before it?\n\n> +\t__u32 reserved3;\n> +\t__u16 reserved4;\n> +\t__u16 pec;\t\t\t/* PCI event code */\n> +\t__u8 reserved5[28];\t\t/* Allow for future expansion */\n> +};\n\nThe explicit data size of this structure appears to be 68 bytes, which\nwould force another 4 bytes of implicit trailing padding to align the 72-byte\nstructure.\n\nCould this implicit padding make ioctl size validation fragile?\n\nAdditionally, if the compiler fails to zero the implicit padding during\nstruct initialization with err = {}, is there a risk that copy_to_user()\nwill leak uninitialized kernel stack memory to userspace?\n\nUsing explicit reserved padding fields to ensure manual, deterministic 8-byte\nalignment could avoid these issues.","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=XqMFnjMS;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c15:e001:75::12fc:5321; helo=sin.lore.kernel.org;\n envelope-from=linux-pci+bounces-53813-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"XqMFnjMS\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sin.lore.kernel.org (sin.lore.kernel.org\n [IPv6:2600:3c15:e001:75::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g9F670ZDFz1yJx\n\tfor ; Wed, 06 May 2026 09:27:11 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sin.lore.kernel.org (Postfix) with ESMTP id 791323009383\n\tfor ; Tue, 5 May 2026 23:27:07 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 9EC801FB1;\n\tTue, 5 May 2026 23:27:05 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 7CA0A2139C9\n\tfor ; Tue, 5 May 2026 23:27:04 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id A6F95C2BCB4;\n\tTue, 5 May 2026 23:27:04 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1778023625; cv=none;\n b=Aa6VYffLCunDjyrtsc1z7UI+BYIdrxNrDsLglutS8Kq63sSrx+Fl7c+/3tdqYwFUYCar4OA7QCetf8k948RxgyNed+swJ1x2L9caxhtsyYdUiccu0ecKC2fX+askzfr1l81cpA1uico925kHPmOKi/LI3ph/bbOwy2hlJgE9tf4=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1778023625; c=relaxed/simple;\n\tbh=m0rd/ksG8t+ewlrpucAqM7DIqhPit9hbUkp2jzldRSo=;\n\th=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date:\n\t Message-Id;\n b=LOT2dCo8HgWGSzYnQi6SH5cLUZECn1/s06ZlzymkcdOGWAHrfaPmS6mP7r3BSKuozUWR9HNYspLtrdyD2MJAzYkAApfs5Bva7YQ0vsDNUPIR6Pm+X+laPDwC192/H3oLdM8QzUezNNYapsptJd6VNHai3sucB1WO2IP1/YT46Cg=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=XqMFnjMS; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1778023624;\n\tbh=m0rd/ksG8t+ewlrpucAqM7DIqhPit9hbUkp2jzldRSo=;\n\th=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date:From;\n\tb=XqMFnjMSHgCLgoH57GitSRF9gyWVBGqfCzl3KbTay5pl1Qb0zET4P33+MD+qC+3wP\n\t dItgB4CPPIXFii13AXFEn6mjweeKNznHPxpZ5OsXYkrpjmIw+lu4mEUiH3ZvXCMtUr\n\t wHVBs8up9UJGW2uboH9f6YOig1Ap6r5922/zgoZjfUcH9sNCAWp/AV+uIJJlQelkGC\n\t mg+hNjN3jApgWKbaJomfDPGBD/1nDDZ6qcltlMGlVl5yMW4RoBiOsolGwygXmDc4Py\n\t K7mzi/vhE5+KZRXEHvzWwKSI3/0Ai+AT+Rj+NRUX6p8LA3Ld/bh7Ybf3AXD21o8lUo\n\t ptTcr0bbcXdfw==","From":"sashiko-bot@kernel.org","Subject":"Re: [PATCH v15 5/7] vfio-pci/zdev: Add a device feature for error\n information","Reply-To":"sashiko@lists.linux.dev","To":"\"Farhan Ali\" ","Cc":"linux-pci@vger.kernel.org","In-Reply-To":"<20260505200510.2954-6-alifm@linux.ibm.com>","References":"<20260505200510.2954-6-alifm@linux.ibm.com>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"quoted-printable","Date":"Tue, 05 May 2026 23:27:04 +0000","Message-Id":"<20260505232704.A6F95C2BCB4@smtp.kernel.org>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":""}}]