Hi, Le dimanche 04 mai 2014 à 23:21 +0200, Yann Droneaud a écrit :
> Please find 4 patches which fix some issues regarding missing explicit > padding at end of structure exchanged between kernel and userspace. > I've made a review of all others drivers. I've identified the following structures as part of ABI: cxgb3/iw_cxgb3.o struct iwch_create_cq_req cxgb3/iw_cxgb3.o struct iwch_create_cq_resp cxgb3/iw_cxgb3.o struct iwch_create_qp_resp cxgb3/iw_cxgb3.o struct iwch_reg_user_mr_resp cxgb4/iw_cxgb4.o struct c4iw_alloc_ucontext_resp cxgb4/iw_cxgb4.o struct c4iw_create_cq_resp cxgb4/iw_cxgb4.o struct c4iw_create_qp_resp ehca/ib_ehca.o struct ehca_create_cq_resp ehca/ib_ehca.o struct ehca_create_qp_resp ehca/ib_ehca.o struct ipzu_queue_resp mlx4/mlx4_ib.o struct mlx4_ib_alloc_ucontext_resp mlx4/mlx4_ib.o struct mlx4_ib_alloc_ucontext_resp_v3 mlx4/mlx4_ib.o struct mlx4_ib_create_cq mlx4/mlx4_ib.o struct mlx4_ib_create_qp mlx4/mlx4_ib.o struct mlx4_ib_create_srq mlx4/mlx4_ib.o struct mlx4_ib_resize_cq mlx5/mlx5_ib.o struct mlx5_ib_alloc_pd_resp mlx5/mlx5_ib.o struct mlx5_ib_alloc_ucontext_req_v2 mlx5/mlx5_ib.o struct mlx5_ib_alloc_ucontext_resp mlx5/mlx5_ib.o struct mlx5_ib_create_cq mlx5/mlx5_ib.o struct mlx5_ib_create_qp mlx5/mlx5_ib.o struct mlx5_ib_create_qp_resp mlx5/mlx5_ib.o struct mlx5_ib_create_srq mlx5/mlx5_ib.o struct mlx5_ib_resize_cq mthca/ib_mthca.o struct mthca_alloc_ucontext_resp mthca/ib_mthca.o struct mthca_create_cq mthca/ib_mthca.o struct mthca_create_qp mthca/ib_mthca.o struct mthca_create_srq mthca/ib_mthca.o struct mthca_reg_mr mthca/ib_mthca.o struct mthca_resize_cq nes/iw_nes.o struct nes_alloc_pd_resp nes/iw_nes.o struct nes_alloc_ucontext_req nes/iw_nes.o struct nes_alloc_ucontext_resp nes/iw_nes.o struct nes_create_cq_req nes/iw_nes.o struct nes_create_cq_resp nes/iw_nes.o struct nes_create_qp_req nes/iw_nes.o struct nes_create_qp_resp nes/iw_nes.o struct nes_mem_reg_req ocrdma/ocrdma.o struct ocrdma_alloc_pd_uresp ocrdma/ocrdma.o struct ocrdma_alloc_ucontext_resp ocrdma/ocrdma.o struct ocrdma_create_cq_ureq ocrdma/ocrdma.o struct ocrdma_create_cq_uresp ocrdma/ocrdma.o struct ocrdma_create_qp_ureq ocrdma/ocrdma.o struct ocrdma_create_qp_uresp ocrdma/ocrdma.o struct ocrdma_create_srq_uresp usnic/usnic_verbs.o struct usnic_ib_create_qp_cmd usnic/usnic_verbs.o struct usnic_ib_create_qp_resp usnic/usnic_verbs.o struct usnic_transport_spec It seems that amso1100/iw_c2.o, ipath/ib_ipath.o and qib/ib_qib.o don't make use of structure to exchange data with userspace: they use single values, either u32 or u64. So using pahole I've found issues in mlx5 and cxgb4 only. > These makes i386 userspace libraries and x86_64 kernel disagree about > the size of the structures. > > Additionally, as reported by Dan Carpenter, in one case, stack information > can be leaked by the kernel to userspace due to implicit padding being not > initialized. > > Unfortunately, the data structure cannot be fixed alone as it would break > existing applications. So in order to remain compatible with i386 libraries, > providers (hw) functions are modified to use the input length to guess the > expected format of the command in order to check the content of the reserved > field for future usage. Other are modified to not write the padding field in > response to make the kernel able to handle gracefully i386 userspace on > x86_64. > > For full coherency, patches against the userspace libraries (libcxgb4 and > libmlx5) will be submitted as a followup to update the data structure on > userspace side. > BTW, as I don't have the hardware / I don't have access to the hardware, the patches are not tested against real world. (I only have HCAs handled by mlx4 and qib drivers). Regards. -- Yann Droneaud OPTEYA -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
