- 11 7月, 2019 1 次提交
-
-
由 Daniel P. Berrangé 提交于
Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 04 2月, 2019 1 次提交
-
-
由 Cole Robinson 提交于
Missing semicolon at the end of macros can confuse some analyzers (like cppcheck <filename>). VIR_ONCE_GLOBAL_INIT is almost exclusively called without an ending semicolon, but let's standardize on using one like the other macros. Add a dummy struct definition at the end of the macro, so the compiler will require callers to add a semicolon. Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NCole Robinson <crobinso@redhat.com>
-
- 14 12月, 2018 1 次提交
-
-
由 Daniel P. Berrangé 提交于
In many files there are header comments that contain an Author: statement, supposedly reflecting who originally wrote the code. In a large collaborative project like libvirt, any non-trivial file will have been modified by a large number of different contributors. IOW, the Author: comments are quickly out of date, omitting people who have made significant contribitions. In some places Author: lines have been added despite the person merely being responsible for creating the file by moving existing code out of another file. IOW, the Author: lines give an incorrect record of authorship. With this all in mind, the comments are useless as a means to identify who to talk to about code in a particular file. Contributors will always be better off using 'git log' and 'git blame' if they need to find the author of a particular bit of code. This commit thus deletes all Author: comments from the source and adds a rule to prevent them reappearing. The Copyright headers are similarly misleading and inaccurate, however, we cannot delete these as they have legal meaning, despite being largely inaccurate. In addition only the copyright holder is permitted to change their respective copyright statement. Reviewed-by: NErik Skultety <eskultet@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 25 7月, 2018 2 次提交
-
-
由 Daniel P. Berrangé 提交于
Consider creating a listener socket from a hostname that resolves to multiple addresses. It might be the case that the hostname resolves to both an IPv4 and IPv6 address because it is reachable over both protocols, but the IPv6 connectivity is provided off-host. In such a case no local NIC will have IPv6 and so bind() would fail with the EADDRNOTAVAIL errno. Thus it should be treated as non-fatal as long as at least one socket was succesfully bound. Reviewed-by: NJiri Denemark <jdenemar@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
由 Daniel P. Berrangé 提交于
When reporting socket/bind failures we want to ensure any fatal error reported is as accurate as possible. We'll prefer reporting a bind() errno over a socket() errno, because if socket() works but bind() fails that is a more significant event. Reviewed-by: NJiri Denemark <jdenemar@redhat.com> Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 23 7月, 2018 1 次提交
-
-
由 Andrea Bolognani 提交于
Currently, the functions return a pointer to the destination buffer on success or NULL on failure. Not only does this kind of error handling look quite alien in the context of libvirt, where most functions return zero on success and a negative int on failure, but it's also somewhat pointless because unless there's been a failure the returned pointer will be the same one passed in by the user, thus offering no additional value. Change the functions so that they return an int instead. Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
-
- 04 5月, 2018 1 次提交
-
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com>
-
- 18 4月, 2018 1 次提交
-
-
由 Michal Privoznik 提交于
So far we are repeating the following lines over and over: if (!(virSomeObjectClass = virClassNew(virClassForObject(), "virSomeObject", sizeof(virSomeObject), virSomeObjectDispose))) return -1; While this works, it is impossible to do some checking. Firstly, the class name (the 2nd argument) doesn't match the name in the code in all cases (the 3rd argument). Secondly, the current style is needlessly verbose. This commit turns example into following: if (!(VIR_CLASS_NEW(virSomeObject, virClassForObject))) return -1; Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 06 4月, 2018 1 次提交
-
-
由 Jim Fehlig 提交于
When preparing for migration, the libxl driver creates a new TCP listen socket for the incoming migration by calling virNetSocketNewListenTCP, passing the destination host name. virNetSocketNewListenTCP calls virSocketAddrParse to check if the host name is a wildcard address, in which case it avoids adding the AI_ADDRCONFIG flag to the hints passed to getaddrinfo. If the host name is not an IP address, virSocketAddrParse reports an error error : virSocketAddrParseInternal:121 : Cannot parse socket address 'myhost.example.com': Name or service not known But virNetSocketNewListenTCP succeeds regardless and the overall migration operation succeeds. Introduce virSocketAddrParseAny and use it when simply testing if a host name/addr is parsable. Signed-off-by: NJim Fehlig <jfehlig@suse.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 26 1月, 2018 1 次提交
-
-
由 Daniel P. Berrange 提交于
The virNetSocketWriteSASL method has to encode the buffer it is given and then write it to the underlying socket. This write is not guaranteed to send the full amount of data that was encoded by SASL. We cache the SASL encoded data so that on the next invocation of virNetSocketWriteSASL we carry on sending it. The subtle problem is that the 'len' value passed into virNetSocketWriteSASL on the 2nd call may be larger than the original value. So when we've completed sending the SASL encoded data we previously cached, we must return the original length we encoded, not the new length. This flaw means we could potentially have been discarded queued data without sending it. This would have exhibited itself as a libvirt client never receiving the reply to a method it invokes, async events silently going missing, or worse stream data silently getting dropped. For this to be a problem libvirtd would have to be queued data to send to the client, while at the same time the TCP socket send buffer is full (due to a very slow client). This is quite unlikely so if this bug was ever triggered by a real world user it would be almost impossible to reproduce or diagnose, if indeed it was ever noticed at all. Reviewed-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 30 8月, 2017 1 次提交
-
-
由 Daniel P. Berrange 提交于
Inspired by the recent GIT / Mercurial security flaws (http://blog.recurity-labs.com/2017-08-10/scm-vulns), consider someone/something manages to feed libvirt a bogus URI such as: virsh -c qemu+ssh://-oProxyCommand=gnome-calculator/system In this case, the hosname "-oProxyCommand=gnome-calculator" will get interpreted as an argument to ssh, not a hostname. Fortunately, due to the set of args we have following the hostname, SSH will then interpret our bit of shell script that runs 'nc' on the remote host as a cipher name, which is clearly invalid. This makes ssh exit during argv parsing and so it never tries to run gnome-calculator. We are lucky this time, but lets be more paranoid, by using '--' to explicitly tell SSH when it has finished seeing command line options. This forces it to interpret "-oProxyCommand=gnome-calculator" as a hostname, and thus see a fail from hostname lookup. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 18 3月, 2017 1 次提交
-
-
由 Peter Krempa 提交于
In some cases a read error due to connection hangup is expected. This patch adds a flag that removes the logging of a virError in such case.
-
- 15 11月, 2016 2 次提交
-
-
由 Pino Toscano 提交于
Implement in virtNetClient and VirNetSocket the needed functions to expose a new libssh transport, providing all the options that the libssh2 transport supports.
-
由 Pino Toscano 提交于
Add an internal variable to mark the FD as "not owned" by the virNetSocket, in case the internal implementation takes the actual ownership of the descriptor; this avoids a warning when closing the socket, as the FD would be invalid.
-
- 24 6月, 2016 4 次提交
-
-
由 Ján Tomko 提交于
Rename them to virNetSocket{Local,Remote}AddrStringSASL to make their format more obvious.
-
由 Ján Tomko 提交于
Make it more obvious that these are in the SASL format.
-
由 Ján Tomko 提交于
It will return the socket address and port in a URI-like format: [::1]:1234 Add a test case to virnetsockettest.
-
由 Ján Tomko 提交于
This partially reverts commit 9b45c9f0. It changed the default format of socket address from the one SASL requires, but did not adjust all the callers. It also removed the test coverage for it. Revert most of the changes except the virSocketAddrFormatFull support for URI-formatted strings. This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1345743 while reverting the format used by virt-admin's client-info command from the URI one to the SASL one. https://bugzilla.redhat.com/show_bug.cgi?id=1345743
-
- 03 5月, 2016 1 次提交
-
-
由 Erik Skultety 提交于
Our socket address format is in a rather non-standard format and that is because sasl library requires the IP address and service to be delimited by a semicolon. The string form is a completely internal matter, however once the admin interfaces to retrieve client identity information are merged, we should return the socket address string in a common format, e.g. format defined by URI rfc-3986, i.e. the IP address and service are delimited by a colon and in case of an IPv6 address, square brackets are added: Examples: 127.0.0.1:1234 [::1]:1234 This patch changes our default format to the one described above, while adding separate methods to request the non-standard SASL format using semicolon as a delimiter. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
- 17 3月, 2016 1 次提交
-
-
由 Cole Robinson 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1271183 We only wait 0.5 seconds for the session daemon to start up and present its socket, which isn't sufficient for many users. Bump up the sleep interval and retry amount so we wait for a total of 5.0 seconds.
-
- 12 1月, 2016 4 次提交
-
-
由 Cole Robinson 提交于
On every socket connect(2) attempt we were re-launching session libvirtd, up to 100 times in 5 seconds. This understandably caused some weird load races and intermittent qemu:///session startup failures https://bugzilla.redhat.com/show_bug.cgi?id=1271183
-
由 Cole Robinson 提交于
When we autolaunch libvirtd for session URIs, we spin in a retry loop waiting for the daemon to start and the connect(2) to succeed. However if we exceed the retry count, we don't explicitly raise an error, which can yield a slew of different error messages elsewhere in the code. Explicitly raise the last connect(2) failure if we run out of retries.
-
由 Cole Robinson 提交于
- Add some debugging - Make the loop dependent only on retries - Make it explicit that connect(2) success exits the loop - Invert the error checking logic
-
OpenBSD uses 'struct sockpeercred' instead of 'struct ucred'. Add a configure check that detects its presence and use if in the code that could be compiled on OpenBSD. Signed-off-by: NRoman Bogorodskiy <bogorodskiy@gmail.com>
-
- 04 11月, 2015 1 次提交
-
-
由 Jiri Denemark 提交于
VIR_DEBUG and VIR_WARN will automatically add a new line to the message, having "\n" at the end or at the beginning of the message results in empty lines. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 12 8月, 2015 1 次提交
-
-
由 Guido Günther 提交于
When running the test suite using "unshare -n" we might have IPv6 but no configured addresses. Due to AI_ADDRCONFIG getaddrinfo then fails with EAI_NONAME which we should then treat as IPv6 unavailable.
-
- 17 7月, 2015 1 次提交
-
-
由 Daniel P. Berrange 提交于
The auto-spawn code would originally attempt to spawn the daemon for both ENOENT and ECONNREFUSED errors from connect(). The various refactorings eventually lost this so we only spawn the daemon on ENOENT. The result is if the daemon exits uncleanly, so that the socket is left in the filesystem, we will never be able to auto-spawn the daemon again.
-
- 19 6月, 2015 2 次提交
-
-
由 Michal Privoznik 提交于
Although highly unlikely, nobody says that virEventAddHandle() can't return 0 as a handle to socket callback. It can't happen with our default implementation since all watches will have value 1 or greater, but users can register their own callback functions (which can re-use unused watch IDs for instance). If this is the case, weird things may happen. Also, there's a little bug I'm fixing too, upon virNetSocketRemoveIOCallback(), the variable holding callback ID was not reset. Therefore calling AddIOCallback() once again would fail. Not that we are doing it right now, but we might. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
When going through the code I've notice that virNetSocketAddIOCallback() increases the reference counter of @socket. However, its counter part RemoveIOCallback does not. It took me a while to realize this disproportion. The AddIOCallback registers our own callback which eventually calls the desired callback and then unref the @sock. Yeah, a bit complicated but it works. So, lets note this hard learned fact in a comment in RemoveIOCallback(). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 11 6月, 2015 2 次提交
-
-
由 Daniel P. Berrange 提交于
The socket test suite has a function for checking if IPv4 or IPv6 are available, and returning a free socket. The first bit of that will be needed in another test, so pull that logic out into a separate helper method. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
By default, getaddrinfo() will return addresses for both IPv4 and IPv6 if both protocols are enabled, and so the RPC code will listen/connect to both protocols too. There may be cases where it is desirable to restrict this to just one of the two protocols, so add an 'int family' parameter to all the TCP related APIs. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 24 4月, 2015 1 次提交
-
-
由 Jiri Denemark 提交于
==26726== by 0x673CD67: __vasprintf_chk (vasprintf_chk.c:80) ==26726== by 0x5673605: UnknownInlinedFun (stdio2.h:210) ==26726== by 0x5673605: virVasprintfInternal (virstring.c:476) ==26726== by 0x56736EE: virAsprintfInternal (virstring.c:497) ==26726== by 0x5680C37: virGetUserRuntimeDirectory (virutil.c:866) ==26726== by 0x5783A89: virNetSocketNewConnectUNIX (virnetsocket.c:572) ==26726== by 0x57751AF: virNetClientNewUNIX (virnetclient.c:344) ==26726== by 0x57689B3: doRemoteOpen (remote_driver.c:895) ==26726== by 0x5769F8E: remoteConnectOpen (remote_driver.c:1195) ==26726== by 0x57092DF: do_open (libvirt.c:1189) ==26726== by 0x570A7BF: virConnectOpenAuth (libvirt.c:1341) https://bugzilla.redhat.com/show_bug.cgi?id=1215042Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 17 4月, 2015 1 次提交
-
-
由 Michal Privoznik 提交于
There is a possibility that we jump onto error label with @lockpath still initialized to NULL. Here, the @lockpath should be unlink()-ed, but passing there a NULL is not a good idea. Don't do that. In fact, we should call unlink() only if we created the lock file successfully. Reported-by: NJohn Ferlan <jferlan@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 15 4月, 2015 1 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1200149 Even though we have a mutex mechanism so that two clients don't spawn two daemons, it's not strong enough. It can happen that while one client is spawning the daemon, the other one fails to connect. Basically two possible errors can happen: error: Failed to connect socket to '/home/mprivozn/.cache/libvirt/libvirt-sock': Connection refused or: error: Failed to connect socket to '/home/mprivozn/.cache/libvirt/libvirt-sock': No such file or directory The problem in both cases is, the daemon is only starting up, while we are trying to connect (and fail). We should postpone the connecting phase until the daemon is started (by the other thread that is spawning it). In order to do that, create a file lock 'libvirt-lock' in the directory where session daemon would create its socket. So even when called from multiple processes, spawning a daemon will serialize on the file lock. So only the first to come will spawn the daemon. Tested-by: NRichard W. M. Jones <rjones@redhat.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 20 11月, 2014 1 次提交
-
-
由 Giuseppe Scrivano 提交于
getsockopt(sock->fd, SOL_SOCKET, SO_PEERCRED, ...) sets the pid to 0 when the process that opens the connection is in another container. Signed-off-by: NGiuseppe Scrivano <gscrivan@redhat.com>
-
- 17 9月, 2014 1 次提交
-
-
由 Martin Kletzander 提交于
This way it behaves more like the daemon itself does (acquiring a pidfile, deleting the socket before binding, etc.). Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=927369 Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1138604Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 15 9月, 2014 1 次提交
-
-
由 Martin Kletzander 提交于
Just remove useless "else". Best viewed with '-w'. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 09 9月, 2014 1 次提交
-
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 05 9月, 2014 1 次提交
-
-
由 Eric Blake 提交于
I'm about to add a syntax check that enforces our documented HACKING style of always using matching {} on if-else statements. This patch focuses on all remaining problems, where there weren't enough issues to warrant splitting it further. * src/remote/remote_driver.c (doRemoteOpen): Correct use of {}. * src/security/virt-aa-helper.c (vah_add_path, valid_path, main): Likewise. * src/rpc/virnetsocket.c (virNetSocketNewConnectLibSSH2): Likewise. * src/esx/esx_vi_types.c (esxVI_Type_FromString): Likewise. * src/uml/uml_driver.c (umlDomainDetachDevice): Likewise. * src/util/viralloc.c (virShrinkN): Likewise. * src/util/virbuffer.c (virBufferURIEncodeString): Likewise. * src/util/virdbus.c (virDBusCall): Likewise. * src/util/virnetdev.c (virNetDevValidateConfig): Likewise. * src/util/virnetdevvportprofile.c (virNetDevVPortProfileGetNthParent): Likewise. * src/util/virpci.c (virPCIDeviceIterDevices) (virPCIDeviceWaitForCleanup) (virPCIDeviceIsBehindSwitchLackingACS): Likewise. * src/util/virsocketaddr.c (virSocketAddrGetNumNetmaskBits): Likewise. * src/util/viruri.c (virURIParseParams): Likewise. * daemon/stream.c (daemonStreamHandleAbort): Likewise. * tests/testutils.c (virtTestResult): Likewise. * tests/cputest.c (cpuTestBaseline): Likewise. * tools/virsh-domain.c (cmdDomPMSuspend): Likewise. * tools/virsh-host.c (cmdNodeSuspend): Likewise. * src/esx/esx_vi_generator.py (Type.generate_typefromstring): Tweak generated code. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 01 9月, 2014 1 次提交
-
-
由 Christophe Fergeau 提交于
Since 1b807f92, connecting with virsh to an already running session libvirtd fails with: $ virsh list --all error: failed to connect to the hypervisor error: no valid connection error: Failed to connect socket to '/run/user/1000/libvirt/libvirt-sock': Transport endpoint is already connected This is caused by a logic error in virNetSocketNewConnectUnix: even if the connection to the daemon socket succeeded, we still try to spawn the daemon and then connect to it. This commit changes the logic to not try to spawn libvirtd if we successfully connected to its socket. Most of this commit is whitespace changes, use of -w is recommended to look at it.
-