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=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 9ADDCC4361B for ; Wed, 16 Dec 2020 11:05:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 47DC223370 for ; Wed, 16 Dec 2020 11:05:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725862AbgLPLFZ convert rfc822-to-8bit (ORCPT ); Wed, 16 Dec 2020 06:05:25 -0500 Received: from eu-smtp-delivery-151.mimecast.com ([207.82.80.151]:35988 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725768AbgLPLFZ (ORCPT ); Wed, 16 Dec 2020 06:05:25 -0500 Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-94--UvXZFBAOeinyWm-PmDBBw-1; Wed, 16 Dec 2020 11:03:46 +0000 X-MC-Unique: -UvXZFBAOeinyWm-PmDBBw-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) by AcuMS.aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 16 Dec 2020 11:03:46 +0000 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Wed, 16 Dec 2020 11:03:46 +0000 From: David Laight To: 'Yong Wu' , Joerg Roedel , "Will Deacon" , Robin Murphy CC: Matthias Brugger , Krzysztof Kozlowski , Tomasz Figa , "linux-mediatek@lists.infradead.org" , "srv_heupstream@mediatek.com" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "iommu@lists.linux-foundation.org" , "youlin.pei@mediatek.com" , Nicolas Boichat , "anan.sun@mediatek.com" , "chao.hao@mediatek.com" , Greg Kroah-Hartman , "kernel-team@android.com" Subject: RE: [PATCH v3 4/7] iommu: Switch gather->end to unsigned long long Thread-Topic: [PATCH v3 4/7] iommu: Switch gather->end to unsigned long long Thread-Index: AQHW05fCvUUyI8/vv0eBmqh9Irindan5jgVQ Date: Wed, 16 Dec 2020 11:03:46 +0000 Message-ID: <6b4a1d37a90f4663adf6b4adb9f80e2b@AcuMS.aculab.com> References: <20201216103607.23050-1-yong.wu@mediatek.com> <20201216103607.23050-5-yong.wu@mediatek.com> In-Reply-To: <20201216103607.23050-5-yong.wu@mediatek.com> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Yong Wu > Sent: 16 December 2020 10:36 > > Currently gather->end is "unsigned long" which may be overflow in > arch32 in the corner case: 0xfff00000 + 0x100000(iova + size). > Although it doesn't affect the size(end - start), it affects the checking > "gather->end < end" > > Fixes: a7d20dc19d9e ("iommu: Introduce struct iommu_iotlb_gather for batching TLB flushes") > Signed-off-by: Yong Wu > --- > include/linux/iommu.h | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/include/linux/iommu.h b/include/linux/iommu.h > index 794d4085edd3..6e907a95d981 100644 > --- a/include/linux/iommu.h > +++ b/include/linux/iommu.h > @@ -178,7 +178,7 @@ enum iommu_dev_features { > */ > struct iommu_iotlb_gather { > unsigned long start; > - unsigned long end; > + unsigned long long end; > size_t pgsize; > }; Doesn't that add two pad words on many 32bit systems? You probably ought to re-order the structure to keep the fields on their natural boundaries. I'm not sure what is being mapped here, but could it make sense to just avoid using the highest addresses? Then you never hit the problem. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) 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=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 34075C4361B for ; Wed, 16 Dec 2020 11:04:00 +0000 (UTC) Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7D2CB23371 for ; Wed, 16 Dec 2020 11:03:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7D2CB23371 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=ACULAB.COM Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 9155687225; Wed, 16 Dec 2020 11:03:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDTVnugg2Uja; Wed, 16 Dec 2020 11:03:55 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by hemlock.osuosl.org (Postfix) with ESMTP id 9441C87219; Wed, 16 Dec 2020 11:03:55 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 51154C088E; Wed, 16 Dec 2020 11:03:55 +0000 (UTC) Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3CE2FC013B for ; Wed, 16 Dec 2020 11:03:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id E0D1920500 for ; Wed, 16 Dec 2020 11:03:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkB8hvyO2-T9 for ; Wed, 16 Dec 2020 11:03:51 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [207.82.80.151]) by silver.osuosl.org (Postfix) with ESMTPS id CE2EE203E7 for ; Wed, 16 Dec 2020 11:03:50 +0000 (UTC) Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-94--UvXZFBAOeinyWm-PmDBBw-1; Wed, 16 Dec 2020 11:03:46 +0000 X-MC-Unique: -UvXZFBAOeinyWm-PmDBBw-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) by AcuMS.aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 16 Dec 2020 11:03:46 +0000 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Wed, 16 Dec 2020 11:03:46 +0000 From: David Laight To: 'Yong Wu' , Joerg Roedel , "Will Deacon" , Robin Murphy Subject: RE: [PATCH v3 4/7] iommu: Switch gather->end to unsigned long long Thread-Topic: [PATCH v3 4/7] iommu: Switch gather->end to unsigned long long Thread-Index: AQHW05fCvUUyI8/vv0eBmqh9Irindan5jgVQ Date: Wed, 16 Dec 2020 11:03:46 +0000 Message-ID: <6b4a1d37a90f4663adf6b4adb9f80e2b@AcuMS.aculab.com> References: <20201216103607.23050-1-yong.wu@mediatek.com> <20201216103607.23050-5-yong.wu@mediatek.com> In-Reply-To: <20201216103607.23050-5-yong.wu@mediatek.com> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Cc: "youlin.pei@mediatek.com" , "anan.sun@mediatek.com" , Nicolas Boichat , "srv_heupstream@mediatek.com" , "chao.hao@mediatek.com" , "linux-kernel@vger.kernel.org" , Krzysztof Kozlowski , Tomasz Figa , "iommu@lists.linux-foundation.org" , "linux-mediatek@lists.infradead.org" , Matthias Brugger , Greg Kroah-Hartman , "kernel-team@android.com" , "linux-arm-kernel@lists.infradead.org" X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" From: Yong Wu > Sent: 16 December 2020 10:36 > > Currently gather->end is "unsigned long" which may be overflow in > arch32 in the corner case: 0xfff00000 + 0x100000(iova + size). > Although it doesn't affect the size(end - start), it affects the checking > "gather->end < end" > > Fixes: a7d20dc19d9e ("iommu: Introduce struct iommu_iotlb_gather for batching TLB flushes") > Signed-off-by: Yong Wu > --- > include/linux/iommu.h | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/include/linux/iommu.h b/include/linux/iommu.h > index 794d4085edd3..6e907a95d981 100644 > --- a/include/linux/iommu.h > +++ b/include/linux/iommu.h > @@ -178,7 +178,7 @@ enum iommu_dev_features { > */ > struct iommu_iotlb_gather { > unsigned long start; > - unsigned long end; > + unsigned long long end; > size_t pgsize; > }; Doesn't that add two pad words on many 32bit systems? You probably ought to re-order the structure to keep the fields on their natural boundaries. I'm not sure what is being mapped here, but could it make sense to just avoid using the highest addresses? Then you never hit the problem. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu 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=-13.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 467A0C4361B for ; Wed, 16 Dec 2020 11:09:36 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D7C2223124 for ; Wed, 16 Dec 2020 11:09:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D7C2223124 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=ACULAB.COM Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:In-Reply-To:References:Message-ID:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=UZq3J/vQQjFJ9TYdb9Y+kvKYo57oJyidgvlNm8fmFdg=; b=yR5KDP3WjTMDB8WxchNicqP19 oT9cXV2qAtrR8VTXfRF3b8mrtW8MF7KnLPGigpP82vuJRoH7F+fG7lkXQeSmDpjq/W2z1J2vblpQy x7cgZLRxa1cBD7S2w0mgqi/ZCbo/QDDKm4JuL3mmTBejjkBYqFkjEXRR6P7Fss9E6mad/D0nNW6hp h4Flt2xIn0/OSqD0ONVaUdwKOHzpEvO8SLgcbrwo2FeOgWx9U4yJ/pNGhYRgKSwSeCmfxUDxOUbhY RnVnt+RMax7Xl2YQN7UH2GSerdAkDM9gpkFbPfGmYEhrWXOZxcwiO875tXSpGTBHKpdxAlrJCP4bO AbdyBoQEA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kpUgM-0000YT-AM; Wed, 16 Dec 2020 11:09:22 +0000 Received: from eu-smtp-delivery-151.mimecast.com ([207.82.80.151]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kpUb1-0005Oa-PT for linux-mediatek@lists.infradead.org; Wed, 16 Dec 2020 11:03:56 +0000 Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-94--UvXZFBAOeinyWm-PmDBBw-1; Wed, 16 Dec 2020 11:03:46 +0000 X-MC-Unique: -UvXZFBAOeinyWm-PmDBBw-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) by AcuMS.aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 16 Dec 2020 11:03:46 +0000 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Wed, 16 Dec 2020 11:03:46 +0000 From: David Laight To: 'Yong Wu' , Joerg Roedel , "Will Deacon" , Robin Murphy Subject: RE: [PATCH v3 4/7] iommu: Switch gather->end to unsigned long long Thread-Topic: [PATCH v3 4/7] iommu: Switch gather->end to unsigned long long Thread-Index: AQHW05fCvUUyI8/vv0eBmqh9Irindan5jgVQ Date: Wed, 16 Dec 2020 11:03:46 +0000 Message-ID: <6b4a1d37a90f4663adf6b4adb9f80e2b@AcuMS.aculab.com> References: <20201216103607.23050-1-yong.wu@mediatek.com> <20201216103607.23050-5-yong.wu@mediatek.com> In-Reply-To: <20201216103607.23050-5-yong.wu@mediatek.com> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201216_060352_896192_349FB413 X-CRM114-Status: GOOD ( 15.50 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "youlin.pei@mediatek.com" , "anan.sun@mediatek.com" , Nicolas Boichat , "srv_heupstream@mediatek.com" , "chao.hao@mediatek.com" , "linux-kernel@vger.kernel.org" , Krzysztof Kozlowski , Tomasz Figa , "iommu@lists.linux-foundation.org" , "linux-mediatek@lists.infradead.org" , Matthias Brugger , Greg Kroah-Hartman , "kernel-team@android.com" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org From: Yong Wu > Sent: 16 December 2020 10:36 > > Currently gather->end is "unsigned long" which may be overflow in > arch32 in the corner case: 0xfff00000 + 0x100000(iova + size). > Although it doesn't affect the size(end - start), it affects the checking > "gather->end < end" > > Fixes: a7d20dc19d9e ("iommu: Introduce struct iommu_iotlb_gather for batching TLB flushes") > Signed-off-by: Yong Wu > --- > include/linux/iommu.h | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/include/linux/iommu.h b/include/linux/iommu.h > index 794d4085edd3..6e907a95d981 100644 > --- a/include/linux/iommu.h > +++ b/include/linux/iommu.h > @@ -178,7 +178,7 @@ enum iommu_dev_features { > */ > struct iommu_iotlb_gather { > unsigned long start; > - unsigned long end; > + unsigned long long end; > size_t pgsize; > }; Doesn't that add two pad words on many 32bit systems? You probably ought to re-order the structure to keep the fields on their natural boundaries. I'm not sure what is being mapped here, but could it make sense to just avoid using the highest addresses? Then you never hit the problem. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek 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=-13.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 9F6D8C4361B for ; Wed, 16 Dec 2020 11:11:17 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 31E5923124 for ; Wed, 16 Dec 2020 11:11:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 31E5923124 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=ACULAB.COM Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:In-Reply-To:References:Message-ID:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=hO+N2zqKvSpIIg8UDoyntZ0xroZk26wDwmVwUT/Txc4=; b=Ey60dtkTua2gbL8DGkNzd6NH4 7mo+4Kq2VbpMN765PCjLiuPcKbO0toTeWxHzF8fofT88Qnn4/IRi2f8WzBtvCrb15VPC3lPcSzHai 0S87kyePso6jR4ecn7xQBn3st0tP/mlZE9PADsJL+n/gfsKiqkEnn2Izjoj0/bK73XGDqQfqG4a01 fjotQ2TzNrdefb3COXYXQMpubapA/CJhr0gBr9468ECs9wFFUexzVGGex+yE3oVWRMYaa8ikJWtqA +N+LzZvjAiw7QZ3xgblM4EgXo620mDBKoMM1bK8dUUCWg7j4EZgwW0PrkKPNziMh9oAxDBXZ4LwNf nQuL2IInA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kpUgU-0000a9-W0; Wed, 16 Dec 2020 11:09:31 +0000 Received: from eu-smtp-delivery-151.mimecast.com ([207.82.80.151]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kpUb1-0005Om-PU for linux-arm-kernel@lists.infradead.org; Wed, 16 Dec 2020 11:03:56 +0000 Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-94--UvXZFBAOeinyWm-PmDBBw-1; Wed, 16 Dec 2020 11:03:46 +0000 X-MC-Unique: -UvXZFBAOeinyWm-PmDBBw-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) by AcuMS.aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 16 Dec 2020 11:03:46 +0000 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Wed, 16 Dec 2020 11:03:46 +0000 From: David Laight To: 'Yong Wu' , Joerg Roedel , "Will Deacon" , Robin Murphy Subject: RE: [PATCH v3 4/7] iommu: Switch gather->end to unsigned long long Thread-Topic: [PATCH v3 4/7] iommu: Switch gather->end to unsigned long long Thread-Index: AQHW05fCvUUyI8/vv0eBmqh9Irindan5jgVQ Date: Wed, 16 Dec 2020 11:03:46 +0000 Message-ID: <6b4a1d37a90f4663adf6b4adb9f80e2b@AcuMS.aculab.com> References: <20201216103607.23050-1-yong.wu@mediatek.com> <20201216103607.23050-5-yong.wu@mediatek.com> In-Reply-To: <20201216103607.23050-5-yong.wu@mediatek.com> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201216_060352_894663_F4232D6D X-CRM114-Status: GOOD ( 16.46 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "youlin.pei@mediatek.com" , "anan.sun@mediatek.com" , Nicolas Boichat , "srv_heupstream@mediatek.com" , "chao.hao@mediatek.com" , "linux-kernel@vger.kernel.org" , Krzysztof Kozlowski , Tomasz Figa , "iommu@lists.linux-foundation.org" , "linux-mediatek@lists.infradead.org" , Matthias Brugger , Greg Kroah-Hartman , "kernel-team@android.com" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org From: Yong Wu > Sent: 16 December 2020 10:36 > > Currently gather->end is "unsigned long" which may be overflow in > arch32 in the corner case: 0xfff00000 + 0x100000(iova + size). > Although it doesn't affect the size(end - start), it affects the checking > "gather->end < end" > > Fixes: a7d20dc19d9e ("iommu: Introduce struct iommu_iotlb_gather for batching TLB flushes") > Signed-off-by: Yong Wu > --- > include/linux/iommu.h | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/include/linux/iommu.h b/include/linux/iommu.h > index 794d4085edd3..6e907a95d981 100644 > --- a/include/linux/iommu.h > +++ b/include/linux/iommu.h > @@ -178,7 +178,7 @@ enum iommu_dev_features { > */ > struct iommu_iotlb_gather { > unsigned long start; > - unsigned long end; > + unsigned long long end; > size_t pgsize; > }; Doesn't that add two pad words on many 32bit systems? You probably ought to re-order the structure to keep the fields on their natural boundaries. I'm not sure what is being mapped here, but could it make sense to just avoid using the highest addresses? Then you never hit the problem. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel