From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.2]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 43D0BA2D; Thu, 9 Jan 2025 09:19:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.2 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736414400; cv=none; b=lFZM2uaI+mJrrnAVW242HGtVaYD/ZE3IemwvCn9cLb5ycm3dDppMx5YDvN6F2JVjqf43Nw36ZH+CM2IPddqUPZKmmVGP2nr0HiVLOlWyccOjKe0PgcMGr5ZOmxlYDQbM9PvvejER/Wq6hvlK+tNrD2aQXxYfQTMVrmt8iFBGVBQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736414400; c=relaxed/simple; bh=P3zlq4ygJF5FDTVCLeWZPwkLrLumivHFTcdRzR7n1zw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=UJyTjcO9PYIQzTcXDUE0vUbEDtvs4cY1UtnVF7siSeVHnAU88XSwg13XuajnK2FP5HZcnDO7HSnAjta2gEUMntm/xiDPq7Il/dYho7MS1kfuec3zqCGNPAp415F8PpykecMqr0wCTu8KnQor0J2Sqsa8bnu1uF9FRBxaNxdv4gY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=pGqniJnk; arc=none smtp.client-ip=220.197.31.2 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="pGqniJnk" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Message-ID:Date:MIME-Version:Subject:From: Content-Type; bh=5PLuhhtZ97rikCQogLx1vtpUFsvhxOgRrEPjxo8AgNY=; b=pGqniJnkG19u8sGJJX+P3wSSqUZKdpn7VfLpoNT3tAY2rRiGP0PQNjk1C1Ugxd SeM0VJIEypT1aIEy9sxl6wMQXl/NW2lJqwMXqDknjA9AtaboIXxjH9Bln6UYGYPR 8WX878coXguIkH/6MbBD3nVCuv9jTPB56yIZkH9vTdBYM= Received: from [192.168.174.52] (unknown []) by gzsmtp4 (Coremail) with SMTP id PygvCgC3w+2blH9nYovLEA--.32969S2; Thu, 09 Jan 2025 17:19:24 +0800 (CST) Message-ID: Date: Thu, 9 Jan 2025 17:19:23 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [v8] misc: pci_endpoint_test: Fix overflow of bar_size To: Arnd Bergmann , Niklas Cassel Cc: Manivannan Sadhasivam , =?UTF-8?Q?Krzysztof_Wilczy=C5=84ski?= , Kishon Vijay Abraham I , Greg Kroah-Hartman , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, rockswang7@gmail.com References: <96b3a0f7-f144-4f2a-9f84-82c31d8ec23e@163.com> <270783b7-70c6-49d5-8464-fb542396e2dd@163.com> <4bfb6c46-6f93-431b-9a8c-038bc7f77241@163.com> <7e025613-3516-4957-b83a-70b125a24fa7@app.fastmail.com> <2b6eabad-ebd1-4e7d-b4bf-6b818dfc20ac@app.fastmail.com> Content-Language: en-US From: Hans Zhang <18255117159@163.com> In-Reply-To: <2b6eabad-ebd1-4e7d-b4bf-6b818dfc20ac@app.fastmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID:PygvCgC3w+2blH9nYovLEA--.32969S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7uw4rCFWfCF1xAryrXw43Jrb_yoW8Jw13pF yxAF40kayDtry3JrZ29r4rZF4avrnrJ3y3uryrGrya9r90yF97AFW8KFWFka1DCr13Kw4F qr17JayfX39rAaUanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jSAp8UUUUU= X-CM-SenderInfo: rpryjkyvrrlimvzbiqqrwthudrp/xtbBDxHPo2d-iJak1gABsH On 2025/1/9 14:29, Arnd Bergmann wrote: >> On 2025/1/8 22:13, Niklas Cassel wrote: >>>>> Ok. Looking at do_div(), it seems to be the correct API to use >>>>> for this problem. Just change bar_size type to u64 (instead of casting) >>>>> and use do_div() ? That is how it is seems to be used in other drivers. >>>> >>>> I think using div_u64_rem() instead of do_div() would make this >>>> more readable as this is always an inline function, so the type can >>>> remain resource_size_t, and the division gets optimized well when >>>> that is a 32-bit type. >>> >>> After patch 1/2, we no longer care about the remainder, so I guess >>> div64_u64() is the correct function to use then? > > div_u64() is the correct interface here, div64_u64() is the > even slower version where both arguments are 64-bit wide. > >> >> drivers/misc/pci_endpoint_test.c:311:11: warning: comparison of >> distinct pointer types ('typeof ((bar_size)) *' (aka 'unsigned int *') >> and 'uint64_t *' (aka 'unsigned long long *')) >> [-Wcompare-distinct-pointer-types] >> 311 | remain = do_div(bar_size, buf_size); >> | ^~~~~~~~~~~~~~~~~~~~~~~~~~ > > You don't use div_u64() or div64_u64() here, do_div() is the macro > version that must be called with a 64-bit argument. > > Arnd Thank you so much Niklas and Arnd. Best regards Hans