Bug 168280

New info...
server: samba-3.0.10-1.4E
client: samba-3.0.10-1.4E
  No Long pause on client mount

server: samba-3.0.10-1.4E.2
client: samba-3.0.10-1.4E.2
  Long pause on client mount

server: samba-3.0.10-1.4E
client: samba-3.0.10-1.4E.2
  Long pause on client mount

Remove Patch20: samba-3.0.10-bug157208.patch with
#%patch20 -p1 -b .bug157208

server: samba-3.0.10-1.4E
client: samba-3.0.10-1.4E.2
  No Long pause on client mount

server: samba-3.0.10-1.4E.2
client: samba-3.0.10-1.4E.2
  No Long pause on client mount

So is samba-3.0.10-bug157208.patch dependent on something else?

I dont have access to bug 157208 but
if there is a dependency its missing in the spec file.

I am getting the same behaviour in RHEL4 U2, but against fully patched MS
Windows Server 2003. I have pam_mount running on login to mount user's
filespace, which worked perfectly under U1, but now gives the same error as the
report above.

weirdly I was still experiencing the same behaviour when I removed Patch20, but
when I removed Patch17:

#Patch17: samba-3.0.12rc1-gcc4.patch

I no longer get the hangs...

If you hit Ctrl-Z to suspend the mount command, then immediately type "bg" to 
background the task, the mount immediately completes successfully.

Looks like the bug is related to some kind of waiting around for a signal that 
never arrives, and the Ctrl-Z+"bg" "hack" delivers whatever it's waiting for...

# rpm -q --whatprovides mount
util-linux-2.12a-16.EL4.12


# mount -w -t smbfs //192.168.0.11/xxx /x -o username=xxx 
Password: 

[1]+  Stopped                 mount -w -t smbfs //192.168.0.11/xxx /x -o 
username=xxx
# bg
[1]+ mount -w -t smbfs //192.168.0.11/xxx /x -o username=xxx &
# 
[1]+  Done                    mount -w -t smbfs //192.168.0.11/xxx /x -o 
username=xxx
# 

The problem is identical using /sbin/mount.smbfs isntead of the "mount" 
command.

Below - I issued the command, waited 30 seconds (it still did not complete) so 
I hit Ctrl-Z, bg, and it completed immediately OK:-

[root@ca2 xxx]# date;/sbin/mount.smbfs //192.168.0.11/xxx /x -o 
username=xxx;date
Thu Oct 20 13:10:58 UTC 2005
Password: 

[1]+  Stopped                 /sbin/mount.smbfs //192.168.0.11/xxx /x -o 
username=xxx
Thu Oct 20 13:11:27 UTC 2005
[root@ca2 xxx]# bg
[1]+ /sbin/mount.smbfs //192.168.0.11/xxx /x -o username=xxx &
[root@ca2 xxx]# 
[1]+  Done                    /sbin/mount.smbfs //192.168.0.11/xxx /x -o 
username=xxx
[root@ca2 xxx]# 

*** Bug 171082 has been marked as a duplicate of this bug. ***

Workaround: set up both of fmask and dmask.

(smbmount -o fmask=777,dmask=777)

*** Bug 202934 has been marked as a duplicate of this bug. ***

Created attachment 154493 [details]
patch -- proposed by Vasily Averin in bug 234300

This patch was proposed by Vasily Averin in bug 234300. Still looking over it
to make sure that it's correct and reasonable, but it does seem to alleviate
this problem.

This patch seems to be a missing delta from the patch that went in for bug
#157402 (i.e. upstream patch has this delta, but the RHEL4 patch doesn't).

That "patch" looks like it's a quick-and-dirty hack to force the workaround.

It's clearly got nothing to do with anything that might be causing a 30-second 
timeout.

If you can't trace the code to find out where it's waiting for those 30 
seconds, and thus locate the actual bug, perhaps looking at a diff between 
known working and broken versions should lure it out?

The pauses may be due to a different reason entirely, but the unitialized
file_mode and dir_mode are definitely an issue in an of themselves. Here's what
we see in userspace:

[pid  2454] mount("//server/testuser", ".", "smbfs",
MS_MGC_VAL|MS_NOSUID|MS_NODEV, "version=7,") = -1 ENOTDIR (Not a directory)
[pid  2454] mount("//server/testuser", ".", "smbfs",
MS_MGC_VAL|MS_NOSUID|MS_NODEV, "\6") = 0

...so the first mount eventually fails (after a long pause) and then falls back
to doing the mount with "old style" options (using a struct instead of a
string). During the mount, we call smb_fill_super that parses the mount options,
and populates the smb_mount_data_kernel struct for the mount. The file_mode and
dir_mode end up being filled out with 0's.

This means that when we call smb_iget, we end up initing a special inode, but
the mode is still bogus. We eventually return back up to the VFS, but the sb
struct has a root inode that's not a directory (mode is 0), so it starts tearing
down the superblock and preparing to return an error.

During the teardown, one of the things it does is delete this inode, and I think
this is where the delay comes in. I believe it calls into smbiod, which for some
reason (which is the part I'm not sure of) discards this request.

Stack trace from during the delay:

smbmnt        S dead4ead00000001     0  2180   2179                     (NOTLB)
ffffff801b22b9e8 0000000000000282 ffffff8000bf0570 0000007400bf0530 
       ffffff801a6b27f0 00000000002ddeaa 0002c5ffe0b4938b ffffff801db82030 
       ffffff801a6b2a88 ffffffff80129988 
Call Trace:<ffffffff80129988>{try_to_wake_up+731}
<ffffffff80138954>{__mod_timer+293} 
       <ffffffff80295566>{schedule_timeout+362}
<ffffffff80139565>{process_timeout+0} 
       <ffffffffa01a7f68>{:smbfs:smb_add_request+925}
<ffffffff8012dbf0>{autoremove_wake_function+0} 
       <ffffffff8015a6a0>{dbg_redzone1+30}
<ffffffff8012dbf0>{autoremove_wake_function+0} 
       <ffffffffa01a0ae1>{:smbfs:smb_request_ok+44}
<ffffffffa01a12a3>{:smbfs:smb_proc_close+98} 
       <ffffffffa01a1440>{:smbfs:smb_proc_close_inode+172} 
       <ffffffff801ce1b5>{superblock_doinit+1547}
<ffffffff801cd50e>{avc_has_perm+70} 
       <ffffffffa01a1492>{:smbfs:smb_close+37}
<ffffffffa01a5e2a>{:smbfs:smb_delete_inode+54} 
       <ffffffffa01a5df4>{:smbfs:smb_delete_inode+0}
<ffffffff8018ee56>{generic_delete_inode+190} 
       <ffffffff8018ed98>{generic_delete_inode+0} <ffffffff8018bb68>{dput+463} 
       <ffffffff8017b05a>{generic_shutdown_super+63}
<ffffffff8017bd40>{kill_anon_super+9} 
       <ffffffff8017b002>{deactivate_super+95} <ffffffff80191352>{do_add_mount+332} 
       <ffffffff80191e12>{do_mount+1721} <ffffffff801ce2d3>{inode_has_perm+89} 
       <ffffffff8018b9d1>{dput+56} <ffffffff801533b0>{find_get_page+57} 
       <ffffffff801e6b7d>{__up_read+16} <ffffffff80191703>{copy_mount_options+157} 
       <ffffffff801429ad>{search_exception_tables+29}
<ffffffff80119891>{do_page_fault+870} 
       <ffffffff80165ed6>{handle_mm_fault+556} <ffffffff8018b9d1>{dput+56} 
       <ffffffff80157054>{buffered_rmqueue+384}
<ffffffff8015acc8>{check_poison_obj+48} 
       <ffffffff8015ab4e>{poison_obj+54} <ffffffff80157244>{__alloc_pages+200} 
       <ffffffff80192196>{sys_mount+186} <ffffffff8010d66e>{system_call+134} 
       <ffffffff8010d5e8>{system_call+0} 
smbiod        S 0000000000000001     0  2181      1                1934 (L-TLB)
ffffff801b1f7eb8 0000000000000246 ffffff801b1f7e08 0000000000000000 
       ffffff801a6b2030 000000000000719c 0002c5ffe0b72b1f ffffff8000a2a030 
       ffffff801a6b22c8 0000000000000000 
Call Trace:<ffffffffa01a77a2>{:smbfs:smbiod+172}
<ffffffff8012dbf0>{autoremove_wake_function+0} 
       <ffffffff8012dbf0>{autoremove_wake_function+0}
<ffffffff80129df8>{schedule_tail+55} 
       <ffffffff8010e092>{child_rip+8} <ffffffffa01a76f6>{:smbfs:smbiod+0} 
       <ffffffff8010e08a>{child_rip+0} 


clearly smbiod isn't doing much of anything, and smbmnt is waiting on it come back.

So, arguably, this is a different bug -- we should probably return an error here
instead of timing out, but the root cause of this particular issue is that the
file and dir modes are not properly set. I don't think this patch is papering
over the issue at all.

As a side note, while I'm not averse to patching smbfs where we have clear bugs
and patches, we're strongly suggesting that people move to using CIFS. The
upstream CIFS code is in much better shape than the smbfs code, and we track
CIFS upstream pretty closely in RHEL.

FWIW, the 30 second pause comes from smb_add_request:

        timeleft = wait_event_interruptible_timeout(req->rq_wait,
                                    req->rq_flags & SMB_REQ_RECEIVED, 30*HZ);

(note the 30*HZ here). It's sitting on the smbiod wait queue, and just never
waking up.

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.

committed in stream U6 build 55.11. A test kernel with this patch is available
from http://people.redhat.com/~jbaron/rhel4/

added to RHEL4.6 release notes under "Kernel-Related Updates":

<quote>
dir_mode and file_mode now have default values
</quote>

please advise if any revisions are necessary. thanks!

*** Bug 241442 has been marked as a duplicate of this bug. ***

Hi,

This customer as not provided any feed back on this, but i have one more
customer having same issue and for him thing works fine with the test
kerenl.

Hope this helps.

Kaustubh.

Internal Status set to 'Waiting on SEG'

This event sent from IssueTracker by jnansi 
 issue 124805

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 the 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-2007-0791.html