Description of problem: In RHEL 4.6 and 4.7, read of /proc/self/mem and /proc/self/task/<pid>/mem returned different failures, $ cat /proc/self/mem RHEL 4.6: Input/output error RHEL 4.7: Invalid argument Version-Release number of selected component (if applicable): kernel-2.6.9-67.0.22 kernel-2.6.9-78.0.3 How reproducible: always
I recall that Anton had a patch where he changed some proc read output ... it went into RHEL4 ~ build 68 or so. Anton, is this really a bug? P.
I just went and looked at the logs for 68.10 -- Anton, your patch changed the default behavior here but I still wonder if this really is a bug. I guess Cai has a point -- "Invalid argument" indicates that the reader did something wrong... P.
I do not think that my patch in 68.10 changed behaviour for this issue at all. It was addressed to completely another thing. I had something assigned in the past regarding the reading of /proc/.../mem, but somebody complaint that he was not able to read it at all by cat, and he must not, so it was closed as WONTFIX. regarding this particular report, I do not understand the issue... And just checked this on RHEL4.6, result is: "Invalid argument" NOTABUG? :-)
Anton, cat /proc/self/mem on RHEL4.6 shows "Input/Output error" (-67.EL). cat /proc/self/mem on RHEL4.7 (from kernels 68.10 and onward) show "Invalid Argument". Removal of patch linux-2.6.9-Don-t-truncate-proc-PID-environ-at-4096-characters.patch changes the behavior of cat /proc/self/mem back to "Input/Output error" (As seen on dell-pe6800-01.rhts.bos.redhat.com which was installed with RHEL4.6 as a base, and binary search through kernels. I then identified the patch inux-2.6.9-Don-t-truncate-proc-PID-environ-at-4096-characters.patch as having been added in 68.10 which is where the error return value changed. After building latest-and-greatest kernel without this patch, the return code is again "Input/Output error".) The question of whether or not this is a nuisance or a real bug is still open. While it does change the return code, does it really matter? ie) Is a userspace program really going to care *why* the read failed? OTOH, "Invalid Argument" indicates that the user/reader did something wrong... P.
Agreed ... I've tested it on -78 kernel. Didn't notice that. In this particular case user-space stuff shouldn't care about the return code, the program shouldn't be able to read mem this way. OTOH, I/O error is correct return code and shouldn't be changed after my patch, but it was changed... I will look into it.
[...cut...] @@ -1587,7 +1634,6 @@ static struct dentry *proc_pident_lookup(struct inode *dir, case PROC_TID_MEM: case PROC_TGID_MEM: inode->i_op = &proc_mem_inode_operations; - inode->i_fop = &proc_mem_operations; break; case PROC_TID_MOUNTS: case PROC_TGID_MOUNTS: this is the problem... /me looking how this happend...
Yep, it was my bad, I posted the wrongly generated patch, and nobody noticed that....
Created attachment 315182 [details] proposed patch
I want to nominate this bug for RHEL4.7 z-stream as well, but do not have rights to put the rhel-4.7.z flag into '?' state.
Anton, if this doesn't hurt customers, should it be a z-stream candidate? P.
This is regression. And I can't vouch for tools customers may have...
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Updating PM score.
This bugzilla has Keywords: Regression. Since no regressions are allowed between releases, it is also being proposed as a blocker for this release. Please resolve ASAP.
Committed in 78.8.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/
*** Bug 459765 has been marked as a duplicate of this bug. ***
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2009-1024.html