All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@redhat.com>
To: Bernhard Schmidt <berni@birkenwald.de>
Cc: linux-cifs-client@lists.samba.org, linux-kernel@vger.kernel.org
Subject: Re: [linux-cifs-client] BUG: Possible cifs+IPv6-Regression 2.6.27.4 -> 2.6.27.9
Date: Mon, 19 Jan 2009 16:07:25 -0500	[thread overview]
Message-ID: <20090119160725.34124637@tleilax.poochiereds.net> (raw)
In-Reply-To: <20090119103248.GA28699@schleppi.birkenwald.de>

On Mon, 19 Jan 2009 11:32:48 +0100
Bernhard Schmidt <berni@birkenwald.de> wrote:

> On Sun, Jan 18, 2009 at 09:03:14PM -0500, Jeff Layton wrote:
> 
> > How reproducible is this? Can you make it happen on every attempt?
> > Is this kernel being built with CONFIG_CIFS_DFS_UPCALL=y ?
> 
> Happens every time. CIFS_DFS_UPCALL is set, yes.
> 
> > Could you email me the cifs.ko module from this kernel? I'd like to
> > disassemble it and have a look at where it crashed. I may not be
> > able to tell much, but it's worth a look...
> 
> Will do unicast when I'm back at my workstation at home.
> 
> Thanks,
> Bernhard

Thanks for the kmod. Kernel crashed doing this:

     e00:       8b 43 30                mov    0x30(%ebx),%eax

...which checks out with the register dump. %ebx is 0x69000000.
and the address we failed to look up was 0x69000030.

My guess from a cursory look at the assembly is that %ebx should be
holding a pointer to cifs_sb. It's referenced quite a few times, but
doesn't seem to change until just before returning from the function.
The interesting bit is that there are a lot of other places  (even some
that look like they've probably already been traversed) in this code
where %ebx is dereferenced but they didn't trigger the problem...

That said, there's a lot of jumping around in this assembly code and
it's not completely clear to me how it got to the point where it crashed.
We'll probably need to see if this can be independently reproduced. Can
you email along the details of how you're reproducing this? In
particular:

1) all mount options being used
2) details on the server (what OS, what version of samba, etc)
3) version of mount.cifs being used

-- 
Jeff Layton <jlayton@redhat.com>

  reply	other threads:[~2009-01-19 21:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-18 22:13 BUG: Possible cifs+IPv6-Regression 2.6.27.4 -> 2.6.27.9 Bernhard Schmidt
2009-01-19  2:03 ` [linux-cifs-client] " Jeff Layton
2009-01-19 10:32   ` Bernhard Schmidt
2009-01-19 21:07     ` Jeff Layton [this message]
2009-01-19 21:38       ` Bernhard Schmidt
2009-01-20 12:25         ` Jeff Layton
2009-01-20 18:50           ` Jeff Layton
2009-01-22 13:41         ` Jeff Layton
2009-01-22 14:45         ` Jeff Layton
2009-01-22 17:02           ` Bernhard Schmidt
2009-01-23  0:00           ` Steve French
2009-01-23  1:49           ` Bernhard Schmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090119160725.34124637@tleilax.poochiereds.net \
    --to=jlayton@redhat.com \
    --cc=berni@birkenwald.de \
    --cc=linux-cifs-client@lists.samba.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.