From: NeilBrown <neilb@suse.de>
To: Dan Carpenter <dan.carpenter@ORACLE.COM>
Cc: linux-raid@vger.kernel.org
Subject: Re: md/bitmap: move some fields of 'struct bitmap' into a 'storage' substruct.
Date: Mon, 23 Apr 2012 10:10:49 +1000 [thread overview]
Message-ID: <20120423101049.633d9be7@notabene.brown> (raw)
In-Reply-To: <20120420131336.GA26339@elgon.mountain>
[-- Attachment #1: Type: text/plain, Size: 2461 bytes --]
On Fri, 20 Apr 2012 16:13:36 +0300 Dan Carpenter <dan.carpenter@ORACLE.COM>
wrote:
> Hello NeilBrown,
>
> This is a semi-automatic email about new static checker warnings.
>
> The patch 9159d8a35d0a: "md/bitmap: move some fields of 'struct
> bitmap' into a 'storage' substruct." from Apr 19, 2012, leads to the
> following Smatch complaint:
>
> drivers/md/bitmap.c:1212 bitmap_daemon_work()
> error: we previously assumed 'bitmap->storage.filemap' could be
> null (see line 1145)
>
> drivers/md/bitmap.c
> 1144 bitmap->need_sync = 0;
> 1145 if (bitmap->storage.filemap) {
> ^^^^^^^^^^^^^^^^^^^^^^^
> Renamed check.
>
> 1146 sb = kmap_atomic(bitmap->storage.sb_page);
> 1147 sb->events_cleared =
> 1148 cpu_to_le64(bitmap->events_cleared);
> 1149 kunmap_atomic(sb);
> 1150 set_page_attr(bitmap, 0,
> 1151 BITMAP_PAGE_NEEDWRITE);
> 1152 }
> 1153 }
>
> [snip]
>
> 1210 if (test_and_clear_page_attr(bitmap, j,
> 1211 BITMAP_PAGE_NEEDWRITE)) {
> 1212 write_page(bitmap, bitmap->storage.filemap[j], 0);
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
> Renamed dereference.
There is a relationship between storage.filemap and storage.file_pages.
If the later is 0, the former must be non-NULL.
This dereference only happens if file_pages > 0... Maybe I should check
file_pages up above so as not to confuse smatch??
>
> 1213 if (!bitmap->storage.filemap)
> ^^^^^^^^^^^^^^^^^^^^^^^
> Another check.
Yes, that does look odd. The check isn't needed any more and I have just
removed it.
Previously if write_page() got an error it would free the filemap. At that
time there was locking here.
spin_unlock
write_page()
spin_lock
if (!bitmap->storage.filemap) ....
so it was more obvious that filemap could well change between the write_page
and the test.
When I change write_page to not free the filemap any more, I could remove the
locking. But I didn't notice that I could remove the test as well.
New code will be in my for-next shortly.
Thanks,
NeilBrown
>
> 1214 break;
>
> Really, this isn't a new warning, it's just shows up as a new warning
> because of the rename. Still, I was curious about the check after the
> dereference.
>
> regards,
> dan carpenter
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2012-04-23 0:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-20 13:13 md/bitmap: move some fields of 'struct bitmap' into a 'storage' substruct Dan Carpenter
2012-04-23 0:10 ` NeilBrown [this message]
2012-04-23 10:17 ` Dan Carpenter
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=20120423101049.633d9be7@notabene.brown \
--to=neilb@suse.de \
--cc=dan.carpenter@ORACLE.COM \
--cc=linux-raid@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;
as well as URLs for NNTP newsgroup(s).