summaryrefslogtreecommitdiffstats
path: root/src/vnet/devices/virtio/vhost-user.c
AgeCommit message (Collapse)AuthorFilesLines
2017-02-22VPP-635: CLI Memory leak with invalid parameterBilly McFall1-18/+44
In the CLI parsing, below is a common pattern: /* Get a line of input. */ if (!unformat_user (input, unformat_line_input, line_input)) return 0; while (unformat_check_input (line_input) != UNFORMAT_END_OF_INPUT) { if (unformat (line_input, "x")) x = 1; : else return clib_error_return (0, "unknown input `%U'", format_unformat_error, line_input); } unformat_free (line_input); The 'else' returns if an unknown string is encountered. There a memory leak because the 'unformat_free(line_input)' is not called. There is a large number of instances of this pattern. Replaced the previous pattern with: /* Get a line of input. */ if (!unformat_user (input, unformat_line_input, line_input)) return 0; while (unformat_check_input (line_input) != UNFORMAT_END_OF_INPUT) { if (unformat (line_input, "x")) x = 1; : else { error = clib_error_return (0, "unknown input `%U'", format_unformat_error, line_input); goto done: } } /* ...Remaining code... */ done: unformat_free (line_input); return error; } In multiple files, 'unformat_free (line_input);' was never called, so there was a memory leak whether an invalid string was entered or not. Also, there were multiple instance where: error = clib_error_return (0, "unknown input `%U'", format_unformat_error, line_input); used 'input' as the last parameter instead of 'line_input'. The result is that output did not contain the substring in error, instead just an empty string. Fixed all of those as well. There are a lot of file, and very mind numbing work, so tried to keep it to a pattern to avoid mistakes. Change-Id: I8902f0c32a47dd7fb3bb3471a89818571702f1d2 Signed-off-by: Billy McFall <bmcfall@redhat.com> Signed-off-by: Dave Barach <dave@barachs.net>
2017-02-14Fix is_server flag in vhost dump (VPP-562)Marek Gradzki1-0/+1
Change-Id: I5b308eb39ae770d58d1498d7fafa49b236b3f534 Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
2017-02-14vhost-user: fix crash when descriptor points to unknown regionDamjan Marion1-1/+2
This happens only on when compiled for older microarchitectures, where BSF insutruction is used instead of TZCNT. BSF provides undefined result if operand is 0. Change-Id: I7a13350786a533428168595097ef01a560fde53b Signed-off-by: Damjan Marion <damarion@cisco.com>
2017-02-03vhost-user: fix missing speculative enqueue unwindSteven1-0/+4
Running trex in a VM with a bad config, trex sent a bogus pack from the VM to the Virtual interface. It caused a crash. Change-Id: I64d0197b444265553ab4c24f21e6a962e89cb587 Signed-off-by: Steven <sluong@cisco.com>
2017-01-18Fix coverity warnings, VPP-608Dave Barach1-2/+6
Change-Id: Ib0144ba3a9a09971d3946c932e8fed6d5c1ad278 Signed-off-by: Dave Barach <dave@barachs.net>
2017-01-17Fix crash on deleting activated vhost-user - VPP-603Wojciech Dec1-3/+4
Vhost-user pool getting freed prematurely Change-Id: I952821ec85efa68923d09a643c70b6b309ea2574 Signed-off-by: Wojciech Dec <wdec@cisco.com>
2017-01-10VPP-585: vhost-user interface deletion leaks memory.Ole Troan1-0/+7
Change-Id: I69bbc447e1989adea40f052eac4550036b6e2e1e Signed-off-by: Ole Troan <ot@cisco.com>
2017-01-03VPP-574: fix VPP hang during security group configuration on a suspended VMAndrew Yourtchenko1-0/+4
The unix connect() in vhost-user driver in VPP is blocking, and a non-expedient accept() on the other side causes the entire VPP to hang. Solution: set the nonblocking flag for the socket fd before calling connect(), and set the socket back to blocking after the accept() succeeds. Change-Id: Ia5ee782037eeffabdad71db8241f476a048a4f6f Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
2017-01-03Fix crash on null vhost-user socket - VPP-573Wojciech Dec1-0/+5
Fix for VPP-573. Change-Id: If7d9690901efebf62fdf28219097153d98c79c0c Signed-off-by: Wojciech Dec <wdec@cisco.com>
2016-12-28Reorganize source tree to use single autotools instanceDamjan Marion1-0/+3314
Change-Id: I7b51f88292e057c6443b12224486f2d0c9f8ae23 Signed-off-by: Damjan Marion <damarion@cisco.com>