netdev - Re: [PATCH net] net/mlx4: Avoid wrong virtual mappings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 27 Apr 2016 11:21:06 +0300
From:	Haggai Abramovsky <haggaia.linux@...il.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Haggai Abramovsky <hagaya@...lanox.com>,
	"David S. Miller" <davem@...emloft.net>,
	Doug Ledford <dledford@...hat.com>, linux-rdma@...r.kernel.org,
	netdev@...r.kernel.org, Sinan Kaya <okaya@...eaurora.org>,
	Timur Tabi <timur@...eaurora.org>,
	Eli Cohen <eli@...lanox.com>,
	Or Gerlitz <ogerlitz@...lanox.com>,
	Eran Ben Elisha <eranbe@...lanox.com>,
	Yishai Hadas <yishaih@...lanox.com>,
	Tal Alon <talal@...lanox.com>,
	Saeed Mahameed <saeedm@...lanox.com>
Subject: Re: [PATCH net] net/mlx4: Avoid wrong virtual mappings

On Wed, Apr 27, 2016 at 10:19 AM, Christoph Hellwig <hch@...radead.org> wrote:
> Hi Haggai,
>
> I've taken a very quick look because I'm a little too busy this week,
> but I failed to grasp the patch, as it seems to do a few too many
> things.  E.g. the whole wqe_shrink thing doesn't correspond to anything
> in the description.

when creating QP from mlx4_ib kernel verbs,  we decide  if we are
going to work using shrinked wqe or regular wqe (not something i
added).
shrinked wqe  means that WQE can be more than one WQE BB (basic block),
regular wqe - means that every WQE is exact one WQE BB,

> How about you split it into easily understanable chunks?

We had internal discussion about this issue.
we decided not to split the patch because it can break kernel
apps/ulps running over the  infiniband driver.
e.g once we removing vmap and not adjust the infiniband driver to work
with fragmented memory,
we can fail when trying to allocate contiguous memory using
dma_zalloc_coherent() while succeeding if trying to allocate
fragmented memory.

> Also now that you split the few places that actually split
> the allocation into chunks to be handled special I think the whole
> mlx4_buf abstraction should go away, as it just obsfucates
> how different the different use cases are.

we still need this mlx4_buf abstraction to store the info on whether
we are working with fragmented memory (can be in IB driver) or direct
memory.

> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html