linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: lsf-pc@lists.linux-foundation.org
Cc: linux-mm@kvack.org
Subject: [LSF/MM TOPIC] Matthew's minor MM topics
Date: Tue, 16 Jan 2018 06:13:54 -0800	[thread overview]
Message-ID: <20180116141354.GB30073@bombadil.infradead.org> (raw)

(trying again with the right MM mailing list address.  Sorry.)

I have a number of things I'd like to discuss that are purely MM related.
I don't know if any of them rise to the level of an entire session,
but maybe lightning talks, or maybe we can dispose of them on the list
before the summit.

1. GFP_DMA / GFP_HIGHMEM / GFP_DMA32

The documentation is clear that only one of these three bits is allowed
to be set.  Indeed, we have code that checks that only one of these
three bits is set.  So why do we have three bits?  Surely this encoding
works better:

00b (normal)
01b GFP_DMA
10b GFP_DMA32
11b GFP_HIGHMEM
(or some other clever encoding that maps well to the zone_type index)

2. kvzalloc_ab_c()

We could bikeshed on this name all summit long, but the idea is to provide
an equivalent of kvmalloc_array() which works for array-plus-header.
These allocations are legion throughout the kernel.  Here's the first
one I found with a grep:

drivers/vhost/vhost.c:  newmem = kvzalloc(size + mem.nregions * sizeof(*m->regions), GFP_KERNEL);

... and, yep, that one's a security hole.

The implementation is not hard, viz:

+static inline void *kvzalloc_ab_c(size_t n, size_t size, size_t c, gfp_t flags)
+{
+       if (size != 0 && n > (SIZE_MAX - c) / size)
+               return NULL;
+
+       return kvmalloc(n * size + c, flags);
+}

but the name will tie us in knots and getting people to actually use
it will be worse.  (I actually stole the name from another project,
but I can't find it now).

We also need to go through and convert dozens of callers that are
doing kvzalloc(a * b) into kvzalloc_array(a, b).  Maybe we can ask for
some coccinelle / smatch / checkpatch help here.

3. Maybe we could rename kvfree() to just free()?  Please?  There's
nothing special about it.  One fewer thing for somebody to learn when
coming fresh to kernel programming.

4. vmf_insert_(page|pfn|mixed|...)

vm_insert_foo are invariably called from fault handlers, usually as
the last thing we do before returning a VM_FAULT code.  As such, why do
they return an errno that has to be translated?  We would be better off
returning VM_FAULT codes from these functions.

Related, I'd like to introduce a new vm_fault_t typedef for unsigned
int that indicates that the function returns VM_FAULT flags rather than
an errno.  We've had so many mistakes in this area.


----- End forwarded message -----

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

             reply	other threads:[~2018-01-16 14:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-16 14:13 Matthew Wilcox [this message]
2018-01-23 12:26 ` [Lsf-pc] " Michal Hocko
2018-01-23 20:48   ` Matthew Wilcox
2018-01-24  8:56     ` Michal Hocko
2018-01-29 12:37   ` Matthew Wilcox
2018-01-29 12:48     ` Michal Hocko

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=20180116141354.GB30073@bombadil.infradead.org \
    --to=willy@infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    /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