lkml.org 
[lkml]   [2019]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v3 03/13] software node: get rid of property_set_pointer()
On Mon, Sep 09, 2019 at 02:36:52PM +0300, Andy Shevchenko wrote:
> On Mon, Sep 09, 2019 at 03:15:55AM -0700, Dmitry Torokhov wrote:
> > On Mon, Sep 09, 2019 at 12:55:05PM +0300, Andy Shevchenko wrote:
> > > On Mon, Sep 09, 2019 at 01:15:47AM -0700, Dmitry Torokhov wrote:
> > > > Instead of explicitly setting values of integer types when copying property
> > > > entries lets just copy entire value union when processing non-array values.
> > > >
> > > > When handling array values assign the pointer there using the newly introduced
> > > > "raw" pointer union member. This allows us to remove property_set_pointer().
> > >
> > > Is this reincarnation of 318a19718261?
> > > Have you read 63dcc7090137?
> >
> > Okay, I think if I squash this and the followup patch to
> > property_get_data() then we'll only go through the "raw" pointer to get
> > to the non-inline data and therefore we will not have the union aliasing
> > issue.
> >
> > The in-line values never change their type when storing/accessing.
>
> It might work, though it prevents to do type checking at compile time. So,
> basically something like
>
> struct obscure_things {
> u8 *prop_array_val;
> bla bla bla
> };
>
> struct property_entry entry;
> struct obscure_things things;
> ...
> entry.pointer.raw = &things;
>
> which shouldn't be possible.

I think type checking is a red herring as we still can't validate the
type. I believe the answer here is to not allow external users to poke
in property_entry and use PROPERTY_ENTRY_XXX macros to construct
entires, as I have done for the Apple EFI driver.

>
> I dunno what others think about your proposal.


Thanks.

--
Dmitry

\
 
 \ /
  Last update: 2019-09-09 15:48    [W:2.405 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site