From: Theodore Ts'o <tytso@mit.edu>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Tao Ma <tm@tao.ma>, linux-ext4@vger.kernel.org
Subject: Re: [ext4:dev 40/60] fs/ext4/inode.c:1953 __ext4_journalled_writepage() error: potential NULL dereference 'page_bufs'.
Date: Wed, 5 Dec 2012 00:41:25 -0500 [thread overview]
Message-ID: <20121205054125.GC18885@thunk.org> (raw)
In-Reply-To: <20121204135602.GE22569@mwanda>
On Tue, Dec 04, 2012 at 04:56:02PM +0300, Dan Carpenter wrote:
> It looks good.
>
> Like I mentioned before Smatch doesn't understand
> ext4_has_inline_data() so it still complains later on in the
> function. But it's now obvious to a human reader that there won't
> be a NULL dereference.
This is what I plan to fold into the patch. It should make it easier
for gcc to produce optimized code, as well as being easier to
understand. Hopefully this should also keep smatch happy.
- Ted
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 52f715e..ae253a2 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -1917,19 +1917,24 @@ static int __ext4_journalled_writepage(struct page *page,
struct inode *inode = mapping->host;
struct buffer_head *page_bufs = NULL;
handle_t *handle = NULL;
- int ret = 0;
- int err;
+ int ret = 0, err = 0;
+ int inline_data = ext4_has_inline_data(inode);
struct buffer_head *inode_bh = NULL;
ClearPageChecked(page);
- if (ext4_has_inline_data(inode)) {
+ if (inline_data) {
BUG_ON(page->index != 0);
BUG_ON(len > ext4_get_max_inline_size(inode));
inode_bh = ext4_journalled_write_inline_data(inode, len, page);
+ if (inode_bh == NULL)
+ goto out;
} else {
page_bufs = page_buffers(page);
- BUG_ON(!page_bufs);
+ if (!page_bufs) {
+ BUG();
+ goto out;
+ }
walk_page_buffers(handle, page_bufs, 0, len, NULL, bget_one);
}
/* As soon as we unlock the page, it can go away, but we have
@@ -1944,7 +1949,7 @@ static int __ext4_journalled_writepage(struct page *page,
BUG_ON(!ext4_handle_valid(handle));
- if (ext4_has_inline_data(inode) && inode_bh) {
+ if (inline_data) {
ret = ext4_journal_get_write_access(handle, inode_bh);
err = ext4_handle_dirty_metadata(handle, inode, inode_bh);
next prev parent reply other threads:[~2012-12-05 5:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-04 11:10 [ext4:dev 40/60] fs/ext4/inode.c:1953 __ext4_journalled_writepage() error: potential NULL dereference 'page_bufs' Dan Carpenter
2012-12-04 13:25 ` Tao Ma
2012-12-04 13:56 ` Dan Carpenter
2012-12-05 5:41 ` Theodore Ts'o [this message]
2012-12-05 8:31 ` Dan Carpenter
2012-12-05 16:25 ` Theodore Ts'o
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=20121205054125.GC18885@thunk.org \
--to=tytso@mit.edu \
--cc=dan.carpenter@oracle.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tm@tao.ma \
/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;
as well as URLs for NNTP newsgroup(s).