From: "Alexander Sandler" <ASandler@store-age.com>
To: <linux-kernel@vger.kernel.org>
Cc: "Ohad Levin" <OLevin@store-age.com>
Subject: Possible bug in ext3 versus filter drivers in 2.4.18-3, 2.4.18-14 and 2.4.20.
Date: Tue, 18 Feb 2003 14:17:28 +0200 [thread overview]
Message-ID: <AE0DC697C2336C4A9767AE031CE4B344134FCE@exchange.store-age.com> (raw)
Hi list.
I am working on a filter driver.
In my driver, I am monitoring whether requests I redirected to other driver were successful or not. To do so, I am replacing b_end_io and b_private fields in buffer header. This way, instead of calling the default completion routine, system is calling my completion routine, which used to, among the other things, recover original b_end_io and b_private fields from value I placed in b_private when mapped the request and call original b_end_io with appropriate uptodate value.
The problem with ext3 is that it is accessing b_private field in locked buffer headers. It is treating b_private field I placed in buffer header, as journal header. As a result, I am getting multiple segmentation faults in different places and you can imagine what else.
The problem starts somewhere in ext3_new_block() in fs/ext3/balloc.c. In the begging it's obtaining buffer header and eventually it's calling __ext3_journal_get_undo_access() in include/linux/ext3_jbd.h. From there, it goes to journal_get_undo_access() in fs/jbd/transaction.c, then to journal_add_journal_head() in fs/jbd/journal.c and so on. Journal header is obtained in line stating "jh = bh2jh(bh);" in journal_add_journal_head().
I see two possible fixes. First, we can make sure filter drivers do not change b_private field in buffer header. It seems to be quite odd solution since as far as I understood, this is what b_private filed is there for (among the other things of course). Other option is to make sure that ext3_new_block() won't access locked buffer headers. This seems to be more reasonable.
I am afraid I am not really an expert in file systems in general and in ext3 in particularly, so I don't know what exactly to do. Perhaps someone can fix this thing or guide me how to do so.
Finally, I found this thing in 2.4.18-3 (RH 7.3). I checked 2.4.18-14 (RH 8.0) and 2.4.20. It seems that the problem is there for all three versions of kernel.
Thank you.
Alexandr Sandler.
next reply other threads:[~2003-02-18 12:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-18 12:17 Alexander Sandler [this message]
2003-02-20 1:15 ` Tim Pepper
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=AE0DC697C2336C4A9767AE031CE4B344134FCE@exchange.store-age.com \
--to=asandler@store-age.com \
--cc=OLevin@store-age.com \
--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 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®