From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4DE9B45A2A; Wed, 25 Sep 2024 17:47:46 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 37B674025D; Wed, 25 Sep 2024 17:47:46 +0200 (CEST) Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by mails.dpdk.org (Postfix) with ESMTP id 72279400EF for ; Wed, 25 Sep 2024 17:47:44 +0200 (CEST) Received: by mail-qt1-f169.google.com with SMTP id d75a77b69052e-458362e898aso55002621cf.0 for ; Wed, 25 Sep 2024 08:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1727279264; x=1727884064; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=+3AdiF6OIjBBo4KEZ9gD9yNo3uYIgJgVRJj96IkzGbU=; b=RFLKu0yYjvwlJRBGeeAP9w5P18wrFyt3kcB1p3oe3wJjcqXCkhbmWYLcbxRGvkFyKG /sq1KS7uu1ABb8jjFaL4ZVCXqSzXJ/jlLaACe8eoYwwpI5OEoOJZcKBAsOYOfhFxwbOf EIPlK++50GchK947j+H9hZFKsWGHZcaOmvdlcZASHXGK0dVsQobaZuJCKvy/l92zoFxP LLk5xnCL3zwqBwJunBrxtBS9a5N6xT/YPjZqYmAfBBEReqgc4HFj4VumdznjlX+PAKY/ 0lByCotcZdJZJwbyrbuGP4u9qgYNQvbMjG+S/BtBUtHcGAz8nfyxUM0tMl4kDN+cRaHm ibNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727279264; x=1727884064; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+3AdiF6OIjBBo4KEZ9gD9yNo3uYIgJgVRJj96IkzGbU=; b=hdah6fNo8TU6BxEWNvrABkNYPmG1acrKcY41b4YbP/Xu8ozY9qlgQ0+c/6aEItelTS bw+KHIVyH+UMyOcPs4Ccfg+Bmpspbk6R46hO0kMGBIPja031+RKb4OFbtxkzT7p2pnF6 zFxPNiMPZjVjBfHB0byB7PUu0W6s+96L26uIMoaWl4vAiFuAWo+QRx7qKQc9jKbbewU1 xmgFaOs7Sfd5cbs5M+voF/OAt0bP6hoFeqFp8js1oURiaZNjkmsUB/MptO/aQEGHe3g0 PRePjkSylZ43UvmOS2z8fLItNN3TqugGA6H35fKBcJEe+WTIhQKyuk+A2ANQC5wE7JGL eqEw== X-Gm-Message-State: AOJu0Yw7z7h1lzMnAY/MERf0gJves5AXI1gRvBkCB9wGdXlmay+TMKg+ EnfXYkuge94JKAH4/7E0wVb8ZCqXZrLWGvfl9O0dHf8DpFHqZq5v5uwu6/xICHs= X-Google-Smtp-Source: AGHT+IHsL77fJZ3jQW1UGflo0Ytj+XLw+dyVbuAYnq/Xg7jZ2o5gEVcTp+eSzU14RxXhsD3ZgASFuA== X-Received: by 2002:a05:6214:468c:b0:6c7:bad5:61dd with SMTP id 6a1803df08f44-6cb1ddb5319mr43771236d6.36.1727279263725; Wed, 25 Sep 2024 08:47:43 -0700 (PDT) Received: from fedora ([173.242.185.50]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6cb0f4bf5adsm17351286d6.41.2024.09.25.08.47.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Sep 2024 08:47:43 -0700 (PDT) Date: Wed, 25 Sep 2024 08:47:41 -0700 From: Stephen Hemminger To: Robin Jarry Cc: dev@dpdk.org Subject: Re: [PATCH dpdk v2] mbuf: fix strict aliasing error in allocator Message-ID: <20240925084741.60852bd6@fedora> In-Reply-To: <20240925154053.80861-2-rjarry@redhat.com> References: <20240925140021.46320-2-rjarry@redhat.com> <20240925154053.80861-2-rjarry@redhat.com> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.43; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Wed, 25 Sep 2024 11:40:54 -0400 Robin Jarry wrote: > From: Robin Jarry > To: dev@dpdk.org > Subject: [PATCH dpdk v2] mbuf: fix strict aliasing error in allocator > Date: Wed, 25 Sep 2024 11:40:54 -0400 >=20 > When building an application with -fstrict-aliasing -Wstrict-aliasing=3D2, > we get errors triggered by rte_mbuf_raw_alloc() which is called inline > from rte_pktmbuf_alloc(). >=20 > ../dpdk/lib/mbuf/rte_mbuf.h: In function =E2=80=98rte_mbuf_raw_alloc=E2= =80=99: > ../dpdk/lib/mbuf/rte_mbuf.h:600:42: error: dereferencing type-punned > pointer might break strict-aliasing rules [-Werror=3Dstrict-aliasing] > 600 | if (rte_mempool_get(mp, (void **)&m) < 0) > | ^~ >=20 > Avoid incorrect casting by using an inline union variable. >=20 > Signed-off-by: Robin Jarry Thanks, union is safer than cast. Reviewed-by: Stephen Hemminger