From patchwork Wed Aug 5 22:41:46 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bart Van Assche X-Patchwork-Id: 6954731 Return-Path: X-Original-To: patchwork-linux-rdma@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id C3180C05AC for ; Wed, 5 Aug 2015 22:41:56 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 9A34420534 for ; Wed, 5 Aug 2015 22:41:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 55955203B4 for ; Wed, 5 Aug 2015 22:41:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753866AbbHEWlx (ORCPT ); Wed, 5 Aug 2015 18:41:53 -0400 Received: from mail-bn1on0086.outbound.protection.outlook.com ([157.56.110.86]:20000 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752101AbbHEWlv (ORCPT ); Wed, 5 Aug 2015 18:41:51 -0400 Received: from BLUPR0201CA0015.namprd02.prod.outlook.com (10.163.116.25) by DM2PR0201MB0750.namprd02.prod.outlook.com (10.160.94.26) with Microsoft SMTP Server (TLS) id 15.1.225.19; Wed, 5 Aug 2015 22:41:48 +0000 Received: from BY2FFO11FD036.protection.gbl (2a01:111:f400:7c0c::104) by BLUPR0201CA0015.outlook.office365.com (2a01:111:e400:52e7::25) with Microsoft SMTP Server (TLS) id 15.1.225.19 via Frontend Transport; Wed, 5 Aug 2015 22:41:47 +0000 Authentication-Results: spf=pass (sender IP is 63.163.107.172) smtp.mailfrom=sandisk.com; obsidianresearch.com; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of sandisk.com designates 63.163.107.172 as permitted sender) receiver=protection.outlook.com; client-ip=63.163.107.172; helo=milsmgep11.sandisk.com; Received: from milsmgep11.sandisk.com (63.163.107.172) by BY2FFO11FD036.mail.protection.outlook.com (10.1.14.221) with Microsoft SMTP Server id 15.1.243.9 via Frontend Transport; Wed, 5 Aug 2015 22:41:46 +0000 Received: from MILHUBIP03.sdcorp.global.sandisk.com ( [172.22.12.162]) by milsmgep11.sandisk.com (Symantec Messaging Gateway) with SMTP id 84.DD.04667.A2192C55; Wed, 5 Aug 2015 15:41:46 -0700 (PDT) Received: from milsmgip11.sandisk.com (10.177.8.100) by MILHUBIP03.sdcorp.global.sandisk.com (10.177.9.96) with Microsoft SMTP Server id 14.3.224.2; Wed, 5 Aug 2015 15:41:06 -0700 X-AuditID: ac160a68-f790b6d00000123b-da-55c2912acef4 Received: from [10.60.52.33] ( [10.177.8.100]) by milsmgip11.sandisk.com (Symantec Messaging Gateway) with SMTP id 24.24.03643.A2192C55; Wed, 5 Aug 2015 15:41:46 -0700 (PDT) Subject: Re: [PATCH v2 00/12] IB: Replace safe uses for ib_get_dma_mr with pd->local_dma_lkey To: Jason Gunthorpe , David Dillow References: <1438298547-21404-1-git-send-email-jgunthorpe@obsidianresearch.com> <55BBF4B8.2050700@sandisk.com> <20150803152420.GA24193@infradead.org> <55BFB40F.8000500@sandisk.com> <20150804180933.GB5038@obsidianresearch.com> <1438756876.5698.2.camel@haswell.thedillows.org> <20150805195122.GA31595@obsidianresearch.com> <55C2840C.5050301@sandisk.com> CC: Christoph Hellwig , Doug Ledford , "linux-rdma@vger.kernel.org" From: Bart Van Assche Message-ID: <55C2912A.50709@sandisk.com> Date: Wed, 5 Aug 2015 15:41:46 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55C2840C.5050301@sandisk.com> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42JZI8azSFdr4qFQg837FS1mXFnGZvHy/AdW i9MTFjFZfL9havHsUC+LA6vH5hVaHt939DJ6vN93lc3jyNuPzB6fN8kFsEZx2aSk5mSWpRbp 2yVwZXTcvchW0CFfsaX9FnsD4zTJLkZODgkBE4lLP/axQthiEhfurWfrYuTiEBI4wSgx48gC FghnO6PEx0vTWGA6tq75ygSR2MQoseTGebB2YYF4ic7Ni4DaOThEBKIlTrbagoSFBJ4zSTzc B1bPLNDFKDHv+S42kASbgJHEt/czwYbyCmhINOzeBWazCKhIbL9/BcwWFYiQmPCyixWiRlDi 5MwnYHFOAW2Ja18WsIPYzAIWEjPnn2eEsOUltr+dwwyyTELgKKtE97d/zBBXqEucXDKfaQKj yCwks2Yh6Z+FpH8BI/MqRrHczJzi3PTUAkNDveLEvJTM4my95PzcTYzgqOHK2MG4dZL5IUYB DkYlHl4Pt4OhQqyJZcWVuYcYJTiYlUR433ccChXiTUmsrEotyo8vKs1JLT7EKM3BoiTO25ur EyokkJ5YkpqdmlqQWgSTZeLglGpglHgeKH2tZU/Tp4CCK8vOTbFQrg191b4z93GD3OM/cl9v R/ObMlQudj33O7jz233/iNN2F3eZrQq9mHFFbrrXpR/XF1wJ2y+s45rHrhMndNp4u3LQCwcl F1uFzeVWDyJqK56kTl8R/6A/yEt8t8nlwmmPIlw5ttUtf7yf9fRz6R186s8/HfZYpMRSnJFo qMVcVJwIAJ+ZIBmWAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsXCtZEjRVdr4qFQg+3ThS1mXFnGZvHy/AdW i9MTFjFZfL9havHsUC+LA6vH5hVaHt939DJ6vN93lc3jyNuPzB6fN8kFsEZx2aSk5mSWpRbp 2yVwZXTcvchW0CFfsaX9FnsD4zTJLkZODgkBE4mta74yQdhiEhfurWfrYuTiEBLYwCixZWsf WEJYIF6ic/MiNhBbRCBaYt38bywgtpDAcyaJh/uYQBqYBXoYJb4ceswKkmATMJL49n4mWBGv gIZEw+5dYDaLgIrE9vtXwGxRgQiJCS+7WCFqBCVOznwCFucU0Ja49mUBO4jNLGAmMW/zQ2YI W15i+9s5zBMY+WchaZmFpGwWkrIFjMyrGMVyM3OKc9MzCwwN9YoT81Iyi7P1kvNzNzGCA5cz cgfj04nmhxiZODilGhgVVrKLO/66lhv0t+CWxbvOderhBuuMzycvOD01/ZHMidvPv3xbscDp zIvSA9rN10+nrNzeuPfGRkmv/FVORjO8Q5brxJ9cm9NveFk+/f/tj6mPP34xiBAqu+NUFlxf UPpjQ0M218WC+H0KmyZ8+sjP3Tll4XavFxrWHKsimhTCDONZPV9w2x9QYinOSDTUYi4qTgQA UHeKzQwCAAA= X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD036; 1:TK7qLAtQ3zAzYZuIhIXIVoV3OZuT/DOmqjKNeDp/v/tb91HE4rOaf6O9c4puD/dQc6uiMruBmjaXnwiiBm4Y2kxpmOaC4Y763Ubu5VdMpC7z0YqUVqz1GWw7sHXNmMQutQ4EIZO7DfX+NxXrc9RDo1slEvc2gNcOy0Ybrsnf9JvFr+Oou6wWCcN07a9UBz5x9BiEKWobyND/ljs6HujgOQBb6BfUMLzXaSoCAN0xZqSDVtel6grI7HcPm6T6B98DNfnF5MC9qVW+DsDtblaU9Q== X-Forefront-Antispam-Report: CIP:63.163.107.172; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(2980300002)(438002)(479174004)(377454003)(199003)(24454002)(377424004)(189002)(76104003)(46102003)(575784001)(76176999)(86362001)(77096005)(68736005)(50986999)(65816999)(62966003)(65806001)(2950100001)(93886004)(87936001)(33656002)(54356999)(50466002)(83506001)(15975445007)(77156002)(106466001)(69596002)(64126003)(5001920100001)(7520500002)(23676002)(64706001)(561944003)(92566002)(81156007)(189998001)(97736004)(5001960100002)(5001770100001)(4001540100001)(47776003)(4001350100001)(5001860100001)(65956001)(36756003)(19580395003)(5001830100001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0201MB0750; H:milsmgep11.sandisk.com; FPR:; SPF:Pass; PTR:ErrorRetry; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0201MB0750; 2:6I/fwqgGSpJy7liclr1B11bY9HUJXlxf5ApNg7f7IYfTzwxtwxqVTKKN+4IT/WF3PUspYNWBft5eCVaFlNrdDX1ahSIsFvxtfXDGREAO4CCgcnftnhlPkZg1i3jA0IPfIC4vUPT9R3lpKFXFtuSO5AEHWG+b7EaOKRljlmF3OKU=; 3:jf+pJvs0bcFBML2R7aZgA9CO2wEGc57rXQOJscgommiunIwlBplzSEgAuZPQVrF27e8zpMFXrPSMPOuCgtBbnmF8WUq7WHc6RIIpnvwXdMQahv3UwBsSJ9qL+LtLGEM3rGw8M6n/jKVemE/02BD0tKlY2IgZtAXrxBZ78VYn8XuJUKk58V1xzpSjShR73ErXok4+p2WnSHcN4828Eor52mXedrC+PBp/Fm4zCv3rjp47pG+/GpGEzeDn+xvUwt+g; 25:ywfArq3Dlqlc+DDKvU9y+fxYs4vwdFEl3uHtclnNJd1nBexBQ5IGMTErToE/1zRWdEid4w83GxzBoWhmiCONd77/9gnrb8uefWDd+Yx7Nfh4UZB+XfeuqeXq6BcMhc0taPsw3F8nNQ6k8KprJa3bC/gHNR8zm8nCzEuQvydPWP0qEuKyenVwpxlA3iQKUBo5k5niBVN9Z/xraJT6m/yzuTX8Fu8tZ9lsaSrEXEILu7T43gMAuDkkaqAyNHcEduYAvg2GRQrxyFvKpuqpgx0Dpw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0201MB0750; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0201MB0750; 20:GoorKn7NNl7u8gdJBOJ/w+Y3YQbsgwS7ijyXAYJaxHvNA1DeGTHEtjATYwvKV69PC8Nz1TQMsVhDzA3zVERcmi0fSpTVeWBmnfoNgeanAcBf9o0/YB6nqf3FRvMT1N5aj0sujZBpRcz+1fONTCoNnl8w3xuXF+7ycg16GR3ptRK8rwHmNtWJyykxgzgisLB4VHt8orvmYr8uROOal47VT0xvqEVxcAsjrUIZfrQMyKAXEV73dfg/S114Um7OluJmWAiWSY47GcuHsJMLlKVR7xQj7EEFvdimOUEYNkIf9zCLx89eCK/SgwoUAhFhABRy0/H+guipfA2LYQs+qEFhdsBzSYK1ciFfsYMOS0phEBl6E2JrVMzAOSXxN48+GNcxl7774RZh+l0Vv1LINoJuGZlQiXxd2j76Wmlve3lo4q9MpA7c475hsVMoZXfIiCoq97NXUKpUkYGimX4xZcAU7RBZEZz1zMrmPSfGqBPs+kSSQ9juBjBqo1D4BhDlR2iL; 4:NTHdqGhla7z1hcB6bYEdBRIrZHK/7WRLQfugzzu5mQ0dJn1PR/iO1IxKelT/BdSgreRFgAszkPafej0b3a2UYBsHaGTgZ2ahq0o0J3vk0MZYj4Yb4VyQNNCUN/bE3+wp/TW0Ci/B0TZ2ouYrs8qIX+VwE0HotXktV2SduFD8T5xLtCDmxvAauuSWlXPk7rU2xZvVz8C9w1GDICxFBBPu8gLwfMERdbEFy+i5YkH5FV0daPcbLSDiN00KwQ+DebnV2Imv7GiAyghpURUmc0NiuS/Rp25ofofNWHQyMOXxnTM= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DM2PR0201MB0750; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0201MB0750; X-Forefront-PRVS: 06592CCE58 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTJQUjAyMDFNQjA3NTA7MjM6SG52UFZ1bi9Nb2p5S0Z3RVowZ2pDbnpH?= =?utf-8?B?bmIzeFNYSm82UXkyV1grYWowSDlaK3FYajgreGcyUjNoRDZ1U0RZV0ZyVDFZ?= =?utf-8?B?MnpPdHJra1VCbVlNQ0t4VG9QZTgxR0x6L1lPRStwUktuQ1d2anRLSnBHQW0r?= =?utf-8?B?ZUlPaW1zZzM2Mk41SHdmWldIRHhYTW9hcXEvMWc1WlhwREE4UWd2bXNWR29i?= =?utf-8?B?MGZuZFlBYmJhU2VLVi9ac25KZGwyOVFrYzZENTNWcG5RMmtYMzI3ZFRrWExR?= =?utf-8?B?SFhkbkdrU3UxVnV4Y3NkZm1ydDFGK0EyTVNiMXZqR3hoOHgwTFFlemExZWE3?= =?utf-8?B?cEc2OVYrSEpWZGloS0JITnpYSjBVbmpXRDRtNFVYSWhCWUtRMDdFeVNtRHlO?= =?utf-8?B?dGdBWkFIKzhIbzdydSt3TFo4VnJuS0dibmY5SHdaMjQ2NHk2TGJkc2JscGpa?= =?utf-8?B?SVhtVWE3QVVHaUxQS25oWHVraFE1RXZYTlJjaHJTZUxWUGRIWW5hL0tXYmRD?= =?utf-8?B?VWVNV2tvMzJxTGNrWGpWRUZhMmtscWtoSHZvUnZEY042K1VuamVPTFpsNDdY?= =?utf-8?B?QTBGNzdLZXRHaUJjRE5CaWpuaEM1cTE2YjUyZkFMRHRhbXg2S3pSdmpobkh0?= =?utf-8?B?dVh6L3JXZDBjQ2pLM3J6b0k3VWV4OW1PUVp5RGgwMmU4OXFZYlU3U0pZakJG?= =?utf-8?B?Zm44TWJlaUMrNUNzY3lxQ3BaKy9aazRXSWdvSkxRY0lUeWFvcTdkT1ZyVCsr?= =?utf-8?B?TnhvMXA5NzBoV1NvL3JBTnhZQmk4UGl6QmdGMFdDMzNvZGhoSU1CZU5mbE1m?= =?utf-8?B?OWFWUHFIQktuWStXQjdURWtPQ25ndG5RdjUrdGp2YWpiajdUSFhsWTNHbnlz?= =?utf-8?B?NXpvNCtFOWM0dmVtMm5seEtzZFV6S21DdDdscTJRNjVVa01PMHV4aUtXTGJG?= =?utf-8?B?b3pLZU4zMXlPc09LRHpoQVhRWHZSTXc2WkFaWjdQeUUrakdSSnRRN2IwQzJL?= =?utf-8?B?TDB2RmRDRU03S01vKzRtWHplajlpbEQyaDVrdjJEOVVuMjRWb2trM3JZaW43?= =?utf-8?B?em9pNXB2eVJDWndXckllbWZTb0hCUVE1SEZWU1krYlUyQkdLazZqYVFHNHdH?= =?utf-8?B?eTBnU0dkYmRpYnNyM0I3MVVGeHFhWFU1QVBDaGZrOEcvMVFkMnhUY1p2OWxq?= =?utf-8?B?d2JKc1grekt0cXpVQUdxY0hjY010dUJLQlovbjlLOTFUYzY5UkVrVklnTUxN?= =?utf-8?B?dFNRdGZ0ZzlDdmlCTDFCZkdVaCtGU1puZXRoQzg5amZyekNDaHBVZHAycmZq?= =?utf-8?B?Nkd4R0JFcUhRZ3R1TmptUlZFNGRreitoYzQ3WC9rcDZaZ3RSd3dxSzE1Z3hz?= =?utf-8?B?NW9aR2xhMHo2RThZT2N1VWgvQVJFUlh3TTZBMVVKVkpEc0ZlWWw2T0VxRXFa?= =?utf-8?B?Mi9oM1IrdndBZ0RvdHYrYTNUNmdEeDl5a29waXY3UHQwYVlnTEVwcTMwbmpo?= =?utf-8?B?bVRZOFozNUhqaC96RHZHQ3c4c0VIeTRHb1V3S3laOU9selFLUnNZRDRtcThV?= =?utf-8?B?YUsrM3R2ZFV0S1pqQkM0eW5GQTVOSXpIMlh5VlJ6NU1MaVBabDRXazd0L2JS?= =?utf-8?B?eEFtSHhIN3krcCtxTjMwemU2M1RWQnNFWkFCQmNpNnZGcHhhalAzeGlWSDg4?= =?utf-8?B?M1VsczVwQ0M0ZFI3YWpVd3dMMmxyMjNuY1RMVWh5cWhqcmg4QVpEajd0cTFw?= =?utf-8?B?S0ZoYlFNcG5hdUNZaUJjVkRtamF6U1ZVemdwZTRlMXZHTWtUVDBwU1dadTh5?= =?utf-8?B?eXdpamU1QzFwRmZia1NrckFOU0Q1RUtBTzNJVkRLQ2k3VXJIQT09?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0201MB0750; 5:EmESr8fnyz7zgJvB4wPcHVl8kmyHe8tRrh7Uua32cxR8F7+BRQnC2J+Z0ao2WVWTmop0ZeTwby7s5Un3s5gDg6A/daD/+yFX3+xkmHhRWm6LYU71MwDCbgW5jG55zroZ5BfAzjHjyQ9QykcuQ9WU8g==; 24:Vf03HVOTnsdO3DfhL67Sr9wHBhWNHeVAQ+NCPpWsAGb2WeITkNaEqYPJfdZqxIFRW5W2McC0q4acwGsvgNtxUV0bdXRogpIsk7KPIuwF850=; 20:0n8A59ndRq+Y38B844X/dTjP/eL+eKN4GrdxRA4YZfEi6O0bg4tb86XTk0/HPYMaSRCR7TqNgerKxjTl0pv4aAwno/oIqsPk7mUndrCYktJidzyXsdkayzmNEcPbKUe3gxndTNFpgbPlfexZgqnxCVuzNG27vLQpX5l+Vjs/LuE= X-OriginatorOrg: sandisk.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2015 22:41:46.6183 (UTC) X-MS-Exchange-CrossTenant-Id: fcd9ea9c-ae8c-460c-ab3c-3db42d7ac64d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=fcd9ea9c-ae8c-460c-ab3c-3db42d7ac64d; Ip=[63.163.107.172]; Helo=[milsmgep11.sandisk.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0201MB0750 Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 08/05/2015 02:45 PM, Bart Van Assche wrote: > On 08/05/2015 12:51 PM, Jason Gunthorpe wrote: >> On Tue, Aug 04, 2015 at 11:41:16PM -0700, David Dillow wrote: >>> On Tue, 2015-08-04 at 12:09 -0600, Jason Gunthorpe wrote: >>>> On Mon, Aug 03, 2015 at 11:33:51AM -0700, Bart Van Assche wrote: >>>>>> Bart, do you know what hardware this workaround is for? >>>>> >>>>> I hope the HW vendors can comment on this. Sorry but I'm not sure which HCA >>>>> models and/or firmware versions do not support FMR mapping with a non-zero >>>>> offset. >>>> >>>> Perhaps David can remember why he added this: >>>> >>>> commit 8f26c9ff9cd0317ad867bce972f69e0c6c2cbe3c >>> >>> It's originally from commit 559ce8f150d7d031c79c4d79173860f1bdfe3ce4, >>> and the list's attempts at code archaeology failed us: >>> http://article.gmane.org/gmane.linux.drivers.rdma/7149 >> >> Okay.. So over time we went from a clear target specific bug described >> 9 years ago in 559ce through chinese whispers to a general unspecific >> fear of non-zero offset FMR? >> >> But nobody has described FMR failure in this way in the past 9 years >> with any specificity? >> >> My random guesses would be broken mthca firmware at the start of the >> FMR feature (long since fixed) or a wonky target that is now 10 years >> obsolete.. >> >> If it was an HCA bug, I strongly have to think it is fixed now. We use >> FMR all over the place and SRP is the only area I've noticed this >> restriction.. >> >> If it is a target bug, then FRWR should trigger it as wel, so we are >> already about to revert that workaround. >> >> I'm inclined to drop this entirely.. What do you think Bart? > > Even today I see memory corruption at the initiator side with FMR and > not with FR if I leave out the alignment check. Since this only occurs > with FMR and not with FR that excludes the target side as a possible > cause. I will have a closer look at the srp_map_finish_fmr() function. > Always passing 0 as the second argument of srp_map_desc() in > srp_map_finish_fmr() is probably wrong. Before 2011 that second argument > was the page offset of the first sg-list entry. (replying to my own e-mail) The patch below makes FMR registration work again for buffers that are not aligned on a page boundary. Regarding the discussion in 2011 about FMR (http://thread.gmane.org/gmane.linux.drivers.rdma/7149): since in 2011 nobody recalled the root cause of the issue with non-page aligned FMR my proposal is to drop the page alignment check and if any issues occur to introduce a blacklist for the SRP target devices that have trouble with this. Bart. [PATCH] IB/srp: Restore FMR offset Since srp_map_finish_fmr() is always called with base_dma_addr aligned on a page boundary this patch does not change any functionality. See also patch "IB/srp: rework mapping engine to use multiple FMR entries" (commit ID 8f26c9ff9cd0; January 2011). --- drivers/infiniband/ulp/srp/ib_srp.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) @@ -1283,7 +1285,8 @@ static int srp_map_finish_fmr(struct srp_map_state *state, *state->next_fmr++ = fmr; state->nmdesc++; - srp_map_desc(state, 0, state->dma_len, fmr->fmr->rkey); + srp_map_desc(state, state->base_dma_addr & ~dev->mr_page_mask, + state->dma_len, fmr->fmr->rkey); return 0; } diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c index 48201b3..cac444e 100644 --- a/drivers/infiniband/ulp/srp/ib_srp.c +++ b/drivers/infiniband/ulp/srp/ib_srp.c @@ -1272,6 +1272,8 @@ static void srp_map_desc(struct srp_map_state *state, dma_addr_t dma_addr, static int srp_map_finish_fmr(struct srp_map_state *state, struct srp_rdma_ch *ch) { + struct srp_target_port *target = ch->target; + struct srp_device *dev = target->srp_host->srp_dev; struct ib_pool_fmr *fmr; u64 io_addr = 0;