Re: [Xen-devel] [PATCH 25/29] libvchan: check for fcntl failures in select-type sample application

[Matthew Daley <mattjd@xxxxxxxxx>]

On Thu, Oct 31, 2013 at 6:06 AM, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote:
> On 10/30/2013 03:52 AM, Matthew Daley wrote:
>>
>> Coverity-ID: 1055041
>> Signed-off-by: Matthew Daley <mattjd@xxxxxxxxx>
>> ---
>>   tools/libvchan/node-select.c |    6 ++++--
>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/libvchan/node-select.c b/tools/libvchan/node-select.c
>> index 6c6c19e..c6914ab 100644
>> --- a/tools/libvchan/node-select.c
>> +++ b/tools/libvchan/node-select.c
>> @@ -105,8 +105,10 @@ int main(int argc, char **argv)
>>                 exit(1);
>>         }
>>
>> -       fcntl(0, F_SETFL, O_NONBLOCK);
>> -       fcntl(1, F_SETFL, O_NONBLOCK);
>> +       if (fcntl(0, F_SETFL, O_NONBLOCK) == -1 || fcntl(1, F_SETFL,
>> O_NONBLOCK) == -1) {
>> +               perror("fcntl");
>> +               exit(1);
>> +       }
>>
>>         libxenvchan_fd = libxenvchan_fd_for_select(ctrl);
>>         for (;;) {
>>
>
> To be completely correct, a call to F_GETFL would be required first, with
> the result ORed with O_NONBLOCK and passed to F_SETFL. That is a separate
> existing bug in the code, however, so this patch is still an improvement
> as-is.

Ah, yes. v2 coming along, also with changes for...

>
> Is the fcntl on line 156 different in some way that does not trigger this
> Coverity check?

...this fcntl. As Andrew replied, sometimes Coverity likes to ignore
repeated issues in a single file until the balance between fixed and
unfixed tips in the former's favour (also, one tends to get tunnel
vision when looking at a issue in Coverity, especially when moving
across a range of subsystems. I need to work on avoiding this).

- Matthew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel