mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@osdl.org>
To: Adam Sampson <azz@us-lot.org>
Cc: urban@teststation.com,
	Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>,
	Zwane Mwaikambo <zwane@arm.linux.org.uk>
Subject: Re: smbfs Oops with Linux 2.6.3
Date: Tue, 9 Mar 2004 18:53:22 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.58.0403091836410.1092@ppc970.osdl.org> (raw)
In-Reply-To: <20040310013933.GA19137@cartman.at.fivegeeks.net>



On Wed, 10 Mar 2004, Adam Sampson wrote:
> 
> I use smbfs on my x86 Linux 2.6.3 machine to mount filesystems from a
> (Debian) Samba 3.0.0beta2 server. This has worked fine with both this
> kernel and previous ones for the last few months, but I've just had an
> Oops message while trying to open a directory with ROX-Filer. The
> filesystem in question is automounted (using autofs4), and this would
> have been the first operation upon it after being mounted.

Hmm.. Looks like an indirect call that jumped through a NULL pointer.

There's a few different indirect calls in "smb_readdir()", so it's a bit 
hard to guess which one. It's at the end of the function, but gcc 
re-orders code so much (and usually wrong, I have to say), that it's hard 
to guess which one it would be.

Three out of four calls are to "readdir()", which is an argument to the 
function and should not really reasonably be NULL unless there is a 
compiler bug or some _major_ stack corruption going on. So I consider 
those to be the less likely causes.

The last one is to "server->ops->readdir()", and it's entirely possible 
that that might be NULL. That's reinforced by the data on the stack 
which would be the arguments to that function:

	c5107840 cf84bfa0 c0165560 cf84bf2c

which makes some amount of sense (arg 2 and 4 are both pointing to the
call-stack, which I think is correct for those arguments if it is that
"->readdir()" call). In contrast, the above would _not_ make sense as the
four first arguments to "filldir" (the third one should be a name length).

So I think you had a NULL pointer for "server->ops->readdir".

As to how something like that could happen, I have absolutely no clue. The 
"smb_install_null_ops()" would seem to cause that, but that's all I can 
say.

Maybe the "smp_ops_null" thing should be filled in with stuff that always
returns EINVAL or something? Rather than actual NULL pointers that will
oops if they are ever used?

(That structure is actually from Andrew's patch from Zwane Mwaikambo 
as a workaround for smb_proc_getattr oops from last summer)

Urban? Andrew? Zwane? I can decode the oopses, but when it comes to smbfs 
I'm a retard.

		Linus

  reply	other threads:[~2004-03-10  2:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-10  1:39 Adam Sampson
2004-03-10  2:53 ` Linus Torvalds [this message]
2004-03-10 12:26   ` Urban Widmark
2004-03-10 18:00     ` Zwane Mwaikambo
2004-03-10 19:13       ` Zwane Mwaikambo
2004-03-10 21:22         ` Urban Widmark
2004-03-10 21:35           ` Zwane Mwaikambo
2004-03-11  6:29           ` Zwane Mwaikambo
2004-03-11 23:10             ` Urban Widmark
2004-03-13  1:55               ` Zwane Mwaikambo
2004-03-13  8:14                 ` Urban Widmark

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=Pine.LNX.4.58.0403091836410.1092@ppc970.osdl.org \
    --to=torvalds@osdl.org \
    --cc=akpm@osdl.org \
    --cc=azz@us-lot.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=urban@teststation.com \
    --cc=zwane@arm.linux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®