[libvirt] [PATCH] avoid a probable EINVAL from lseek
Jim Meyering
jim at meyering.net
Tue Feb 2 10:01:55 UTC 2010
Daniel P. Berrange wrote:
> On Tue, Feb 02, 2010 at 10:37:32AM +0100, Jim Meyering wrote:
>> Daniel P. Berrange wrote:
>>
>> > On Mon, Feb 01, 2010 at 10:18:27PM +0100, Jim Meyering wrote:
>> >>
>> >> In src/qemu/qemu_driver.c, coverity reports this:
>> >>
>> >> Event negative_return_fn: Called negative-returning function "lseek(logfile, 0L, 2)"
>> >> Event var_assign: NEGATIVE return value of "lseek" assigned to signed variable "pos"
>> >> At conditional (1): "(pos = lseek(logfile, 0L, 2)) < 0" taking true path
>> >> 2877 if ((pos = lseek(logfile, 0, SEEK_END)) < 0)
>> >> 2878 VIR_WARN(_("Unable to seek to end of logfile: %s"),
>> >> 2879 virStrerror(errno, ebuf, sizeof ebuf));
>> >
>> > I think it'd be less surprising to just set 'pos = 0' inside the if
>> > branch here, so later code doesn't have to worry about unexpected
>> > negative values.
>>
>> Oh. I pushed after DV's ACK.
>>
>> That would let the later code continue, but using (lseek'ing to) an
>> invalid position. Sounds like it could result in a cascade of
>> additional errors, or worse, silent malfunction.
>
> The code which later uses this 'pos' variable, does so in order to skip
> over the start of the logfile which it does not want. So by setting pos=0
> we make it start at the beginning of the file instead.
Wouldn't that result in reprocessing (misleadingly) past diagnostics?
>> But this is largely hypothetical, since failing to lseek-to-EOF
>> on a valid file descriptor is not likely to happen.
>
> My reasoning is that putting the 'pos < 0' check in another separate
> method far away from where the error occurs is rather obscure, and
> the kind of code that will likely be deleted by mistake in later
> refactoring.
I agree that this action-at-a-distance is bad.
I can add a comment pointing to this discussion.
Or,... considering that this type of failure is so unlikely,
would you prefer to make the initial lseek evoke failure
rather than just a warning?
More information about the libvir-list
mailing list