mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nicholas Piggin <npiggin@gmail.com>
To: Joel Fernandes <joelaf@google.com>
Cc: Christoph Hellwig <hch@lst.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jisheng Zhang <jszhang@marvell.com>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	John Dias <joaodias@google.com>,
	"open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>,
	linux-rt-users@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/6] mm: remove free_unmap_vmap_area_addr
Date: Fri, 21 Oct 2016 12:58:28 +1100	[thread overview]
Message-ID: <20161021125828.17b8960e@roar.ozlabs.ibm.com> (raw)
In-Reply-To: <CAJWu+oqOw6uMh+Q_78MGjO8WKLxCuh4fmVmKxEJ5aoviXjoMcA@mail.gmail.com>

On Thu, 20 Oct 2016 17:46:36 -0700
Joel Fernandes <joelaf@google.com> wrote:

> > @@ -1100,10 +1091,14 @@ void vm_unmap_ram(const void *mem, unsigned int count)
> >         debug_check_no_locks_freed(mem, size);
> >         vmap_debug_free_range(addr, addr+size);
> >
> > -       if (likely(count <= VMAP_MAX_ALLOC))
> > +       if (likely(count <= VMAP_MAX_ALLOC)) {
> >                 vb_free(mem, size);
> > -       else
> > -               free_unmap_vmap_area_addr(addr);
> > +               return;
> > +       }
> > +
> > +       va = find_vmap_area(addr);
> > +       BUG_ON(!va);  
> 
> Considering recent objections to BUG_ON [1], lets make this a WARN_ON
> while we're moving the code?

If you lost track of your kernel memory mappings, you are in big trouble
and fail stop is really the best course of action for containing the
problem, which could have security and data corruption implications. This
is covered by Linus' last paragraph in that commit.

Thanks,
Nick

  reply	other threads:[~2016-10-21  1:58 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-18  6:56 [RFC] reduce latency in __purge_vmap_area_lazy Christoph Hellwig
2016-10-18  6:56 ` [PATCH 1/6] mm: refactor __purge_vmap_area_lazy Christoph Hellwig
2016-10-18  6:56 ` [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping Christoph Hellwig
2016-10-18 10:33   ` Chris Wilson
2016-10-18 10:38     ` Christoph Hellwig
2016-10-19 11:15   ` Chris Wilson
2016-10-19 13:05     ` Christoph Hellwig
2016-10-19 15:34       ` Andy Lutomirski
2016-10-19 16:31         ` Christoph Hellwig
2016-10-19 19:43           ` Chris Wilson
2016-10-21  0:32           ` Joel Fernandes
2016-11-08 13:24     ` Joel Fernandes
2016-11-08 14:32       ` Andrey Ryabinin
2016-10-18  6:56 ` [PATCH 3/6] mm: remove free_unmap_vmap_area_noflush Christoph Hellwig
2016-10-18  6:56 ` [PATCH 4/6] mm: remove free_unmap_vmap_area_addr Christoph Hellwig
2016-10-21  0:46   ` Joel Fernandes
2016-10-21  1:58     ` Nicholas Piggin [this message]
2016-10-18  6:56 ` [PATCH 5/6] mm: turn vmap_purge_lock into a mutex Christoph Hellwig
2016-10-18  6:56 ` [PATCH 6/6] mm: add preempt points into __purge_vmap_area_lazy Christoph Hellwig
2016-10-18 20:56   ` Steven Rostedt
2016-10-18 21:01     ` Steven Rostedt
2016-10-18 10:40 ` [RFC] reduce latency in __purge_vmap_area_lazy Nicholas Piggin
2016-10-18 11:21 ` Jisheng Zhang
2016-10-21  1:08 ` Joel Fernandes

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=20161021125828.17b8960e@roar.ozlabs.ibm.com \
    --to=npiggin@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=hch@lst.de \
    --cc=joaodias@google.com \
    --cc=joelaf@google.com \
    --cc=jszhang@marvell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-rt-users@vger.kernel.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

Powered by JetHome