On Fri, 20 Apr 2012 16:13:36 +0300 Dan Carpenter <dan.carpenter@xxxxxxxxxx>
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:
signature.asc
Description: PGP signature
