Bug 465979
| Summary: | mount.cifs exits with incorrect error code | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Jeff Moyer <jmoyer> | ||||
| Component: | samba | Assignee: | Simo Sorce <ssorce> | ||||
| Status: | CLOSED ERRATA | QA Contact: | BaseOS QE <qe-baseos-auto> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 5.3 | CC: | azelinka, dpal, duck, gdeschner, ikent, jlayton | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2009-09-02 11:54:52 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Jeff Moyer
2008-10-07 15:27:21 UTC
I think that might be a problem with the generic mount command. It looks like when the kernel returns -ENXIO on a mount() call, the mount.cifs program returns -1. I assume that the generic mount program is converting that to a return code of 16 for some reason. Unfortunately, there doesn't seem to be much info on how mount helpers are supposed to exit in error conditions, so it's possible we're doing something wrong in mount.cifs... > I think that might be a problem with the generic mount command. It looks like > when the kernel returns -ENXIO on a mount() call, the mount.cifs program > returns -1. I assume that the generic mount program is converting that to a > return code of 16 for some reason. Looking at the code for mount, it seems that it just returns the exit status of the mount.cifs (in this case) command. Are you sure mount.cifs is returning -1? > Unfortunately, there doesn't seem to be much info on how mount helpers are > supposed to exit in error conditions, so it's possible we're doing something > wrong in mount.cifs... From reading the source, it looks pretty clear. Just return the exit code as documented in mount(8). Right? > Looking at the code for mount, it seems that it just returns the exit status of > the mount.cifs (in this case) command. Are you sure mount.cifs is returning > -1? It certainly looks that way from when I reproduce mount() returning -ENXIO. I don't see /sbin/mount returning 16 in that situation, but instead returning 255. It says that the mount return is expected to be a bitfield though, so maybe it's not actually returning 16 and is just returning with the 16 bit set? > From reading the source, it looks pretty clear. Just return the exit code as > documented in mount(8). Right? It looks that way in the code, but the results I'm seeing are strange... Ahh ok, I think I see what the deal is. check_special_mountprog() does this:
*status = (WIFEXITED(st) ? WEXITSTATUS(st) : EX_SYSERR);
...from wait(2) manpage:
WEXITSTATUS(status)
returns the exit status of the child. This consists of the
least significant 8 bits of the status argument that the child
specified in a call to exit(3) or _exit(2) or as the argument
for a return statement in main(). This macro should only be
employed if WIFEXITED returned true.
...so the -1 is getting converted to 0xff, which == 255. The mount.cifs exit status is a bit of a mess. I'll see about patching it up to do the right thing.
Created attachment 319761 [details]
patch: fix mount.cifs return codes
This seems to fix the reproducer, and should fix some other problems based on a cursory look over the code.
I'll go ahead and commit this to upstream samba git trees tomorrow unless anyone has objections...
Slightly modified patch pushed to upstream git tree. I'll put this on the 5.4 proposed list and clone it and see if we can get it for 4.8 Reassigning back to Simo. Let me know if you need me to backport the patch, but the one in v3-0-test ought to be OK for this. RHEL4 bug is bug 466285 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/RHBA-2009-1416.html |