All of lore.kernel.org
 help / color / mirror / Atom feed
From: Earl Chew <earl_chew@agilent.com>
To: Frans Pop <elendil@planet.nl>
Cc: linux-kernel@vger.kernel.org
Subject: Re: fs/pipe.c null pointer dereference
Date: Wed, 14 Oct 2009 15:50:40 -0700	[thread overview]
Message-ID: <4AD655C0.2030202@agilent.com> (raw)
In-Reply-To: <200910141653.03611.elendil@planet.nl>

Frans Pop wrote:
> 2.6.21 is really rather ancient for the kernel community and I doubt anyone 
> here will really want to look into issues with it, given that there's a 
> realistic chance it has already been fixed since then. The current stable 
> version is 2.6.31 after all.
> 
> Can you reproduce the oops with a current kernel? Have you checked if there 
> have been any changes in the code you identified since 2.6.21?

I was mostly after some guidance. I'm happy to dig around to figure
out what the problem is and log a bug if indeed I find one.


Yes, I have searched for obvious patches but didn't turn up anything.

I have looked at the code for more recent 2.6.31 kernel on
lxr.linux.no and haven't turned up any appreciable difference.

I have given the matter more thought, and I believe it is unlikely
that the problem is in fs/fifo.c. As outlined in my previous
email, the code looks ok.


I'm a little confused about the switch between the fifo_open()
and the subsequent call to pipe_rdwr_open(). My understanding
is fifo_open() is called during open("/fifo", O_RDWR) which
fills in filp->f_op to point at rdwr_fifo_fops.

Thereafter, a call to close() will vector through filp->f_op
to pipe_rdwr_release().

I'm still puzzled as to how pipe_rdwr_open() is called. The
stack trace says:

Call Trace:
  [<ffffffff8028125c>] __dentry_open+0x13c/0x230
  [<ffffffff8028143d>] do_filp_open+0x2d/0x40
  [<ffffffff802814aa>] do_sys_open+0x5a/0x100
  [<ffffffff8021faf3>] sysenter_do_call+0x1b/0x67

I figure that the fileoperation for the fifo inode must be
revectored to rdwr_fifo_fops --- but I can't see that's
done exactly.

Any hints as to where to look for this ?


In any case, my current guess as to how this happens is that
there might be window of time between do_sys_open() ... pipe_rdwr_open()
where the inode is obtained and the fileoperation pointer is
followed to get to pipe_rdwr_open().

During that window of time, might it be possible for the fifo
to be closed and the underlying pipe released?


Where can I look to see if this is possible?

Earl



  reply	other threads:[~2009-10-14 22:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-14 13:39 fs/pipe.c null pointer dereference Earl Chew
2009-10-14 14:53 ` Frans Pop
2009-10-14 22:50   ` Earl Chew [this message]
2009-10-15  0:11     ` Frans Pop
2009-10-16  4:27       ` Earl Chew
2009-10-16  7:16         ` Pekka Enberg
2009-10-16 14:51           ` Earl Chew
2009-10-16  3:31     ` Earl Chew
2009-10-16  3:39       ` Earl Chew

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=4AD655C0.2030202@agilent.com \
    --to=earl_chew@agilent.com \
    --cc=elendil@planet.nl \
    --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.