From: Kees Cook <keescook@chromium.org>
To: Paolo Abeni <pabeni@redhat.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
netdev@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Nick Desaulniers <ndesaulniers@google.com>,
David Rientjes <rientjes@google.com>,
Vlastimil Babka <vbabka@suse.cz>,
Pavel Begunkov <asml.silence@gmail.com>,
Menglong Dong <imagedong@tencent.com>,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH v3][next] skbuff: Proactively round up to kmalloc bucket size
Date: Fri, 21 Oct 2022 09:10:21 -0700 [thread overview]
Message-ID: <202210210909.76CDB7A2@keescook> (raw)
In-Reply-To: <0ea1fc165a6c6117f982f4f135093e69cb884930.camel@redhat.com>
On Thu, Oct 20, 2022 at 10:42:47AM +0200, Paolo Abeni wrote:
> > size = SKB_DATA_ALIGN(size);
> > size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
> > - data = kmalloc_reserve(size, gfp_mask, node, &pfmemalloc);
> > - if (unlikely(!data))
> > - goto nodata;
>
> I'm sorry for not noticing the above in the previous iteration, but I
> think this revision will produce worse code than the V1, as
> kmalloc_reserve() now pollutes an additional register.
>
> Why did you prefer adding an additional parameter to kmalloc_reserve()?
> I think computing the alloc_size in the caller is even more readable.
>
> Additionally, as a matter of personal preference, I would not introduce
> an additional variable for alloc_size, just:
>
> // ...
> size = kmalloc_size_roundup(size);
> data = kmalloc_reserve(size, gfp_mask, node, &pfmemalloc);
>
> The rationale is smaller diff, and consistent style with the existing
> code where 'size' is already adjusted multiple times icrementally.
Sure, I can do that. I will respin it. :)
--
Kees Cook
prev parent reply other threads:[~2022-10-21 16:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-18 9:33 [PATCH v3][next] skbuff: Proactively round up to kmalloc bucket size Kees Cook
2022-10-20 8:42 ` Paolo Abeni
2022-10-21 16:10 ` Kees Cook [this message]
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=202210210909.76CDB7A2@keescook \
--to=keescook@chromium.org \
--cc=asml.silence@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=imagedong@tencent.com \
--cc=kuba@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ndesaulniers@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rientjes@google.com \
--cc=vbabka@suse.cz \
/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.