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

[Greg KH <gregkh@linuxfoundation.org>]

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
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization