Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 162038 - spinlock problems in samba filesystem support
Summary: spinlock problems in samba filesystem support
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-29 12:25 UTC by paul.knowles
Modified: 2015-01-04 22:20 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-10-03 00:02:47 UTC

Attachments (Terms of Use)

Description paul.knowles 2005-06-29 12:25:35 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.7.8-1.3.1

Description of problem:
 We have a Toshiba E3511 photocopier which makes a samba share of scanned documents available.  When the share is mounted, commands like rsync and ls work (mostly) to give a list of the files in the directory or copy them to other disks.  Today, i was faced with a directory containing 305 files, more than I have had to deal with before.  Simply cd'ing to the directory and typing ls gave a directory listing; attempting to cp the files from the photocopier to the local machine caused a hard kernel lockup on the local machine.  This occurred for kernels 2.6.10 (custom compiled) and the stock Fedora 2.6.11-1.27_FC3 and 2.6.11-1.35_FC3.  

Version-Release number of selected component (if applicable):
kernels 2.6.10,  2.6.11-1.27_FC3,  2.6.11-1.35_FC3

How reproducible:

Steps to Reproduce:
1. mount -t smbfs \\\\physpr19\\FILE_SHARE /mnt/physpr19/
2. cd /mnt/physpr19/
3. <tab>, cp, ls ...

Actual Results:  system locks up hard. not even magic sysreq keys get a response. 

Expected Results:  list of available files in the directory should be displayed

Additional info:

I have tried this from two machines, both FC3, but with different kernel versions.  The only oops information I could capture was from a custom 2.6.10 kernel which confessed that it had called:
 filldir64 several times
 smb_readdir(64? or long )
 and then mm/slab.c whinged about
   spin_is_locked on uninitialized spinlock, 
 Kernel Panic
and the system died.

That system was responsive for the sysreq keys and so syncing disks and so on worked.  My understanding of the sysreq-task list seemed to say that smbiod was taking all the CPU. When rebooted, I mounted the smb share, did an rsync of the data to the local disk, being careful to never ask for tab completion while typing the path, and the copy worked.  Immediately after the copy completed, i cd'ed to the mounted directory and pressed <tab> in bash to get an automagic file list and the system died.  Again a hard crash, no sysreq key response.

What is weird is that the simply `ls' of the directory didn't create a lockup directly all the time (did on one machine, but not on another: it is possible that the tab completion was involved in the first lockup).  Attempting tab completion, via bash, of any filename on the smb share, or simply to see the file list, caused immediate and catastrophic lockup.  

The photocopier providing the smb service is running linux 2.4.x.  The machines which crashed are UP machines.  This type of file access is commonly used here and has always been successful up 'til yesterday, but normally the directories on the smb server have less than 200 files.

The machines are in production environments, so I have only limited time to run any tests.  However, if specific testing is needed, I may be able to schedule it.

Comment 1 paul.knowles 2005-06-29 12:55:47 UTC
This seems to be the same problem as described in 
    Bug 157557 â Mount -t smbfs leads to system crash
and Bug 129577 â Mount -t smbfs leads to system crash
so it has been around and known since at least August 2004.

Comment 2 paul.knowles 2005-06-30 10:29:30 UTC
seems to indicate a good candidate for the source of the error in
fs/smbfs/request.c: a request can be conditionally free'ed but the 
remaining code continues to assume it is still there.

I think this requires Guru intervention.

Comment 3 Dave Jones 2005-07-15 17:31:49 UTC
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.

Comment 4 Dave Jones 2005-10-03 00:02:47 UTC
This bug has been automatically closed as part of a mass update.
It had been in NEEDINFO state since July 2005.
If this bug still exists in current errata kernels, please reopen this bug.

There are a large number of inactive bugs in the database, and this is the only
way to purge them.

Thank you.

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