[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190812172951.GA5361@debby.home>
Date: Mon, 12 Aug 2019 19:29:51 +0200
From: Romain Perier <romain.perier@...il.com>
To: Kees Cook <keescook@...omium.org>, kernel-hardening@...ts.openwall.com
Subject: Re: refactor tasklets to avoid unsigned long argument
On Thu, Aug 08, 2019 at 02:02:52PM -0700, Kees Cook wrote:
> On Thu, Aug 08, 2019 at 05:47:29PM +0200, Romain Perier wrote:
> > Le mar. 23 juil. 2019 à 10:15, Romain Perier <romain.perier@...il.com> a écrit :
> > >
> > > Le lun. 22 juil. 2019 à 19:19, Kees Cook <keescook@...omium.org> a écrit :
> > > >
> > > > On Sun, Jul 21, 2019 at 07:55:33PM +0200, Romain Perier wrote:
> > > > > Ok, thanks for these explanations.
> > > >
> > > > (Reminder: please use inline-context email replies instead of
> > > > top-posting, this makes threads much easier to read.)
> > >
> > > Arf, good point. My bad :)
> > >
> > > >
> > > >
> > > > Looks good! I wonder if you're able to use Coccinelle to generate the
> > > > conversion patch? There appear to be just under 400 callers of
> > > > tasklet_init(), which is a lot to type by hand. :)
> > >
> > > Mmmhhh, I did not thought *at all* to coccinelle for this, good idea.
> > > I am gonna to read some docs about the tool
> > >
> > > >
> > > > Also, have you found any other tasklet users that are NOT using
> > > > tasklet_init()? The timer_struct conversion had about three ways
> > > > to do initialization. :(
> > >
> > > This is what I was looking before you give me details about the task.
> > > It seems, there
> > > is only one way to init a tasklet. I have just re-checked, it seems ok.
> >
> > Work is in progress (that's an hobby not full time). I am testing the
> > build with "allyesconfig".
>
> That's good -- I tend to use allmodconfig (since it sort of tests a
> larger set of functions -- the module init code is more complex than the
> static init code, IIRC), but I think for this series, you're fine either
> way.
>
Oh, good to know (I did not know allmodconfig). Yeah I think that it is enough
for this series, but that's a good idea for the other ones :)
> > Do you think it is acceptable to change
> > drivers/mmc/host/renesas_sdhi_internal_dmac.c to add a pointer to the
> > "struct device" or to the "host", so
> > renesas_sdhi_internal_dmac_complete_tasklet_fn() could access "host"
> > from the tasklet parameter
> > because currently, it is not possible.
> > from the tasklet you can access "dma_priv", from "dma_priv" you can
> > access "priv", then from "priv", you're blocked :)
> >
> >
> > This is what I have done for now :
> > https://salsa.debian.org/rperier-guest/linux-tree/commit/a0e5735129b4118a1df55b02fead6fa9b7996520
> > (separately)
> >
> > Then the handler would be something like:
> > https://salsa.debian.org/rperier-guest/linux-tree/commit/5fe1eaeb45060a7df10d166cc96e0bdcf0024368
> > (scroll down to renesas_sdhi_internal_dmac_complete_tasklet_fn() ).
>
> I did things like this in a few cases for timer_struct, yes. The only
> question I have is if "struct device" is what you want or "struct
> platform_device" is what you want?
>
> + priv->dev = &pdev->dev;
>
> You're already dereferencing "pdev" to get "dev", and then:
>
> + struct platform_device *pdev = container_of(priv->dev, typeof(*pdev), dev);
>
> What you really want is the pdev anyway in the handler. Maybe just store
> that instead?
Yup, this is what I have done after sending the previous email ;)
>
> Also, I think you can avoid the "dma_priv" variable with a from_tasklet()
> that uses dma_priv.dma_complete. Something like:
>
> struct renesas_sdhi *priv = from_tasklet(priv, t, dma_priv.dma_complete);
>
Mhhh, I thought that container_of() was only working for "1-level" (so
just take the pointer of the parent structure), indeed when you take
a look at how the macro is defined, it make sense. It will make the
code easier to read. Interesting... !
> The only other gotcha to check is if it's ever possible for the pointer
> you're storing to change through some other means, which would cause you
> to be doing a use-after-free in this handler? (I assume not, since dma
> completion is tied to the device...)
>
I think not in this case, but I agree, that's also preferable for this
reason.
Thanks for your feedbacks,
Regards,
Romain
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
