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
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
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,
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.
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.
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.
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'.
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.