Messages in this thread | | | Date | Fri, 12 Mar 2004 00:10:47 +0100 (CET) | From | Urban Widmark <> | Subject | Re: smbfs Oops with Linux 2.6.3 |
| |
On Thu, 11 Mar 2004, Zwane Mwaikambo wrote:
> Two patches applied in this order; > > patch-smbfs-readdir-oops > fs/smbfs/inode.c | 1 + > fs/smbfs/proc.c | 45 ++++++++++++++++++++++++++++++++++++++++++--- > include/linux/smb_fs_sb.h | 2 +- > 3 files changed, 44 insertions(+), 4 deletions(-) > > patch-smbfs-rcls-cleanup > fs/smbfs/proc.c | 12 ++++++------ > include/linux/smb_fs_sb.h | 3 --- > 2 files changed, 6 insertions(+), 9 deletions(-) > > I avoided adding the BUG() placeholders, since we will PF# when we hit the > NULL pointer and the call trace should give us a decent idea of where it > is.
Not quite there yet.
I have added a sleep(10); in send_fs_socket (smbmount) to give me time to send other requests to the fs. Here is what I get when I run the mount and two 'ls' in parallel:
1. smbmount mounts and goes to sleep 2. ls 1 ends up in smb_proc_ops_wait 3. ls 2 ends up in smb_proc_ops_wait 4. smbmount wakes up and passes the socket to smbfs
5a. ls 1 & 2 are woken and lists files
5b. Everyone is waiting for ls 1 (or 2 I don't know) to timeout. 6b. ls 1 lists nothing because of the timeout 7b. ls 2 lists normally
The difference between a and b is that in the first case I wait a few seconds between the two ls' but in the second I run the within one second of each other.
Some debug printks give:
a: smb_proc_getattr_null: smb_proc_ops_wait: state: 1 smb_proc_getattr_null: smb_proc_ops_wait: state: 1 (here it waits for smbmount to do the ioctl) smb_proc_ops_wait: result: 26192 smb_proc_ops_wait: result: 23014
b: smb_proc_readdir_null: smb_proc_ops_wait: state: 1 smb_proc_getattr_null: smb_proc_ops_wait: state: 1 (here it waits for smbmount to do the ioctl) smb_proc_ops_wait: result: 0 smb_proc_ops_wait: result: 682
The difference must be that in a the inode data for the root inode is not considered current when the second ls runs, but I don't understand why the readdir is printed before the getattr.
/Urban
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |