[Ocfs2-tools-devel] [PATCH] fix wrap assignment for extended slot map in ocfs2_store_slot_map()
Coly Li
coly.li at suse.de
Tue Jun 16 00:49:58 PDT 2009
Joel Becker Wrote:
> On Mon, Jun 15, 2009 at 04:06:00PM +0800, Coly Li wrote:
>> in ocfs2_store_slot_map(), no matter extended slot map is used, only wrap.mw_map
>> is initialized, which will introduce a wild memory accessing when extended slot
>> map is used.
>
> The slot_map_wrapper structure is a union. That is, the address
> of mw_map and mw_map_extended is the same. There's no wild memory
> access because merely accessing the union's addresses doesn't select
> which portion of the union is used later.
>
>> @@ -334,7 +334,12 @@ errcode_t ocfs2_store_slot_map(ocfs2_filesys *fs,
>> ret = ocfs2_malloc0(bytes, &slot_map_buf);
>> if (ret)
>> return ret;
>> - wrap.mw_map = (struct ocfs2_slot_map *)slot_map_buf;
>> +
>> + if (extended)
>> + wrap.mw_map_extended =
>> + (struct ocfs2_slot_map_extened *)slot_map_buf;
>> + else
>> + wrap.mw_map = (struct ocfs2_slot_map *)slot_map_buf;
>
> Your change makes explicit what C considers implicit. It's a
> union of one pointer. That pointer can be named mw_map_extended or
> mw_map, but it's the same pointer. So the code
>
> wrap.mw_map = (struct ocfs2_slot_map *)slot_map_buf;
>
> is equivalent to:
>
> (char *)wrap.mw_map = slot_map_buf;
>
> It is just setting the pointer, with casts making sure that the compiler
> does not complain. Higher up in ocfs2_store_slot_map(), we make sure
> the buffer is big enough and we zero it out.
> So, NAK, the code is correct as-is.
>
Hi Joel,
I toke slot_map_wrapper as a structure other than union in my patch. That's how
my (incorrect) conclusion came.
Yes, the code is correct. Thanks for the patient explaining :)
--
Coly Li
SuSE Labs
More information about the Ocfs2-tools-devel
mailing list