From: Michael Roth <mdroth@linux.vnet.ibm.com>
To: Luiz Capitulino <lcapitulino@redhat.com>
Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1.1] qemu-ga: fix segv after failure to open log file
Date: Tue, 15 May 2012 09:14:13 -0500 [thread overview]
Message-ID: <20120515141413.GA2967@illuin> (raw)
In-Reply-To: <20120515100432.4999c2e7@doriath.home>
On Tue, May 15, 2012 at 10:04:32AM -0300, Luiz Capitulino wrote:
> On Mon, 14 May 2012 17:04:17 -0500
> Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
>
> > Currently, if we fail to open the specified log file (generally due to a
> > permissions issue), we'll assign NULL to the logfile handle (stderr,
> > initially) used by the logging routines, which can cause a segfault to
> > occur when we attempt to report the error before exiting.
> >
> > Instead, only re-assign if the open() was successful.
> >
> > Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
> > ---
> > qemu-ga.c | 6 ++++--
> > 1 files changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/qemu-ga.c b/qemu-ga.c
> > index 3a88333..e2725c8 100644
> > --- a/qemu-ga.c
> > +++ b/qemu-ga.c
> > @@ -681,6 +681,7 @@ int main(int argc, char **argv)
> > const char *log_filepath = NULL;
> > const char *pid_filepath = QGA_PIDFILE_DEFAULT;
> > const char *state_dir = QGA_STATEDIR_DEFAULT;
> > + FILE *log_file;
> > #ifdef _WIN32
> > const char *service = NULL;
> > #endif
> > @@ -836,12 +837,13 @@ int main(int argc, char **argv)
> > become_daemon(pid_filepath);
> > }
> > if (log_filepath) {
> > - s->log_file = fopen(log_filepath, "a");
> > - if (!s->log_file) {
> > + log_file = fopen(log_filepath, "a");
> > + if (!log_file) {
> > g_critical("unable to open specified log file: %s",
> > strerror(errno));
> > goto out_bad;
> > }
> > + s->log_file = log_file;
>
> Is it safe to change the log file this way? Isn't it necessary
> to go through g_log_set_default_handler() or some other function?
Are you worried about a race condition? g_log_set_default_handler() does
do locking, but our log handler is actually unchanged, so the only case
it would be needed is if the opaque argument changes, or there were
multiple fields changed in the opaque, since that might result it an
undefined mix of old/new values.
The locking for the actual fields in the opaque is our responsibility,
and there's no way to get glib to comply (short of duplicating the
opaque and then using g_log_set_default_handler(), since g_messages_lock
isn't exposed)
But since we're only changing a single field, the FILE* the log handler
passes to fprintf(), we get the same level of automicity: a log
statement will get stuck either in stderr or the new handle, depending
on whether we made this change before or after another caller got to
that point in ga_log(). So we should be okay, and aren't violating any
glib locking protocols with change.
>
> > }
> > }
> >
>
>
next prev parent reply other threads:[~2012-05-15 14:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-14 22:04 [Qemu-devel] [PATCH 1.1] qemu-ga: fix segv after failure to open log file Michael Roth
2012-05-15 8:07 ` Michal Privoznik
2012-05-15 13:04 ` Luiz Capitulino
2012-05-15 14:14 ` Michael Roth [this message]
2012-05-15 14:46 ` Luiz Capitulino
2012-05-15 13:32 ` Peter Maydell
2012-05-15 14:22 ` Michael Roth
2012-05-15 14:36 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120515141413.GA2967@illuin \
--to=mdroth@linux.vnet.ibm.com \
--cc=aliguori@us.ibm.com \
--cc=lcapitulino@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).