Bug 427544 - Update CIFS to 1.50cRH for 4.7
Update CIFS to 1.50cRH for 4.7
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
high Severity high
: rc
: ---
Assigned To: Jeff Layton
Martin Jenner
: 349291 426080 427346 440082 442446 (view as bug list)
Depends On:
Blocks: RHEL4u7_relnotes
  Show dependency treegraph
Reported: 2008-01-04 11:05 EST by Jeff Layton
Modified: 2010-10-22 17:33 EDT (History)
9 users (show)

See Also:
Fixed In Version: RHSA-2008-0665
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-07-24 15:24:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
tarball containing stock cifs-1.50c (242.77 KB, application/octet-stream)
2008-01-07 13:50 EST, Jeff Layton
no flags Details
tarball containing patches to bring 4.6ish kernels up to 1.50cRH (143.99 KB, application/octet-stream)
2008-01-07 13:53 EST, Jeff Layton
no flags Details

  None (edit)
Description Jeff Layton 2008-01-04 11:05:33 EST
We've updated CIFS to 1.50cRH for 5.2, do the same for 4.7.
Comment 1 Jeff Layton 2008-01-07 13:03:32 EST
I have test kernels on my people page with the updated CIFS code. Testing now,
but it looks good so far. I'll post the patches to the BZ as well...
Comment 2 Jeff Layton 2008-01-07 13:50:29 EST
Created attachment 290996 [details]
tarball containing stock cifs-1.50c

Tarball containing stock 1.50c code from Steve French's backported kernel
series. Pulled from here:

Comment 3 Jeff Layton 2008-01-07 13:53:45 EST
Created attachment 290997 [details]
tarball containing patches to bring 4.6ish kernels up to 1.50cRH

The update is 19 patches, so I'm not going to attach them individually. This
tarball contains the set. The result builds with a few warnings, which seem to
be innocuous. I've also sent a few of these patches to Steve F. to fix a few
spots where older kernels of RHEL4's vintage were not accounted for.

Cursory testing looks good so far -- no failures with connectathon. Testing
with fsstress now...
Comment 4 Jeff Layton 2008-01-07 13:55:09 EST
Test kernels with the above patchset are available on my peoplepage:

Comment 5 RHEL Product and Program Management 2008-01-15 06:17:13 EST
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
Comment 6 Jeff Layton 2008-01-21 15:17:57 EST
*** Bug 427346 has been marked as a duplicate of this bug. ***
Comment 7 Jeff Layton 2008-01-21 15:18:05 EST
*** Bug 426080 has been marked as a duplicate of this bug. ***
Comment 8 Jeff Layton 2008-01-21 15:19:17 EST
*** Bug 349291 has been marked as a duplicate of this bug. ***
Comment 11 Vivek Goyal 2008-02-11 10:50:11 EST
Committed in 68.11. RPMS are available at http://people.redhat.com/vgoyal/rhel4/.
Comment 14 Jeff Layton 2008-04-03 12:46:37 EDT
*** Bug 440082 has been marked as a duplicate of this bug. ***
Comment 17 Jeff Layton 2008-04-17 15:34:40 EDT
*** Bug 442446 has been marked as a duplicate of this bug. ***
Comment 19 Issue Tracker 2008-04-17 17:32:38 EDT
Hi David,

IBM is clamoring fairly loudly that they need a fix for this problem
immediately.  Now that we've isolated the problem (with Jeff Layton's
help) and verified the issue is already fixed with updates/fixes made to
the CIFS module prior to U7, the customer is asking for an accelerated

I imagine we've probably released something as a hotfix kernel already
for another customer.  Per Jeff it would need to be -68.11 or newer to
have the fix for this issue.  The nightly U7 on curly (20080416.0a) has


Internal Status set to 'Waiting on Engineering'

This event sent from IssueTracker by vincew 
 issue 173383
Comment 23 Issue Tracker 2008-05-01 14:33:39 EDT
I appreciate the efforts of the engineering team on this.  I think we may
be talking about two different issues here.  The posix mkdir code that was
added and sold to the customer as a "fix" for their problem, is only a
fix in that it avoids the section of the code that causes the problem.  

When CIFS sends the SMBmkdir to the server, Samba is creating the file
with the permissions that it should have.  The setgid bit is getting set
correctly.  The problem is that afterwards, CIFS is sending another packet
overwriting those permissions with new ones that do not take setgid into
account.  There are two solutions, either don't send the additional
packet that alters the permissions (which may break the umask related
functions of the client), or have the cifs_mkdir code take the setgid bit
into consideration when overwriting the permissions.  

With the posix mkdir code included in the hotfix, as long as unix
extensions are turned off and the server supports posix operations, then
the code above does not get used.  The posix mkdir code runs instead. 
But, if either of those things are not true (which for this customer it
was the fact that Samba was at 3.0.10 instead of 3.0.25b and therefore
lacked posix support) it will fall back to the old incorrect behavior.  

Inode caching on the client should not impact this from what I can tell.

With all that said, this may all be academic.  The customer has decided to
not disable unix extensions (and thus live without case sensitivity).  With
unix extensions enabled, the problem is resolved.  As a result, they are
looking to close their call and thus I must close this one.  Since I do
see a defect here, I wouldn't mind following any bugzillas that are open
on the subject.  Was a bugzilla ever opened for this issue (not the inode
caching issue)?

Internal Status set to 'Waiting on Support'
Status set to: Waiting on Tech

This event sent from IssueTracker by jwest 
 issue 173383
Comment 24 Issue Tracker 2008-05-01 14:33:40 EDT
correction:  paragraph 3 of the last update should read "... unix
extensions are turned ON and the ..."

This event sent from IssueTracker by jwest 
 issue 173383
Comment 25 Issue Tracker 2008-05-09 16:01:43 EDT
Couple of things:

From what I can tell is doesn't take a Samba server that is all that old
to not have posix support.  In this customer's case, they have RHEL 4 U6
machines running Samba 3.0.10, which doesn't support posix mkdir (at
least in my testing).

With unix extensions disabled, the routine falls through and from what I
can tell will always reset the permissions after the SMBmkdir.  The
cifs_mkdir() code reads:

                if (cifs_sb->tcon->ses->capabilities & CAP_UNIX)
                        if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_SET_UID)
                                CIFSSMBUnixSetPerms(xid, pTcon,
                        } else {
                                CIFSSMBUnixSetPerms(xid, pTcon,
                else {
                        if(direntry->d_inode) {
                                direntry->d_inode->i_mode = mode;

This looks like it will still overwrite the local inode's mode even with
UNIX extensions disabled.  This looks incorrect.  If the server doesn't
support posix operations, the mkdir code should still honor setgid on

In this customer's case, they have decided to not disable unix
extensions, but they are now forced to upgrade their servers to the latest
Samba in order to get posix support.  Shouldn't the client be set up to
work regardless of the server's release level?

This event sent from IssueTracker by jwest 
 issue 173383
Comment 26 Jeff Layton 2008-05-09 16:15:59 EDT
Sounds reasonable and we may actually have enough info to try to make the client
set this correctly. That said, it's not going to happen in 4.7. The fix will
need to go upstream first. I suggest opening a new BZ for it.
Comment 27 Don Domingo 2008-05-21 21:29:11 EDT
adding to RHEL4.7 release notes under "Kernel-Related Updates":

CIFS is now updated to version 1.50c. This update applies several enhancements
and bug fixes, including the capability to mount OS/2 shares (even when
CONFIG_CIFS_WEAK_PW_HASH was not set during module compilation).

please advise if any revisions are required, particularly if any other CIFS
updates need to be noted as well.
Comment 28 Jeff Layton 2008-05-22 06:31:14 EDT
The part in parenthesis doesn't make much sense. Turning on
CONFIG_CIFS_WEAK_PW_HASH is required to make OS/2 shares work. I suggest we
leave that part out. How about:

CIFS is now updated to version 1.50c. This update applies several enhancements
and bug fixes, including the capability to mount shares from older servers such
as OS/2.

Comment 29 Don Domingo 2008-05-22 19:21:13 EDT
thanks JEff. revised accordingly. 
Comment 30 Don Domingo 2008-06-02 19:17:14 EDT

the RHEL4.7 release notes deadline is on June 17, 2008 (Tuesday). they will
undergo a final proofread before being dropped to translation, at which point no
further additions or revisions will be entertained.

a mockup of the RHEL4.7 release notes can be viewed here:

please use the aforementioned link to verify if your bugzilla is already in the
release notes (if it needs to be). each item in the release notes contains a
link to its original bug; as such, you can search through the release notes by
bug number.

Comment 32 errata-xmlrpc 2008-07-24 15:24:04 EDT
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.


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