Bug 1219214

Summary: Coverity-detected defect: call to fcntl without checking return value
Product: Red Hat Enterprise Linux 6 Reporter: Jeff Nelson <jen>
Component: qemu-kvmAssignee: Jeff Cody <jcody>
Status: CLOSED NOTABUG QA Contact: Virtualization Bugs <virt-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.6CC: ailan, chayang, juzhang, mkenneth, pbonzini, qzhang, rbalakri, rpacheco, virt-maint
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1219217 (view as bug list) Environment:
Last Closed: 2016-01-20 19:47:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1219217    

Description Jeff Nelson 2015-05-06 20:29:30 UTC 
Description of problem:
Coverity reports:

CHECKED_RETURN (block/gluster.c:335)
Calling "fcntl(s->fds[0], 4, 2048)" without checking return value. This library function may fail and return an error code. 

Error occurs in function qemu_gluster_open.

Version-Release number of selected component (if applicable):
qemu-kvm-0.12.1.2-2.474.el6

Additional info:
Appears to be legitimate defect. Present in rhel7 too, but has been around for years.
Comment 2 Paolo Bonzini 2016-01-20 19:47:33 UTC 
No, it is not valid. We know that nothing can fail here. IIRC without having the code in front of me this is a F_SETFL.
Comment 3 Jeff Nelson 2016-01-21 01:25:28 UTC 
>IIRC without having the code in front of me this is a F_SETFL.

It is.

>We know that nothing can fail here.

fcntl is documented as returning specific error conditions when a given operation is attempted; the F_SETFL command is not specifically mentioned, so these error conditions cannot occur. However, several generic error conditions are documented--without mentioning a command--so it is reasonable to assume they could occur:

 EACCES or EAGAIN
   Operation is prohibited by locks held by other processes.

 EAGAIN
   The operation is prohibited because the file has been memory-mapped by another process.

 EBADF
   fd is not an open file descriptor

 ENOLCK
   Too many segment locks open, lock table is full, or a remote locking protocol failed (e.g., locking over NFS).

 EPERM
   Attempted to clear the O_APPEND flag on a file that has the append-only attribute set.

Out of all these, I'd be most concerned about ENOLCK (given that this is in a glusterfs function). Are you sure that nothing can fail here?
Comment 4 Paolo Bonzini 2016-01-21 08:49:24 UTC 
The file descriptor is a pipe that has been just opened, so it cannot be any of the above.