[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 10 Nov 2010 16:39:20 -0800
From: "Hefty, Sean" <sean.hefty@...el.com>
To: Roland Dreier <rdreier@...co.com>,
Vasiliy Kulikov <segooon@...il.com>
CC: "kernel-janitors@...r.kernel.org" <kernel-janitors@...r.kernel.org>,
Roland Dreier <rolandd@...co.com>,
Hal Rosenstock <hal.rosenstock@...il.com>,
Alex Chiang <achiang@...com>, Andi Kleen <ak@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...e.de>,
Julia Lawall <julia@...u.dk>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] infiniband: core: fix information leak to userland
> Sean, what is intended for qp_state handling here? It seems
> ib_copy_qp_attr_to_user() should either clear it or set it to something
> sensible.
I'm not sure what the original intent was, but both libibcm and librdmacm provide the qp_state as input to the init_qp_attr calls. It doesn't end up mattering if the kernel returns the value because the corresponding call in libibverbs (ibv_copy_qp_attr_from_kern) doesn't copy out the qp_state. So, the value that was originally specified ends up being used. The flow looks something like this:
qp_attr.qp_state = INIT;
cmd.qp_state = qp_attr.qp_state;
write(..cmd..);
ibv_copy_qp_attr_from_kern(&qp_attr, cmd.resp)
I agree that it makes sense for ib_copy_qp_attr_to_user() to set the qp_state. Deciding what to do in libibverbs seems more troublesome.
- Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists