Hi all,
Peter noticed that with some dumb luck you can toast the kernel address
space with exported vmalloc symbols.
I used this as an opportunity to decruft the vmalloc.c API and make it
much more systematic. This also removes any chance to create vmalloc
mappings outside the designated areas or using executable permissions
from modules. Besides that it removes more than 300 lines of code.
A git tree is also available here:
git://git.infradead.org/users/hch/misc.git sanitize-vmalloc-api
Gitweb:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/sanitize-vm…
From: Randy Dunlap <rdunlap(a)infradead.org>
Fix documentation warnings in dma-buf.[hc]:
../drivers/dma-buf/dma-buf.c:678: warning: Function parameter or member 'importer_ops' not described in 'dma_buf_dynamic_attach'
../drivers/dma-buf/dma-buf.c:678: warning: Function parameter or member 'importer_priv' not described in 'dma_buf_dynamic_attach'
../include/linux/dma-buf.h:339: warning: Incorrect use of kernel-doc format: * @move_notify
Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org>
Cc: Sumit Semwal <sumit.semwal(a)linaro.org>
Cc: linux-media(a)vger.kernel.org
Cc: dri-devel(a)lists.freedesktop.org
Cc: linaro-mm-sig(a)lists.linaro.org
---
drivers/dma-buf/dma-buf.c | 4 ++--
include/linux/dma-buf.h | 3 +--
2 files changed, 3 insertions(+), 4 deletions(-)
--- linux-next-20200407.orig/drivers/dma-buf/dma-buf.c
+++ linux-next-20200407/drivers/dma-buf/dma-buf.c
@@ -655,8 +655,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
* calls attach() of dma_buf_ops to allow device-specific attach functionality
* @dmabuf: [in] buffer to attach device to.
* @dev: [in] device to be attached.
- * @importer_ops [in] importer operations for the attachment
- * @importer_priv [in] importer private pointer for the attachment
+ * @importer_ops: [in] importer operations for the attachment
+ * @importer_priv: [in] importer private pointer for the attachment
*
* Returns struct dma_buf_attachment pointer for this attachment. Attachments
* must be cleaned up by calling dma_buf_detach().
--- linux-next-20200407.orig/include/linux/dma-buf.h
+++ linux-next-20200407/include/linux/dma-buf.h
@@ -329,13 +329,12 @@ struct dma_buf {
/**
* struct dma_buf_attach_ops - importer operations for an attachment
- * @move_notify: [optional] notification that the DMA-buf is moving
*
* Attachment operations implemented by the importer.
*/
struct dma_buf_attach_ops {
/**
- * @move_notify
+ * @move_notify: [optional] notification that the DMA-buf is moving
*
* If this callback is provided the framework can avoid pinning the
* backing store while mappings exists.
On Wed, Apr 08, 2020 at 08:15:19AM -0700, Matthew Wilcox wrote:
> > > > config ZSMALLOC_PGTABLE_MAPPING
> > > > bool "Use page table mapping to access object in zsmalloc"
> > > > - depends on ZSMALLOC
> > > > + depends on ZSMALLOC=y
> > >
> > > It's a bool so this shouldn't matter... not needed.
> >
> > My mm/Kconfig has:
> >
> > config ZSMALLOC
> > tristate "Memory allocator for compressed pages"
> > depends on MMU
> >
> > which I think means it can be modular, no?
>
> Randy means that ZSMALLOC_PGTABLE_MAPPING is a bool, so I think hch's patch
> is wrong ... if ZSMALLOC is 'm' then ZSMALLOC_PGTABLE_MAPPING would become
> 'n' instead of 'y'.
In Linus' tree you can select PGTABLE_MAPPING=y with ZSMALLOC=m,
and that fits my understanding of the kbuild language. With this
patch I can't anymore.
On 4/8/20 8:15 AM, Matthew Wilcox wrote:
> On Wed, Apr 08, 2020 at 05:12:03PM +0200, Peter Zijlstra wrote:
>> On Wed, Apr 08, 2020 at 08:01:00AM -0700, Randy Dunlap wrote:
>>> Hi,
>>>
>>> On 4/8/20 4:59 AM, Christoph Hellwig wrote:
>>>> diff --git a/mm/Kconfig b/mm/Kconfig
>>>> index 36949a9425b8..614cc786b519 100644
>>>> --- a/mm/Kconfig
>>>> +++ b/mm/Kconfig
>>>> @@ -702,7 +702,7 @@ config ZSMALLOC
>>>>
>>>> config ZSMALLOC_PGTABLE_MAPPING
>>>> bool "Use page table mapping to access object in zsmalloc"
>>>> - depends on ZSMALLOC
>>>> + depends on ZSMALLOC=y
>>>
>>> It's a bool so this shouldn't matter... not needed.
>>
>> My mm/Kconfig has:
>>
>> config ZSMALLOC
>> tristate "Memory allocator for compressed pages"
>> depends on MMU
>>
>> which I think means it can be modular, no?
ack. I misread it.
> Randy means that ZSMALLOC_PGTABLE_MAPPING is a bool, so I think hch's patch
> is wrong ... if ZSMALLOC is 'm' then ZSMALLOC_PGTABLE_MAPPING would become
> 'n' instead of 'y'.
sigh, I wish that I had meant that. :)
thanks.
--
~Randy
On Wed, Apr 08, 2020 at 01:38:36PM +0100, Mark Rutland wrote:
> > +static inline pgprot_t pgprot_nx(pgprot_t prot)
> > +{
> > + return __pgprot(pgprot_val(prot) | _PAGE_NX);
> > +}
> > +#define pgprot_nx pgprot_nx
> > +
> > #ifdef CONFIG_X86_PAE
>
> I reckon for arm64 we can do similar in our <asm/pgtable.h>:
>
> #define pgprot_nx(pgprot_t prot) \
> __pgprot_modify(prot, 0, PTE_PXN)
>
> ... matching the style of our existing pgprot_*() modifier helpers.
I've added that for the next version with attribution to you.