From: Kees Cook <keescook@chromium.org>
To: Romain Perier <romain.perier@gmail.com>
Cc: Kernel Hardening <kernel-hardening@lists.openwall.com>,
Shyam Saini <mayhs11saini@gmail.com>
Subject: Re: refactor tasklets to avoid unsigned long argument
Date: Thu, 8 Aug 2019 14:02:52 -0700 [thread overview]
Message-ID: <201908081344.B616EB365F@keescook> (raw)
In-Reply-To: <CABgxDo+ys-84ifkAMQp2Snv2PV4yTEYwi+3Jj9aGARn0hbhuWQ@mail.gmail.com>
On Thu, Aug 08, 2019 at 05:47:29PM +0200, Romain Perier wrote:
> Le mar. 23 juil. 2019 à 10:15, Romain Perier <romain.perier@gmail.com> a écrit :
> >
> > Le lun. 22 juil. 2019 à 19:19, Kees Cook <keescook@chromium.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.
> 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?
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);
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...)
--
Kees Cook
next prev parent reply other threads:[~2019-08-08 21:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-02 7:35 refactor tasklets to avoid unsigned long argument Romain Perier
2019-07-02 15:51 ` Kees Cook
2019-07-03 15:48 ` Romain Perier
2019-07-03 22:46 ` Kees Cook
2019-07-21 17:55 ` Romain Perier
2019-07-22 17:19 ` Kees Cook
2019-07-23 8:15 ` Romain Perier
2019-08-08 15:47 ` Romain Perier
2019-08-08 21:02 ` Kees Cook [this message]
2019-08-12 17:29 ` Romain Perier
2019-08-29 18:13 ` Romain Perier
2019-08-29 18:35 ` Kees Cook
2019-09-29 16:37 ` Romain Perier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201908081344.B616EB365F@keescook \
--to=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=mayhs11saini@gmail.com \
--cc=romain.perier@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).