Re: [PATCH v3 08/12] treewide: Use initializer for struct vm_unmapped_area_info
On Tue, 2024-03-12 at 20:18 -0700, Kees Cook wrote: > > Thanks! This looks to do exactly what it describes. :) > > Reviewed-by: Kees Cook Thanks!
Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info
On Mon, 2024-03-04 at 18:00 +, Christophe Leroy wrote:
> > Personally, I think a single patch that sets "= {}" for all of them
> > and
> > drop the all the "= 0" or "= NULL" assignments would be the
> > cleanest way
> > to go.
>
> I agree with Kees, set = {} and drop all the "something = 0;" stuff.
Thanks. Now some of the arch's have very nicely acked and reviewed the
existing patches. I'll leave those as is, and do this for anyone that
doesn't respond.
Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info
On Wed, 2024-02-28 at 09:21 -0800, Kees Cook wrote:
> I totally understand. If the "uninitialized" warnings were actually
> reliable, I would agree. I look at it this way:
>
> - initializations can be missed either in static initializers or via
> run time initializers. (So the risk of mistake here is matched --
> though I'd argue it's easier to *find* static initializers when
> adding
> new struct members.)
> - uninitialized warnings are inconsistent (this becomes an unknown
> risk)
> - when a run time initializer is missed, the contents are whatever
> was
> on the stack (high risk)
> - what a static initializer is missed, the content is 0 (low risk)
>
> I think unambiguous state (always 0) is significantly more important
> for
> the safety of the system as a whole. Yes, individual cases maybe bad
> ("what uid should this be? root?!") but from a general memory safety
> perspective the value doesn't become potentially influenced by order
> of
> operations, leftover stack memory, etc.
>
> I'd agree, lifting everything into a static initializer does seem
> cleanest of all the choices.
Hi Kees,
Well, I just gave this a try. It is giving me flashbacks of when I last
had to do a tree wide change that I couldn't fully test and the
breakage was caught by Linus.
Could you let me know if you think this is additionally worthwhile
cleanup outside of the guard gap improvements of this series? Because I
was thinking a more cowardly approach could be a new vm_unmapped_area()
variant that takes the new start gap member as a separate argument
outside of struct vm_unmapped_area_info. It would be kind of strange to
keep them separate, but it would be less likely to bump something.
Thanks,
Rick
Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info
On Wed, 2024-02-28 at 13:22 +, Christophe Leroy wrote:
> > Any preference? Or maybe am I missing your point and talking
> > nonsense?
> >
>
> So my preference would go to the addition of:
>
> info.new_field = 0;
>
> But that's very minor and if you think it is easier to manage and
> maintain by performing {} initialisation at declaration, lets go for
> that.
Appreciate the clarification and help getting this right. I'm thinking
Kees' and now Kirill's point about this patch resulting in unnecessary
manual zero initialization of the structs is probably something that
needs to be addressed.
If I created a bunch of patches to change each call site, I think the
the best is probably to do the designated field zero initialization
way.
But I can do something for powerpc special if you want. I'll first try
with powerpc matching the others, and if it seems objectionable, please
let me know.
Thanks,
Rick
Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info
On Tue, 2024-02-27 at 18:16 +, Christophe Leroy wrote: > > > Why doing a full init of the struct when all fields are re- > > > written a few > > > lines after ? > > > > It's a nice change for robustness and makes future changes easier. > > It's > > not actually wasteful since the compiler will throw away all > > redundant > > stores. > > Well, I tend to dislike default init at declaration because it often > hides missed real init. When a field is not initialized GCC should > emit > a Warning, at least when built with W=2 which sets > -Wmissing-field-initializers ? Sorry, I'm not following where you are going with this. There aren't any struct vm_unmapped_area_info users that use initializers today, so that warning won't apply in this case. Meanwhile, designated style struct initialization (which would zero new members) is very common, as well as not get anything checked by that warning. Anything with this many members is probably going to use the designated style. If we are optimizing to avoid bugs, the way this struct is used today is not great. It is essentially being used as an argument passer. Normally when a function signature changes, but a caller is missed, of course the compiler will notice loudly. But not here. So I think probably zero initializing it is safer than being setup to pass garbage. I'm trying to figure out what to do here. If I changed it so that just powerpc set the new field manually, then the convention across the kernel would be for everything to be default zero, and future other new parameters could have a greater chance of turning into garbage on powerpc. Since it could be easy to miss that powerpc was special. Would you prefer it? Or maybe I could try a new vm_unmapped_area() that takes the extra argument separately? The old callers could call the old function and not need any arch updates. It all seems strange though, because automatic zero initializing struct members is so common in the kernel. But it also wouldn't add the cleanup Kees was pointing out. Hmm. Any preference? Or maybe am I missing your point and talking nonsense?
Re: [PATCH v2 5/9] mm: Initialize struct vm_unmapped_area_info
On Tue, 2024-02-27 at 07:02 +, Christophe Leroy wrote: > > It could be possible to initialize the new field for each arch to > > 0, but > > instead simply inialize the field with a C99 struct inializing > > syntax. > > Why doing a full init of the struct when all fields are re-written a > few > lines after ? > > If I take the exemple of powerpc function slice_find_area_bottomup(): > > struct vm_unmapped_area_info info; > > info.flags = 0; > info.length = len; > info.align_mask = PAGE_MASK & ((1ul << pshift) - 1); > info.align_offset = 0; > > For me it looks better to just add: > > info.new_field = 0; /* or whatever value it needs to have */ Hi, Thanks for taking a look. Yes, I guess that should have some justification. I was thinking of two reasons: 1. No future additions of optional parameters would need to make tree wide changes like this. 2. The change is easier to review and get correct because the necessary context is within a single line. For example, in that function some of members are set within a while loop. The place you pointed seems to be the correct one, but a diff that had the new field set after: info.high_limit = addr; ...would look correct too, but not be. What is the concern with C99 initialization? FWIW, the full series also removes an indirect branch, and probably is a net win for performance in this path.
