On Mon, Mar 07, 2011 at 03:06:18PM +0800, Daniel Veillard wrote:
> On Fri, Mar 04, 2011 at 08:53:55AM -0700, Eric Blake wrote:
> > On 03/04/2011 03:30 AM, Daniel Veillard wrote:
> > > virLogEmergencyDumpAll() allows to dump the content of the
> > > debug buffer from within a signal handler. It saves to all
> > > log file or stderr if none is found
> > > * src/util/logging.h src/util/logging.c: add the new API
> > > and cleanup the old virLogDump code
> > > * src/libvirt_private.syms: exports it as a private symbol
> >
> > >
> > > +void
> > > +virLogEmergencyDumpAll(int signum) {
> > > + int ret = 0, len;
> > > + char buf[100];
> > > +
> > > + if (virLogLen == 0)
> > > + return;
> > >
> > > - if ((virLogLen == 0) || (f == NULL))
> > > - return 0;
> > > virLogLock();
> >
> > Is virLogLock async-signal-safe?
>
> I could not find, I'm afraid it's implementation dependant. I would
> expect the lock to be done in user space using an atomic test and set
> op and hence being safe at least on i386 and x86_64.
> The problem is that if we drop the lock we can crash if used on USR2
> while another thread is legitimately running.
Even if the impl was robust there is an architectural problem
with mixing of mutexes and signals. If a thread is running
virLogMessage(), it will be holding the log mutex. If a signal
is processed, and it calls into this new log code, it will
likely deadlock.
Is there a way we can somehow make the global log buffer into
something that can be lockless for readers. ie although our
main log funcs would still need to use the mutex in general
when writing to the buffer, we could read the log buffer
without any locks.
It would probably suffice to make sure we use atomic integer
arithmetic on virLogLen, virLogStart and virLogEnd, and update
them in a specific order to avoid a reader seeing garbage.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list