RE: [PATCH v4 19/19] IB/mad: Implement Intel Omni-Path Architecture MAD processing

2015-04-03 Thread Hefty, Sean
> diff --git a/drivers/infiniband/core/agent.c > b/drivers/infiniband/core/agent.c > index b6bd305..18275a5 100644 > --- a/drivers/infiniband/core/agent.c > +++ b/drivers/infiniband/core/agent.c > @@ -80,13 +80,17 @@ ib_get_agent_port(struct ib_device *device, int > port_num) > > void agent_send_

RE: [PATCH v4 15/19] IB/mad: Create jumbo_mad data structures

2015-04-03 Thread Hefty, Sean
> > diff --git a/include/rdma/ib_mad.h b/include/rdma/ib_mad.h > > index 00a5e51..80e7cf4 100644 > > --- a/include/rdma/ib_mad.h > > +++ b/include/rdma/ib_mad.h > > @@ -136,6 +136,11 @@ enum { > > IB_MGMT_DEVICE_HDR = 64, > > IB_MGMT_DEVICE_DATA = 192, > > IB_MGMT_MAD_SIZE = IB_MGMT_MAD

RE: [PATCH v4 18/19] IB/mad: Implement Intel Omni-Path Architecture SMP processing

2015-04-03 Thread Hefty, Sean
> @@ -236,6 +252,24 @@ enum smi_action smi_handle_dr_smp_recv(struct ib_smp > *smp, u8 node_type, > smp->dr_slid == IB_LID_PERMISSIVE); > } > > +/* > + * Adjust information for a received SMP > + * Return 0 if the SMP should be dropped The function returns a

RE: [PATCH v4 17/19] IB/mad: Implement support for Intel Omni-Path Architecture base version MADs in ib_create_send_mad

2015-04-03 Thread Hefty, Sean
> @@ -937,20 +937,31 @@ struct ib_mad_send_buf * ib_create_send_mad(struct > ib_mad_agent *mad_agent, > struct ib_mad_send_wr_private *mad_send_wr; > int pad, message_size, ret, size; > void *buf; > + size_t mad_size; > + int opa; > > mad_agent_priv = container_of(m

RE: [PATCH v4 16/19] IB/mad: Add Intel Omni-Path Architecture defines

2015-04-03 Thread Hefty, Sean
> /* Registration table sizes */ > #define MAX_MGMT_CLASS 80 > -#define MAX_MGMT_VERSION 8 > +#define MAX_MGMT_VERSION 0x83 It's unfortunate that this results in a big jump in used versions. Mad_priv.h defines this: struct ib_mad_port_private { ... struct

RE: [PATCH v4 15/19] IB/mad: Create jumbo_mad data structures

2015-04-03 Thread Hefty, Sean
> Define jumbo_mad and jumbo_rmpp_mad. I would just use 'opa_mad' in place of 'jumbo_mad'. Jumbo sounds like a marketing term or elephant name. > Jumbo MAD structures are 2K versions of ib_mad and ib_rmpp_mad structures. > Currently only OPA base version MADs are of this type. > > Create an R

RE: [PATCH v4 12/19] IB/mad: Add MAD size parameters to process_mad

2015-04-03 Thread Hefty, Sean
> -static struct ib_mad_private *alloc_mad_priv(struct ib_device *dev) > +static struct ib_mad_private *alloc_mad_priv(struct ib_device *dev, > + size_t *mad_size) > { > + *mad_size = dev->cached_dev_attrs.max_mad_size; Why does this function return th

RE: [PATCH v4 08/19] IB/mad: Add helper function for smi_handle_dr_smp_send

2015-04-03 Thread Hefty, Sean
Reviewed-by: Sean Hefty -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

RE: [PATCH v4 04/19] IB/mad: Change ib_response_mad signature to take ib_mad_hdr rather than ib_mad

2015-04-03 Thread Hefty, Sean
Reviewed-by: Sean Hefty -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

RE: [PATCH v4 03/19] IB/mad: Change validate_mad signature to take ib_mad_hdr rather than ib_mad

2015-04-03 Thread Hefty, Sean
Reviewed-by: Sean Hefty -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

RE: [PATCH v4 02/19] IB/core: Cache device attributes for use by upper level drivers

2015-04-03 Thread Hefty, Sean
> diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h > index 0d74f1d..0116e4b 100644 > --- a/include/rdma/ib_verbs.h > +++ b/include/rdma/ib_verbs.h > @@ -1675,6 +1675,7 @@ struct ib_device { > u32 local_dma_lkey; > u8 node_

Re: [oss-security] RE: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access

2015-04-03 Thread Dominique Martinet
Hi, Shachar Raindel wrote on Fri, Apr 03, 2015 at 11:49:13AM +: > > couldn't get it to work - ibv_reg_mr would return EINVAL on an address > > obtained by mmap. > > Were you mmaping a normal disk file, or was the mmap targeting an MMIO of > another hardware device? mmap of a normal disk file

Re: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access

2015-04-03 Thread Yann Droneaud
Hi, Le vendredi 03 avril 2015 à 08:39 +, Haggai Eran a écrit : > On Thursday, April 2, 2015 11:40 PM, Yann Droneaud > wrote: > > Le jeudi 02 avril 2015 à 16:44 +, Shachar Raindel a écrit : > >> > -Original Message- > >> > From: Yann Droneaud [mailto:ydrone...@opteya.com] > >> > S

RE: [oss-security] RE: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access

2015-04-03 Thread Shachar Raindel
Hi Dominique, > -Original Message- > From: Dominique Martinet [mailto:dominique.marti...@cea.fr] > Sent: Thursday, April 02, 2015 8:44 PM > To: Shachar Raindel > Subject: Re: [oss-security] RE: CVE-2014-8159 kernel: infiniband: > uverbs: unprotected physical memory access > > Hi, > > Sha

Re: CVE-2014-8159 kernel: infiniband: uverbs: unprotected physical memory access

2015-04-03 Thread Haggai Eran
On Thursday, April 2, 2015 11:40 PM, Yann Droneaud wrote: > Le jeudi 02 avril 2015 à 16:44 +, Shachar Raindel a écrit : >> > -Original Message- >> > From: Yann Droneaud [mailto:ydrone...@opteya.com] >> > Sent: Thursday, April 02, 2015 7:35 PM > >> > Another related question: as the la