mbox series

[v2,0/5] Clean up error handling in libvhost-user memory mapping

Message ID 20220106064717.7477-1-raphael.norwitz@nutanix.com (mailing list archive)
Headers show
Series Clean up error handling in libvhost-user memory mapping | expand

Message

Raphael Norwitz Jan. 6, 2022, 6:47 a.m. UTC
Hey Stefan, Marc-Andre, MST, David -

As promised here is a series cleaning up error handling in the
libvhost-user memory mapping path. Most of these cleanups are
straightforward and have been discussed on the mailing list in threads
[1] and [2].

[1] https://lore.kernel.org/qemu-devel/20211018143319.GA11006@raphael-debian-dev/
[2] https://lore.kernel.org/qemu-devel/9391f500-70be-26cf-bcfc-591d3ee84d4e@redhat.com/

Changes since V1:
 * Checks for a single fd vu_add_mem_reg and vu_rem_mem_reg return false
   instead of true.
 * Check for over-running max ram slots in vu_add_mem_reg returns false
   instead of true.
 * vu_rem_mem_reg unmaps all matching regions.
 * Decriment iterator variable when looping through regions in
   vu_rem_mem_reg to ensure matching regions aren’t missed.

Thanks,
Raphael

David Hildenbrand (1):
  libvhost-user: Simplify VHOST_USER_REM_MEM_REG

Raphael Norwitz (4):
  libvhost-user: Add vu_rem_mem_reg input validation
  libvhost-user: Add vu_add_mem_reg input validation
  libvhost-user: prevent over-running max RAM slots
  libvhost-user: handle removal of identical regions

 subprojects/libvhost-user/libvhost-user.c | 51 +++++++++++++++--------
 1 file changed, 34 insertions(+), 17 deletions(-)

Comments

David Hildenbrand Jan. 10, 2022, 9:01 a.m. UTC | #1
On 06.01.22 07:47, Raphael Norwitz wrote:
> Hey Stefan, Marc-Andre, MST, David -
> 
> As promised here is a series cleaning up error handling in the
> libvhost-user memory mapping path. Most of these cleanups are
> straightforward and have been discussed on the mailing list in threads
> [1] and [2].
> 

A note that we still want the fix in [3] upstream:

[3] https://lkml.kernel.org/r/20211012183832.62603-1-david@redhat.com
Stefan Hajnoczi Jan. 10, 2022, 11:25 a.m. UTC | #2
On Thu, Jan 06, 2022 at 06:47:24AM +0000, Raphael Norwitz wrote:
> Hey Stefan, Marc-Andre, MST, David -
> 
> As promised here is a series cleaning up error handling in the
> libvhost-user memory mapping path. Most of these cleanups are
> straightforward and have been discussed on the mailing list in threads
> [1] and [2].
> 
> [1] https://lore.kernel.org/qemu-devel/20211018143319.GA11006@raphael-debian-dev/
> [2] https://lore.kernel.org/qemu-devel/9391f500-70be-26cf-bcfc-591d3ee84d4e@redhat.com/
> 
> Changes since V1:
>  * Checks for a single fd vu_add_mem_reg and vu_rem_mem_reg return false
>    instead of true.
>  * Check for over-running max ram slots in vu_add_mem_reg returns false
>    instead of true.
>  * vu_rem_mem_reg unmaps all matching regions.
>  * Decriment iterator variable when looping through regions in
>    vu_rem_mem_reg to ensure matching regions aren’t missed.
> 
> Thanks,
> Raphael
> 
> David Hildenbrand (1):
>   libvhost-user: Simplify VHOST_USER_REM_MEM_REG
> 
> Raphael Norwitz (4):
>   libvhost-user: Add vu_rem_mem_reg input validation
>   libvhost-user: Add vu_add_mem_reg input validation
>   libvhost-user: prevent over-running max RAM slots
>   libvhost-user: handle removal of identical regions
> 
>  subprojects/libvhost-user/libvhost-user.c | 51 +++++++++++++++--------
>  1 file changed, 34 insertions(+), 17 deletions(-)
> 
> -- 
> 2.20.1

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Raphael Norwitz Jan. 10, 2022, 10:36 p.m. UTC | #3
On Mon, Jan 10, 2022 at 10:01:36AM +0100, David Hildenbrand wrote:
> On 06.01.22 07:47, Raphael Norwitz wrote:
> > Hey Stefan, Marc-Andre, MST, David -
> > 
> > As promised here is a series cleaning up error handling in the
> > libvhost-user memory mapping path. Most of these cleanups are
> > straightforward and have been discussed on the mailing list in threads
> > [1] and [2].
> > 
> 
> A note that we still want the fix in [3] upstream:
>
> [3] https://lore.kernel.org/all/20211012183832.62603-1-david@redhat.com/T/#u 

Ah I thought it was merged.

I'll add it to the series to ensure it doesn't get lost.

> 
> 
> -- 
> Thanks,
> 
> David / dhildenb
>