Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
The IOCTL_GET_INFORMATION virtio-serial device IO control call previously didn't return the actual size of the data in case a too small of a buffer was passed. This made it impossible for applications to query the size, often resorting to worst case guesses. This update introduces a new IOCTL_GET_INFORMATION IO control code with the same semantics as the old one, only with the bug fixes. The old IO control code is still supported for backward compatibility, now named IOCTL_GET_INFORMATION_BUFFERED in the source files.
Description of problem:
The way IOCTL_GET_INFORMATION is handled suggests that if the supplied output buffer is too small, the required size would be passed back to the caller. This doesn't work because we use STATUS_BUFFER_TOO_SMALL (error) as opposed to STATUS_BUFFER_OVERFLOW (warning) and the IO manager will not propagate anything back if the ioctl failed with an error. Switching to the warning code still wouldn't work because we use METHOD_BUFFERED and the IO manager would actually attempt to copy that many bytes back to the userspace buffer and corrupt it.
Interesting read about the topic
http://blogs.msdn.com/b/doronh/archive/2006/12/12/how-to-return-the-number-of-bytes-required-for-a-subsequent-operation.aspx
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1. Run the vioser-test app (vioserial/app)
2. Type 'i' for info
Actual results:
Serial port information is printed
Expected results:
IOCTL fails
Additional info:
Created attachment 1139850[details]
Ioctl failed with code 122_with build 102
Hi Ladi,
I tried this issue with build 102 and a newer build 115.
With the build 102, run vioser-test.exe, type "i", error massage "Ioctl failed with code 122" shown, detail please refer to the attachment1[details].
With the build 115, run vioser-test.exe, type "i", Serial port information is printed, detail please refer to the attachment2[details].
According to the comment 0, actual result is "Serial port information is printed", Expected results is "IOCTL fails". But I verified results seem not match the comment 0. So please help to confirm if the actual result and expected result of comment 0 were written reversed? Thanks so much~~
Best Regards!
Peixiu Hou
Hi Peixiu Hou,
Yes, the actual and expected result in comment 0 are reversed. "Serial port information is printed" is the expected result. Sorry about that!
Thanks,
Ladi
I have encountered a problem with the latest 117 drivers when using IOCTL_GET_INFORMATION. Here is the specific code snippet I have:
BYTE buffer[512];
ULONG length = 0;
BOOL success = DeviceIoControl(handle,
IOCTL_GET_INFORMATION,
NULL,
0,
buffer,
sizeof(buffer),
&length,
NULL);
When using the 102 drivers, this works successfully. But when I use the latest 117 drivers the DeviceIoControl call returns false and GetLastError() returns 1 with a message of "Incorrect function". Not sure if the changes discussed here somehow broke this.
(In reply to Nat Meo from comment #6)
> I have encountered a problem with the latest 117 drivers when using
> IOCTL_GET_INFORMATION. Here is the specific code snippet I have:
>
> BYTE buffer[512];
> ULONG length = 0;
> BOOL success = DeviceIoControl(handle,
> IOCTL_GET_INFORMATION,
> NULL,
> 0,
> buffer,
> sizeof(buffer),
> &length,
> NULL);
>
> When using the 102 drivers, this works successfully. But when I use the
> latest 117 drivers the DeviceIoControl call returns false and GetLastError()
> returns 1 with a message of "Incorrect function". Not sure if the changes
> discussed here somehow broke this.
Yes, they did. The IOCTL code changed (intentionally) but the driver was also supposed to keep responding to the old one for compatibility. The second part somehow didn't make it into the tree.
A huge thank you for the report. If you know that you'll always query driver 117 or later, the workaround is to rebuild the code against the current sources where the code is defined like so:
#define IOCTL_GET_INFORMATION CTL_CODE(FILE_DEVICE_UNKNOWN, 0x800, METHOD_OUT_DIRECT, FILE_ANY_ACCESS)
Thanks again,
Ladi
Created attachment 1165801[details]
Serial port information is normal with build 117
I retested this issue with build 117 driver, step as comment#0, the output serial port information is normal, detail please refer to the attachment, thanks~
Best Regards~
Peixiu Hou
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHBA-2016-2609.html