From: Russell King - ARM Linux <linux@armlinux.org.uk>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: linux-mm@kvack.org, mark.rutland@arm.com, mhocko@suse.com,
akpm@linux-foundation.org, zhongjiang@huawei.com,
linux-arm-kernel@lists.infradead.org, labbott@fedoraproject.org
Subject: Re: [PATCH] mm: vmalloc: simplify vread/vwrite to use existing mappings
Date: Thu, 8 Jun 2017 17:06:44 +0100 [thread overview]
Message-ID: <20170608160644.GM4902@n2100.armlinux.org.uk> (raw)
In-Reply-To: <20170607182052.31447-1-ard.biesheuvel@linaro.org>
On Wed, Jun 07, 2017 at 06:20:52PM +0000, Ard Biesheuvel wrote:
> The current safe path iterates over each mapping page by page, and
> kmap()'s each one individually, which is expensive and unnecessary.
> Instead, let's use kern_addr_valid() to establish on a per-VMA basis
> whether we may safely derefence them, and do so via its mapping in
> the VMALLOC region. This can be done safely due to the fact that we
> are holding the vmap_area_lock spinlock.
This doesn't sound correct if you look at the definition of
kern_addr_valid(). For example, x86-32 has:
/*
* kern_addr_valid() is (1) for FLATMEM and (0) for
* SPARSEMEM and DISCONTIGMEM
*/
#ifdef CONFIG_FLATMEM
#define kern_addr_valid(addr) (1)
#else
#define kern_addr_valid(kaddr) (0)
#endif
The majority of architectures simply do:
#define kern_addr_valid(addr) (1)
So, the result is that on the majority of architectures, we're now
going to simply dereference 'addr' with very little in the way of
checks.
I think this makes these functions racy - the point at which the
entry is placed onto the vmalloc list is quite different from the
point where the page table entries for it are populated (which
happens with the lock dropped.) So, I think this is asking for
an oops.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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>
next prev parent reply other threads:[~2017-06-08 16:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-07 18:20 [PATCH] mm: vmalloc: simplify vread/vwrite to use existing mappings Ard Biesheuvel
2017-06-07 18:22 ` Ard Biesheuvel
2017-06-08 16:06 ` Russell King - ARM Linux [this message]
2017-06-08 16:15 ` Ard Biesheuvel
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=20170608160644.GM4902@n2100.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=akpm@linux-foundation.org \
--cc=ard.biesheuvel@linaro.org \
--cc=labbott@fedoraproject.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=mark.rutland@arm.com \
--cc=mhocko@suse.com \
--cc=zhongjiang@huawei.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).