Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp844448pxb; Thu, 9 Sep 2021 13:29:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzEcoK4CHubNFeVIXJ9DaZ9rb0ZoNpxQnpTSFGp96LulbGRF+Cba4rFmAkO57aaMTRfiNhh X-Received: by 2002:a17:906:4746:: with SMTP id j6mr5378539ejs.517.1631219390034; Thu, 09 Sep 2021 13:29:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631219390; cv=none; d=google.com; s=arc-20160816; b=oGw6+cIFXv1PNdlj2/Im/uGXZgd/TEIHYaDyr+U9TOlrrDbcaOXBI6AnBZAB/gVwRe U3nd8q9kRXVoumae3ckMHEzMmHrWUGUE3wLagmrNA/DquaDMCoh6X+FDS7zwwsmuOUoC LCIIXdtDl3wnyJ5mBfwwB+bPTqyIewZkpwVrTHh6U3IMXhqG5rBkDM16xtv5uxeRwHhC lgU5jRRcIuE7LT7qPHq7jW+KNgbxkJmliNwO4ZWy58KsdhzbQIZ9BkwpjebN51tVBNkR kqicik9WHmoFcN5VVELP9W/OOPBE94j3lx51M4FrzzO5NtdCIbYaPs65TSVG/3SNKi81 ooig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=kiRSdEGIwnNdp1hMVUncYSkrp1+bmoQ1/H/lLJ1GuAI=; b=dwgdid/bycG8Sl9w6ffDh9extE7H9HUrYLFtEosgjlIAoSOP95ivrXJH5WaUKFAcs7 1SIkueD0W6ijJQigiaJjGttj6JD4baTzvHqni5AJemXoz8noL+37Uzf2SCDnuJAAOXl4 XSqAFbnFREfBJ7AjafrylIJxBjSMcHN3k51V+Pp+QIITxCJlAM2ZYEpQYQoEr9gYAS8J szKH3eR1DkkeASJX4VBJ94dR7rAhlR77TQxmUyZNp69PaIerA0E0TulGIpzHgNX1nRZc OUjbw3jhCuWx4xpyAYVu0YBmitaaL3df/Ja55tIcEsX7S8s3AX88ZyJohxzKtOM8LHsx 7l2A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=1v3wdMHm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hq16si3073468ejc.653.2021.09.09.13.29.25; Thu, 09 Sep 2021 13:29:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=1v3wdMHm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242195AbhIIU3E (ORCPT + 99 others); Thu, 9 Sep 2021 16:29:04 -0400 Received: from mail.kernel.org ([198.145.29.99]:32908 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233423AbhIIU3D (ORCPT ); Thu, 9 Sep 2021 16:29:03 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 1F45F6054F; Thu, 9 Sep 2021 20:27:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1631219273; bh=fnkQqJX1niYT9H/+a/DbaGfg4H9TSYi5/PmDtGfAYlI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=1v3wdMHmHXPx0mm0Iv+Ti+xSLjrlUVq54qI/K7/iCGbcF+7jzjIfxiT1dWPKnFZS2 /Qw8w/OMqmCHdh90tTVnkg2cmFNO99csuW2dlqkXf6xmYx+JkHsU1YFlmb8Xmsb21Z 6Cj4vdNRLdPmF8vHasQYu+FzkMJ7J7xW7DK9zl/c= Date: Thu, 9 Sep 2021 13:27:52 -0700 From: Andrew Morton To: Kees Cook Cc: kernel test robot , Matt Porter , Alexandre Bounine , Jing Xiangfeng , Ira Weiny , John Hubbard , Souptick Joarder , "Gustavo A . R . Silva" , Dan Carpenter , linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH] rapidio: Avoid bogus __alloc_size warning Message-Id: <20210909132752.4bde36ccf50720e56160f00c@linux-foundation.org> In-Reply-To: <20210909161409.2250920-1-keescook@chromium.org> References: <20210909161409.2250920-1-keescook@chromium.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 9 Sep 2021 09:14:09 -0700 Kees Cook wrote: > GCC 9.3 (but not later) incorrectly evaluates the arguments to > check_copy_size(), getting seemingly confused by the size being returned > from array_size(). Instead, perform the calculation once, which both > makes the code more readable and avoids the bug in GCC. > > In file included from arch/x86/include/asm/preempt.h:7, > from include/linux/preempt.h:78, > from include/linux/spinlock.h:55, > from include/linux/mm_types.h:9, > from include/linux/buildid.h:5, > from include/linux/module.h:14, > from drivers/rapidio/devices/rio_mport_cdev.c:13: > In function 'check_copy_size', > inlined from 'copy_from_user' at include/linux/uaccess.h:191:6, > inlined from 'rio_mport_transfer_ioctl' at drivers/rapidio/devices/rio_mport_cdev.c:983:6: > include/linux/thread_info.h:213:4: error: call to '__bad_copy_to' declared with attribute error: copy destination size is too small > 213 | __bad_copy_to(); > | ^~~~~~~~~~~~~~~ > > But the allocation size and the copy size are identical: > > transfer = vmalloc(array_size(sizeof(*transfer), transaction.count)); > if (!transfer) > return -ENOMEM; > > if (unlikely(copy_from_user(transfer, > (void __user *)(uintptr_t)transaction.block, > array_size(sizeof(*transfer), transaction.count)))) { That's an "error", not a warning. Or is this thanks to the new -Werror? Either way, I'm inclined to cc:stable on this, because use of gcc-9 on older kernels will be a common thing down the ages. If it's really an "error" on non-Werror kernels then definitely cc:stable.