Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp2889673ybl; Mon, 19 Aug 2019 08:56:29 -0700 (PDT) X-Google-Smtp-Source: APXvYqx2yh4eWt7Lh7Z8ECNilmNagupejSf0csHSgpK8lCAsSDLXS4kDzgFjRVOrDga+F5PHc+BJ X-Received: by 2002:a65:4b8b:: with SMTP id t11mr20503135pgq.130.1566230189698; Mon, 19 Aug 2019 08:56:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566230189; cv=none; d=google.com; s=arc-20160816; b=OM2KLkNcSDRxsWc7fcQFFUfZJl0eHu7vVA7IFU1g4IVvsEAIzzDofpEaeM7TvMjhnh rG+npBb1Q4hB/zAYBMfqjZYpns9ryO9rAvUxe/G+m0qmzi+XHrkoNMIlWsENhl268pTc tqFvl68iTDj+arVFAn46iODH43rAm2zoxWQrme0kVoWjbxE0COWmtjDfMGLLPtrNhUKL +70LiFxJRzDSarBcnZ15Q7BT8+ltnPHFiHtmnjDi5GX9H0joNl+p2rsSpRfDFFHc556R ovjO3/qj95DPvH4i/uPca/zXHQzvJLbNm5IBvpr9weNCYuvGUabQ3ggsgRfOLfINLfCB j/Ag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:content-transfer-encoding :references:importance:sensitivity:mime-version:date:cc:to:from :subject:in-reply-to; bh=XANAKP8/f7SMAnvmevXseP5YxvJZhjyINSmC+Typ2lU=; b=Nj7rsjrttnavVdEw757Sh56qwQwFzIXbgQMSX4buWFMSt2ge7/17le8rtPSZVf1SIY EcMFHrs/w7h9PN5Ic9ty0BVZcGvgsNVyagwvNPmNe0aC9k+72HB8uUoDxCBan30HsVTe awLRxXhs81hIPyye0P47+5VQxfqfcDA2QNtK4fvK7GAn1u6ajHqujb3fiqlI4m+l96N1 Shsz0hvyOn64VU7/S2ZddK/X7sUQk4Ymiijj7587QxH3EiUd2POPLEDJMmsBwTQi9kak C/il75IPxIVi7ABBigg0gCuJ5fQ48RFnF6WK6OVLQBYDdnIp53O9CtYKg6Lju12IVztb ggYw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v143si10586343pfc.63.2019.08.19.08.56.15; Mon, 19 Aug 2019 08:56:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727639AbfHSPzF convert rfc822-to-8bit (ORCPT + 99 others); Mon, 19 Aug 2019 11:55:05 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:46320 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726959AbfHSPzF (ORCPT ); Mon, 19 Aug 2019 11:55:05 -0400 Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x7JFlmWf082713 for ; Mon, 19 Aug 2019 11:55:04 -0400 Received: from smtp.notes.na.collabserv.com (smtp.notes.na.collabserv.com [192.155.248.73]) by mx0a-001b2d01.pphosted.com with ESMTP id 2ufwaec2pf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 19 Aug 2019 11:55:04 -0400 Received: from localhost by smtp.notes.na.collabserv.com with smtp.notes.na.collabserv.com ESMTP for from ; Mon, 19 Aug 2019 15:55:03 -0000 Received: from us1a3-smtp04.a3.dal06.isc4sb.com (10.106.154.237) by smtp.notes.na.collabserv.com (10.106.227.90) with smtp.notes.na.collabserv.com ESMTP; Mon, 19 Aug 2019 15:54:57 -0000 Received: from us1a3-mail162.a3.dal06.isc4sb.com ([10.146.71.4]) by us1a3-smtp04.a3.dal06.isc4sb.com with ESMTP id 2019081915545714-682546 ; Mon, 19 Aug 2019 15:54:57 +0000 In-Reply-To: <20190819150723.GH5058@ziepe.ca> Subject: Re: Re: Re: Re: [PATCH] RDMA/siw: Fix compiler warnings on 32-bit due to u64/pointer abuse From: "Bernard Metzler" To: "Jason Gunthorpe" Cc: "Geert Uytterhoeven" , "Doug Ledford" , linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org Date: Mon, 19 Aug 2019 15:54:56 +0000 MIME-Version: 1.0 Sensitivity: Importance: Normal X-Priority: 3 (Normal) References: <20190819150723.GH5058@ziepe.ca>,<20190819141856.GG5058@ziepe.ca> <20190819135213.GF5058@ziepe.ca> <20190819122456.GB5058@ziepe.ca> <20190819100526.13788-1-geert@linux-m68k.org> X-Mailer: IBM iNotes ($HaikuForm 1054) | IBM Domino Build SCN1812108_20180501T0841_FP55 May 22, 2019 at 11:09 X-LLNOutbound: False X-Disclaimed: 48307 X-TNEFEvaluated: 1 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset=UTF-8 x-cbid: 19081915-8877-0000-0000-000000D9CA43 X-IBM-SpamModules-Scores: BY=0.002744; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.40962; ST=0; TS=0; UL=0; ISC=; MB=0.006883 X-IBM-SpamModules-Versions: BY=3.00011618; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000287; SDB=6.01249118; UDB=6.00659382; IPR=6.01030652; MB=3.00028235; MTD=3.00000008; XFM=3.00000015; UTC=2019-08-19 15:55:01 X-IBM-AV-DETECTION: SAVI=unsuspicious REMOTE=unsuspicious XFE=unused X-IBM-AV-VERSION: SAVI=2019-08-19 14:23:28 - 6.00010304 x-cbparentid: 19081915-8878-0000-0000-000003B8E432 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-08-19_03:,, signatures=0 X-Proofpoint-Spam-Reason: safe Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org -----"Jason Gunthorpe" wrote: ----- >To: "Bernard Metzler" >From: "Jason Gunthorpe" >Date: 08/19/2019 05:07PM >Cc: "Geert Uytterhoeven" , "Doug Ledford" >, linux-rdma@vger.kernel.org, >linux-kernel@vger.kernel.org >Subject: [EXTERNAL] Re: Re: Re: [PATCH] RDMA/siw: Fix compiler >warnings on 32-bit due to u64/pointer abuse > >On Mon, Aug 19, 2019 at 02:52:13PM +0000, Bernard Metzler wrote: >> >> >To: "Bernard Metzler" >> >From: "Jason Gunthorpe" >> >Date: 08/19/2019 04:19PM >> >Cc: "Geert Uytterhoeven" , "Doug Ledford" >> >, linux-rdma@vger.kernel.org, >> >linux-kernel@vger.kernel.org >> >Subject: [EXTERNAL] Re: Re: Re: [PATCH] RDMA/siw: Fix compiler >> >warnings on 32-bit due to u64/pointer abuse >> > >> >On Mon, Aug 19, 2019 at 02:15:36PM +0000, Bernard Metzler wrote: >> >> >> >> >To: "Bernard Metzler" >> >> >From: "Jason Gunthorpe" >> >> >Date: 08/19/2019 03:52PM >> >> >Cc: "Geert Uytterhoeven" , "Doug Ledford" >> >> >, linux-rdma@vger.kernel.org, >> >> >linux-kernel@vger.kernel.org >> >> >Subject: [EXTERNAL] Re: Re: [PATCH] RDMA/siw: Fix compiler >> >warnings >> >> >on 32-bit due to u64/pointer abuse >> >> > >> >> >On Mon, Aug 19, 2019 at 01:36:11PM +0000, Bernard Metzler >wrote: >> >> >> >If the value is really a kernel pointer, then it ought to be >> >> >printed >> >> >> >with %p. We have been getting demanding on this point lately >in >> >> >RDMA >> >> >> >to enforce the ability to keep kernel pointers secret. >> >> >> > >> >> >> >> - wqe->sqe.sge[0].laddr = (u64)&wqe->sqe.sge[1]; >> >> >> >> + wqe->sqe.sge[0].laddr = (uintptr_t)&wqe->sqe.sge[1]; >> >> >> > >> >> >> >[..] >> >> >> > >> >> >> >> rv = siw_rx_kva(srx, >> >> >> >> - (void *)(sge->laddr + frx->sge_off), >> >> >> >> + (void *)(uintptr_t)(sge->laddr + frx->sge_off), >> >> >> >> sge_bytes); >> >> >> > >> >> >> >Bernard, this is nonsense, what is going on here with >> >sge->laddr >> >> >that >> >> >> >it can't be a void *? >> >> >> > >> >> >> siw_sge is defined in siw-abi.h. We make the address u64 to >keep >> >> >the ABI >> >> >> arch independent. >> >> > >> >> >Eh? How does the siw-abi.h store a kernel pointer? Sounds like >> >kernel >> >> >and user types are being mixed. >> >> > >> >> >> >> siw-abi.h defines the work queue elements of a siw send queue. >> >> For user land, the send queue is mmapped. Kernel or user land >> >> clients write to its send queue when posting work >> >> (SGE: buffer address, length, local key). >> > >> >Should have different types.. Don't want to accidently mix a laddr >> >under user control with one under kernel control. >> > >> Well we have an unsigned 64bit for both user and kernel >> application buffer addresses throughout the rdma stack, > >We do not. Kernel addresses are consistenyly void * or dma_addr_t > Absolutely. But these addresses are conveyed through the API as unsigned 64 during post_send(), and land in the siw send queue as is. During send queue processing, these addresses must be interpreted according to its context and transformed (casted) back to the callers intention. I frankly do not know what we can do differently... The representation of all addresses as unsigned 64 is given. Sorry for the confusion. >Most places that consume a data address are using lkeys anyhow, which >does have a lkey & u64, but that u64 is not a application buffer >address, but the IOVA of the lkey, which is very different. > >I really have no idea why siw needs to mix kernel VAs with user >pointers, particularly in wqes... > >Jason > >