Bug 62038 - qlogic drivers don't fail on unimplemented IOCTLs
qlogic drivers don't fail on unimplemented IOCTLs
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-03-26 16:38 EST by Eric Sandeen
Modified: 2008-08-01 12:22 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:39:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eric Sandeen 2002-03-26 16:38:08 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.0.2 (X11; Linux i686; U;) Gecko/20020102

Description of problem:
Trying the (unimplemented) BLKGETSIZE64 ioctl on the qlogic drivers ( qla2x00.o
and qla2200.o tested) does not fail.

Version-Release number of selected component (if applicable):
7.2 + kernel updates, 2.4.9-31 kernel

How reproducible:
Always

Steps to Reproduce:
1. Load qla2* driver
2. Try BLKGETSIZE64 ioctl
3. Observe results
	

Actual Results:  BLKGETSIZE64 ioctl returns with a value of 6 ( <0 would be failure)

Expected Results:  BLKGETSIZE64 ioctl should return with a value of < 0

Additional info:

Point this at the device (i.e. ioctl-test /dev/sda1)

==========

#define _GNU_SOURCE
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <sys/types.h>

#define BLKGETSIZE _IO(0x12,96) /* return device size /512 (long *arg) */
#define BLKGETSIZE64 _IOR(0x12,114,sizeof(unsigned long long)) /* return device
size in bytes (u64 *arg) */

int main(int argc, char **argv)
{

        int fd, error;
        unsigned long   size;
        unsigned long long llsize;

        fd = open(argv[1], O_RDWR, 0666);
        if (fd < 0) {
                fprintf(stderr, "error opening device special file: %s\n",
                        strerror(errno));
                exit(1);
        }

        error = ioctl(fd, BLKGETSIZE, &size);
        if (error < 0) {
                fprintf(stderr, "BLKGETSIZE can't determine device size: %s\n",
                        strerror(errno));
                exit(1);
        }
        printf("Device size is %d blocks (%lld bytes)\n", size, size*512);

        llsize = 12345;

        error = ioctl(fd, BLKGETSIZE64, &llsize);
        if (error < 0) {
                fprintf(stderr, "BLKGETSIZE64 can't determine device size: %s\n",
                        strerror(errno));
                exit(1);
        }
        printf("Device size per BLKGETSIZE64 is %lld bytes\n", llsize);

        close(fd);
        return 0;
}
Comment 1 Arjan van de Ven 2002-03-26 16:49:16 EST
2.4.9-31 doesn't support the BLKGETSIZE64 ioctl at all.
Comment 2 Eric Sandeen 2002-03-26 16:54:20 EST
I understand that it's not supported, but shouldn't it fail if it's not implemented?

If "not supported" means "we don't want to hear anything about it" then I
understand.  :)  But if some userspace wants to try BLKGETSIZE64 and fall back
to BLKGETSIZE on failure, this won't work on this kernel, because this driver
lies about success.

Thanks,

-Eric
Comment 3 Eric Sandeen 2002-03-27 10:42:01 EST
Hi Arjan -

I don't want to be a pain, just making sure you didn't scan the bug too quickly.  :)

I understand that BLKGETSIZE64 is not supported in 2.4.9-31 at all.  That's why
I consider it to be a bug to return success + bogus data when the ioctl is issued.

The only way for userspace to know whether a kernel supports an ioctl is to try
it, and test for success or failure.  The qlogic driver incorrectly reports
success, and returns garbage, rather than -EINVAL as it should.

This isn't just BLKGETSIZE64, it appears that other unimplemented and/or bogus
ioctls will behave the same way, which may indicate a bug in error handling in
general.

The other scsi drivers don't exhibit this behavior.

Thanks,

-Eric
Comment 4 Arjan van de Ven 2002-03-27 10:48:46 EST
I'm already investigating this in the driver; I agree it's "not nice".
Comment 5 Bugzilla owner 2004-09-30 11:39:27 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

Note You need to log in before you can comment on or make changes to this bug.