From mboxrd@z Thu Jan 1 00:00:00 1970 From: Haggai Eran Subject: Re: [PATCH 1/3] IB/uverbs: reject invalid or unknown opcodes Date: Mon, 24 Aug 2015 10:59:21 +0300 Message-ID: <55DACED9.4060603@mellanox.com> References: <1440002254-795-1-git-send-email-hch@lst.de> <20150822082516.GC1857@lst.de> <55DABF1E.2050804@mellanox.com> <20150824065501.GA31990@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150824065501.GA31990-jcswGhMUV9g@public.gmane.org> Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Christoph Hellwig Cc: Sagi Grimberg , Doug Ledford , Sean Hefty , Hal Rosenstock , Eli Cohen , "linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: linux-rdma@vger.kernel.org On 24/08/2015 09:55, Christoph Hellwig wrote: > On Mon, Aug 24, 2015 at 09:52:14AM +0300, Haggai Eran wrote: >> Okay. Maybe you can just add a case for IB_WR_SEND in this patch to >> avoid hurting bisectability. > > I've done this already, just waiting for more feedback before resending: > > http://git.infradead.org/users/hch/rdma.git/commitdiff/20f34ca8ecac302984f3a92b9ad29f5f4b41780d Great. >> Looking at the uverbs part in patch 2, I think the changes are okay. I >> noticed there's a (__be32 __force) cast of the immediate data from >> userspace (it was already in the existing code). I wonder, why not >> define the field in the uapi struct as __be32 in the first place? > > It looks odd to me as well, but it's not really something I want to > change in this series. Note that sparse annoted types like __be32 > aren't really common in userspace, but with a bit of effort they can > be supported. We have them and regularly run sparse for xfsprogs for > example. I have to try it with libibverbs sometime. It doesn't use uapi yet though IIRC - it has its own version of the header files. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-db3on0082.outbound.protection.outlook.com ([157.55.234.82]:13089 "EHLO emea01-db3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753804AbbHXINq (ORCPT ); Mon, 24 Aug 2015 04:13:46 -0400 Subject: Re: [PATCH 1/3] IB/uverbs: reject invalid or unknown opcodes To: Christoph Hellwig References: <1440002254-795-1-git-send-email-hch@lst.de> <20150822082516.GC1857@lst.de> <55DABF1E.2050804@mellanox.com> <20150824065501.GA31990@lst.de> CC: Sagi Grimberg , Doug Ledford , Sean Hefty , Hal Rosenstock , Eli Cohen , "linux-rdma@vger.kernel.org" , "stable@vger.kernel.org" From: Haggai Eran Message-ID: <55DACED9.4060603@mellanox.com> Date: Mon, 24 Aug 2015 10:59:21 +0300 MIME-Version: 1.0 In-Reply-To: <20150824065501.GA31990@lst.de> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org List-ID: On 24/08/2015 09:55, Christoph Hellwig wrote: > On Mon, Aug 24, 2015 at 09:52:14AM +0300, Haggai Eran wrote: >> Okay. Maybe you can just add a case for IB_WR_SEND in this patch to >> avoid hurting bisectability. > > I've done this already, just waiting for more feedback before resending: > > http://git.infradead.org/users/hch/rdma.git/commitdiff/20f34ca8ecac302984f3a92b9ad29f5f4b41780d Great. >> Looking at the uverbs part in patch 2, I think the changes are okay. I >> noticed there's a (__be32 __force) cast of the immediate data from >> userspace (it was already in the existing code). I wonder, why not >> define the field in the uapi struct as __be32 in the first place? > > It looks odd to me as well, but it's not really something I want to > change in this series. Note that sparse annoted types like __be32 > aren't really common in userspace, but with a bit of effort they can > be supported. We have them and regularly run sparse for xfsprogs for > example. I have to try it with libibverbs sometime. It doesn't use uapi yet though IIRC - it has its own version of the header files.