Re: [PATCH] VMCI: Enforce queuepair max size for IOCTL_VMCI_QUEUEPAIR_ALLOC

Greg KH
2021-01-11T14:16:54Z

On Mon, Jan 11, 2021 at 02:05:56PM +0000, Jorgen Hansen wrote:
> On 11 Jan 2021, at 13:46, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Mon, Jan 11, 2021 at 04:18:53AM -0800, Jorgen Hansen wrote:
> >> When create the VMCI queue pair tracking data structures on the host
> >> side, the IOCTL for creating the VMCI queue pair didn't validate
> >> the queue pair size parameters. This change adds checks for this.
> >>
> >> This avoids a memory allocation issue in qp_host_alloc_queue, as
> >> reported by nslusarek@gmx.net. The check in qp_host_alloc_queue
> >> has also been updated to enforce the maximum queue pair size
> >> as defined by VMCI_MAX_GUEST_QP_MEMORY.
> >>
> >> The fix has been verified using sample code supplied by
> >> nslusarek@gmx.net.
> >>
> >> Reported-by: nslusarek@gmx.net
> >> Reviewed-by: Vishnu Dasa <vdasa@vmware.com>
> >> Signed-off-by: Jorgen Hansen <jhansen@vmware.com>
> >> ---
> >> drivers/misc/vmw_vmci/vmci_queue_pair.c | 12 ++++++++----
> >> include/linux/vmw_vmci_defs.h | 4 ++--
> >> 2 files changed, 10 insertions(+), 6 deletions(-)
> >
> > Hi,
> >
> > This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
> > a patch that has triggered this response. He used to manually respond
> > to these common problems, but in order to save his sanity (he kept
> > writing the same thing over and over, yet to different people), I was
> > created. Hopefully you will not take offence and will fix the problem
> > in your patch and resubmit it so that it can be accepted into the Linux
> > kernel tree.
> >
> > You are receiving this message because of the following common error(s)
> > as indicated below:
> >
> > - You sent multiple patches, yet no indication of which ones should be
> > applied in which order. Greg could just guess, but if you are
> > receiving this email, he guessed wrong and the patches didn't apply.
> > Please read the section entitled "The canonical patch format" in the
> > kernel file, Documentation/SubmittingPatches for a description of how
> > to do this so that Greg has a chance to apply these correctly.
> >
> >
> > If you wish to discuss this problem further, or you have questions about
> > how to resolve this issue, please feel free to respond to this email and
> > Greg will reply once he has dug out from the pending patches received
> > from other developers.
> >
> > thanks,
> >
> > greg k-h's patch email bot
>
> Hi,
>
> The patches are independent and should be able to apply in any order;
> I didn’t see any problems when applying them in different orders locally.
>
> I’m hesitant to provide the patches as a series of patches, since one of
> them:
> VMCI: Use set_page_dirty_lock() when unregistering guest memory
> is marked as fixing an original checkin, and should be considered for
> backporting, whereas the others are either not important to backport
> or rely on other recent changes. However, if formatting them as a
> series of misc fixes is preferred, I’ll do that.

If one patch is wanting to be merged now, for 5.11-final, great, don't
send it in a middle of series of other patches that are not, how am I
supposed to know any of this?

Please send them in the proper order, and as individual series for
different releases, if relevant, again, otherwise how am I supposed to
know what to do with them?

thanks,

greg k-h