From: Johannes Berg <johannes@sipsolutions.net>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "<linux-wireless@vger.kernel.org>"
<linux-wireless@vger.kernel.org>,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
"<netdev@vger.kernel.org>" <netdev@vger.kernel.org>,
Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: [PATCH v4] mac80211: move extra crypto data off the stack
Date: Mon, 17 Oct 2016 11:54:01 +0200 [thread overview]
Message-ID: <1476698041.19992.19.camel@sipsolutions.net> (raw)
In-Reply-To: <67161BCC-596E-4DDE-A58E-9195BB5570C2@linaro.org> (sfid-20161017_115245_275022_941CE721)
> > Well, if your other patch to make it OK to be on-stack would be
> > applied instead, this wouldn't make much sense either :)
> >
>
> Yes but that one only fixes ccm not gcm
Yes, but we can do the same for GCM, no?
> > In this particular patch, we could reduce the size of the struct,
> > but I
> > don't actually think it'll make a difference to go from 48 to 36
> > bytes,
> > given alignment etc., so I think I'll just leave it as is.
> >
>
> I understand you are in a hurry, but this is unlikely to be the only
> such issue. I will propose an 'auxdata' feature for the crypto api
> that can be used here, but also for any other occurrence where client
> data assoiciated with the request can no longer be allocated on the
> stack
No objections. I'll merge this anyway today I think, reverting is easy
later.
johannes
WARNING: multiple messages have this Message-ID (diff)
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
To: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: "<linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>"
<linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Sergey Senozhatsky
<sergey.senozhatsky.work-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>"
<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Herbert Xu
<herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Subject: Re: [PATCH v4] mac80211: move extra crypto data off the stack
Date: Mon, 17 Oct 2016 11:54:01 +0200 [thread overview]
Message-ID: <1476698041.19992.19.camel@sipsolutions.net> (raw)
In-Reply-To: <67161BCC-596E-4DDE-A58E-9195BB5570C2-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> (sfid-20161017_115245_275022_941CE721)
> > Well, if your other patch to make it OK to be on-stack would be
> > applied instead, this wouldn't make much sense either :)
> >
>
> Yes but that one only fixes ccm not gcm
Yes, but we can do the same for GCM, no?
> > In this particular patch, we could reduce the size of the struct,
> > but I
> > don't actually think it'll make a difference to go from 48 to 36
> > bytes,
> > given alignment etc., so I think I'll just leave it as is.
> >
>
> I understand you are in a hurry, but this is unlikely to be the only
> such issue. I will propose an 'auxdata' feature for the crypto api
> that can be used here, but also for any other occurrence where client
> data assoiciated with the request can no longer be allocated on the
> stack
No objections. I'll merge this anyway today I think, reverting is easy
later.
johannes
next prev parent reply other threads:[~2016-10-17 9:54 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-17 8:33 [PATCH v4] mac80211: move extra crypto data off the stack Johannes Berg
2016-10-17 8:33 ` Johannes Berg
2016-10-17 9:14 ` Ard Biesheuvel
2016-10-17 9:17 ` Ard Biesheuvel
2016-10-17 9:23 ` Johannes Berg
2016-10-17 9:23 ` Johannes Berg
2016-10-17 9:30 ` Ard Biesheuvel
2016-10-17 9:35 ` Johannes Berg
2016-10-17 9:35 ` Johannes Berg
2016-10-17 9:49 ` Ard Biesheuvel
2016-10-17 9:49 ` Ard Biesheuvel
2016-10-17 9:52 ` Ard Biesheuvel
2016-10-17 9:52 ` Ard Biesheuvel
2016-10-17 9:54 ` Johannes Berg [this message]
2016-10-17 9:54 ` Johannes Berg
2016-10-17 10:02 ` Ard Biesheuvel
2016-10-17 10:02 ` Ard Biesheuvel
2016-10-17 13:06 ` Ard Biesheuvel
2016-10-17 13:06 ` Ard Biesheuvel
2016-10-17 13:16 ` Johannes Berg
2016-10-17 13:20 ` Ard Biesheuvel
2016-10-17 13:20 ` Ard Biesheuvel
2016-10-17 13:25 ` Johannes Berg
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=1476698041.19992.19.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=ard.biesheuvel@linaro.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sergey.senozhatsky.work@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.