linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	"Uladzislau Rezki (Sony)" <urezki@gmail.com>,
	Kees Cook <keescook@chromium.org>, Shuah Khan <shuah@kernel.org>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
	Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC PATCH 1/1] vmalloc: add test driver to analyse vmalloc allocator
Date: Thu, 15 Nov 2018 05:47:06 -0800	[thread overview]
Message-ID: <20181115134706.GC19286@bombadil.infradead.org> (raw)
In-Reply-To: <20181115125750.GS23831@dhcp22.suse.cz>

On Thu, Nov 15, 2018 at 01:57:50PM +0100, Michal Hocko wrote:
> On Thu 15-11-18 00:46:42, Matthew Wilcox wrote:
> > How about adding
> > 
> > #ifdef CONFIG_VMALLOC_TEST
> > int run_internal_vmalloc_tests(void)
> > {
> > ...
> > }
> > EXPORT_SYMBOL_GPL(run_internal_vmalloc_tests);
> > #endif
> > 
> > to vmalloc.c?  That would also allow calling functions which are marked
> > as static, not just functions which aren't exported to modules.
> 
> Yes that would be easier but do we want to pollute the normal code with
> testing? This looks messy to me.

I don't think it's necessarily the worst thing in the world if random
people browsing the file are forced to read test-cases ;-)

There's certainly a spectrum of possibilities here, one end being to
basically just re-export static functions, and the other end putting
every vmalloc test into vmalloc.c.  vmalloc.c is pretty big at 70kB, but
on the other hand, it's the 18th largest file in mm/ (can you believe
page_alloc.c is 230kB?!)

  reply	other threads:[~2018-11-15 13:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-13 15:16 [RFC PATCH 0/1] test driver to analyse vmalloc allocator Uladzislau Rezki (Sony)
2018-11-13 15:16 ` [RFC PATCH 1/1] vmalloc: add " Uladzislau Rezki (Sony)
2018-11-13 22:10   ` Andrew Morton
2018-11-14 15:17     ` Michal Hocko
2018-11-14 23:00       ` Andrew Morton
2018-11-15  8:39         ` Michal Hocko
2018-11-15  8:46           ` Matthew Wilcox
2018-11-15 12:57             ` Michal Hocko
2018-11-15 13:47               ` Matthew Wilcox [this message]
2018-11-15 20:57                 ` Andrew Morton
2018-11-15 12:36     ` Uladzislau Rezki

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=20181115134706.GC19286@bombadil.infradead.org \
    --to=willy@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=oleksiy.avramchenko@sonymobile.com \
    --cc=shuah@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=urezki@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).