All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: KVM list <kvm@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Sean Christopherson <seanjc@google.com>, Willy Tarreau <w@1wt.eu>,
	Kees Cook <keescook@chromium.org>,
	syzbot+e0de2333cbf95ea473e8@syzkaller.appspotmail.com
Subject: Re: [PATCH] mm: allow huge kvmalloc() calls if they're accounted to memcg
Date: Sat, 16 Oct 2021 11:10:19 -0700	[thread overview]
Message-ID: <CAHk-=whZ+iCW5yMc3zuTpZrZzjb082xtVyzk3rV+S0SUNrtAAw@mail.gmail.com> (raw)
In-Reply-To: <510287f2-84ae-b1d2-13b5-22e847284588@redhat.com>

On Sat, Oct 16, 2021 at 10:53 AM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> Sounds good, and you'll get a pull request for that tomorrow.  Then I'll
> send via Andrew a patch to add __vcalloc, so that the accounting is
> restored.

Ahh. So you used kvmalloc() mainly because the regular vmalloc()
doesn't do the gfp-flags.

We do have that "__vmalloc()" thing, but the double underscore naming
makes it a bit unfortunate (since it tends to mean "local special use
only").

I suspect you could just make "vcalloc()".

That said, I also do wonder if we could possibly change "kvcalloc()"
to avoid the warning. The reason I didn't like your patch is that
kvmalloc_node() only takes a "size_t", and the overflow condition
there is that "MAX_INT".

But the "kvcalloc()" case that takes a "number of elements and size"
should _conceptually_ warn not when the total size overflows, but when
either number or the element size overflows.

So I would also accept a patch that just changes how "kvcalloc()"
works (or how "kvmalloc_array()" works).

It's a bit annoying how we've ended up losing that "n/size"
information by the time we hit kvmalloc().

               Linus

  reply	other threads:[~2021-10-16 18:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-16  6:43 [PATCH] mm: allow huge kvmalloc() calls if they're accounted to memcg Paolo Bonzini
2021-10-16 15:39 ` Linus Torvalds
2021-10-16 17:53   ` Paolo Bonzini
2021-10-16 18:10     ` Linus Torvalds [this message]
2021-10-16 23:17       ` Paolo Bonzini
2021-10-18 15:19         ` Kees Cook
2021-10-18 15:24           ` Paolo Bonzini
2021-10-16  6:51 Paolo Bonzini
2021-10-18 15:09 ` Kees Cook

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='CAHk-=whZ+iCW5yMc3zuTpZrZzjb082xtVyzk3rV+S0SUNrtAAw@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=keescook@chromium.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=syzbot+e0de2333cbf95ea473e8@syzkaller.appspotmail.com \
    --cc=w@1wt.eu \
    /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.