From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-17.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,MSGID_FROM_MTA_HEADER,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1CDC6C433DB for ; Tue, 23 Feb 2021 21:53:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6FA4564EC8 for ; Tue, 23 Feb 2021 21:53:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6FA4564EC8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=oracle.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0120D6B0005; Tue, 23 Feb 2021 16:53:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EDE4E6B0006; Tue, 23 Feb 2021 16:53:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D58A28D0001; Tue, 23 Feb 2021 16:53:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0007.hostedemail.com [216.40.44.7]) by kanga.kvack.org (Postfix) with ESMTP id B6FC66B0005 for ; Tue, 23 Feb 2021 16:53:09 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 7796E9409 for ; Tue, 23 Feb 2021 21:53:09 +0000 (UTC) X-FDA: 77850883698.08.3E8DC81 Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) by imf29.hostedemail.com (Postfix) with ESMTP id AE99CF4 for ; Tue, 23 Feb 2021 21:53:08 +0000 (UTC) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 11NLnFmX147402; Tue, 23 Feb 2021 21:53:06 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2020-01-29; bh=Bn6T1qCzL0/Iiy8B7qkVxUCQealFvCxFzmG4GxeXiEw=; b=V48QoCCICxe8NuL0fBcCFC08xdOTIO0D+ZoLcHyw2rn2PHWhk9LSE/Y/a2i6izDulTo5 sRqoGeJoU/khojJKibxiwcYClmY/sk+WWHb3FW+DuAWHDyQctzLlvlTzgLRkkD/RQAA3 f6bEZqrLK+TtUeYJtnsZWOpXMRiR+J/jOVrDY5Y06nlBZXafHbvxv/ZLVQElIw+wr1pA xl2CWx3U8teeKUMQdxcNpsfuwFYJ188uWuwBaZbW4TO8gQuI0FGROlmnvn91odKl7Ukp okLu752iaI5lcSoZ11pWEfBd344zwKFAkgn4cPk2vrQ6B9VZBulhZ6oGFB32lGkyWVYL DA== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 36tsur10rf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 23 Feb 2021 21:53:06 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 11NLobRU113555; Tue, 23 Feb 2021 21:53:05 GMT Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2103.outbound.protection.outlook.com [104.47.58.103]) by aserp3020.oracle.com with ESMTP id 36ucayy0m8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 23 Feb 2021 21:53:05 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SmV3KNAbqs3LvPskxxq9Zxjh+JP89SMVbmf7AH2pmMD7MW2X5KmmcAU1fxASXdEpiWz8fobB1JBF/xK8WjGXwLCzI0RPeb/zzx3OlOAIa/HS1xf4lJw60kWntKhkQXi+r9ekXPQESOTa+R7whfREaM4rxyu6CFJ0ee5avjqGtdsRB/sSpkmPMgAsjRXoC7CdKeNliWT3SXplMe/X8e6ESGk/gFNjy3JizaPNowNr0kMWFUS6GZ7FER0R76dKyN5t+EESCUVdxeH+IYLg4RzX5Ka7LM31+sJ+YiCGx0PPbFSdJR/+8DhSvFyWTDEJytpZijH4qzvN7/ZlDuxh6RsyJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Bn6T1qCzL0/Iiy8B7qkVxUCQealFvCxFzmG4GxeXiEw=; b=kjZ29272JMLwYg3rAQCg0j2xAwd495cyYwIAytS1gWguSdA4PROEtvcy5/N2F7bjMGByADL0f0hfV8HZnMDcAvscY+f/Hx8vlB2dhLHtH1f3CvsHtnkaP8XbbFgMV0jQeE+XOiIflAkOAmjZpmbRG6fmlzDltPxcgGPNz8+iPHBvcjQ4bRNlUTVNvr421lJP9/oyKgAAtyk57CmuKHcc8anlN2hNlfOwub78XTxzH5zCs1LwSEsAWSDO/QQ7w2yo4a/LqOUqjwIfzdcjlUXc6CTf3rpYjTtz19ToVB0kt+uKcOaUIEdkTO2y6XSaI98eaZvt4GuL5iD1l2mAf4ETIg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Bn6T1qCzL0/Iiy8B7qkVxUCQealFvCxFzmG4GxeXiEw=; b=YbQFzvJIF2HK0fYT4QAZeMXo7jjIC8wAr6WSbxl+JXBBBRmoNsPvpl9Zlnor5EjdEbUZxZJYbOGsFaxTWHXR/aVp9Zb69vX3XwgOm6hYmrDr6E3J9jrmmr2/+JzchL3sFzhC3e/zSp+WPtniqS1ZrCbQgSXccIvGk2Yjr+tOhyA= Received: from BYAPR10MB3240.namprd10.prod.outlook.com (2603:10b6:a03:155::17) by BYAPR10MB3621.namprd10.prod.outlook.com (2603:10b6:a03:121::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.29; Tue, 23 Feb 2021 21:53:03 +0000 Received: from BYAPR10MB3240.namprd10.prod.outlook.com ([fe80::7ccb:17c2:c957:65cd]) by BYAPR10MB3240.namprd10.prod.outlook.com ([fe80::7ccb:17c2:c957:65cd%6]) with mapi id 15.20.3868.033; Tue, 23 Feb 2021 21:53:03 +0000 Subject: Re: [kbuild] [linux-next:master 6931/12022] drivers/vfio/vfio_iommu_type1.c:1093 vfio_dma_do_unmap() warn: impossible condition '(size > (~0)) => (0-u32max > u32max)' To: Alex Williamson Cc: Dan Carpenter , kbuild@lists.01.org, lkp@intel.com, kbuild-all@lists.01.org, Linux Memory Management List , Cornelia Huck References: <20210222141043.GW2222@kadam> <20210222155145.50e2d513@omen.home.shazbot.org> <20210222161753.7acc4e92@omen.home.shazbot.org> <20210223104535.17986dee@omen.home.shazbot.org> <6527a7db-3b13-2572-3450-157e7de598c0@oracle.com> <20210223141001.765ae37f@omen.home.shazbot.org> From: Steven Sistare Organization: Oracle Corporation Message-ID: <57e47f93-e8f2-fdc6-ad26-dfb6bdbe3a25@oracle.com> Date: Tue, 23 Feb 2021 16:52:58 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 In-Reply-To: <20210223141001.765ae37f@omen.home.shazbot.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [24.62.106.7] X-ClientProxiedBy: SN4PR0201CA0064.namprd02.prod.outlook.com (2603:10b6:803:20::26) To BYAPR10MB3240.namprd10.prod.outlook.com (2603:10b6:a03:155::17) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.92] (24.62.106.7) by SN4PR0201CA0064.namprd02.prod.outlook.com (2603:10b6:803:20::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.27 via Frontend Transport; Tue, 23 Feb 2021 21:53:02 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7c375be7-a2e2-4e0e-0e8b-08d8d8456513 X-MS-TrafficTypeDiagnostic: BYAPR10MB3621: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: q1DOj9H77iIr5sH5G+3imEB0zE4BB8xXBBi7uYc3eoSDkn6gd5rlOnyyHGLeAcwfCP39+5iut/oXUkI/YMd5e1a/Y3ByAX6+TFqRiCQ2D6nVenk+qrqHk0jNj+kNsW2k6FP5a9A0LqfFIlCSgvg0/b2B+eAfYuaKJyZrvbWPKSSET9Tmk4sTChWm/isLyOeE378oU6r5CqcYpOwPMLluF0LRqESwkibpqxAmXv+fuemz0arIQy9XYX3gsySGpG8uWeECPIlRQ03kNltusyQW6BabLHhfGr/pDTePe0/LpR1zU9aS1MCxYUZVK+B1JIRhfcb/o8/j9b5UpPsSehtvOCcUr04wpr43pS24l6qw05eVDKajNS02rqeIzTiaVmFudPqb4lvRIfdKjYKv6A6yq4/SPKNocwPKGttqJUyKByRRkwsJRq7f7ZqLbH4KlrIoEboJSy1tcHEYc+krxBCrT5U+T4YsUYgsGI9MkXWKCYmY7iejAdHQbEFaif90Kf1wLJzo/JwGsprROTgvf8tyDbS5gjOLSqeCnQHNm2A/jz9XvVpHf796PuEQcIsPsnVCvmOgbfTgWo8HLk2tm6ikbwFC5DtLmbAfRoUO4+szRkZno2gvK669feRv5sQzilWgGLMlOTvyEZ/Y5e+cp72+zVtLMe25TNCrYpZHyxFRoI+FPPbDaOezT7e9fbvProaj X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BYAPR10MB3240.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(39860400002)(366004)(376002)(396003)(346002)(136003)(8676002)(4001150100001)(186003)(16526019)(8936002)(4326008)(83380400001)(2906002)(956004)(2616005)(16576012)(36756003)(6666004)(44832011)(54906003)(66556008)(66476007)(66946007)(53546011)(30864003)(966005)(31696002)(31686004)(36916002)(316002)(86362001)(478600001)(6916009)(5660300002)(6486002)(26005)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?dnJ3L0ZjejRpS3g5VWs4b0M3d2czblJOeWltbG5SL1JjSGlBQUIxWGFkUjd4?= =?utf-8?B?VVpLZkY0aS92M0hNUmdXSmZyRnU3bkgxSFBpcjY0a1QvL0JpQ1dmTkt0STJW?= =?utf-8?B?TFVwR1BQbU05V0JWZVlDZFB1ZHZGR1VUMXQyR2lRbi8wOFVrWEVvYk50dDY1?= =?utf-8?B?dEs3a0VRMytQRURCZ3lTazJqZ1FXQXVVOHUycENjME9JYlZWVEtUbHBFWGU0?= =?utf-8?B?c2lTdm9OVFVaMXdmcjZmTzJRT2Fla091VTBTcHpVeW9Lb2tKWmhGZDNpOHlT?= =?utf-8?B?U0VMbFBwMzFxUTAwejM2MUkvalgrZXd1c2xsRGFxcUhwZmhQYUdRMnRDMHVZ?= =?utf-8?B?ZEhtWVZkcDN0N0crbEhSL045N2lucUlUY2RpRGxxWjlzRUhrT3gwQ1JQN3A1?= =?utf-8?B?SUtWdDRGSlV1eXBCYWNsMCszL0dpb29NbUl3bVlIOVMxem10cFVrWlgrYTNu?= =?utf-8?B?cWdKODJYVWFzbnlIY0IvVnlYU3VQc1JuMDRMcW9xeTVyalRSSmlUcVZzQWk2?= =?utf-8?B?b0RSU0gwVkRjZVhtSDlUUElWRW0yV25FeDg5WDZNaUZ1bitqVzFFN3VTanRB?= =?utf-8?B?ZWUzdjBFbzA4c3EvSGRqN2xSSWZ5SzVPNHUybEZHaE83TXZ6Nk5PNzcxM1Fu?= =?utf-8?B?VzhaM2V1MFVaeHJPREpHQWgwK2NJRk41UDd0NnZVVXFuc1NiT2dpOEtEYXhJ?= =?utf-8?B?TERQWHR0QytkTEg5dXowNmx3MWdCMm5lZG52cWh0UkdOTkpJN0FOdVVickZR?= =?utf-8?B?WURIQWcvcTZ1a3BNYU4wUnhMMU9mZTFCdWF1L0I1OC91L0M1ZXJDdzNUQzU5?= =?utf-8?B?Qi9yaVk3OSswWGpQSzhQTUdyYWY2VmMxZ3ZQQWprTVl4RG50WGs0VEZVajA0?= =?utf-8?B?Yk5raWwzRjBMSE1MdzNoMXhJMWJrWHNhZEsyTkpVd1crMjRUUko4VzdHMFhQ?= =?utf-8?B?bVRoS2U3Q3F6VWxmQWhoWEYrSUNWVWR6eFZYWmV3TkN1Mmp2UWQvQ0Q1a25r?= =?utf-8?B?MXJ5ZzRtejU2Nm8xY2FBbEE4MFlVSWpLdmZuNjdFT3hyVUZzdlFKTlQzbkxK?= =?utf-8?B?ZnVlVTIzVmZEblcvc0xUbm5qdE5oNUVvcjhCR2Yzak1CUEd1MExqRkV2cFBC?= =?utf-8?B?WVhZM2d2WHRpR3hzRDZ2MkVkTXd1emc3VWcyclhRMlBjNVZMMVhlZGl5Y0xC?= =?utf-8?B?aEw3dFIrV1U1UDE5Z25zZU11RHZuamhPMjA2eVZDbFV3YURpaUF6R0g1dE9O?= =?utf-8?B?UldjNW1jL1FnQUtnR0F1eUVOU21DSWYrNDNiellmS1grM2dyZ0d6QVRSRGxJ?= =?utf-8?B?enlnclQzSG5MbXRjUWhXTldNZHhFNVhhMk50aGdyV0RPZUZRNVdHcVlNL1Nj?= =?utf-8?B?TkhKM1hjdzAvRVBjYXQveDRPQUFpWVJxbmM1V2xKNHh3enhJejdlRlVvcnRF?= =?utf-8?B?VVlORUlqeEFXWFFkQ3p6RENPYXZVL2N5TEpqWWJvR0ppSFZ4STNNU3A4YllP?= =?utf-8?B?eWxOdnE3MVIwVVR1TEhmcUFGNGxland6SmZlU2hyZ0dKazgrUXAxS1VLWUpQ?= =?utf-8?B?UE9XdlVESjJicXpXY3NZVjljdHRmeVBVbEtqZ1NvVXNyajNEa0xmOVpNM3lj?= =?utf-8?B?Z2RKTmE4ZW5seS9tMVllU3k0cDZzUVlSSUhJdWgxYnU2V1hqRitIUEFsZTcy?= =?utf-8?B?eVdUaVR5MkhqL3p3ZGVuYnh1WE1DUmNhRExKN3ROTW1pQ0E5VEFtM1ZpaGxI?= =?utf-8?Q?NuR+TExUL4C4+vkjoAeC0JWYfp/MsgXCsQu6tRO?= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7c375be7-a2e2-4e0e-0e8b-08d8d8456513 X-MS-Exchange-CrossTenant-AuthSource: BYAPR10MB3240.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2021 21:53:03.5334 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: WUTJqZR5UcRjePgZKZsFa9Aku2hEJqStAph+35bVauWGt+QdpwgEMQEWtxR/1bNBD+abs2g0iRsxWPCFtMd+pcIv7cMdrWMo4jNYdvbbUFo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR10MB3621 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9904 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999 adultscore=0 bulkscore=0 mlxscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102230183 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9904 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 spamscore=0 priorityscore=1501 impostorscore=0 bulkscore=0 mlxscore=0 malwarescore=0 clxscore=1015 phishscore=0 mlxlogscore=999 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102230182 X-Stat-Signature: xo1sqrnyxinasfb1hyxkj8urea1mqrwg X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: AE99CF4 Received-SPF: none (oracle.com>: No applicable sender policy available) receiver=imf29; identity=mailfrom; envelope-from=""; helo=userp2130.oracle.com; client-ip=156.151.31.86 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614117188-303128 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2/23/2021 4:10 PM, Alex Williamson wrote: > On Tue, 23 Feb 2021 15:37:31 -0500 > Steven Sistare wrote: > >> On 2/23/2021 12:45 PM, Alex Williamson wrote: >>> On Tue, 23 Feb 2021 08:56:36 -0500 >>> Steven Sistare wrote: >>> >>>> On 2/22/2021 6:17 PM, Alex Williamson wrote: >>>>> On Mon, 22 Feb 2021 15:51:45 -0700 >>>>> Alex Williamson wrote: >>>>> >>>>>> On Mon, 22 Feb 2021 17:10:43 +0300 >>>>>> Dan Carpenter wrote: >>>>>> >>>>>>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master >>>>>>> head: 37dfbfbdca66834bc0f64ec9b35e09ac6c8898da >>>>>>> commit: 0f53afa12baec8c00f5d1d6afb49325ada105253 [6931/12022] vfio/type1: unmap cleanup >>>>>> >>>>>> It's always the patches that claim no functional change... ;) >>>>>> >>>>>>> config: i386-randconfig-m021-20210222 (attached as .config) >>>>>>> compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 >>>>>>> >>>>>>> If you fix the issue, kindly add following tag as appropriate >>>>>>> Reported-by: kernel test robot >>>>>>> Reported-by: Dan Carpenter >>>>>>> >>>>>>> New smatch warnings: >>>>>>> drivers/vfio/vfio_iommu_type1.c:1093 vfio_dma_do_unmap() warn: impossible condition '(size > (~0)) => (0-u32max > u32max)' >>>>>>> >>>>>>> vim +1093 drivers/vfio/vfio_iommu_type1.c >>>>>>> >>>>>>> 73fa0d10d077d9 Alex Williamson 2012-07-31 1071 static int vfio_dma_do_unmap(struct vfio_iommu *iommu, >>>>>>> 331e33d2960c82 Kirti Wankhede 2020-05-29 1072 struct vfio_iommu_type1_dma_unmap *unmap, >>>>>>> 331e33d2960c82 Kirti Wankhede 2020-05-29 1073 struct vfio_bitmap *bitmap) >>>>>>> 73fa0d10d077d9 Alex Williamson 2012-07-31 1074 { >>>>>>> c086de818dd81c Kirti Wankhede 2016-11-17 1075 struct vfio_dma *dma, *dma_last = NULL; >>>>>>> 331e33d2960c82 Kirti Wankhede 2020-05-29 1076 size_t unmapped = 0, pgsize; >>>>>>> 0f53afa12baec8 Steve Sistare 2021-01-29 1077 int ret = -EINVAL, retries = 0; >>>>>>> 331e33d2960c82 Kirti Wankhede 2020-05-29 1078 unsigned long pgshift; >>>>>>> 0f53afa12baec8 Steve Sistare 2021-01-29 1079 dma_addr_t iova = unmap->iova; >>>>>>> 0f53afa12baec8 Steve Sistare 2021-01-29 1080 unsigned long size = unmap->size; >>>>>>> ^^^^^^^^^^^^^^^^^^ >>>>>>> >>>>>>> 73fa0d10d077d9 Alex Williamson 2012-07-31 1081 >>>>>>> cade075f265b25 Kirti Wankhede 2020-05-29 1082 mutex_lock(&iommu->lock); >>>>>>> cade075f265b25 Kirti Wankhede 2020-05-29 1083 >>>>>>> 331e33d2960c82 Kirti Wankhede 2020-05-29 1084 pgshift = __ffs(iommu->pgsize_bitmap); >>>>>>> 331e33d2960c82 Kirti Wankhede 2020-05-29 1085 pgsize = (size_t)1 << pgshift; >>>>>>> cade075f265b25 Kirti Wankhede 2020-05-29 1086 >>>>>>> 0f53afa12baec8 Steve Sistare 2021-01-29 1087 if (iova & (pgsize - 1)) >>>>>>> cade075f265b25 Kirti Wankhede 2020-05-29 1088 goto unlock; >>>>>>> cade075f265b25 Kirti Wankhede 2020-05-29 1089 >>>>>>> 0f53afa12baec8 Steve Sistare 2021-01-29 1090 if (!size || size & (pgsize - 1)) >>>>>>> cade075f265b25 Kirti Wankhede 2020-05-29 1091 goto unlock; >>>>>>> 73fa0d10d077d9 Alex Williamson 2012-07-31 1092 >>>>>>> 0f53afa12baec8 Steve Sistare 2021-01-29 @1093 if (iova + size - 1 < iova || size > SIZE_MAX) >>>>>>> >>>>>>> size is unsigned long and SIZE_MAX is ULONG_MAX so "size > SIZE_MAX" >>>>>>> does not make sense. >>>>>> >>>>>> I think it made sense before the above commit, where unmap->size is a >>>>>> __u64 and a user could provide a value that exceeds SIZE_MAX on ILP32. >>>>>> Seems like the fix is probably to use a size_t for the local variable >>>>>> and restore this test to compare (unmap->size > SIZE_MAX). Steve? >>>>> >>>>> Actually it seems like VFIO_DMA_UNMAP_FLAG_ALL doesn't work when >>>>> PHYS_ADDR_MAX != SIZE_MAX (ex. x86 PAE - I think). >>>> >>>> It seems like PAE causes problems even before VFIO_DMA_UNMAP_FLAG_ALL. >>> >>> This wouldn't surprise me, I don't know of any actual non-64bit users >>> and pure 32bit support was only lightly validated ages ago. >>> >>>> In the previous vfio_dma_do_unmap code, the u64 unmap->size would be >>>> truncated when passed to vfio_find_dma. >>> >>> We would have failed with -EINVAL before we get there due to this >>> SIZE_MAX test. I think the existing (previous) PAE interface is at >>> least self consistent; I see the mapping path also attempts to check >>> that casting map->size as size_t still matches the original value. >> >> Good point, and it also checks for vaddr and iova overflow and wrap: >> >> vfio_dma_do_map() >> if (map->size != size || map->vaddr != vaddr || map->iova != iova) >> return -EINVAL; >> if (iova + size - 1 < iova || vaddr + size - 1 < vaddr) { >> ret = -EINVAL; >> >> With that, I don't see a problem with PAE, for unmap-all or otherwise. >> We just need "u64 size" in vfio_dma_do_unmap to avoid the smatch warning. > > I'm not convinced. My understanding is that on PAE phys_addr_t is > 64-bit while size_t is 32-bit. dma_addr_t (iova above) seems to follow > phys_addr_t. That suggests to me that our {un}map.iova lives in a > 64-bit address space, but each mapping is limited to 32-bits. The OK, the "map->iova != iova" test does not help because dma_addr_t is 64-bit. My bad. So, I re-propose my fix for unmap-all from previous email. I am not keen on proposing a fix for the potential legacy bugs, vfio_find_dma() and its callers, if no one is reporting bugs and no one uses it with vfio. It has the potential for regression with no upside. - Steve > unmap-all logic only looks for a first entry to unmap in the > [0..SIZE_MAX] range. If an entry happens to exist there, we'll unmap > everything, but the user would have no requirement to have a mapping > within that range, their first mapping could exist at iova = (SIZE_MAX > + 1). So unmap-all would effectively need a special case to use > rb_first(), which mostly negates the reason we added > vfio_find_dma_first_node(). Right? Thanks, > > Alex > > >>>> For unmap, these fixes should suffice, and I would rather do this than >>>> disable the unmap-all flag for a corner case: >>>> >>>> vfio_dma_do_unmap() >>>> size_t unmapped = 0; >>>> unsigned long size = unmap->size; >>>> ==> >>>> u64 unmapped = 0; >>>> u64 size = unmap->size; >>>> >>>> static struct rb_node *vfio_find_dma_first_node( >>>> struct vfio_iommu *iommu, dma_addr_t start, size_t size) >>>> ==> >>>> static struct rb_node *vfio_find_dma_first_node( >>>> struct vfio_iommu *iommu, dma_addr_t start, u64 size) >>>> >>>> And maybe use dma_addr_t instead of u64 in the above (which is 64 bits for >>>> CONFIG_X86_PAE). >>>> >>>> However, there are other places in the existing code that need tweaking >>>> to be safe for PAE, the vfio_find_dma() size arg for one. >>> >>> Yes, it looks like the IOMMU aperture checking using vfio_find_dma() >>> could have issues where dma_addr_t > size_t. Do you want to propose a >>> patch? Thanks, >>> >>> Alex >>> >>>>> I can't say I'm >>>>> really interested in adding complexity to make it work in such a case >>>>> either. Maybe we can just not expose it, ex: >>>>> >>>>> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c >>>>> index ed03f3fcb07e..6b69a74b3db0 100644 >>>>> --- a/drivers/vfio/vfio_iommu_type1.c >>>>> +++ b/drivers/vfio/vfio_iommu_type1.c >>>>> @@ -1207,7 +1207,7 @@ static int vfio_dma_do_unmap(struct vfio_iommu *iommu, >>>>> int ret = -EINVAL, retries = 0; >>>>> unsigned long pgshift; >>>>> dma_addr_t iova = unmap->iova; >>>>> - unsigned long size = unmap->size; >>>>> + size_t size = unmap->size; >>>>> bool unmap_all = unmap->flags & VFIO_DMA_UNMAP_FLAG_ALL; >>>>> bool invalidate_vaddr = unmap->flags & VFIO_DMA_UNMAP_FLAG_VADDR; >>>>> struct rb_node *n, *first_n; >>>>> @@ -1228,7 +1228,7 @@ static int vfio_dma_do_unmap(struct vfio_iommu *iommu, >>>>> goto unlock; >>>>> } >>>>> >>>>> - if (iova + size - 1 < iova || size > SIZE_MAX) >>>>> + if (iova + size - 1 < iova || unmap->size > SIZE_MAX) >>>>> goto unlock; >>>>> >>>>> /* When dirty tracking is enabled, allow only min supported pgsize */ >>>>> @@ -2657,9 +2657,10 @@ static int vfio_iommu_type1_check_extension(struct vfio_iommu *iommu, >>>>> case VFIO_TYPE1_IOMMU: >>>>> case VFIO_TYPE1v2_IOMMU: >>>>> case VFIO_TYPE1_NESTING_IOMMU: >>>>> - case VFIO_UNMAP_ALL: >>>>> case VFIO_UPDATE_VADDR: >>>>> return 1; >>>>> + case VFIO_UNMAP_ALL: >>>>> + return PHYS_ADDR_MAX == SIZE_MAX ? 1 : 0; >>>>> case VFIO_DMA_CC_IOMMU: >>>>> if (!iommu) >>>>> return 0; >>>>> @@ -2868,6 +2869,10 @@ static int vfio_iommu_type1_unmap_dma(struct vfio_iommu *iommu, >>>>> VFIO_DMA_UNMAP_FLAG_VADDR))) >>>>> return -EINVAL; >>>>> >>>>> + if ((PHYS_ADDR_MAX != SIZE_MAX) && >>>>> + (unmap.flags & VFIO_DMA_UNMAP_FLAG_ALL)) >>>>> + return -EINVAL; >>>>> + >>>>> if (unmap.flags & VFIO_DMA_UNMAP_FLAG_GET_DIRTY_BITMAP) { >>>>> unsigned long pgshift; >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>> Is the " - 1" intentional on the other overflow check? As in it's okay >>>>>>> to wrap around to zero but not further than that? Sometimes this is >>>>>>> intentional but it requires more subsystem expertise than I possess. >>>>>> >>>>>> Yes, since we're dealing with a start + length we need to account for >>>>>> the -1 in the end value, otherwise the user could never unmap the last >>>>>> page of the address space. Thanks for the report! >>>>>> >>>>>> Alex >>>>>> >>>>>>> cade075f265b25 Kirti Wankhede 2020-05-29 1094 goto unlock; >>>>>>> 73fa0d10d077d9 Alex Williamson 2012-07-31 1095 >>>>>>> 331e33d2960c82 Kirti Wankhede 2020-05-29 1096 /* When dirty tracking is enabled, allow only min supported pgsize */ >>>>>>> 331e33d2960c82 Kirti Wankhede 2020-05-29 1097 if ((unmap->flags & VFIO_DMA_UNMAP_FLAG_GET_DIRTY_BITMAP) && >>>>>>> 331e33d2960c82 Kirti Wankhede 2020-05-29 1098 (!iommu->dirty_page_tracking || (bitmap->pgsize != pgsize))) { >>>>>>> 331e33d2960c82 Kirti Wankhede 2020-05-29 1099 goto unlock; >>>>>>> 331e33d2960c82 Kirti Wankhede 2020-05-29 1100 } >>>>>>> 73fa0d10d077d9 Alex Williamson 2012-07-31 1101 >>>>>>> 331e33d2960c82 Kirti Wankhede 2020-05-29 1102 WARN_ON((pgsize - 1) & PAGE_MASK); >>>>>>> 331e33d2960c82 Kirti Wankhede 2020-05-29 1103 again: >>>>>>> 1ef3e2bc04223f Alex Williamson 2014-02-26 1104 /* >>>>>>> >>>>>>> --- >>>>>>> 0-DAY CI Kernel Test Service, Intel Corporation >>>>>>> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org >>>>>> >>>>> >>>> >>> >> >