| Message ID | 20220922031013.2150682-5-keescook@chromium.org (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | slab: Introduce kmalloc_size_roundup() | expand |
On Wed, Sep 21, 2022 at 08:10:05PM -0700, Kees Cook wrote: > Instead of discovering the kmalloc bucket size _after_ allocation, round > up proactively so the allocation is explicitly made for the full size, > allowing the compiler to correctly reason about the resulting size of > the buffer through the existing __alloc_size() hint. > > Cc: linux-btrfs@vger.kernel.org > Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: David Sterba <dsterba@suse.com>
diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c index e7671afcee4f..d40d65598e8f 100644 --- a/fs/btrfs/send.c +++ b/fs/btrfs/send.c @@ -435,6 +435,11 @@ static int fs_path_ensure_buf(struct fs_path *p, int len) path_len = p->end - p->start; old_buf_len = p->buf_len; + /* + * Allocate to the next largest kmalloc bucket size, to let + * the fast path happen most of the time. + */ + len = kmalloc_size_roundup(len); /* * First time the inline_buf does not suffice */ @@ -448,11 +453,7 @@ static int fs_path_ensure_buf(struct fs_path *p, int len) if (!tmp_buf) return -ENOMEM; p->buf = tmp_buf; - /* - * The real size of the buffer is bigger, this will let the fast path - * happen most of the time - */ - p->buf_len = ksize(p->buf); + p->buf_len = len; if (p->reversed) { tmp_buf = p->buf + old_buf_len - path_len - 1;
Instead of discovering the kmalloc bucket size _after_ allocation, round up proactively so the allocation is explicitly made for the full size, allowing the compiler to correctly reason about the resulting size of the buffer through the existing __alloc_size() hint. Cc: linux-btrfs@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> --- fs/btrfs/send.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)