From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F1AA93B4EA9 for ; Tue, 26 May 2026 07:57:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779782223; cv=none; b=UQeQaAFUbv8vytsuj9QOvT+cfA3iRcwjcjuoslR+UyEyDGMK7q7DM9Gh/gBANOwC4hdc7VN173azLG8OdIVJFltQ2JiTivQMymmNYRmw74GoMIpnNnh/TP0GlXrZ+HxRlvIvSVvBHgSXz0PuprleAn2QnfjBQxgrezrzqTouCwI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779782223; c=relaxed/simple; bh=/PP9KzfPgPPYnf2CrAWDmtazkrFsrTswwQu774a4yhU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=VBHC+qdQkBIt4NigBUMjGpKNXMOEr+3EM2CB/84Q4zt19wFSx4LFrSnU8yQKK9AgBy1qWKSxxo/2G16p+orxC7bMKHuwqargMmcd+VH/x3BcDpcvu6gw3F7TtCBq+zmkW6Yp9aeoG0u75S4kYDNqvuM5a4Hi9R0fDnvSP5ZcmOI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=IgPyLX33; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=VH9/Lbkk; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="IgPyLX33"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="VH9/Lbkk" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779782220; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xY7mocn0KmK7ngWOScBkr1Rtj5DdaTsx0/KZ/kJfr9c=; b=IgPyLX33s/b/IOUvARHD0oXqIfJNxDFT/QeiDUJ+pfGayc/0Du3wQKoe9qVOpnz3dfovaZ +YbAcM01chNX8nEkQbZ485jRlhPDYlPE0Cd/chW+ygSBfpjC93AVNi8hvFKfcPn6SDBqkr R5vPj5qFA/Vd0uIq8VRQrdRCYui0AgQ= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-266-xp6n5SIKO-SyKbb_HDE4wQ-1; Tue, 26 May 2026 03:56:58 -0400 X-MC-Unique: xp6n5SIKO-SyKbb_HDE4wQ-1 X-Mimecast-MFC-AGG-ID: xp6n5SIKO-SyKbb_HDE4wQ_1779782217 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-4904ee02e72so25836555e9.1 for ; Tue, 26 May 2026 00:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1779782217; x=1780387017; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=xY7mocn0KmK7ngWOScBkr1Rtj5DdaTsx0/KZ/kJfr9c=; b=VH9/LbkkwS0NbcLcsLN7YRwBlTeWuxFwtIaKrqB79eMwECjIdNus0UxxWUecS2QfrG 6qsHfHvvlLq8YIaA94GjA0AG7pzaz9VS3RT6D8IuFT7D3XqN2qsSkn7t47HkKeyr8bPr LWqkRerrmpTh9Ltbi9L52Dce161lmnz0b///4udVT5xxGlfND8meHV6KeM3jT09feH0q mJu+ezHC6w/tPJny48v3Ej7WlrMMTVTOadmQXmBzOcFOzwkxrkbWjFwmiZ9OQNfV9qNs Eb2tcTX2jF6vZss7DD412m6GZAm6nJN5eIJKH0m5K5Fpun5S1acDVz6Ujr0XAm735mhA swnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779782217; x=1780387017; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xY7mocn0KmK7ngWOScBkr1Rtj5DdaTsx0/KZ/kJfr9c=; b=U58YxJva90dsfl7/MN6s0F0J/5CcCvBuueyUnUzhA8rr99UpYTP8GryCArp8sC72pX 2CrNobiAZoaljXuoDKU/Qd2bd7LLg7BOUIv8m8RyX492I2TbfPXLRK3sHfc3YY3ZEjvu qYk9gv5qf+s16kJeMcJ1tZdWaPKAX49TrBF09fwugMdI3tpn8Prmhr3qle51KheIHN5o XdpRzjvpb3WJkErDlLrjOvV0FFjVdva3TrVEJqay4uM/ff1YvfPrbgSe88u4JTKMrIvb 4yghOIoAuYogBncPF+jWq8rXRg8lid47MNaestJOxhf9U4ECB6uk/R2T93HBcFool5Bd UAJQ== X-Forwarded-Encrypted: i=1; AFNElJ8lH4p7T7TYhFpelfv88VFg3V7tbwltzFSRoXhEP8htb8RO7MDkmGWxVbpYO8qt97Tg2ROVBv4=@vger.kernel.org X-Gm-Message-State: AOJu0YzBoO5MAeQa1LDppxh6wMg8yneFduPRNovlSB/R4+KhS8ztVcql PobQPGObsxBtNW0hUXome+ACnuX0ZPnWwyGwWj27cP9VyH0nmGmSz5MUo9BFhmflI1GWgJTKslX j9bQjqBH1XkiaUVTvglXrkBGN//sYJiq3l7FDDZc8INh7ivwq7b/NTjwNmQ== X-Gm-Gg: Acq92OHOzi3ty0vXs5YVMXBFBdegDp451FxV0oVBPyKPSa/ZC71581z4wEZLA0AFde8 p6zixB13gpcmrW7a+9GV+7ekwdo0Mvc6AQl8SK9KLpGOXr51ewFkNtld4nwSEvOVmQoj1NcMbCj Bcub9o5nAK+PJ1qDOaR5kvs99kG7yiQ3NOKLqY98ElTHxtSYP9JKNRHuCPIe8tOVAVvBSSdKJ3w ahU0IMrET/xoRkdhf3jQ0tVxYnGnZFjjtwXjGEOkxrptTV3hGziNLKcTsQfn0Q7R8hLqNi+uEN9 zdYkf+u4J1H3cLEsjXvGoRASmMh5G6DptMJV7QdMl0ndClgJ70mv/WkuJdDORYO35/+OV5k27kB RoYp+d81532hI3rgmdLslR8Y9iBPZFlGngeOs42w78xGjIr65V7EOhNWhNA== X-Received: by 2002:a05:600d:8499:20b0:48a:5970:1fe1 with SMTP id 5b1f17b1804b1-4904248ad4cmr214893725e9.4.1779782217136; Tue, 26 May 2026 00:56:57 -0700 (PDT) X-Received: by 2002:a05:600d:8499:20b0:48a:5970:1fe1 with SMTP id 5b1f17b1804b1-4904248ad4cmr214893345e9.4.1779782216746; Tue, 26 May 2026 00:56:56 -0700 (PDT) Received: from [192.168.88.32] ([212.105.155.152]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-490454a0b82sm322436755e9.9.2026.05.26.00.56.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2026 00:56:56 -0700 (PDT) Message-ID: Date: Tue, 26 May 2026 09:56:55 +0200 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net] net/mlx4: avoid GCC 10 __bad_copy_from() false positive To: Tariq Toukan , Yao Sang , "David S . Miller" , Jakub Kicinski Cc: Andrew Lunn , Eric Dumazet , "Gustavo A . R . Silva" , netdev@vger.kernel.org, linux-rdma@vger.kernel.org References: <20260520102130.423044-1-sangyao@kylinos.cn> <31260e8f-15c3-4738-b5b6-67b0ea2d3b0e@nvidia.com> From: Paolo Abeni Content-Language: en-US In-Reply-To: <31260e8f-15c3-4738-b5b6-67b0ea2d3b0e@nvidia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/25/26 12:47 PM, Tariq Toukan wrote: > On 20/05/2026 13:21, Yao Sang wrote: >> mlx4_init_user_cqes() allocates a single PAGE_SIZE buffer and fills it >> with the CQE initialization pattern. When entries_per_copy >= entries, >> the function copies array_size(entries, cqe_size) bytes from that buffer >> to userspace. >> >> That copy is actually bounded by PAGE_SIZE in the else branch because >> entries_per_copy >= entries implies entries * cqe_size <= PAGE_SIZE. >> However, GCC 10 does not derive that constraint and falsely triggers >> __bad_copy_from() in mlx4_init_user_cqes(). >> >> Cap the single copy_to_user() length to PAGE_SIZE to make that bound >> explicit and avoid the GCC 10 false positive. >> >> Fixes: f69bf5dee7ef ("net/mlx4: Use array_size() helper in copy_to_user()") >> Signed-off-by: Yao Sang >> --- >> drivers/net/ethernet/mellanox/mlx4/cq.c | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/net/ethernet/mellanox/mlx4/cq.c b/drivers/net/ethernet/mellanox/mlx4/cq.c >> index e130e7259275..7b024a5e13c8 100644 >> --- a/drivers/net/ethernet/mellanox/mlx4/cq.c >> +++ b/drivers/net/ethernet/mellanox/mlx4/cq.c >> @@ -314,8 +314,11 @@ static int mlx4_init_user_cqes(void *buf, int entries, int cqe_size) >> buf += PAGE_SIZE; >> } >> } else { >> + size_t copy_bytes = min_t(size_t, array_size(entries, cqe_size), >> + PAGE_SIZE); >> + >> err = copy_to_user((void __user *)buf, init_ents, >> - array_size(entries, cqe_size)) ? >> + copy_bytes) ? >> -EFAULT : 0; >> } >> > > Thanks for your patch. > > This is a compiler issue. > Did you try fixing it there first? AFAICS gcc 10 is a supported version, the kernel should build correctly with it, right? Also AFAICS this is not fastpath so an additional check should not be problematic? Perhaps a warn instead would be more palatable? if (WARN_ON_ONCE(array_size(entries, cqe_size) > PAGE_SIZE)) // ... /P