On Thu, Jul 13, 2017 at 06:44:38PM +0000, Ismail, Mustafa wrote: > > -----Original Message----- > > From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] > > Sent: Thursday, July 13, 2017 11:26 AM > > To: Ismail, Mustafa <mustafa.ism...@intel.com> > > Cc: linux-kernel@vger.kernel.org; linux-r...@vger.kernel.org; > > sta...@vger.kernel.org; Yevgeny Kliteynik <klit...@mellanox.com>; > > Tziporet Koren <tzipo...@mellanox.com>; Alex Polak > > <ale...@mellanox.com>; Boris Pismenny <bor...@mellanox.com>; Leon > > Romanovsky <l...@kernel.org>; Doug Ledford <dledf...@redhat.com> > > Subject: Re: [PATCH 4.4 29/57] RDMA/uverbs: Check port number supplied > > by user verbs cmds > > > > On Thu, Jul 13, 2017 at 03:54:28PM +0000, Ismail, Mustafa wrote: > > > > Subject: [PATCH 4.4 29/57] RDMA/uverbs: Check port number supplied > > > > by user verbs cmds > > > > > > > > 4.4-stable review patch. If anyone has any objections, please let me > > know. > > > > > > Yes, this breaks modify qp. > > > See https://patchwork.kernel.org/patch/9830663/ > > > > I don't understand this response at all, sorry. > > > > What should I do about this? Is this patch alone a problem? Is there some > > other patch I should apply that is in Linus's tree? Where is the problem, > > only in this old release? > > > Applying this patch will break RDMA functionality with respect to modify_qp. > Specifically this part: > + if (cmd.port_num < rdma_start_port(ib_dev) || > + cmd.port_num > rdma_end_port(ib_dev)) > + return -EINVAL; > + > The cmd.port_num is only valid if (cmd->base.attr_mask & IB_QP_PORT). > So the above can be fixed with: > if ((cmd->base.attr_mask & IB_QP_PORT) && > (cmd.port_num < rdma_start_port(ib_dev) || > cmd.port_num > rdma_end_port(ib_dev))) > return -EINVAL; > > A version of this patch is in Linus's tree and it has the same problem: > commit 5ecce4c9b17bed4dc9cb58bfb10447307569b77b "RDMA/uverbs: Check port > number supplied by user verbs cmds" > > We will be submitting a patch to fix this shortly.
Ok, so we will be "bug compatible" with Linus's tree then, right? :) Should I hold off on applying this now, or just stay in sync and wait for your fixes to land in Linus's tree? I vote stay-in-sync, as the other stable trees are also "broken" in the same way right now... thanks, greg k-h
