| Message ID | 20091202131835.3f2584bd@tlielax.poochiereds.net |
|---|---|
| State | New |
| Headers | show |
Hi, > Dec 2 15:14:10 CGDWX08027093 klogd: ---[ end trace 93d72a36b9146f25 ]--- > > > > ------------------------------------- > > Hard to be sure from the info here but I think I might see the problem... > > Can you reproduce this at will? If you can, could you let me know > whether the attached patch fixes it? Note that I haven't even compile > tested it, but it's pretty straightforward. We can't reproduce this because we don't have rights over the windows infra-structure that got unstable. And I belive that it won't stay unstable for long :| We'll see if the symptom persists. Is this patch commited for the current kernel GIT so that it will appear on the next kernel release? Cheers Gustavo
On Wed, 2 Dec 2009 21:12:54 +0000 Gustavo Carvalho Homem <gustavo@angulosolido.pt> wrote: > Hi, > > > > Dec 2 15:14:10 CGDWX08027093 klogd: ---[ end trace 93d72a36b9146f25 ]--- > > > > > > ------------------------------------- > > > > Hard to be sure from the info here but I think I might see the problem... > > > > Can you reproduce this at will? If you can, could you let me know > > whether the attached patch fixes it? Note that I haven't even compile > > tested it, but it's pretty straightforward. > > We can't reproduce this because we don't have rights over the windows > infra-structure that got unstable. And I belive that it won't stay unstable > for long :| > > We'll see if the symptom persists. > > Is this patch commited for the current kernel GIT so that it will appear on > the next kernel release? > > Cheers > Gustavo No, I just wrote it today based on the stack traces you sent. I'm pretty sure that the patch is correct, but unfortunately it's tough to be certain it'll fix the problem you reported. If you don't have a way to test it, I'll probably just go ahead and send it to Steve later this week once I've given it some smoke testing. We'll just have to hope for the best in that case. Cheers,
From a2d6f76bb2bbc45ab9a534fdfe5c7f1617c0e87a Mon Sep 17 00:00:00 2001 From: Jeff Layton <jlayton@redhat.com> Date: Wed, 2 Dec 2009 13:16:20 -0500 Subject: [PATCH] cifs: NULL out tcon, pSesInfo, and srvTcp pointers when chasing DFS referrals The scenario is this: We've got a valid tcon pointer and we're chasing a DFS referral. We put the tcon reference, which puts the session reference too. Then we try the mount again with the new mount info. That mount fails, and we goto mount_fail_check. The tcon and pSesInfo pointers are non-NULL, but no longer valid, and things blow up when we try to put references to them. Fix this by zeroing out the tcon, tcp and smb session pointers before retrying the mount. Signed-off-by: Jeff Layton <jlayton@redhat.com> --- fs/cifs/connect.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c index 63ea83f..54f38f1 100644 --- a/fs/cifs/connect.c +++ b/fs/cifs/connect.c @@ -2595,6 +2595,9 @@ remote_path_check: else if (pSesInfo) cifs_put_smb_ses(pSesInfo); + tcon = NULL; + pSesInfo = NULL; + srvTcp = NULL; cleanup_volume_info(&volume_info); referral_walks_count++; goto try_mount_again; -- 1.6.5.2