Re: [PATCH v5 2/5] allow mapping page-less memremaped areas into KVA
On 08/13/2015 06:01 AM, Dan Williams wrote:
> Introduce a type that encapsulates a page-frame-number that can also be
> used to encode other information. This other information is the
> traditional "page_link" encoding in a scatterlist, but can also denote
> "device memory". Where "device memory" is a set of pfns that are not
> part of the kernel's linear mapping, but are accessed via the same
> memory controller as ram. The motivation for this conversion is large
> capacity persistent memory that does not enjoy struct page coverage,
> entries in 'memmap' by default.
>
> This type will be used in replace usage of 'struct page *' in cases
> where only a pfn is required, i.e. scatterlists for drivers, dma mapping
> api, and potentially biovecs for the block layer. The operations in
> those i/o paths that formerly required a 'struct page *' are converted
> to use __pfn_t aware equivalent helpers.
>
> It turns out that while 'struct page' references are used broadly in the
> kernel I/O stacks the usage of 'struct page' based capabilities is very
> shallow for block-i/o. It is only used for populating bio_vecs and
> scatterlists for the retrieval of dma addresses, and for temporary
> kernel mappings (kmap). Aside from kmap, these usages can be trivially
> converted to operate on a pfn.
>
> Indeed, kmap_atomic() is more problematic as it uses mm infrastructure,
> via struct page, to setup and track temporary kernel mappings. It would
> be unfortunate if the kmap infrastructure escaped its 32-bit/HIGHMEM
> bonds and leaked into 64-bit code. Thankfully, it seems all that is
> needed here is to convert kmap_atomic() callers, that want to opt-in to
> supporting persistent memory, to use a new kmap_atomic_pfn_t(). Where
> kmap_atomic_pfn_t() is enabled to re-use the existing ioremap() mapping
> established by the driver for persistent memory.
>
> Note, that as far as conceptually understanding __pfn_t is concerned,
> 'persistent memory' is really any address range in host memory not
> covered by memmap. Contrast this with pure iomem that is on an mmio
> mapped bus like PCI and cannot be converted to a dma_addr_t by "pfn <<
> PAGE_SHIFT".
>
> It would be unfortunate if the kmap infrastructure escaped its current
> 32-bit/HIGHMEM bonds and leaked into 64-bit code. Instead, if the user
> has enabled CONFIG_DEV_PFN we direct the kmap_atomic_pfn_t()
> implementation to scan a list of pre-mapped persistent memory address
> ranges inserted by the pmem driver.
>
> The __pfn_t to resource lookup is indeed inefficient walking of a linked list,
> but there are two mitigating factors:
>
> 1/ The number of persistent memory ranges is bounded by the number of
>DIMMs which is on the order of 10s of DIMMs, not hundreds.
>
> 2/ The lookup yields the entire range, if it becomes inefficient to do a
>kmap_atomic_pfn_t() a PAGE_SIZE at a time the caller can take
>advantage of the fact that the lookup can be amortized for all kmap
>operations it needs to perform in a given range.
>
> [hch: various changes]
> Signed-off-by: Christoph Hellwig
> Signed-off-by: Dan Williams
> ---
> include/linux/kmap_pfn.h | 31
> include/linux/mm.h | 57 ++
> mm/Kconfig |3 +
> mm/Makefile |1
> mm/kmap_pfn.c| 117
> ++
> 5 files changed, 209 insertions(+)
> create mode 100644 include/linux/kmap_pfn.h
> create mode 100644 mm/kmap_pfn.c
>
> diff --git a/include/linux/kmap_pfn.h b/include/linux/kmap_pfn.h
> new file mode 100644
> index ..fa44971d8e95
> --- /dev/null
> +++ b/include/linux/kmap_pfn.h
> @@ -0,0 +1,31 @@
> +#ifndef _LINUX_KMAP_PFN_H
> +#define _LINUX_KMAP_PFN_H 1
> +
> +#include
> +
> +struct device;
> +struct resource;
> +#ifdef CONFIG_KMAP_PFN
> +extern void *kmap_atomic_pfn_t(__pfn_t pfn);
> +extern void kunmap_atomic_pfn_t(void *addr);
> +extern int devm_register_kmap_pfn_range(struct device *dev,
> + struct resource *res, void *base);
> +#else
> +static inline void *kmap_atomic_pfn_t(__pfn_t pfn)
> +{
> + return kmap_atomic(__pfn_t_to_page(pfn));
> +}
> +
> +static inline void kunmap_atomic_pfn_t(void *addr)
> +{
> + __kunmap_atomic(addr);
> +}
> +
> +static inline int devm_register_kmap_pfn_range(struct device *dev,
> + struct resource *res, void *base)
> +{
> + return 0;
> +}
> +#endif /* CONFIG_KMAP_PFN */
> +
> +#endif /* _LINUX_KMAP_PFN_H */
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 84b05ebedb2d..57ba5ca6be72 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -924,6 +924,63 @@ static inline void set_page_links(struct page *page,
> enum zone_type zone,
> }
>
> /*
> + * __pfn_t: encapsulates a page-frame number that is optionally backed
> + * by memmap (struct page). This type will be used in place of a
> + * 'struct page *' instance in contexts where unmapped memory
[PATCH] sched: sync with the cfs_rq when changing sched class
From: Byungchul Park
this work is based on a patch below, which may not be reviewed yet.
https://lkml.org/lkml/2015/8/12/914, that subject is,
"sched: sync with the prev cfs when changing cgroup within a cpu".
->8-
>From e96bc0439a8d9504c9ea33d6253f946a92c3dbc5 Mon Sep 17 00:00:00 2001
From: Byungchul Park
Date: Thu, 13 Aug 2015 14:29:52 +0900
Subject: [PATCH] sched: sync with the cfs_rq when changing sched class
currently, a task load is synced with its cfs_rq, only when it
leaves from fair class. we also need to sync it with cfs_rq when
it returns back to fair class, too.
in addition, i created two functions for attaching/detaching a se
load from/to its cfs_rq, and let them use those functions. and i
place that function call to where a se is attached/detached
to/from cfs_rq.
Signed-off-by: Byungchul Park
---
kernel/sched/fair.c | 78 +--
1 file changed, 39 insertions(+), 39 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 979ca2c..72d13af 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2709,6 +2709,31 @@ static inline void update_load_avg(struct sched_entity
*se, int update_tg)
update_tg_load_avg(cfs_rq, 0);
}
+static void attach_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity
*se)
+{
+ se->avg.last_update_time = cfs_rq->avg.last_update_time;
+ cfs_rq->avg.load_avg += se->avg.load_avg;
+ cfs_rq->avg.load_sum += se->avg.load_sum;
+ cfs_rq->avg.util_avg += se->avg.util_avg;
+ cfs_rq->avg.util_sum += se->avg.util_sum;
+}
+
+static void detach_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity
*se)
+{
+ __update_load_avg(cfs_rq->avg.last_update_time, cpu_of(rq_of(cfs_rq)),
+ >avg, se->on_rq * scale_load_down(se->load.weight),
+ cfs_rq->curr == se, NULL);
+
+ cfs_rq->avg.load_avg =
+ max_t(long, cfs_rq->avg.load_avg - se->avg.load_avg, 0);
+ cfs_rq->avg.load_sum =
+ max_t(s64, cfs_rq->avg.load_sum - se->avg.load_sum, 0);
+ cfs_rq->avg.util_avg =
+ max_t(long, cfs_rq->avg.util_avg - se->avg.util_avg, 0);
+ cfs_rq->avg.util_sum =
+ max_t(s32, cfs_rq->avg.util_sum - se->avg.util_sum, 0);
+}
+
/* Add the load generated by se into cfs_rq's load average */
static inline void
enqueue_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se)
@@ -2717,27 +2742,20 @@ enqueue_entity_load_avg(struct cfs_rq *cfs_rq, struct
sched_entity *se)
u64 now = cfs_rq_clock_task(cfs_rq);
int migrated = 0, decayed;
- if (sa->last_update_time == 0) {
- sa->last_update_time = now;
+ if (sa->last_update_time == 0)
migrated = 1;
- }
- else {
+ else
__update_load_avg(now, cpu_of(rq_of(cfs_rq)), sa,
- se->on_rq * scale_load_down(se->load.weight),
- cfs_rq->curr == se, NULL);
- }
+ se->on_rq * scale_load_down(se->load.weight),
+ cfs_rq->curr == se, NULL);
decayed = update_cfs_rq_load_avg(now, cfs_rq);
cfs_rq->runnable_load_avg += sa->load_avg;
cfs_rq->runnable_load_sum += sa->load_sum;
- if (migrated) {
- cfs_rq->avg.load_avg += sa->load_avg;
- cfs_rq->avg.load_sum += sa->load_sum;
- cfs_rq->avg.util_avg += sa->util_avg;
- cfs_rq->avg.util_sum += sa->util_sum;
- }
+ if (migrated)
+ attach_entity_load_avg(cfs_rq, se);
if (decayed || migrated)
update_tg_load_avg(cfs_rq, 0);
@@ -7911,17 +7929,7 @@ static void switched_from_fair(struct rq *rq, struct
task_struct *p)
#ifdef CONFIG_SMP
/* Catch up with the cfs_rq and remove our load when we leave */
- __update_load_avg(cfs_rq->avg.last_update_time, cpu_of(rq), >avg,
- se->on_rq * scale_load_down(se->load.weight), cfs_rq->curr ==
se, NULL);
-
- cfs_rq->avg.load_avg =
- max_t(long, cfs_rq->avg.load_avg - se->avg.load_avg, 0);
- cfs_rq->avg.load_sum =
- max_t(s64, cfs_rq->avg.load_sum - se->avg.load_sum, 0);
- cfs_rq->avg.util_avg =
- max_t(long, cfs_rq->avg.util_avg - se->avg.util_avg, 0);
- cfs_rq->avg.util_sum =
- max_t(s32, cfs_rq->avg.util_sum - se->avg.util_sum, 0);
+ detach_entity_load_avg(cfs_rq, se);
#endif
}
@@ -7938,6 +7946,11 @@ static void switched_to_fair(struct rq *rq, struct
task_struct *p)
*/
se->depth = se->parent ? se->parent->depth + 1 : 0;
#endif
+
+#ifdef CONFIG_SMP
+ /* synchronize task with its cfs_rq */
+ attach_entity_load_avg(cfs_rq_of(>se), >se);
+#endif
if (!task_on_rq_queued(p))
return;
@@ -8023,16 +8036,7 @@ static void
Re: [PATCH v5 6/8] pmem: convert to generic memremap
On Wed, Aug 12, 2015 at 08:12:35PM -0400, Dan Williams wrote: > Kill arch_memremap_pmem() and just let the architecture specify the > flags to be passed to memremap(). Default to writethrough by default. Looks good, Reviewed-by: Christoph Hellwig -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 3/8] cleanup IORESOURCE_CACHEABLE vs ioremap()
Looks good, Reviewed-by: Christoph Hellwig -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REPOST PATCH] kexec: Remove the unnecessary conditional judgement to simplify the code logic
On 08/13/15 at 09:55am, Simon Horman wrote: > On Tue, Jul 28, 2015 at 12:46:42PM +0800, Minfei Huang wrote: > > Transforming PFN(Page Frame Number) to struct page is never failure, so > > we can simplify the code logic to do the image->control_page assignment > > directly in the loop, and remove the unnecessary conditional judgement. > > > > Signed-off-by: Minfei Huang > > Acked-by: Dave Young > > Acked-by: Vivek Goyal > > Andrew, could you consider picking this up. > It seems to have been sufficiently reviewed, acked, etc... I saw this has been in linux-next tree. commit b90b6ef0f152ef42fe66ce5c9ccf2783ea84fa69 Author: Minfei Huang Date: Thu Jul 30 09:56:18 2015 +1000 kexec: remove unnecessary test in kimage_alloc_crash_control_pages() Thanks Baoquan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: get_vmalloc_info() and /proc/meminfo insanely expensive
On Wed, Aug 12, 2015 at 9:00 PM, Andrew Morton wrote: > > Do your /proc/meminfo vmalloc numbers actually change during that build? > Mine don't. Perhaps we can cache the most recent vmalloc_info and > invalidate that cache whenever someone does a vmalloc/vfree/etc. Sure, that works too. Looking at that mm/vmalloc.c file, the locking is pretty odd. It looks pretty strange in setup_vmalloc_vm(), for example. If that newly allocated "va" that we haven't even exposed to anybody yet has its address or size changed, we're screwed in so many ways. I get the feeling this file should be rewritten. But that's not going to happen. The "let's just cache the last value for one jiffy" seemed to be the minimal fixup to it. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] x86/KASAN updates for 4.3
These 2 patches taken from v5 'KASAN for arm64' series. The only change is updated changelog in second patch. I hope this is not too late to queue these for 4.3, as this allow us to merge arm64/KASAN patches in v4.4 through arm64 tree. Andrey Ryabinin (2): x86/kasan: define KASAN_SHADOW_OFFSET per architecture x86/kasan, mm: introduce generic kasan_populate_zero_shadow() arch/x86/include/asm/kasan.h | 3 + arch/x86/mm/kasan_init_64.c | 123 ++ include/linux/kasan.h| 10 ++- mm/kasan/Makefile| 2 +- mm/kasan/kasan_init.c| 152 +++ 5 files changed, 170 insertions(+), 120 deletions(-) create mode 100644 mm/kasan/kasan_init.c -- 2.4.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 1/2] x86/kasan: define KASAN_SHADOW_OFFSET per architecture
Current definition of KASAN_SHADOW_OFFSET in include/linux/kasan.h will not work for upcomming arm64, so move it to the arch header. Signed-off-by: Andrey Ryabinin --- arch/x86/include/asm/kasan.h | 3 +++ include/linux/kasan.h| 1 - 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/kasan.h b/arch/x86/include/asm/kasan.h index 74a2a8d..1410b56 100644 --- a/arch/x86/include/asm/kasan.h +++ b/arch/x86/include/asm/kasan.h @@ -1,6 +1,9 @@ #ifndef _ASM_X86_KASAN_H #define _ASM_X86_KASAN_H +#include +#define KASAN_SHADOW_OFFSET _AC(CONFIG_KASAN_SHADOW_OFFSET, UL) + /* * Compiler uses shadow offset assuming that addresses start * from 0. Kernel addresses don't start from 0, so shadow diff --git a/include/linux/kasan.h b/include/linux/kasan.h index 5486d77..6fb1c7d 100644 --- a/include/linux/kasan.h +++ b/include/linux/kasan.h @@ -10,7 +10,6 @@ struct vm_struct; #ifdef CONFIG_KASAN #define KASAN_SHADOW_SCALE_SHIFT 3 -#define KASAN_SHADOW_OFFSET _AC(CONFIG_KASAN_SHADOW_OFFSET, UL) #include #include -- 2.4.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 2/2] x86/kasan, mm: introduce generic kasan_populate_zero_shadow()
Introduce generic kasan_populate_zero_shadow(shadow_start, shadow_end).
This function maps kasan_zero_page to the [shadow_start, shadow_end]
addresses.
This replaces x86_64 specific populate_zero_shadow() and will
be used for ARM64 in follow on patches.
The main changes from original version are:
* Use p?d_populate*() instead of set_p?d()
* Use memblock allocator directly instead of vmemmap_alloc_block()
* __pa() instead of __pa_nodebug(). __pa() causes troubles
iff we use it before kasan_early_init(). kasan_populate_zero_shadow()
will be used later, so we ok with __pa() here.
Signed-off-by: Andrey Ryabinin
---
arch/x86/mm/kasan_init_64.c | 123 ++-
include/linux/kasan.h | 9 +++
mm/kasan/Makefile | 2 +-
mm/kasan/kasan_init.c | 152
4 files changed, 167 insertions(+), 119 deletions(-)
create mode 100644 mm/kasan/kasan_init.c
diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c
index e1840f3..9ce5da2 100644
--- a/arch/x86/mm/kasan_init_64.c
+++ b/arch/x86/mm/kasan_init_64.c
@@ -12,20 +12,6 @@
extern pgd_t early_level4_pgt[PTRS_PER_PGD];
extern struct range pfn_mapped[E820_X_MAX];
-static pud_t kasan_zero_pud[PTRS_PER_PUD] __page_aligned_bss;
-static pmd_t kasan_zero_pmd[PTRS_PER_PMD] __page_aligned_bss;
-static pte_t kasan_zero_pte[PTRS_PER_PTE] __page_aligned_bss;
-
-/*
- * This page used as early shadow. We don't use empty_zero_page
- * at early stages, stack instrumentation could write some garbage
- * to this page.
- * Latter we reuse it as zero shadow for large ranges of memory
- * that allowed to access, but not instrumented by kasan
- * (vmalloc/vmemmap ...).
- */
-static unsigned char kasan_zero_page[PAGE_SIZE] __page_aligned_bss;
-
static int __init map_range(struct range *range)
{
unsigned long start;
@@ -62,106 +48,6 @@ static void __init kasan_map_early_shadow(pgd_t *pgd)
}
}
-static int __init zero_pte_populate(pmd_t *pmd, unsigned long addr,
- unsigned long end)
-{
- pte_t *pte = pte_offset_kernel(pmd, addr);
-
- while (addr + PAGE_SIZE <= end) {
- WARN_ON(!pte_none(*pte));
- set_pte(pte, __pte(__pa_nodebug(kasan_zero_page)
- | __PAGE_KERNEL_RO));
- addr += PAGE_SIZE;
- pte = pte_offset_kernel(pmd, addr);
- }
- return 0;
-}
-
-static int __init zero_pmd_populate(pud_t *pud, unsigned long addr,
- unsigned long end)
-{
- int ret = 0;
- pmd_t *pmd = pmd_offset(pud, addr);
-
- while (IS_ALIGNED(addr, PMD_SIZE) && addr + PMD_SIZE <= end) {
- WARN_ON(!pmd_none(*pmd));
- set_pmd(pmd, __pmd(__pa_nodebug(kasan_zero_pte)
- | _KERNPG_TABLE));
- addr += PMD_SIZE;
- pmd = pmd_offset(pud, addr);
- }
- if (addr < end) {
- if (pmd_none(*pmd)) {
- void *p = vmemmap_alloc_block(PAGE_SIZE, NUMA_NO_NODE);
- if (!p)
- return -ENOMEM;
- set_pmd(pmd, __pmd(__pa_nodebug(p) | _KERNPG_TABLE));
- }
- ret = zero_pte_populate(pmd, addr, end);
- }
- return ret;
-}
-
-
-static int __init zero_pud_populate(pgd_t *pgd, unsigned long addr,
- unsigned long end)
-{
- int ret = 0;
- pud_t *pud = pud_offset(pgd, addr);
-
- while (IS_ALIGNED(addr, PUD_SIZE) && addr + PUD_SIZE <= end) {
- WARN_ON(!pud_none(*pud));
- set_pud(pud, __pud(__pa_nodebug(kasan_zero_pmd)
- | _KERNPG_TABLE));
- addr += PUD_SIZE;
- pud = pud_offset(pgd, addr);
- }
-
- if (addr < end) {
- if (pud_none(*pud)) {
- void *p = vmemmap_alloc_block(PAGE_SIZE, NUMA_NO_NODE);
- if (!p)
- return -ENOMEM;
- set_pud(pud, __pud(__pa_nodebug(p) | _KERNPG_TABLE));
- }
- ret = zero_pmd_populate(pud, addr, end);
- }
- return ret;
-}
-
-static int __init zero_pgd_populate(unsigned long addr, unsigned long end)
-{
- int ret = 0;
- pgd_t *pgd = pgd_offset_k(addr);
-
- while (IS_ALIGNED(addr, PGDIR_SIZE) && addr + PGDIR_SIZE <= end) {
- WARN_ON(!pgd_none(*pgd));
- set_pgd(pgd, __pgd(__pa_nodebug(kasan_zero_pud)
- | _KERNPG_TABLE));
- addr += PGDIR_SIZE;
- pgd = pgd_offset_k(addr);
- }
-
- if (addr < end) {
- if (pgd_none(*pgd)) {
- void *p = vmemmap_alloc_block(PAGE_SIZE, NUMA_NO_NODE);
- if (!p)
-
Re: regression introduced by "block: Add support for DAX reads/writes to block devices"
On 08/13/2015 12:11 AM, Jeff Moyer wrote: > Boaz Harrosh writes: > >> On 08/07/2015 11:41 PM, Jeff Moyer wrote: >> <> >>> We need to cope with the case where the end of a partition isn't on a page boundary though. >>> >>> Well, that's usually done by falling back to buffered I/O. I gave that >>> a try and panicked the box. :) I'll keep looking into it, but probably >>> won't have another patch until next week. >>> >> >> lets slow down for a sec, please. >> >> We have all established that an unaligned partition start is BAD and not >> supported? > > No. Unaligned partitions on RAID arrays or 512e devices are bad because > they result in suboptimal performance. They are most certainly still > supported, though. > What ? I meant for dax on pmem or brd. I meant that we *do not* support dax access on an unaligned partition start. (None dax is perfectly supported) We did it this way because of the direct_access API that returns a pfn with is PAGE_SIZE. We could introduce a pfn+offset but we thought it is not worth it, and that dax should be page aligned for code simplicity Cheers Boaz > -Jeff > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] zram: use crypto API to compress the page
Removed Herbert, David, Stephan not spam their mail boxes.
I'd rather investigate something like this.
WARNING!!! NOT TESTED AT ALL! like for real... only compile tested.
RFC
define ZLIB backend the same way as we already do. and introduce
compression frontend ->flags field. backend that requires zstream
for read op will set it to ZCOMP_NEED_READ_STRM. zram checks this
flag in read() path and does slow zcomp_strm_find()/zcomp_strm_release()
if backend requires it; otherwise we have our fast "just decompress it"
path.
this is very ugly and quick. just as an idea at the moment.
I will return to this a bit later.
not-yet-signed-off-by: Sergey Senozhatsky
---
drivers/block/zram/Kconfig | 12 -
drivers/block/zram/Makefile | 1 +
drivers/block/zram/zcomp.c | 21 +++-
drivers/block/zram/zcomp.h | 9 +++-
drivers/block/zram/zcomp_lz4.c | 2 +-
drivers/block/zram/zcomp_lzo.c | 2 +-
drivers/block/zram/zcomp_zlib.c | 115
drivers/block/zram/zcomp_zlib.h | 17 ++
drivers/block/zram/zram_drv.c | 15 --
9 files changed, 184 insertions(+), 10 deletions(-)
create mode 100644 drivers/block/zram/zcomp_zlib.c
create mode 100644 drivers/block/zram/zcomp_zlib.h
diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig
index 386ba3d..7afd2ac 100644
--- a/drivers/block/zram/Kconfig
+++ b/drivers/block/zram/Kconfig
@@ -23,4 +23,14 @@ config ZRAM_LZ4_COMPRESS
default n
help
This option enables LZ4 compression algorithm support. Compression
- algorithm can be changed using `comp_algorithm' device attribute.
\ No newline at end of file
+ algorithm can be changed using `comp_algorithm' device attribute.
+
+config ZRAM_ZLIB_COMPRESS
+ bool "Enable ZLIB algorithm support"
+ depends on ZRAM
+ select ZLIB_INFLATE
+ select ZLIB_DEFLATE
+ default n
+ help
+ This option enables ZLIB compression algorithm support. Compression
+ algorithm can be changed using `comp_algorithm' device attribute.
diff --git a/drivers/block/zram/Makefile b/drivers/block/zram/Makefile
index be0763f..0922f54 100644
--- a/drivers/block/zram/Makefile
+++ b/drivers/block/zram/Makefile
@@ -1,5 +1,6 @@
zram-y := zcomp_lzo.o zcomp.o zram_drv.o
zram-$(CONFIG_ZRAM_LZ4_COMPRESS) += zcomp_lz4.o
+zram-$(CONFIG_ZRAM_ZLIB_COMPRESS) += zcomp_zlib.o
obj-$(CONFIG_ZRAM) += zram.o
diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
index 965d1af..4f04186 100644
--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -19,6 +19,9 @@
#ifdef CONFIG_ZRAM_LZ4_COMPRESS
#include "zcomp_lz4.h"
#endif
+#ifdef CONFIG_ZRAM_ZLIB_COMPRESS
+#include "zcomp_zlib.h"
+#endif
/*
* single zcomp_strm backend
@@ -48,6 +51,9 @@ static struct zcomp_backend *backends[] = {
#ifdef CONFIG_ZRAM_LZ4_COMPRESS
_lz4,
#endif
+#ifdef CONFIG_ZRAM_ZLIB_COMPRESS
+ _zlib,
+#endif
NULL
};
@@ -313,10 +319,16 @@ int zcomp_compress(struct zcomp *comp, struct zcomp_strm
*zstrm,
zstrm->private);
}
-int zcomp_decompress(struct zcomp *comp, const unsigned char *src,
+int zcomp_decompress(struct zcomp *comp, struct zcomp_strm *zstrm,
+ const unsigned char *src,
size_t src_len, unsigned char *dst)
{
- return comp->backend->decompress(src, src_len, dst);
+ void *private = NULL;
+
+ if (unlikely(zstrm))
+ private = zstrm->private;
+
+ return comp->backend->decompress(src, src_len, dst, private);
}
void zcomp_destroy(struct zcomp *comp)
@@ -354,5 +366,10 @@ struct zcomp *zcomp_create(const char *compress, int
max_strm)
kfree(comp);
return ERR_PTR(-ENOMEM);
}
+
+ /* FIXME quick dirty and ugly. ONLY for testing purposes */
+ if (sysfs_streq(compress, "zlib"))
+ comp->flags |= ZCOMP_NEED_READ_STRM;
+
return comp;
}
diff --git a/drivers/block/zram/zcomp.h b/drivers/block/zram/zcomp.h
index 46e2b9f..e3ac8d3 100644
--- a/drivers/block/zram/zcomp.h
+++ b/drivers/block/zram/zcomp.h
@@ -12,6 +12,8 @@
#include
+#define ZCOMP_NEED_READ_STRM (1 << 0)
+
struct zcomp_strm {
/* compression/decompression buffer */
void *buffer;
@@ -31,7 +33,7 @@ struct zcomp_backend {
size_t *dst_len, void *private);
int (*decompress)(const unsigned char *src, size_t src_len,
- unsigned char *dst);
+ unsigned char *dst, void *private);
void *(*create)(void);
void (*destroy)(void *private);
@@ -44,6 +46,8 @@ struct zcomp {
void *stream;
struct zcomp_backend *backend;
+ int flags;
+
struct zcomp_strm *(*strm_find)(struct zcomp *comp);
void (*strm_release)(struct zcomp *comp, struct zcomp_strm *zstrm);
bool (*set_max_streams)(struct
Re: page-flags behavior on compound pages: a worry
On Fri, 7 Aug 2015, Kirill A. Shutemov wrote: > On Thu, Aug 06, 2015 at 12:24:22PM -0700, Hugh Dickins wrote: > > > > Oh, and I know a patchset which avoids these problems completely, > > by not using compound pages at all ;) > > BTW, I haven't heard anything about the patchset for a while. > What's the status? It's gone well, and being put into wider use here. But I'm not one for monthly updates of large patchsets myself, always too much to do; and nobody else seemed anxious to have it yet, back in March. As I said at the time of posting huge tmpfs against v3.19, it was fully working (and little changed since), but once memory pressure had disbanded a team to swap it out, there was nothing to put it together again later, to restore the original hugepage performance. I couldn't imagine people putting it into real use while that remained the case, so spent the next months adding "huge tmpfs recovery" - considered hooking into khugepaged, but settled on work item queued from fault. Which has worked out well, except that I had to rush it in before I went on vacation in June, then spent last month fixing all the concurrent hole-punching bugs Andres found with his fuzzing while I was away. Busy time, stable now; but I do want to reconsider a few rushed decisions before offering the rebased and extended set. And there's three pieces of the work not begun: The page-table allocation delay in mm/memory.c had been great for the first posting, but not good enough for recovery (replacing ptes by pmd): for the moment I skate around that by guarding with mmap_sem, but mmap_sem usually ends up regrettable, and shouldn't be necessary - there's just a lot of scattered walks to work through, adjusting them to racy replacement of ptes by pmd. Maybe I can get away without doing this for now, we seem to be working well enough without it. And I suspect that my queueing a recovery work item from fault is over eager, needs some stats and knobs to tune it down. Though not surfaced as a problem yet; and I don't think we could live with the opposite extreme, of khugepaged lumbering its way around the vmas. But the one I think I shall have to do something better about before posting, is NUMA. For a confluence of reasons, that rule out swapin readahead for now, it's not a serious issue for us as yet. But swapin readahead and NUMA have always been a joke in tmpfs, and I'll be amplifying that joke with my current NUMA placement in recovery. Unfortunately, there's a lot of opportunity to make silly mistakes when trying to get NUMA right: I doubt I can get it right, but do need to get it a little less wrong before letting others take over. > > Optimizing rmap operations in my patchset (see PG_double_map), I found > that it would be very tricky to expand team pages to anon-THP without > performance regression on rmap side due to amount of atomic ops it > requires. Thanks for thinking of it: I've been too busy with the recovery to put more thought into extending teams to anon THP, though I'd certainly like to try that once the huge tmpfs end is "complete". Yes, there's not a doubt that starting from compound pages is more rigid but should involve much less repetition; whereas starting from the other end with a team of ordinary 4k pages, more flexible but a lot of wasted effort. I can't predict where we shall meet. > > Is there any clever approach to the issue? I'd been hoping that I could implement first, and then optimize away the unnecessary; but you're right that it's easier to live with that in the pagecache case, whereas with anon THP it would be a regression. Hugh > > Team pages are probably fine for file mappings due different performance > baseline. I'm less optimistic about anon-THP. > > -- > Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: fix wrong skb_get() usage / crash in IGMP/MLD parsing code
On Thu, Aug 13, 2015 at 05:54:07AM +0200, Linus Lüssing wrote:
> The recent refactoring of the IGMP and MLD parsing code into
> ipv6_mc_check_mld() / ip_mc_check_igmp() introduced a potential crash /
> BUG() invocation for bridges:
>
> I wrongly assumed that skb_get() could be used as a simple reference
> counter for an skb which is not the case. skb_get() bears additional
> semantics, a user count. This leads to a BUG() invocation in
> pskb_expand_head() / kernel panic if pskb_may_pull() is called on an skb
> with a user count greater than one - unfortunately the refactoring did
> just that.
>
> Fixing this by removing the skb_get() call and changing the API: The
> caller of ipv6_mc_check_mld() / ip_mc_check_igmp() now needs to
> additionally check whether the returned skb_trimmed is a clone.
>
> Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code")
> Reported-by: Brenden Blanco
> Signed-off-by: Linus Lüssing
I think the fix actually made the code easier to read.
Thank you. Looks good to me.
Acked-by: Alexei Starovoitov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the staging tree with the tip tree
Hi Greg,
Today's linux-next merge of the staging tree got a conflict in:
drivers/staging/ozwpan/ozproto.c
between commit:
5a447f09a8df ("staging: ozwpan: Fix hrtimer wreckage")
from the tip tree and commit:
a73e99cb67e7 ("staging: ozwpan: Remove from tree")
from the staging tree.
I fixed it up (I just removed the file) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] power_supply: max8998: Use devm_power_supply_register
Use managed resource function devm_power_supply_register instead
of power_supply_register to simplify the error path by allowing
unregister to happen automatically on error. To be compatible with
the change, replace various gotos by direct returns and remove
unneeded label err.
Also, remove max8998_battery_remove as it is now redundant.
Signed-off-by: Vaishali Thakkar
---
Changes since v1:
- Make commit log more reasonable
---
drivers/power/max8998_charger.c | 28 +++-
1 file changed, 7 insertions(+), 21 deletions(-)
diff --git a/drivers/power/max8998_charger.c b/drivers/power/max8998_charger.c
index 47448d4..6014df5 100644
--- a/drivers/power/max8998_charger.c
+++ b/drivers/power/max8998_charger.c
@@ -117,8 +117,7 @@ static int max8998_battery_probe(struct platform_device
*pdev)
"EOC value not set: leave it unchanged.\n");
} else {
dev_err(max8998->dev, "Invalid EOC value\n");
- ret = -EINVAL;
- goto err;
+ return -EINVAL;
}
/* Setup Charge Restart Level */
@@ -141,8 +140,7 @@ static int max8998_battery_probe(struct platform_device
*pdev)
break;
default:
dev_err(max8998->dev, "Invalid Restart Level\n");
- ret = -EINVAL;
- goto err;
+ return -EINVAL;
}
/* Setup Charge Full Timeout */
@@ -165,34 +163,22 @@ static int max8998_battery_probe(struct platform_device
*pdev)
break;
default:
dev_err(max8998->dev, "Invalid Full Timeout value\n");
- ret = -EINVAL;
- goto err;
+ return -EINVAL;
}
psy_cfg.drv_data = max8998;
- max8998->battery = power_supply_register(max8998->dev,
-_battery_desc,
-_cfg);
+ max8998->battery = devm_power_supply_register(max8998->dev,
+ _battery_desc,
+ _cfg);
if (IS_ERR(max8998->battery)) {
ret = PTR_ERR(max8998->battery);
dev_err(max8998->dev, "failed: power supply register: %d\n",
ret);
- goto err;
+ return ret;
}
return 0;
-err:
- return ret;
-}
-
-static int max8998_battery_remove(struct platform_device *pdev)
-{
- struct max8998_battery_data *max8998 = platform_get_drvdata(pdev);
-
- power_supply_unregister(max8998->battery);
-
- return 0;
}
static const struct platform_device_id max8998_battery_id[] = {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] add GPT timer support for mt8173
On Wed, Aug 12, 2015 at 8:32 PM, Daniel Lezcano wrote: > On 08/11/2015 05:54 PM, Daniel Kurtz wrote: >> >> On Mon, Jul 13, 2015 at 5:32 PM, Yingjoe Chen >> wrote: >>> >>> This series add GPT timer support for mt8173. This is based on v4.2-rc1 >>> and Matthias' next branch (for dts parts). >>> >>> The first 2 patches comes from 'Add SMP bringup support for mt65xx socs' >>> series [1]. I decide to move these 2 patches to this series, since it >>> is more relevent here. They are changed based on Matthias' and Daniel's >>> comments. >>> >>> [1] >>> http://lists.infradead.org/pipermail/linux-mediatek/2015-May/000714.html >>> >>> Daniel Kurtz (1): >>>arm64: dts: mt8173: add timer node >>> >>> Yingjoe Chen (4): >>>clocksource: mediatek: do not enable GPT_CLK_EVT when setup >>>clocksource: mediatek: Use GPT as sched clock source >>>arm64: mediatek: enable MTK_TIMER >>>clk: mediatek: add 13mhz clock for MT8173 >> >> >> Was this mediatek clocksource patch set get forgotten again? > > > Yep. Sounds like it felt at the wrong moment. > >> All 5 patches have have been reviewed, and I think the ones that need >> it have been Ack'ed by Matthias and/or Stephen. >> What is the plan for merging them? > > > So if I am not wrong we have two patches I can take in my tree as a couple > of fixes (1 and 2), right ? Yes. Patches 3 & 5 are for Matthias, and patch 4 is Ack'ed by Stephen Boyd, so I assume Matthias can pick that one up too. Matthias, is that correct? Or does Patch 4 need to go in via a clock maintainer's tree? -Dan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 2/7] arm64: Add more test functions to insn.c
On 08/11/15 14:00, Will Deacon wrote:
On Tue, Aug 11, 2015 at 01:52:39AM +0100, David Long wrote:
From: "David A. Long"
Certain instructions are hard to execute correctly out-of-line (as in
kprobes). Test functions are added to insn.[hc] to identify these. The
instructions include any that use PC-relative addressing, change the PC,
or change interrupt masking. For efficiency and simplicity test
functions are also added for small collections of related instructions.
Signed-off-by: David A. Long
---
arch/arm64/include/asm/insn.h | 18 ++
arch/arm64/kernel/insn.c | 28
2 files changed, 46 insertions(+)
diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index 30e50eb..66bfb21 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -223,8 +223,13 @@ static __always_inline bool aarch64_insn_is_##abbr(u32
code) \
static __always_inline u32 aarch64_insn_get_##abbr##_value(void) \
{ return (val); }
+__AARCH64_INSN_FUNCS(adr_adrp, 0x1F00, 0x1000)
+__AARCH64_INSN_FUNCS(prfm_lit, 0xFF00, 0xD800)
__AARCH64_INSN_FUNCS(str_reg, 0x3FE0EC00, 0x38206800)
__AARCH64_INSN_FUNCS(ldr_reg, 0x3FE0EC00, 0x38606800)
+__AARCH64_INSN_FUNCS(ldr_lit, 0xBF00, 0x1800)
+__AARCH64_INSN_FUNCS(ldrsw_lit,0xFF00, 0x9800)
+__AARCH64_INSN_FUNCS(exclusive,0x3F00, 0x0800)
Hmm, so this class also pulls in load-acquire and store-release, which
we *should* be able to single-step, no? Maybe it's worth splitting this
category up (or at least changing aarch64_insn_is_exclusive to be more
permissive).
I was not confident that this was the case. After reading the relevant
parts of the v8 ARM yet again I think I see your point.
__AARCH64_INSN_FUNCS(stp_post,0x7FC0, 0x2880)
__AARCH64_INSN_FUNCS(ldp_post,0x7FC0, 0x28C0)
__AARCH64_INSN_FUNCS(stp_pre, 0x7FC0, 0x2980)
@@ -264,19 +269,29 @@ __AARCH64_INSN_FUNCS(ands,0x7F20, 0x6A00)
__AARCH64_INSN_FUNCS(bics,0x7F20, 0x6A20)
__AARCH64_INSN_FUNCS(b, 0xFC00, 0x1400)
__AARCH64_INSN_FUNCS(bl, 0xFC00, 0x9400)
+__AARCH64_INSN_FUNCS(b_bl, 0x7C00, 0x1400)
Why do we need this when we already have checks for b and bl?
I was trying to avoid doing multiple checks for different variants of
similar instructions.
+__AARCH64_INSN_FUNCS(cb, 0x7E00, 0x3400)
Likewise for cbz and cbnz...
__AARCH64_INSN_FUNCS(cbz, 0x7F00, 0x3400)
__AARCH64_INSN_FUNCS(cbnz,0x7F00, 0x3500)
+__AARCH64_INSN_FUNCS(tb, 0x7E00, 0x3600)
... there's a pattern here!
^^
__AARCH64_INSN_FUNCS(tbz, 0x7F00, 0x3600)
__AARCH64_INSN_FUNCS(tbnz,0x7F00, 0x3700)
+__AARCH64_INSN_FUNCS(b_bl_cb_tb, 0x5C00, 0x1400)
I must be missing something :)
^^
__AARCH64_INSN_FUNCS(bcond, 0xFF10, 0x5400)
__AARCH64_INSN_FUNCS(svc, 0xFFE0001F, 0xD401)
__AARCH64_INSN_FUNCS(hvc, 0xFFE0001F, 0xD402)
__AARCH64_INSN_FUNCS(smc, 0xFFE0001F, 0xD403)
__AARCH64_INSN_FUNCS(brk, 0xFFE0001F, 0xD420)
+__AARCH64_INSN_FUNCS(exception,0xFF00, 0xD400)
__AARCH64_INSN_FUNCS(hint,0xF01F, 0xD503201F)
__AARCH64_INSN_FUNCS(br, 0xFC1F, 0xD61F)
__AARCH64_INSN_FUNCS(blr, 0xFC1F, 0xD63F)
+__AARCH64_INSN_FUNCS(br_blr, 0xFFDFFC1F, 0xD61F)
__AARCH64_INSN_FUNCS(ret, 0xFC1F, 0xD65F)
+__AARCH64_INSN_FUNCS(msr_imm, 0xFFF8F01F, 0xD500401F)
+__AARCH64_INSN_FUNCS(msr_reg, 0xFFF0, 0xD510)
+__AARCH64_INSN_FUNCS(set_clr_daif, 0xF0DF, 0xD50340DF)
+__AARCH64_INSN_FUNCS(rd_wr_daif, 0xFFDFFFE0, 0xD51B4220)
I think I'd rather have separate decoders to decode the register field
of an mrs/msr instruction than overload each encoding here.
Anyway, on the whole this looks pretty good, I'd just prefer not to build
compound instruction checks at the encoding level (even though it looks
like you did a good job on the values).
OK, easy enough to just add to the if statements where these are getting
used. May be getting a little bloated looking there though.
-dl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] EDAC fix for 4.2
Hi Linus,
please pull a ppc4xx_edac fix for an oops due to wrongly dereferencing a
csrow descriptor.
Thanks.
---
The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git tags/edac_fix_for_4.2
for you to fetch changes up to 5c16179b550b9fd8114637a56b153c9768ea06a5:
EDAC, ppc4xx: Access mci->csrows array elements properly (2015-08-13 06:02:19
+0200)
A ppc4xx_edac fix for accessing ->csrows properly. This driver was
missed during the conversion a couple of years ago.
Michael Walle (1):
EDAC, ppc4xx: Access mci->csrows array elements properly
drivers/edac/ppc4xx_edac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/edac/ppc4xx_edac.c b/drivers/edac/ppc4xx_edac.c
index 3515b381c131..711d8ad74f11 100644
--- a/drivers/edac/ppc4xx_edac.c
+++ b/drivers/edac/ppc4xx_edac.c
@@ -920,7 +920,7 @@ static int ppc4xx_edac_init_csrows(struct mem_ctl_info
*mci, u32 mcopt1)
*/
for (row = 0; row < mci->nr_csrows; row++) {
- struct csrow_info *csi = >csrows[row];
+ struct csrow_info *csi = mci->csrows[row];
/*
* Get the configuration settings for this
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: page-flags behavior on compound pages: a worry
On Thu, 13 Aug 2015, Kirill A. Shutemov wrote:
>
> All this situation is ugly. I'm thinking on more general solution for
> PageTail() vs. ->first_page race.
>
> We would be able to avoid the race in first place if we encode PageTail()
> and position of head page within the same word in struct page. This way we
> update both thing in one shot without possibility of race.
>
> Details get tricky.
>
> I'm going to try tomorrow something like this: encode the position of head
> as offset from the tail page and store it as negative number in the union
> with ->mapping and ->s_mem. PageTail() can be implemented as check value
> of the field to be in range -1..-MAX_ORDER_NR_PAGES.
>
> I'm not sure at all if it's going to work, especially looking on
> ridiculously high CONFIG_FORCE_MAX_ZONEORDER some architectures allow.
>
> We could also try to encode page order instead (again as negative number)
> and calculate head page position based on alignment...
>
> Any other ideas are welcome.
Good luck, I've not given it any thought, but hope it works out:
my reasoning was the same when I put the PageAnon bit into
page->mapping instead of page->flags.
Something to beware of though: although exceedingly unlikely to be a
problem, page->mapping always contained a pointer to or into a relevant
structure, or else something that could not possibly be a kernel pointer,
when I was working on KSM swapping: see comment above get_ksm_page() in
mm/ksm.c. It is best to keep page->mapping for pointers if possible
(and probably avoid having the PageAnon bit set unless really Anon).
I've only just read your mail, and I'm too slow a thinker to have
worked through your isolate_migratepages_block() race yet. But, given
the timing, cannot resist sending you a code fragment I wrote earlier
today for our v3.11-based kernel: which still has compound_trans_order(),
which we had been using in a similar racy physical scan.
I'm not for a moment suggesting that this fragment is relevant to your
race; but it is something amusing to consider when you're thinking of
such races. Credit to Greg Thelen for thinking of the prep_compound_page()
end of it, when I'd been focussed on the __split_huge_page_refcount() end.
/*
* It is not safe to use compound_lock (inside compound_trans_order)
* until we have a reference on the page (okay, done above) and have
* then seen PageLRU on it (just below): because mm/huge_memory.c uses
* the non-atomic __SetPageUptodate on a freshly allocated THPage in
* several places, believing it to be invisible to the outside world,
* but liable to race and leave PG_compound_lock set when cleared here.
*/
nr_pages = 1;
if (PageHead(page)) {
/*
* smp_rmb() against the smp_wmb() in the first iteration of
* prep_compound_page(), so that the PageTail test ensures
* that compound_order(page) is now correctly readable.
*/
smp_rmb();
if (PageTail(page + 1)) {
nr_pages = 1 << compound_order(page);
/*
* Then smp_rmb() against smp_wmb() in last iteration of
* __split_huge_page_refcount(), to ensure that has not
* yet written something else into page[1].lru.prev.
*/
smp_rmb();
if (!PageTail(page + 1))
nr_pages = 1;
}
}
Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] genet:Fix error handling in the function bcmgenet_fini_gma
Le 08/12/15 19:27, Nicholas Krause a écrit :
> This fixes error handing in the function bcmgenet_fini_gma to
> properly check if its internal call to the function
> bcm_genet_teardown has failed by returning a error code and if
> so return immediately to this function's caller with a return
> statement as this function call can no longer continue without
> issues arising from the call to the function bcm_genet_teardown.
NACK, this is not a good idea, there are specific reasons why the DMA
teardown can fail, e.g: when no bandwidth has been allocated at the
memory controller level, and we still want to keep tearing down and
freeing up resources while we reconfigure the controller one way or the
other, this can happen while debugging a system, and this is specific to
how GENET is integrated on Broadcom BCM7xxx SoCs.
Also, if you ever need to submit more patches, please look at the git
log history and use consistent prefixes, for this driver this would be
"net: bcmgenet: blah blah"
>
> Signed-off-by: Nicholas Krause
> ---
> drivers/net/ethernet/broadcom/genet/bcmgenet.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> index 64c1e9d..50e6183 100644
> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> @@ -2180,7 +2180,8 @@ static void bcmgenet_fini_dma(struct bcmgenet_priv
> *priv)
> bcmgenet_fini_tx_napi(priv);
>
> /* disable DMA */
> - bcmgenet_dma_teardown(priv);
> + if (bcmgenet_dma_teardown(priv))
> + return;
>
> for (i = 0; i < priv->num_tx_bds; i++) {
> if (priv->tx_cbs[i].skb != NULL) {
>
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net: fix wrong skb_get() usage / crash in IGMP/MLD parsing code
The recent refactoring of the IGMP and MLD parsing code into
ipv6_mc_check_mld() / ip_mc_check_igmp() introduced a potential crash /
BUG() invocation for bridges:
I wrongly assumed that skb_get() could be used as a simple reference
counter for an skb which is not the case. skb_get() bears additional
semantics, a user count. This leads to a BUG() invocation in
pskb_expand_head() / kernel panic if pskb_may_pull() is called on an skb
with a user count greater than one - unfortunately the refactoring did
just that.
Fixing this by removing the skb_get() call and changing the API: The
caller of ipv6_mc_check_mld() / ip_mc_check_igmp() now needs to
additionally check whether the returned skb_trimmed is a clone.
Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code")
Reported-by: Brenden Blanco
Signed-off-by: Linus Lüssing
---
net/bridge/br_multicast.c |4 ++--
net/core/skbuff.c | 37 ++---
net/ipv4/igmp.c | 33 ++---
net/ipv6/mcast_snoop.c| 33 ++---
4 files changed, 56 insertions(+), 51 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 0b39dcc..1285eaf 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1591,7 +1591,7 @@ static int br_multicast_ipv4_rcv(struct net_bridge *br,
break;
}
- if (skb_trimmed)
+ if (skb_trimmed && skb_trimmed != skb)
kfree_skb(skb_trimmed);
return err;
@@ -1636,7 +1636,7 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
break;
}
- if (skb_trimmed)
+ if (skb_trimmed && skb_trimmed != skb)
kfree_skb(skb_trimmed);
return err;
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index b6a19ca..bf9a5d9 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -4022,8 +4022,8 @@ EXPORT_SYMBOL(skb_checksum_setup);
* Otherwise returns the provided skb. Returns NULL in error cases
* (e.g. transport_len exceeds skb length or out-of-memory).
*
- * Caller needs to set the skb transport header and release the returned skb.
- * Provided skb is consumed.
+ * Caller needs to set the skb transport header and free any returned skb if it
+ * differs from the provided skb.
*/
static struct sk_buff *skb_checksum_maybe_trim(struct sk_buff *skb,
unsigned int transport_len)
@@ -4032,16 +4032,12 @@ static struct sk_buff *skb_checksum_maybe_trim(struct
sk_buff *skb,
unsigned int len = skb_transport_offset(skb) + transport_len;
int ret;
- if (skb->len < len) {
- kfree_skb(skb);
+ if (skb->len < len)
return NULL;
- } else if (skb->len == len) {
+ else if (skb->len == len)
return skb;
- }
skb_chk = skb_clone(skb, GFP_ATOMIC);
- kfree_skb(skb);
-
if (!skb_chk)
return NULL;
@@ -4066,8 +4062,8 @@ static struct sk_buff *skb_checksum_maybe_trim(struct
sk_buff *skb,
* If the skb has data beyond the given transport length, then a
* trimmed & cloned skb is checked and returned.
*
- * Caller needs to set the skb transport header and release the returned skb.
- * Provided skb is consumed.
+ * Caller needs to set the skb transport header and free any returned skb if it
+ * differs from the provided skb.
*/
struct sk_buff *skb_checksum_trimmed(struct sk_buff *skb,
unsigned int transport_len,
@@ -4079,23 +4075,26 @@ struct sk_buff *skb_checksum_trimmed(struct sk_buff
*skb,
skb_chk = skb_checksum_maybe_trim(skb, transport_len);
if (!skb_chk)
- return NULL;
+ goto err;
- if (!pskb_may_pull(skb_chk, offset)) {
- kfree_skb(skb_chk);
- return NULL;
- }
+ if (!pskb_may_pull(skb_chk, offset))
+ goto err;
__skb_pull(skb_chk, offset);
ret = skb_chkf(skb_chk);
__skb_push(skb_chk, offset);
- if (ret) {
- kfree_skb(skb_chk);
- return NULL;
- }
+ if (ret)
+ goto err;
return skb_chk;
+
+err:
+ if (skb_chk && skb_chk != skb)
+ kfree_skb(skb_chk);
+
+ return NULL;
+
}
EXPORT_SYMBOL(skb_checksum_trimmed);
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 651cdf6..9fdfd9d 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1435,33 +1435,35 @@ static int __ip_mc_check_igmp(struct sk_buff *skb,
struct sk_buff **skb_trimmed)
struct sk_buff *skb_chk;
unsigned int transport_len;
unsigned int len = skb_transport_offset(skb) + sizeof(struct igmphdr);
- int ret;
+ int ret = -EINVAL;
transport_len = ntohs(ip_hdr(skb)->tot_len) - ip_hdrlen(skb);
- skb_get(skb);
skb_chk =
[PATCH] net/fddi: remove HWM_REVERSE() macro
HWM_REVERSE() macro is unused, remove it. Signed-off-by: yalin wang --- drivers/net/fddi/skfp/h/hwmtm.h | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/net/fddi/skfp/h/hwmtm.h b/drivers/net/fddi/skfp/h/hwmtm.h index 5924d42..4ca2341 100644 --- a/drivers/net/fddi/skfp/h/hwmtm.h +++ b/drivers/net/fddi/skfp/h/hwmtm.h @@ -74,15 +74,6 @@ #define NULL 0 #endif -#ifdef LITTLE_ENDIAN -#define HWM_REVERSE(x) (x) -#else -#defineHWM_REVERSE(x) x)<<24L)&0xff00L) + \ -(((x)<< 8L)&0x00ffL) + \ -(((x)>> 8L)&0xff00L) + \ -(((x)>>24L)&0x00ffL)) -#endif - #define C_INDIC(1L<<25) #define A_INDIC(1L<<26) #defineRD_FS_LOCAL 0x80 -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: get_vmalloc_info() and /proc/meminfo insanely expensive
On Wed, 12 Aug 2015 20:29:34 -0700 Linus Torvalds wrote: > I just did some profiling of a simple "make test" in the git repo, and > was surprised by the top kernel offender: get_vmalloc_info() showed up > at roughly 4% cpu use. > > It turns out that bash ends up reading /proc/meminfo on every single > activation, and "make test" is basically just running a huge > collection of shell scripts. You can verify by just doing > > strace -o trace sh -c "echo" > > to see what bash does on your system. I suspect it's actually glibc, > because a quick google finds the function "get_phys_pages()" that just > looks at the "MemTotal" line (or possibly get_avphys_pageslooks at the > MemFree" line). And bash surely isn't interested in vmalloc stats. Putting all these things in the same file wasn't the smartest thing we've ever done. > Ok, so bash is insane for caring so deeply that it does this > regardless of anything else. But what else is new - user space does > odd things. It's like a truism. > > My gut feel for this is that we should just rate-limit this and cache > the vmalloc information for a fraction of a second or something. Maybe > we could expose total memory sizes in some more efficient format, but > it's not like existing binaries will magically de-crapify themselves, > so just speeding up meminfo sounds like a good thing. > > Maybe we could even cache the whole seqfile buffer - Al? How painful > would something like that be? Although from the profiles, it's really > just the vmalloc info gathering that shows up as actually wasting CPU > cycles.. > Do your /proc/meminfo vmalloc numbers actually change during that build? Mine don't. Perhaps we can cache the most recent vmalloc_info and invalidate that cache whenever someone does a vmalloc/vfree/etc. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 2/7] x86, mm: introduce struct vmem_altmap
This is a preparation patch only, no functional changes. It simply
makes the following patch easier to read. struct vmem_altmap modifies
the memory hotplug code to enable it to map "device memory" while
allocating the storage for struct page from that same capacity. The
first user of this capability will be the pmem driver for persistent
memory.
Cc: H. Peter Anvin
Cc: Ingo Molnar
Cc: Dave Hansen
Cc: Rik van Riel
Cc: Mel Gorman
Cc: linux...@kvack.org
Signed-off-by: Dan Williams
---
arch/powerpc/mm/init_64.c |7
arch/x86/mm/init_64.c | 79 ++--
include/linux/memory_hotplug.h | 17 -
include/linux/mm.h | 13 ++-
mm/memory_hotplug.c| 67 +-
mm/page_alloc.c| 11 +-
mm/sparse-vmemmap.c| 29 ---
mm/sparse.c| 29 +--
8 files changed, 177 insertions(+), 75 deletions(-)
diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
index d747dd7bc90b..e3e367399935 100644
--- a/arch/powerpc/mm/init_64.c
+++ b/arch/powerpc/mm/init_64.c
@@ -404,6 +404,13 @@ void __ref vmemmap_free(unsigned long start, unsigned long
end)
}
}
}
+
+void __ref __vmemmap_free(unsigned long start, unsigned long end,
+ struct vmem_altmap *altmap)
+{
+ WARN_ONCE(altmap, "vmem_altmap support not implemented.\n");
+ return vmemmap_free(start, end);
+}
#endif
void register_page_bootmem_memmap(unsigned long section_nr,
struct page *start_page, unsigned long size)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 94f0fa56f0ed..c2f872a379d2 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -683,7 +683,8 @@ static void update_end_of_memory_vars(u64 start, u64 size)
}
}
-static int __arch_add_memory(int nid, u64 start, u64 size, struct zone *zone)
+static int __arch_add_memory(int nid, u64 start, u64 size, struct zone *zone,
+ struct vmem_altmap *altmap)
{
unsigned long start_pfn = start >> PAGE_SHIFT;
unsigned long nr_pages = size >> PAGE_SHIFT;
@@ -691,7 +692,7 @@ static int __arch_add_memory(int nid, u64 start, u64 size,
struct zone *zone)
init_memory_mapping(start, start + size);
- ret = __add_pages(nid, zone, start_pfn, nr_pages);
+ ret = __add_pages_altmap(nid, zone, start_pfn, nr_pages, altmap);
WARN_ON_ONCE(ret);
/*
@@ -714,7 +715,7 @@ int arch_add_memory(int nid, u64 start, u64 size)
struct zone *zone = pgdat->node_zones +
zone_for_memory(nid, start, size, ZONE_NORMAL);
- return __arch_add_memory(nid, start, size, zone);
+ return __arch_add_memory(nid, start, size, zone, NULL);
}
EXPORT_SYMBOL_GPL(arch_add_memory);
@@ -758,7 +759,8 @@ static void __meminit free_pte_table(pte_t *pte_start,
pmd_t *pmd)
spin_unlock(_mm.page_table_lock);
}
-static void __meminit free_pmd_table(pmd_t *pmd_start, pud_t *pud)
+static void __meminit free_pmd_table(pmd_t *pmd_start, pud_t *pud,
+ struct vmem_altmap *altmap)
{
pmd_t *pmd;
int i;
@@ -869,9 +871,9 @@ remove_pte_table(pte_t *pte_start, unsigned long addr,
unsigned long end,
update_page_count(PG_LEVEL_4K, -pages);
}
-static void __meminit
+static void noinline __meminit
remove_pmd_table(pmd_t *pmd_start, unsigned long addr, unsigned long end,
-bool direct)
+bool direct, struct vmem_altmap *altmap)
{
unsigned long next, pages = 0;
pte_t *pte_base;
@@ -925,9 +927,9 @@ remove_pmd_table(pmd_t *pmd_start, unsigned long addr,
unsigned long end,
update_page_count(PG_LEVEL_2M, -pages);
}
-static void __meminit
+static void noinline __meminit
remove_pud_table(pud_t *pud_start, unsigned long addr, unsigned long end,
-bool direct)
+bool direct, struct vmem_altmap *altmap)
{
unsigned long next, pages = 0;
pmd_t *pmd_base;
@@ -972,8 +974,8 @@ remove_pud_table(pud_t *pud_start, unsigned long addr,
unsigned long end,
}
pmd_base = (pmd_t *)pud_page_vaddr(*pud);
- remove_pmd_table(pmd_base, addr, next, direct);
- free_pmd_table(pmd_base, pud);
+ remove_pmd_table(pmd_base, addr, next, direct, altmap);
+ free_pmd_table(pmd_base, pud, altmap);
}
if (direct)
@@ -982,7 +984,8 @@ remove_pud_table(pud_t *pud_start, unsigned long addr,
unsigned long end,
/* start and end are both virtual address. */
static void __meminit
-remove_pagetable(unsigned long start, unsigned long end, bool direct)
+remove_pagetable(unsigned long start, unsigned long end, bool direct,
+ struct vmem_altmap *altmap)
{
unsigned long next;
unsigned long addr;
@@
[PATCH 1/2] crypto: KEYS: convert public key to the akcipher API
This patch converts the module verification code to the new akcipher API.
RSA implementation from crypto/asymmetric_keys has been removed and the
new API is used for cryptographic primitives. The signature verification
has been moved into a new crypto/asymmetric_keys/rsa_pkcs1_v1_5.c file.
There is no need for MPI above the API anymore.
Modules can be verified with software as well as HW rsa implementations.
Signed-off-by: Tadeusz Struk
---
crypto/asymmetric_keys/Kconfig|2
crypto/asymmetric_keys/Makefile |7 -
crypto/asymmetric_keys/pkcs7_parser.c | 12 +
crypto/asymmetric_keys/pkcs7_trust.c |2
crypto/asymmetric_keys/pkcs7_verify.c |2
crypto/asymmetric_keys/public_key.c | 59 ++
crypto/asymmetric_keys/public_key.h | 36
crypto/asymmetric_keys/rsa.c | 278 -
crypto/asymmetric_keys/rsa_pkcs1_v1_5.c | 229
crypto/asymmetric_keys/x509_cert_parser.c | 37 +---
crypto/asymmetric_keys/x509_public_key.c | 17 +-
crypto/asymmetric_keys/x509_rsakey.asn1 |4
include/crypto/public_key.h | 48 +
kernel/module_signing.c | 56 ++
security/integrity/digsig_asymmetric.c| 11 -
15 files changed, 301 insertions(+), 499 deletions(-)
delete mode 100644 crypto/asymmetric_keys/public_key.h
delete mode 100644 crypto/asymmetric_keys/rsa.c
create mode 100644 crypto/asymmetric_keys/rsa_pkcs1_v1_5.c
delete mode 100644 crypto/asymmetric_keys/x509_rsakey.asn1
diff --git a/crypto/asymmetric_keys/Kconfig b/crypto/asymmetric_keys/Kconfig
index 4870f28..905d745 100644
--- a/crypto/asymmetric_keys/Kconfig
+++ b/crypto/asymmetric_keys/Kconfig
@@ -22,7 +22,7 @@ config ASYMMETRIC_PUBLIC_KEY_SUBTYPE
config PUBLIC_KEY_ALGO_RSA
tristate "RSA public-key algorithm"
- select MPILIB
+ select CRYPTO_RSA
help
This option enables support for the RSA algorithm (PKCS#1, RFC3447).
diff --git a/crypto/asymmetric_keys/Makefile b/crypto/asymmetric_keys/Makefile
index e47fcd9..895d8ca 100644
--- a/crypto/asymmetric_keys/Makefile
+++ b/crypto/asymmetric_keys/Makefile
@@ -7,7 +7,7 @@ obj-$(CONFIG_ASYMMETRIC_KEY_TYPE) += asymmetric_keys.o
asymmetric_keys-y := asymmetric_type.o signature.o
obj-$(CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE) += public_key.o
-obj-$(CONFIG_PUBLIC_KEY_ALGO_RSA) += rsa.o
+obj-$(CONFIG_PUBLIC_KEY_ALGO_RSA) += rsa_pkcs1_v1_5.o
#
# X.509 Certificate handling
@@ -15,16 +15,13 @@ obj-$(CONFIG_PUBLIC_KEY_ALGO_RSA) += rsa.o
obj-$(CONFIG_X509_CERTIFICATE_PARSER) += x509_key_parser.o
x509_key_parser-y := \
x509-asn1.o \
- x509_rsakey-asn1.o \
x509_cert_parser.o \
x509_public_key.o
-$(obj)/x509_cert_parser.o: $(obj)/x509-asn1.h $(obj)/x509_rsakey-asn1.h
+$(obj)/x509_cert_parser.o: $(obj)/x509-asn1.h
$(obj)/x509-asn1.o: $(obj)/x509-asn1.c $(obj)/x509-asn1.h
-$(obj)/x509_rsakey-asn1.o: $(obj)/x509_rsakey-asn1.c $(obj)/x509_rsakey-asn1.h
clean-files+= x509-asn1.c x509-asn1.h
-clean-files+= x509_rsakey-asn1.c x509_rsakey-asn1.h
#
# PKCS#7 message handling
diff --git a/crypto/asymmetric_keys/pkcs7_parser.c
b/crypto/asymmetric_keys/pkcs7_parser.c
index 3bd5a1e..8e3597a 100644
--- a/crypto/asymmetric_keys/pkcs7_parser.c
+++ b/crypto/asymmetric_keys/pkcs7_parser.c
@@ -15,7 +15,7 @@
#include
#include
#include
-#include "public_key.h"
+#include
#include "pkcs7_parser.h"
#include "pkcs7-asn1.h"
@@ -41,7 +41,7 @@ struct pkcs7_parse_context {
static void pkcs7_free_signed_info(struct pkcs7_signed_info *sinfo)
{
if (sinfo) {
- mpi_free(sinfo->sig.mpi[0]);
+ kfree(sinfo->sig.s);
kfree(sinfo->sig.digest);
kfree(sinfo->signing_cert_id);
kfree(sinfo);
@@ -374,16 +374,14 @@ int pkcs7_sig_note_signature(void *context, size_t hdrlen,
const void *value, size_t vlen)
{
struct pkcs7_parse_context *ctx = context;
- MPI mpi;
BUG_ON(ctx->sinfo->sig.pkey_algo != PKEY_ALGO_RSA);
- mpi = mpi_read_raw_data(value, vlen);
- if (!mpi)
+ ctx->sinfo->sig.s = kmemdup(value, vlen, GFP_KERNEL);
+ if (!ctx->sinfo->sig.s)
return -ENOMEM;
- ctx->sinfo->sig.mpi[0] = mpi;
- ctx->sinfo->sig.nr_mpi = 1;
+ ctx->sinfo->sig.s_size = vlen;
return 0;
}
diff --git a/crypto/asymmetric_keys/pkcs7_trust.c
b/crypto/asymmetric_keys/pkcs7_trust.c
index 1d29376..68ebae2 100644
--- a/crypto/asymmetric_keys/pkcs7_trust.c
+++ b/crypto/asymmetric_keys/pkcs7_trust.c
@@ -17,7 +17,7 @@
#include
#include
#include
-#include "public_key.h"
+#include
#include "pkcs7_parser.h"
/**
diff --git a/crypto/asymmetric_keys/pkcs7_verify.c
b/crypto/asymmetric_keys/pkcs7_verify.c
index cd45545..c32a337 100644
--- a/crypto/asymmetric_keys/pkcs7_verify.c
+++
[RFC PATCH 7/7] libnvdimm, pmem: 'struct page' for pmem
Enable the pmem driver to handle PFN device instances. Attaching a pmem
namespace to a pfn device triggers the driver to allocate and initialize
struct page entries for pmem. Memory capacity for this allocation can
either come from RAM (if the mapped PMEM capacity is low), or from PMEM
(if the write endurance and relative performance concerns of PMEM are
low).
Given this adds a new call to devm_memunmap() the corresponding wrapper
is added to tools/testing/nvdimm/.
Cc: Boaz Harrosh
Cc: Ross Zwisler
Cc: Christoph Hellwig
Signed-off-by: Dan Williams
---
drivers/nvdimm/Kconfig|4 +
drivers/nvdimm/pfn_devs.c |3 -
drivers/nvdimm/pmem.c | 213 -
tools/testing/nvdimm/Kbuild |1
tools/testing/nvdimm/test/iomap.c | 13 ++
5 files changed, 225 insertions(+), 9 deletions(-)
diff --git a/drivers/nvdimm/Kconfig b/drivers/nvdimm/Kconfig
index 7e05f2657d09..87fbd693c68e 100644
--- a/drivers/nvdimm/Kconfig
+++ b/drivers/nvdimm/Kconfig
@@ -77,6 +77,10 @@ config ND_PFN
config NVDIMM_PFN
bool "PFN: Map persistent (device) memory"
default LIBNVDIMM
+ depends on MEMORY_HOTPLUG
+ depends on MEMORY_HOTREMOVE
+ depends on X86_64 #arch_add_memory() comprehends device memory
+ depends on ZONE_DEVICE
select ND_CLAIM
help
Map persistent memory, i.e. advertise it to the memory
diff --git a/drivers/nvdimm/pfn_devs.c b/drivers/nvdimm/pfn_devs.c
index 41824b3bf0d2..b1319ed53642 100644
--- a/drivers/nvdimm/pfn_devs.c
+++ b/drivers/nvdimm/pfn_devs.c
@@ -227,7 +227,7 @@ struct device *nd_pfn_create(struct nd_region *nd_region)
return dev;
}
-static int nd_pfn_validate(struct nd_pfn *nd_pfn)
+int nd_pfn_validate(struct nd_pfn *nd_pfn)
{
struct nd_namespace_common *ndns = nd_pfn->ndns;
struct nd_pfn_sb *pfn_sb = nd_pfn->pfn_sb;
@@ -296,6 +296,7 @@ static int nd_pfn_validate(struct nd_pfn *nd_pfn)
return 0;
}
+EXPORT_SYMBOL(nd_pfn_validate);
int nd_pfn_probe(struct nd_namespace_common *ndns, void *drvdata)
{
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index 85d4101bb821..51867759b3f3 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -22,19 +22,24 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include "pfn.h"
#include "nd.h"
struct pmem_device {
struct request_queue*pmem_queue;
struct gendisk *pmem_disk;
+ struct nd_namespace_common *ndns;
/* One contiguous memory region per device */
phys_addr_t phys_addr;
+ /* when non-zero this device is hosting a 'pfn' instance */
+ phys_addr_t data_offset;
void __pmem *virt_addr;
size_t size;
};
@@ -46,7 +51,7 @@ static void pmem_do_bvec(struct pmem_device *pmem, struct
page *page,
sector_t sector)
{
void *mem = kmap_atomic(page);
- size_t pmem_off = sector << 9;
+ phys_addr_t pmem_off = sector * 512 + pmem->data_offset;
void __pmem *pmem_addr = pmem->virt_addr + pmem_off;
if (rw == READ) {
@@ -97,10 +102,23 @@ static long pmem_direct_access(struct block_device *bdev,
sector_t sector,
__pfn_t *pfn)
{
struct pmem_device *pmem = bdev->bd_disk->private_data;
- size_t offset = sector << 9;
-
- *pfn = phys_to_pfn_t(pmem->phys_addr + offset, PFN_DEV);
- return pmem->size - offset;
+ resource_size_t offset = sector * 512 + pmem->data_offset;
+ unsigned long flags = PFN_DEV;
+ resource_size_t size;
+
+ if (pmem->data_offset) {
+ flags |= PFN_MAP;
+ /*
+* Limit the direct_access() size to what is covered by
+* the memmap
+*/
+ size = (pmem->size - offset) & ~ND_PFN_MASK;
+ } else
+ size = pmem->size - offset;
+
+ *pfn = phys_to_pfn_t(pmem->phys_addr + offset, flags);
+
+ return size;
}
static const struct block_device_operations pmem_fops = {
@@ -140,6 +158,9 @@ static struct pmem_device *pmem_alloc(struct device *dev,
static void pmem_detach_disk(struct pmem_device *pmem)
{
+ if (!pmem->pmem_disk)
+ return;
+
del_gendisk(pmem->pmem_disk);
put_disk(pmem->pmem_disk);
blk_cleanup_queue(pmem->pmem_queue);
@@ -181,7 +202,7 @@ static int pmem_attach_disk(struct device *dev,
disk->flags = GENHD_FL_EXT_DEVT;
nvdimm_namespace_disk_name(ndns, disk->disk_name);
disk->driverfs_dev = >dev;
- set_capacity(disk, pmem->size >> 9);
+ set_capacity(disk, (pmem->size - pmem->data_offset) / 512);
pmem->pmem_disk = disk;
add_disk(disk);
@@ -210,6 +231,170 @@ static int pmem_rw_bytes(struct nd_namespace_common *ndns,
return 0;
}
[RFC PATCH 4/7] mm: register_dev_memmap()
Provide an interface for device drivers to register physical memory
The register_dev_memmap() api enables a device driver like pmem to setup
struct page entries for the memory it has discovered. While this
mechanism is motivated by the desire to use persistent memory outside of
the block I/O and direct access (DAX) paths, this mechanism is generic
for any physical range that is not marked as RAM at boot.
Given capacities for the registered memory range may be too large to
house the memmap in RAM, this interface allows for the memmap to be
allocated from the new range being registered. The pmem driver uses
this capability to let userspace policy determine the placement of the
memmap for peristent memory.
Cc: H. Peter Anvin
Cc: Ingo Molnar
Cc: Dave Hansen
Cc: Rik van Riel
Cc: Mel Gorman
Cc: linux...@kvack.org
Signed-off-by: Dan Williams
---
include/linux/kmap_pfn.h | 33
include/linux/mm.h |4 +
mm/kmap_pfn.c| 195 ++
3 files changed, 231 insertions(+), 1 deletion(-)
diff --git a/include/linux/kmap_pfn.h b/include/linux/kmap_pfn.h
index fa44971d8e95..2dfad83337ba 100644
--- a/include/linux/kmap_pfn.h
+++ b/include/linux/kmap_pfn.h
@@ -4,7 +4,9 @@
#include
struct device;
+struct dev_map;
struct resource;
+struct vmem_altmap;
#ifdef CONFIG_KMAP_PFN
extern void *kmap_atomic_pfn_t(__pfn_t pfn);
extern void kunmap_atomic_pfn_t(void *addr);
@@ -28,4 +30,35 @@ static inline int devm_register_kmap_pfn_range(struct device
*dev,
}
#endif /* CONFIG_KMAP_PFN */
+#ifdef CONFIG_ZONE_DEVICE
+struct dev_map *__register_dev_memmap(struct device *dev, struct resource *res,
+ struct vmem_altmap *altmap, struct module *mod);
+void unregister_dev_memmap(struct dev_map *dev_map);
+struct dev_map * __must_check try_pin_devpfn_range(__pfn_t pfn);
+void unpin_devpfn_range(struct dev_map *dev_map);
+#else
+static inline struct dev_map *__register_dev_memmap(struct device *dev,
+ struct resource *res, struct vmem_altmap *altmap,
+ struct module *mod)
+{
+ return NULL;
+}
+
+static inline void unregister_dev_memmap(struct dev_map *dev_map)
+{
+}
+
+static inline struct dev_map * __must_check try_pin_devpfn_range(__pfn_t pfn)
+{
+ return NULL;
+}
+
+static inline void unpin_devpfn_range(struct dev_map *dev_map)
+{
+}
+#endif
+
+#define register_dev_memmap(d, r, a) \
+__register_dev_memmap((d), (r), (a), THIS_MODULE)
+
#endif /* _LINUX_KMAP_PFN_H */
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 8a4f24d7fdb0..07152a54b841 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -939,6 +939,7 @@ typedef struct {
* PFN_SG_CHAIN - pfn is a pointer to the next scatterlist entry
* PFN_SG_LAST - pfn references a page and is the last scatterlist entry
* PFN_DEV - pfn is not covered by system memmap
+ * PFN_MAP - pfn is covered by a device specific memmap
*/
enum {
PFN_MASK = (1UL << PAGE_SHIFT) - 1,
@@ -949,6 +950,7 @@ enum {
#else
PFN_DEV = 0,
#endif
+ PFN_MAP = (1UL << 3),
};
static inline __pfn_t pfn_to_pfn_t(unsigned long pfn, unsigned long flags)
@@ -965,7 +967,7 @@ static inline __pfn_t phys_to_pfn_t(dma_addr_t addr,
unsigned long flags)
static inline bool __pfn_t_has_page(__pfn_t pfn)
{
- return (pfn.val & PFN_DEV) == 0;
+ return (pfn.val & PFN_DEV) == 0 || (pfn.val & PFN_MAP) == PFN_MAP;
}
static inline unsigned long __pfn_t_to_pfn(__pfn_t pfn)
diff --git a/mm/kmap_pfn.c b/mm/kmap_pfn.c
index 2d58e167dfbc..d60ac7463454 100644
--- a/mm/kmap_pfn.c
+++ b/mm/kmap_pfn.c
@@ -10,16 +10,36 @@
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*/
+#include
+#include
#include
#include
#include
#include
+#include
#include
#include
#include
static LIST_HEAD(ranges);
+static LIST_HEAD(dev_maps);
static DEFINE_MUTEX(register_lock);
+static DECLARE_WAIT_QUEUE_HEAD(dev_map_wq);
+
+#ifndef CONFIG_MEMORY_HOTPLUG
+int __weak arch_add_dev_memory(int nid, u64 start, u64 size,
+ struct vmem_altmap *altmap)
+{
+ return -ENXIO;
+}
+#endif
+
+#ifndef CONFIG_MEMORY_HOTREMOVE
+int __weak arch_remove_dev_memory(u64 start, u64 size)
+{
+ return -ENXIO;
+}
+#endif
struct kmap {
struct list_head list;
@@ -28,6 +48,22 @@ struct kmap {
void *base;
};
+enum {
+ DEV_MAP_LIVE,
+ DEV_MAP_CONFIRM,
+};
+
+struct dev_map {
+ struct list_head list;
+ resource_size_t base;
+ resource_size_t end;
+ struct percpu_ref percpu_ref;
+ struct device *dev;
+ struct module *module;
+ struct vmem_altmap *altmap;
+ unsigned long flags;
+};
+
static void teardown_kmap(void *data)
{
struct kmap *kmap = data;
@@ -115,3 +151,162 @@ void kunmap_atomic_pfn_t(void *addr)
rcu_read_unlock();
}
EXPORT_SYMBOL(kunmap_atomic_pfn_t);
+
+#ifdef CONFIG_ZONE_DEVICE
[RFC PATCH 3/7] x86, mm: arch_add_dev_memory()
Use struct vmem_altmap to augment vmemmap_{populate|free}().
In support of providing struct page coverage for persistent memory,
use struct vmem_altmap to change the default policy for mapping pfns for
a page range. The default vmemmap_populate() allocates page table
storage area from the page allocator. In support of storing struct page
infrastructure on device memory (pmem) directly vmem_altmap directs
vmmemap_populate() to use a pre-allocated block of contiguous pfns for
storage of the new vmemmap entries.
Cc: H. Peter Anvin
Cc: Ingo Molnar
Cc: Dave Hansen
Cc: Rik van Riel
Cc: Mel Gorman
Cc: linux...@kvack.org
Signed-off-by: Dan Williams
---
arch/x86/mm/init_64.c | 55 +---
include/linux/memory_hotplug.h |4 +++
include/linux/mm.h | 38 +++-
mm/memory_hotplug.c| 12 +
mm/page_alloc.c|4 +++
mm/sparse-vmemmap.c| 31 +++
mm/sparse.c| 17 +++-
7 files changed, 154 insertions(+), 7 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index c2f872a379d2..eda65ec8484e 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -719,6 +719,21 @@ int arch_add_memory(int nid, u64 start, u64 size)
}
EXPORT_SYMBOL_GPL(arch_add_memory);
+#ifdef CONFIG_ZONE_DEVICE
+/*
+ * The primary difference vs arch_add_memory is that the zone is known
+ * apriori.
+ */
+int arch_add_dev_memory(int nid, u64 start, u64 size,
+ struct vmem_altmap *altmap)
+{
+ struct pglist_data *pgdat = NODE_DATA(nid);
+ struct zone *zone = pgdat->node_zones + ZONE_DEVICE;
+
+ return __arch_add_memory(nid, start, size, zone, altmap);
+}
+#endif
+
#define PAGE_INUSE 0xFD
static void __meminit free_pagetable(struct page *page, int order)
@@ -771,8 +786,13 @@ static void __meminit free_pmd_table(pmd_t *pmd_start,
pud_t *pud,
return;
}
- /* free a pmd talbe */
- free_pagetable(pud_page(*pud), 0);
+ /*
+* Free a pmd table if it came from the page allocator (i.e. !altmap).
+* In the altmap case the pages are being freed implicitly by the
+* section becoming unmapped / unplugged.
+*/
+ if (!altmap)
+ free_pagetable(pud_page(*pud), 0);
spin_lock(_mm.page_table_lock);
pud_clear(pud);
spin_unlock(_mm.page_table_lock);
@@ -890,7 +910,7 @@ remove_pmd_table(pmd_t *pmd_start, unsigned long addr,
unsigned long end,
if (pmd_large(*pmd)) {
if (IS_ALIGNED(addr, PMD_SIZE) &&
IS_ALIGNED(next, PMD_SIZE)) {
- if (!direct)
+ if (!direct && !altmap)
free_pagetable(pmd_page(*pmd),
get_order(PMD_SIZE));
@@ -946,7 +966,7 @@ remove_pud_table(pud_t *pud_start, unsigned long addr,
unsigned long end,
if (pud_large(*pud)) {
if (IS_ALIGNED(addr, PUD_SIZE) &&
IS_ALIGNED(next, PUD_SIZE)) {
- if (!direct)
+ if (!direct && !altmap)
free_pagetable(pud_page(*pud),
get_order(PUD_SIZE));
@@ -993,6 +1013,8 @@ remove_pagetable(unsigned long start, unsigned long end,
bool direct,
pud_t *pud;
bool pgd_changed = false;
+ WARN_ON_ONCE(direct && altmap);
+
for (addr = start; addr < end; addr = next) {
next = pgd_addr_end(addr, end);
@@ -1041,6 +1063,31 @@ static int __ref __arch_remove_memory(u64 start, u64
size, struct zone *zone,
__phys_to_pfn(size), altmap);
}
+int __ref arch_remove_dev_memory(u64 start, u64 size,
+ struct vmem_altmap *altmap)
+{
+ unsigned long pfn = __phys_to_pfn(start);
+ struct zone *zone;
+ int rc;
+
+ /*
+* Reserve pages will not have initialized pfns, so we need to
+* calulate the page zone from the first valid pfn.
+*/
+ if (altmap) {
+ if (altmap->base_pfn != pfn) {
+ WARN_ONCE(1, "pfn: %#lx expected: %#lx\n",
+ pfn, altmap->base_pfn);
+ return -EINVAL;
+ }
+ pfn += altmap->reserve;
+ }
+ zone = page_zone(pfn_to_page(pfn));
+ rc = __arch_remove_memory(start, size, zone, altmap);
+ WARN_ON_ONCE(rc);
+ return rc;
+}
+
int __ref arch_remove_memory(u64 start, u64 size)
{
struct zone *zone = page_zone(pfn_to_page(__phys_to_pfn(start)));
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index
[RFC PATCH 5/7] libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option
Purely for ease of testing, with this in place we can run the unit test
alongside any tests that depend on the memmap=ss!nn kernel parameter.
The unit test mocking implementation requires that libnvdimm be a module
and not built-in.
A nice side effect is the implementation is a bit more generic as it no
longer depends on .
Cc: Christoph Hellwig
Signed-off-by: Dan Williams
---
arch/x86/Kconfig |6 ++-
arch/x86/include/uapi/asm/e820.h |2 -
arch/x86/kernel/Makefile |2 -
arch/x86/kernel/pmem.c | 79 ---
drivers/nvdimm/Makefile |3 +
drivers/nvdimm/e820.c| 86 ++
tools/testing/nvdimm/Kbuild |4 ++
7 files changed, 108 insertions(+), 74 deletions(-)
create mode 100644 drivers/nvdimm/e820.c
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 64829b17980b..5d6994f62c4d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1439,10 +1439,14 @@ config ILLEGAL_POINTER_VALUE
source "mm/Kconfig"
+config X86_PMEM_LEGACY_DEVICE
+ bool
+
config X86_PMEM_LEGACY
- bool "Support non-standard NVDIMMs and ADR protected memory"
+ tristate "Support non-standard NVDIMMs and ADR protected memory"
depends on PHYS_ADDR_T_64BIT
depends on BLK_DEV
+ select X86_PMEM_LEGACY_DEVICE
select LIBNVDIMM
help
Treat memory marked using the non-standard e820 type of 12 as used
diff --git a/arch/x86/include/uapi/asm/e820.h b/arch/x86/include/uapi/asm/e820.h
index 0f457e6eab18..9dafe59cf6e2 100644
--- a/arch/x86/include/uapi/asm/e820.h
+++ b/arch/x86/include/uapi/asm/e820.h
@@ -37,7 +37,7 @@
/*
* This is a non-standardized way to represent ADR or NVDIMM regions that
* persist over a reboot. The kernel will ignore their special capabilities
- * unless the CONFIG_X86_PMEM_LEGACY=y option is set.
+ * unless the CONFIG_X86_PMEM_LEGACY option is set.
*
* ( Note that older platforms also used 6 for the same type of memory,
* but newer versions switched to 12 as 6 was assigned differently. Some
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 0f15af41bd80..ac2bb7e28ba2 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -92,7 +92,7 @@ obj-$(CONFIG_KVM_GUEST) += kvm.o kvmclock.o
obj-$(CONFIG_PARAVIRT) += paravirt.o paravirt_patch_$(BITS).o
obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= paravirt-spinlocks.o
obj-$(CONFIG_PARAVIRT_CLOCK) += pvclock.o
-obj-$(CONFIG_X86_PMEM_LEGACY) += pmem.o
+obj-$(CONFIG_X86_PMEM_LEGACY_DEVICE) += pmem.o
obj-$(CONFIG_PCSPKR_PLATFORM) += pcspeaker.o
diff --git a/arch/x86/kernel/pmem.c b/arch/x86/kernel/pmem.c
index 64f90f53bb85..4f00b63d7ff3 100644
--- a/arch/x86/kernel/pmem.c
+++ b/arch/x86/kernel/pmem.c
@@ -3,80 +3,17 @@
* Copyright (c) 2015, Intel Corporation.
*/
#include
-#include
#include
-#include
-
-static void e820_pmem_release(struct device *dev)
-{
- struct nvdimm_bus *nvdimm_bus = dev->platform_data;
-
- if (nvdimm_bus)
- nvdimm_bus_unregister(nvdimm_bus);
-}
-
-static struct platform_device e820_pmem = {
- .name = "e820_pmem",
- .id = -1,
- .dev = {
- .release = e820_pmem_release,
- },
-};
-
-static const struct attribute_group *e820_pmem_attribute_groups[] = {
- _bus_attribute_group,
- NULL,
-};
-
-static const struct attribute_group *e820_pmem_region_attribute_groups[] = {
- _region_attribute_group,
- _device_attribute_group,
- NULL,
-};
static __init int register_e820_pmem(void)
{
- static struct nvdimm_bus_descriptor nd_desc;
- struct device *dev = _pmem.dev;
- struct nvdimm_bus *nvdimm_bus;
- int rc, i;
-
- rc = platform_device_register(_pmem);
- if (rc)
- return rc;
-
- nd_desc.attr_groups = e820_pmem_attribute_groups;
- nd_desc.provider_name = "e820";
- nvdimm_bus = nvdimm_bus_register(dev, _desc);
- if (!nvdimm_bus)
- goto err;
- dev->platform_data = nvdimm_bus;
-
- for (i = 0; i < e820.nr_map; i++) {
- struct e820entry *ei = [i];
- struct resource res = {
- .flags = IORESOURCE_MEM,
- .start = ei->addr,
- .end= ei->addr + ei->size - 1,
- };
- struct nd_region_desc ndr_desc;
-
- if (ei->type != E820_PRAM)
- continue;
-
- memset(_desc, 0, sizeof(ndr_desc));
- ndr_desc.res =
- ndr_desc.attr_groups = e820_pmem_region_attribute_groups;
- ndr_desc.numa_node = NUMA_NO_NODE;
- if (!nvdimm_pmem_region_create(nvdimm_bus, _desc))
- goto err;
- }
-
- return 0;
-
- err:
- dev_err(dev, "failed to register legacy persistent memory
[RFC PATCH 6/7] libnvdimm, pfn: 'struct page' provider infrastructure
Implement the base infrastructure for libnvdimm PFN devices. Similar to
BTT devices they take a namespace as a backing device and layer
functionality on top. In this case the functionality is reserving space
for an array of 'struct page' entries to be handed out through
pfn_to_page(). For now this is just the basic libnvdimm-device-model for
configuring the base PFN device.
As the namespace claiming mechanism for PFN devices is mostly identical
to BTT devices drivers/nvdimm/claim.c is created to house the common
bits.
Cc: Ross Zwisler
Signed-off-by: Dan Williams
---
drivers/nvdimm/Kconfig | 22 +++
drivers/nvdimm/Makefile |2
drivers/nvdimm/btt.c|8 -
drivers/nvdimm/btt_devs.c | 172 +---
drivers/nvdimm/claim.c | 201
drivers/nvdimm/namespace_devs.c | 34 +++-
drivers/nvdimm/nd-core.h|9 +
drivers/nvdimm/nd.h | 59 +++
drivers/nvdimm/pfn.h| 35
drivers/nvdimm/pfn_devs.c | 333 +++
drivers/nvdimm/region.c |2
drivers/nvdimm/region_devs.c| 19 ++
tools/testing/nvdimm/Kbuild |2
13 files changed, 720 insertions(+), 178 deletions(-)
create mode 100644 drivers/nvdimm/claim.c
create mode 100644 drivers/nvdimm/pfn.h
create mode 100644 drivers/nvdimm/pfn_devs.c
diff --git a/drivers/nvdimm/Kconfig b/drivers/nvdimm/Kconfig
index 0d8c6bda7a41..7e05f2657d09 100644
--- a/drivers/nvdimm/Kconfig
+++ b/drivers/nvdimm/Kconfig
@@ -22,6 +22,7 @@ config BLK_DEV_PMEM
depends on HAS_IOMEM
select KMAP_PFN
select ND_BTT if BTT
+ select ND_PFN if NVDIMM_PFN
help
Memory ranges for PMEM are described by either an NFIT
(NVDIMM Firmware Interface Table, see CONFIG_NFIT_ACPI), a
@@ -48,12 +49,16 @@ config ND_BLK
(CONFIG_ACPI_NFIT), or otherwise exposes BLK-mode
capabilities.
+config ND_CLAIM
+ bool
+
config ND_BTT
tristate
config BTT
bool "BTT: Block Translation Table (atomic sector updates)"
default y if LIBNVDIMM
+ select ND_CLAIM
help
The Block Translation Table (BTT) provides atomic sector
update semantics for persistent memory devices, so that
@@ -66,4 +71,21 @@ config BTT
Select Y if unsure
+config ND_PFN
+ tristate
+
+config NVDIMM_PFN
+ bool "PFN: Map persistent (device) memory"
+ default LIBNVDIMM
+ select ND_CLAIM
+ help
+ Map persistent memory, i.e. advertise it to the memory
+ management sub-system. By default persistent memory does
+ not support direct I/O, RDMA, or any other usage that
+ requires a 'struct page' to mediate an I/O request. This
+ driver allocates and initializes the infrastructure needed
+ to support those use cases.
+
+ Select Y if unsure
+
endif
diff --git a/drivers/nvdimm/Makefile b/drivers/nvdimm/Makefile
index 9bf15db52dee..ea84d3c4e8e5 100644
--- a/drivers/nvdimm/Makefile
+++ b/drivers/nvdimm/Makefile
@@ -20,4 +20,6 @@ libnvdimm-y += region_devs.o
libnvdimm-y += region.o
libnvdimm-y += namespace_devs.o
libnvdimm-y += label.o
+libnvdimm-$(CONFIG_ND_CLAIM) += claim.o
libnvdimm-$(CONFIG_BTT) += btt_devs.o
+libnvdimm-$(CONFIG_NVDIMM_PFN) += pfn_devs.o
diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm/btt.c
index 552f1c4f4dc6..a0db65788a92 100644
--- a/drivers/nvdimm/btt.c
+++ b/drivers/nvdimm/btt.c
@@ -595,7 +595,7 @@ static int arena_is_valid(struct arena_info *arena, struct
btt_sb *super,
checksum = le64_to_cpu(super->checksum);
super->checksum = 0;
- if (checksum != nd_btt_sb_checksum(super))
+ if (checksum != nd_sb_checksum((struct nd_gen_sb *) super))
return 0;
super->checksum = cpu_to_le64(checksum);
@@ -759,6 +759,7 @@ static int create_arenas(struct btt *btt)
static int btt_arena_write_layout(struct arena_info *arena, u8 *uuid)
{
int ret;
+ u64 sum;
struct btt_sb *super;
ret = btt_map_init(arena);
@@ -795,7 +796,8 @@ static int btt_arena_write_layout(struct arena_info *arena,
u8 *uuid)
super->info2off = cpu_to_le64(arena->info2off - arena->infooff);
super->flags = 0;
- super->checksum = cpu_to_le64(nd_btt_sb_checksum(super));
+ sum = nd_sb_checksum((struct nd_gen_sb *) super);
+ super->checksum = cpu_to_le64(sum);
ret = btt_info_write(arena, super);
@@ -1447,8 +1449,6 @@ static int __init nd_btt_init(void)
{
int rc;
- BUILD_BUG_ON(sizeof(struct btt_sb) != SZ_4K);
-
btt_major = register_blkdev(0, "btt");
if (btt_major < 0)
return btt_major;
diff --git a/drivers/nvdimm/btt_devs.c b/drivers/nvdimm/btt_devs.c
index 6ac8c0fea3ec..8256c481762b 100644
--- a/drivers/nvdimm/btt_devs.c
+++ b/drivers/nvdimm/btt_devs.c
@@ -21,63 +21,13 @@
[PATCH 2/2] crypto: qat - Don't move data inside output buffer
Don't need to move data inside of the output buffer because SW doen't need to do this anymore sice the new MPI mpi_read_buf() has been added. Just set the correct output len. Signed-off-by: Tadeusz Struk --- drivers/crypto/qat/qat_common/qat_asym_algs.c |3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/crypto/qat/qat_common/qat_asym_algs.c b/drivers/crypto/qat/qat_common/qat_asym_algs.c index fe352a6..6ddb13c 100644 --- a/drivers/crypto/qat/qat_common/qat_asym_algs.c +++ b/drivers/crypto/qat/qat_common/qat_asym_algs.c @@ -144,9 +144,6 @@ static void qat_rsa_cb(struct icp_qat_fw_pke_resp *resp) ptr++; } - if (areq->dst_len != req->ctx->key_sz) - memcpy(areq->dst, ptr, areq->dst_len); - akcipher_request_complete(areq, err); } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 1/7] x86, mm: ZONE_DEVICE for "device memory"
While pmem is usable as a block device or via DAX mappings to userspace
there are several usage scenarios that can not target pmem due to its
lack of struct page coverage. In preparation for "hot plugging" pmem
into the vmemmap add ZONE_DEVICE as a new zone to tag these pages
separately from the ones that are subject to standard page allocations.
Importantly "device memory" can be removed at will by userspace
unbinding the driver of the device.
Having a separate zone prevents allocation and otherwise marks these
pages that are distinct from typical uniform memory. Device memory has
different lifetime and performance characteristics than RAM. However,
since we have run out of ZONES_SHIFT bits this functionality currently
depends on sacrificing ZONE_DMA.
arch_add_memory() is reorganized a bit in preparation for a new
arch_add_dev_memory() api, for now there is no functional change to the
memory hotplug code.
Cc: H. Peter Anvin
Cc: Ingo Molnar
Cc: Dave Hansen
Cc: Rik van Riel
Cc: Mel Gorman
Cc: linux...@kvack.org
Signed-off-by: Dan Williams
---
arch/x86/Kconfig | 13 +
arch/x86/mm/init_64.c | 32 +---
include/linux/mmzone.h | 23 +++
mm/memory_hotplug.c|5 -
mm/page_alloc.c|3 +++
5 files changed, 64 insertions(+), 12 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b3a1a5d77d92..64829b17980b 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -308,6 +308,19 @@ config ZONE_DMA
If unsure, say Y.
+config ZONE_DEVICE
+ bool "Device memory (pmem, etc...) hotplug support" if EXPERT
+ default !ZONE_DMA
+ depends on !ZONE_DMA
+ help
+ Device memory hotplug support allows for establishing pmem,
+ or other device driver discovered memory regions, in the
+ memmap. This allows pfn_to_page() lookups of otherwise
+ "device-physical" addresses which is needed for using a DAX
+ mapping in an O_DIRECT operation, among other things.
+
+ If FS_DAX is enabled, then say Y.
+
config SMP
bool "Symmetric multi-processing support"
---help---
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 3fba623e3ba5..94f0fa56f0ed 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -683,15 +683,8 @@ static void update_end_of_memory_vars(u64 start, u64 size)
}
}
-/*
- * Memory is added always to NORMAL zone. This means you will never get
- * additional DMA/DMA32 memory.
- */
-int arch_add_memory(int nid, u64 start, u64 size)
+static int __arch_add_memory(int nid, u64 start, u64 size, struct zone *zone)
{
- struct pglist_data *pgdat = NODE_DATA(nid);
- struct zone *zone = pgdat->node_zones +
- zone_for_memory(nid, start, size, ZONE_NORMAL);
unsigned long start_pfn = start >> PAGE_SHIFT;
unsigned long nr_pages = size >> PAGE_SHIFT;
int ret;
@@ -701,11 +694,28 @@ int arch_add_memory(int nid, u64 start, u64 size)
ret = __add_pages(nid, zone, start_pfn, nr_pages);
WARN_ON_ONCE(ret);
- /* update max_pfn, max_low_pfn and high_memory */
- update_end_of_memory_vars(start, size);
+ /*
+* Update max_pfn, max_low_pfn and high_memory, unless we added
+* "device memory" which should not effect max_pfn
+*/
+ if (!is_dev_zone(zone))
+ update_end_of_memory_vars(start, size);
return ret;
}
+
+/*
+ * Memory is added always to NORMAL zone. This means you will never get
+ * additional DMA/DMA32 memory.
+ */
+int arch_add_memory(int nid, u64 start, u64 size)
+{
+ struct pglist_data *pgdat = NODE_DATA(nid);
+ struct zone *zone = pgdat->node_zones +
+ zone_for_memory(nid, start, size, ZONE_NORMAL);
+
+ return __arch_add_memory(nid, start, size, zone);
+}
EXPORT_SYMBOL_GPL(arch_add_memory);
#define PAGE_INUSE 0xFD
@@ -1028,7 +1038,7 @@ int __ref arch_remove_memory(u64 start, u64 size)
return ret;
}
-#endif
+#endif /* CONFIG_MEMORY_HOTREMOVE */
#endif /* CONFIG_MEMORY_HOTPLUG */
static struct kcore_list kcore_vsyscall;
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 754c25966a0a..9217fd93c25b 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -319,7 +319,11 @@ enum zone_type {
ZONE_HIGHMEM,
#endif
ZONE_MOVABLE,
+#ifdef CONFIG_ZONE_DEVICE
+ ZONE_DEVICE,
+#endif
__MAX_NR_ZONES
+
};
#ifndef __GENERATING_BOUNDS_H
@@ -794,6 +798,25 @@ static inline bool pgdat_is_empty(pg_data_t *pgdat)
return !pgdat->node_start_pfn && !pgdat->node_spanned_pages;
}
+static inline int zone_id(const struct zone *zone)
+{
+ struct pglist_data *pgdat = zone->zone_pgdat;
+
+ return zone - pgdat->node_zones;
+}
+
+#ifdef CONFIG_ZONE_DEVICE
+static inline bool is_dev_zone(const struct zone *zone)
+{
+ return zone_id(zone) == ZONE_DEVICE;
+}
[RFC PATCH 0/7] 'struct page' driver for persistent memory
When we last left this debate [1] it was becoming clear that the 'page-less' approach left too many I/O scenarios off the table. The page-less enabling is still useful for avoiding the overhead of struct page where it is not needed, but in the end, page-backed persistent memory seems to be a requirement. With that assumption in place the next debate was where to allocate the storage for the memmap array, or otherwise reduce the overhead of 'struct page' with a fancier object like variable length pages. This series takes the position of mapping persistent memory with standard 'struct page' and pushes the policy decision of allocating the storage for the memmap array, from RAM or PMEM, to userspace. It turns out the best place to allocate 64-bytes per 4K page will be platform specific. If PMEM capacities are low then mapping in RAM is a good choice. Otherwise, for very large capacities storing the memmap in PMEM might be a better choice. Yet again, PMEM might not have the performance characteristics favorable to a high rate of change object like 'struct page'. The kernel can make a reasonable guess, but it seems we will need to maintain the ability to override any default. Outside of the new libvdimm sysfs mechanisms to specify the memmap allocation policy for a given PMEM device, the core of this implementation is 'struct vmem_altmap'. 'vmem_altmap' alters the memory hotplug code to optionally use a reserved PMEM-pfn range rather than dynamic allocation for the memmap. Only lightly tested so far to confirm valid pfn_to_page() and page_address() conversions across a range of persistent memory specified by 'memmap=ss!nn' (kernel command line option to simulate a PMEM range). [1]: https://lists.01.org/pipermail/linux-nvdimm/2015-May/000748.html --- Dan Williams (7): x86, mm: ZONE_DEVICE for "device memory" x86, mm: introduce struct vmem_altmap x86, mm: arch_add_dev_memory() mm: register_dev_memmap() libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option libnvdimm, pfn: 'struct page' provider infrastructure libnvdimm, pmem: 'struct page' for pmem arch/powerpc/mm/init_64.c |7 + arch/x86/Kconfig | 19 ++ arch/x86/include/uapi/asm/e820.h |2 arch/x86/kernel/Makefile |2 arch/x86/kernel/pmem.c| 79 + arch/x86/mm/init_64.c | 160 +- drivers/nvdimm/Kconfig| 26 +++ drivers/nvdimm/Makefile |5 + drivers/nvdimm/btt.c |8 - drivers/nvdimm/btt_devs.c | 172 +-- drivers/nvdimm/claim.c| 201 ++ drivers/nvdimm/e820.c | 86 ++ drivers/nvdimm/namespace_devs.c | 34 +++- drivers/nvdimm/nd-core.h |9 + drivers/nvdimm/nd.h | 59 ++- drivers/nvdimm/pfn.h | 35 drivers/nvdimm/pfn_devs.c | 334 + drivers/nvdimm/pmem.c | 213 +++- drivers/nvdimm/region.c |2 drivers/nvdimm/region_devs.c | 19 ++ include/linux/kmap_pfn.h | 33 include/linux/memory_hotplug.h| 21 ++ include/linux/mm.h| 53 ++ include/linux/mmzone.h| 23 +++ mm/kmap_pfn.c | 195 ++ mm/memory_hotplug.c | 84 ++--- mm/page_alloc.c | 18 ++ mm/sparse-vmemmap.c | 60 ++- mm/sparse.c | 44 +++-- tools/testing/nvdimm/Kbuild |7 + tools/testing/nvdimm/test/iomap.c | 13 + 31 files changed, 1673 insertions(+), 350 deletions(-) create mode 100644 drivers/nvdimm/claim.c create mode 100644 drivers/nvdimm/e820.c create mode 100644 drivers/nvdimm/pfn.h create mode 100644 drivers/nvdimm/pfn_devs.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] crypto: KEYS: convert public key to the akcipher API
This patch converts the module verification code to the new akcipher API. RSA implementation from crypto/asymmetric_keys has been removed and the new API is used for cryptographic primitives. The signature verification has been moved into a new crypto/asymmetric_keys/rsa_pkcs1_v1_5.c file. There is no need for MPI above the API anymore. Modules can be verified with software as well as HW rsa implementations. Also changed qat rsa implementation not to move data inside the output buff similarly to SW. --- Tadeusz Struk (2): crypto: KEYS: convert public key to the akcipher API crypto: qat - Don't move data inside output buffer crypto/asymmetric_keys/Kconfig|2 crypto/asymmetric_keys/Makefile |7 - crypto/asymmetric_keys/pkcs7_parser.c | 12 - crypto/asymmetric_keys/pkcs7_trust.c |2 crypto/asymmetric_keys/pkcs7_verify.c |2 crypto/asymmetric_keys/public_key.c | 59 + crypto/asymmetric_keys/public_key.h | 36 --- crypto/asymmetric_keys/rsa.c | 278 - crypto/asymmetric_keys/rsa_pkcs1_v1_5.c | 232 + crypto/asymmetric_keys/x509_cert_parser.c | 37 +-- crypto/asymmetric_keys/x509_public_key.c | 17 +- crypto/asymmetric_keys/x509_rsakey.asn1 |4 drivers/crypto/qat/qat_common/qat_asym_algs.c |3 include/crypto/public_key.h | 48 +--- kernel/module_signing.c | 56 ++--- security/integrity/digsig_asymmetric.c| 11 - 16 files changed, 304 insertions(+), 502 deletions(-) delete mode 100644 crypto/asymmetric_keys/public_key.h delete mode 100644 crypto/asymmetric_keys/rsa.c create mode 100644 crypto/asymmetric_keys/rsa_pkcs1_v1_5.c delete mode 100644 crypto/asymmetric_keys/x509_rsakey.asn1 -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 1/7] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
On 08/11/15 13:31, Will Deacon wrote:
Hi David,
On Tue, Aug 11, 2015 at 01:52:38AM +0100, David Long wrote:
From: "David A. Long"
Add HAVE_REGS_AND_STACK_ACCESS_API feature for arm64.
Signed-off-by: David A. Long
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/ptrace.h | 25 +
arch/arm64/kernel/ptrace.c | 77 +
3 files changed, 103 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 318175f..ef5d726 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -70,6 +70,7 @@ config ARM64
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
+ select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_RCU_TABLE_FREE
select HAVE_SYSCALL_TRACEPOINTS
select IRQ_DOMAIN
diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index d6dd9fd..8f440e9 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -118,6 +118,8 @@ struct pt_regs {
u64 syscallno;
};
+#define MAX_REG_OFFSET (sizeof(struct user_pt_regs) - sizeof(u64))
Can you not use offset_of(struct user_pt_regs, pstate) here?
Yes, "offsetof" actually though. I've just made that change.
+
#define arch_has_single_step()(1)
#ifdef CONFIG_COMPAT
@@ -146,6 +148,29 @@ struct pt_regs {
#define user_stack_pointer(regs) \
(!compat_user_mode(regs) ? (regs)->sp : (regs)->compat_sp)
+/**
+ * regs_get_register() - get register value from its offset
+ * @regs: pt_regs from which register value is gotten
+ * @offset:offset number of the register.
+ *
+ * regs_get_register returns the value of a register whose offset from @regs.
+ * The @offset is the offset of the register in struct pt_regs.
+ * If @offset is bigger than MAX_REG_OFFSET, this returns 0.
+ */
+static inline u64 regs_get_register(struct pt_regs *regs,
+ unsigned int offset)
+{
+ if (unlikely(offset > MAX_REG_OFFSET))
+ return 0;
+ return *(u64 *)((u64)regs + offset);
+}
Is this guaranteed only to be called on kernel-mode regs, or do we need
to deal with compat tasks too?
If I understand the question I think it's fine that it only deals with
kernel-mode registers. The implemenation is functionally similar to the
other five architectures that implement it.
+
+/* Valid only for Kernel mode traps. */
+static inline unsigned long kernel_stack_pointer(struct pt_regs *regs)
+{
+ return regs->sp;
+}
+
static inline unsigned long regs_return_value(struct pt_regs *regs)
{
return regs->regs[0];
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index d882b83..f6199a5 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -48,6 +48,83 @@
#define CREATE_TRACE_POINTS
#include
+#define ARM_pstate pstate
+#define ARM_pc pc
+#define ARM_sp sp
+#define ARM_x30regs[30]
+#define ARM_x29regs[29]
+#define ARM_x28regs[28]
+#define ARM_x27regs[27]
+#define ARM_x26regs[26]
+#define ARM_x25regs[25]
+#define ARM_x24regs[24]
+#define ARM_x23regs[23]
+#define ARM_x22regs[22]
+#define ARM_x21regs[21]
+#define ARM_x20regs[20]
+#define ARM_x19regs[19]
+#define ARM_x18regs[18]
+#define ARM_x17regs[17]
+#define ARM_x16regs[16]
+#define ARM_x15regs[15]
+#define ARM_x14regs[14]
+#define ARM_x13regs[13]
+#define ARM_x12regs[12]
+#define ARM_x11regs[11]
+#define ARM_x10regs[10]
+#define ARM_x9 regs[9]
+#define ARM_x8 regs[8]
+#define ARM_x7 regs[7]
+#define ARM_x6 regs[6]
+#define ARM_x5 regs[5]
+#define ARM_x4 regs[4]
+#define ARM_x3 regs[3]
+#define ARM_x2 regs[2]
+#define ARM_x1 regs[1]
+#define ARM_x0 regs[0]
I've said it before, but I really don't like these macros. I'd rather
rework the following REG_OFFSET_NAME to be GPR_OFFSET_NAME which could
prefix the "x" in the name field.
OK, I've ripped that out and replaced REG_OFFSET_NAME with
GPR_OFFSET_NAME, for the numbered registers. I'm using REGS_OFFSET_NAME
(defined for all architectures in my earlier cleanup patch) for the
non-numbered registers.
+
+#define REG_OFFSET_NAME(r) \
+ {.name = #r, .offset = offsetof(struct pt_regs, ARM_##r)}
+#define REG_OFFSET_END {.name = NULL, .offset = 0}
+
+const struct pt_regs_offset regs_offset_table[] = {
+ REG_OFFSET_NAME(x0),
+ REG_OFFSET_NAME(x1),
+ REG_OFFSET_NAME(x2),
+ REG_OFFSET_NAME(x3),
+ REG_OFFSET_NAME(x4),
+ REG_OFFSET_NAME(x5),
+
Re: [PATCH 2/2] zram: use crypto API to compress the page
On (08/13/15 11:24), Joonsoo Kim wrote: > Until now, zram uses compression algorithm through direct call > to core algorithm function, but, it has drawback that we need to add > compression algorithm manually to zram if needed. Without this work, > we cannot utilize various compression algorithms in the system. > Moreover, to add new compression algorithm, we need to know how to use it > and this is somewhat time-consuming. > I don't like this change, sorry. Here is why. One of the main reasons why I haven't implemented it using crypto API (and it was an option and I thought about it) was and still is the fact that crypto API requires tfm for both compress and decompress operations. And this is a show stopper. No matter how you implement it, it is slower than what we have by definition. Now zram_bvec_read() operations depends on: a) other read operations because read() path now use limited in size idle stream list b) write operations because write() path uses same idle streams list Literally, you change zram_bvec_read() from a fast zram_decompress_page(zram, uncmem, index); to a slow zstrm = zcomp_strm_find(zram->comp); zram_decompress_page(zram, zstrm, uncmem, index); zcomp_strm_release(zram->comp, zstrm); you either slow down both write() and read() if you use a single idle stream list for both read and write, or double the amount of memory used by idle streams if you decide to use separate read and write idle stream lists. I see no real reason to do either of those. I like that the existing read() is as fast as probably possible. -ss > When I tested new algorithms such as zlib, these problems make me hard > to test them. To prevent these problem in the future, I think that > using crypto API to compress the page is better approach and this patch > implements it. > > The reason we need to support vairous compression algorithms is that > zram's performance is highly depend on workload and compression algorithm > and architecture. Every compression algorithm has it's own strong point. > For example, zlib is the best for compression ratio, but, it's > (de)compression speed is rather slow. Against my expectation, in my kernel > build test with zram swap, in low-memory condition on x86, zlib shows best > performance than others. In this case, I guess that compression ratio is > the most important factor. Unlike this situation, on ARM, maybe fast > (de)compression speed is the most important because it's computation speed > is slower than x86. > > We can't expect what algorithm is the best fit for one's system, because > it needs too complex calculation. We need to test it in case by case and > easy to use new compression algorithm by this patch will help > that situation. > > Signed-off-by: Joonsoo Kim > --- > drivers/block/zram/Kconfig | 13 +-- > drivers/block/zram/Makefile| 4 +- > drivers/block/zram/zcomp.c | 87 > ++ > drivers/block/zram/zcomp.h | 34 + > drivers/block/zram/zcomp_lz4.c | 47 --- > drivers/block/zram/zcomp_lz4.h | 17 - > drivers/block/zram/zcomp_lzo.c | 47 --- > drivers/block/zram/zcomp_lzo.h | 17 - > drivers/block/zram/zram_drv.c | 28 +- > 9 files changed, 66 insertions(+), 228 deletions(-) > delete mode 100644 drivers/block/zram/zcomp_lz4.c > delete mode 100644 drivers/block/zram/zcomp_lz4.h > delete mode 100644 drivers/block/zram/zcomp_lzo.c > delete mode 100644 drivers/block/zram/zcomp_lzo.h > > diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig > index 386ba3d..36ec96f 100644 > --- a/drivers/block/zram/Kconfig > +++ b/drivers/block/zram/Kconfig > @@ -1,8 +1,7 @@ > config ZRAM > tristate "Compressed RAM block device support" > depends on BLOCK && SYSFS && ZSMALLOC > - select LZO_COMPRESS > - select LZO_DECOMPRESS > + select CRYPTO_LZO > default n > help > Creates virtual block devices called /dev/zramX (X = 0, 1, ...). > @@ -14,13 +13,3 @@ config ZRAM > disks and maybe many more. > > See zram.txt for more information. > - > -config ZRAM_LZ4_COMPRESS > - bool "Enable LZ4 algorithm support" > - depends on ZRAM > - select LZ4_COMPRESS > - select LZ4_DECOMPRESS > - default n > - help > - This option enables LZ4 compression algorithm support. Compression > - algorithm can be changed using `comp_algorithm' device attribute. > \ No newline at end of file > diff --git a/drivers/block/zram/Makefile b/drivers/block/zram/Makefile > index be0763f..9e2b79e 100644 > --- a/drivers/block/zram/Makefile > +++ b/drivers/block/zram/Makefile > @@ -1,5 +1,3 @@ > -zram-y := zcomp_lzo.o zcomp.o zram_drv.o > - > -zram-$(CONFIG_ZRAM_LZ4_COMPRESS) += zcomp_lz4.o > +zram-y := zcomp.o zram_drv.o > > obj-$(CONFIG_ZRAM) += zram.o > diff --git a/drivers/block/zram/zcomp.c
Re: [PATCH v5 3/3] arm64: dts: Add spi bus dts
> > + spi: spi@1100a000 {
> > + compatible = "mediatek,mt8173-spi";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0 0x1100a000 0 0x1000>;
> > + interrupts = ;
> > + clocks = < CLK_TOP_SPI_SEL>, <
> > CLK_TOP_SYSPLL3_D2>;
> > + clock-names = "spi-clk", "parent-clk";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_pins_a>;
> > + mediatek,pad-select = <0>;
>
> The pinctl and pad-select fields are board specific.
> Please move to mt8173-evb.dtsi, along with status = "okay";
>
OK, I will fix it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [Intel-gfx] [4.2-rc4] acpi|drm|i915: circular locking dependency: acpi_video_get_backlight_type
Hi, Ville
Have you reported this to the owner of the backlight core?
This looks like a bug that the backlight core should handle.
What intel backlight driver and acpi backlight driver have done here are just
invoking APIs provided by the backlight core.
So it is the duty of the backlight core to handle such kind of circular locking.
Thanks
-Lv
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Ville Syrj?l?
> Sent: Thursday, August 13, 2015 3:26 AM
>
> On Mon, Aug 10, 2015 at 08:29:00PM +0200, Sedat Dilek wrote:
> > On Sat, Aug 1, 2015 at 2:23 PM, Sedat Dilek wrote:
> > > On Mon, Jul 27, 2015 at 12:33 AM, Sedat Dilek
> > > wrote:
> > >> Hi,
> > >>
> > >> this my first build of a 4.2-rcN Linux-kernel and I see this...
> > >>
> > >
> > > Just FYI:
> > >
> > > I am *not* seeing this with drm-intel-nightly from below url.
> > >
> > > Also, I plan to test Linux v4.2-rc5.
> > >
> >
> > [ CC Linus ]
> >
> > Knock Knock Knock.
> >
> > This issue still remains here (with CONFIG_DRM_I915=m)...
> >
> > [ 18.269792] ==
> > [ 18.269798] [ INFO: possible circular locking dependency detected ]
> > [ 18.269805] 4.2.0-rc6-1-iniza-small #1 Not tainted
> > [ 18.269810] ---
> > [ 18.269816] modprobe/727 is trying to acquire lock:
> > [ 18.269822] (init_mutex){+.+.+.}, at: []
> > acpi_video_get_backlight_type+0x17/0x164 [video]
> > [ 18.269840]
> > [ 18.269840] but task is already holding lock:
> > [ 18.269848] (&(_notifier)->rwsem){..}, at:
> > [] __blocking_notifier_call_chain+0x39/0x70
> > [ 18.269864]
> > [ 18.269864] which lock already depends on the new lock.
> > [ 18.269864]
> > [ 18.269875]
> > [ 18.269875] the existing dependency chain (in reverse order) is:
> > [ 18.269884]
> > ...
> >
> > Full dmesg log and kernel-config attached.
> >
> > Shall I add Rusty and modules/modprobe folks?
>
> Just got back from vacation and was greeted by this same lockdep splat.
>
> On a hunch I reverted
>
> commit 93a291dfaf9c328ca5a9cea1733af1a128efe890
> Author: Hans de Goede
> Date: Tue Jun 16 16:27:52 2015 +0200
>
> ACPI / video: Move backlight notifier to video_detect.c
>
> and the problem seems to be gone. Hans, any thoughts?
>
> >
> > - Sedat -
> >
> > > - Sedat -
> > >
> > > [1]
> > > http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-08-01-unstable/
> > > [2]
> > > http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-08-01-unstable/linux-image-4.2.0-994-generic_4.2.0-
> 994.201508010158_amd64.deb
> > >
> > >> [ 24.001043] [drm] Memory usable by graphics device = 2048M
> > >> [ 24.001118] [drm] Replacing VGA console driver
> > >> [ 24.011642] [drm] Supports vblank timestamp caching Rev 2
> > >> (21.10.2013).
> > >> [ 24.011646] [drm] Driver supports precise vblank timestamp query.
> > >> [ 24.012480] vgaarb: device changed decodes:
> > >> PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
> > >> [ 24.028005]
> > >> [ 24.028014] ==
> > >> [ 24.028020] [ INFO: possible circular locking dependency detected ]
> > >> [ 24.028027] 4.2.0-rc4-1-iniza-small #1 Not tainted
> > >> [ 24.028032] ---
> > >> [ 24.028038] modprobe/740 is trying to acquire lock:
> > >> [ 24.028043] (init_mutex){+.+.+.}, at: []
> > >> acpi_video_get_backlight_type+0x17/0x164 [video]
> > >> [ 24.028060]
> > >> [ 24.028060] but task is already holding lock:
> > >> [ 24.028068] (&(_notifier)->rwsem){..}, at:
> > >> [] __blocking_notifier_call_chain+0x39/0x70
> > >> [ 24.028083]
> > >> [ 24.028083] which lock already depends on the new lock.
> > >> [ 24.028083]
> > >> [ 24.028095]
> > >> [ 24.028095] the existing dependency chain (in reverse order) is:
> > >> [ 24.028103]
> > >> [ 24.028103] -> #1 (&(_notifier)->rwsem){..}:
> > >> [ 24.028113][] lock_acquire+0xcf/0x280
> > >> [ 24.028121][] down_write+0x49/0x80
> > >> [ 24.028129][]
> > >> blocking_notifier_chain_register+0x21/0xb0
> > >> [ 24.028138][]
> > >> backlight_register_notifier+0x18/0x20
> > >> [ 24.028147][]
> > >> acpi_video_get_backlight_type+0xfa/0x164 [video]
> > >> [ 24.028158][] 0xa00a20e9
> > >> [ 24.028164][] do_one_initcall+0x88/0x1c0
> > >> [ 24.028172][] do_init_module+0x61/0x1ec
> > >> [ 24.028179][] load_module+0x2008/0x25c0
> > >> [ 24.028187][] SyS_init_module+0x126/0x140
> > >> [ 24.028194][]
> > >> entry_SYSCALL_64_fastpath+0x16/0x7a
> > >> [ 24.028202]
> > >> [ 24.028202] -> #0 (init_mutex){+.+.+.}:
> > >> [ 24.028211][] __lock_acquire+0x1f5d/0x21c0
> > >> [ 24.028218][] lock_acquire+0xcf/0x280
> > >> [ 24.028225][]
get_vmalloc_info() and /proc/meminfo insanely expensive
I just did some profiling of a simple "make test" in the git repo, and was surprised by the top kernel offender: get_vmalloc_info() showed up at roughly 4% cpu use. It turns out that bash ends up reading /proc/meminfo on every single activation, and "make test" is basically just running a huge collection of shell scripts. You can verify by just doing strace -o trace sh -c "echo" to see what bash does on your system. I suspect it's actually glibc, because a quick google finds the function "get_phys_pages()" that just looks at the "MemTotal" line (or possibly get_avphys_pageslooks at the MemFree" line). Ok, so bash is insane for caring so deeply that it does this regardless of anything else. But what else is new - user space does odd things. It's like a truism. My gut feel for this is that we should just rate-limit this and cache the vmalloc information for a fraction of a second or something. Maybe we could expose total memory sizes in some more efficient format, but it's not like existing binaries will magically de-crapify themselves, so just speeding up meminfo sounds like a good thing. Maybe we could even cache the whole seqfile buffer - Al? How painful would something like that be? Although from the profiles, it's really just the vmalloc info gathering that shows up as actually wasting CPU cycles.. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
On Wed, 12 Aug 2015 15:20:54 -0700 Andy Lutomirski wrote: > On 08/12/2015 08:49 AM, Linus Torvalds wrote: > > On Tue, Aug 11, 2015 at 11:24 PM, Christoph Hellwig > > wrote: > >> > >> Maybe it's time to rely on gcc to handle 64 bit divisions now? > > > > Ugh. gcc still does a pretty horrible job at it. While gcc knows that > > a widening 32x32->64 multiplication can be simplified, it doesn't do > > the same thing for a 64/32->64 division, and always calls __udivdi3 > > for it. > > > > Now, __udivdi3 does avoid the general nasty case by then testing the > > upper 32 bits of the divisor against zero, so it's not entirely > > disastrous. It's just ugly. > > > > But perhaps more importantly, I'm not at all sure libgcc is > > kernel-safe. In particular, I'm not at all sure it *remains* > > kernel-safe. Just as an example: can you guarantee that libgcc doesn't > > implement integer division on some architecture by using the FP > > hardware? > > > > There's been a few cases where not having libgcc saved us headaches. I > > forget the exact details, but it was something like several years ago > > that we had gcc start to generate some insane crap exception handling > > for C code generation, and the fact that we didn't include libgcc was > > what made us catch it because of the resulting link error. > > > > libgcc just isn't reliable in kernel space. I'm not opposed to some > > random architecture using it (arch/tile does include "-lgcc" for > > example), but I _do_ object to the notion that we say "let's use > > libgcc in general". > > > > So no. I do not believe that the occasional pain of a few people who > > do 64-bit divides incorrectly is a good enough argument to start using > > libgcc. > > > > Does your objection still apply if we supplied our own implementations > of a handful of libgcc helpers? It's not just a matter of "how fast is the divide". The 32-bit build error is supposed to prompt people to ask "did I really need to use 64 bits". That *used* to work. A bit. But nowadays the errors are detected so late that the fix (often by someone other than the original developer) is to just slap a do_div() in there. And as the build error no longer appears to be having the desired effect, I too have been wondering if it's time to just give up and implement __udivdi and friends. Or maybe there's a way of breaking 64-bit builds instead ;) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 09/16] PM / hibernate: Reserve hibernation key and erase footprints
Hi Yu,
Thanks for your reviewing.
On Thu, Aug 13, 2015 at 02:45:32AM +, Chen, Yu C wrote:
> Hi Chun-yi,
> On Tue, 2015-08-11 at 14:16 +0800, Lee, Chun-Yi wrote:
>
> > +/* A page used to keep hibernation keys */
> > +static struct hibernation_keys *hibernation_keys;
> > +
> > +void __init parse_hibernation_keys(u64 phys_addr, u32 data_len)
> > +{
> > + struct setup_data *hibernation_setup_data;
> > +
> > + /* Reserve keys memory, will copy and erase in init_hibernation_keys()
> > */
> > + keys_phys_addr = phys_addr + sizeof(struct setup_data);
> > + memblock_reserve(keys_phys_addr, sizeof(struct hibernation_keys));
> > +
> > + /* clear hibernation_data */
> > + hibernation_setup_data = early_memremap(phys_addr, data_len);
> > + if (!hibernation_setup_data)
> > + return;
> > +
> should we invoke memblock_free if early_memremap failed?
>
> Best Regards,
> Yu
>
>
Should not free memblock reservation of key data.
Using memblock_reserve is for reserve hibernation key until
init_hibernation_keys() copy key data to arbitrary allocated page.
Using early_memremap is for cleaning the setup_data header that's
used to carry key. That above 2 actions are different purposes.
So, even the action of cleaning setup_data failed, it doesn't
affect to the action for reserve hibernation key by memblock until
copy it.
Thanks a lot!
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/5] pwm: add the Berlin pwm controller driver
Dear Antoine,
On Wed, 12 Aug 2015 15:51:33 +0200
Antoine Tenart wrote:
> Add a PWM controller driver for the Marvell Berlin SoCs. This PWM
> controller has 4 channels.
>
> Signed-off-by: Antoine Tenart
> ---
> drivers/pwm/Kconfig | 9 ++
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-berlin.c | 227
> +++
> 3 files changed, 237 insertions(+)
> create mode 100644 drivers/pwm/pwm-berlin.c
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index b1541f40fd8d..1773da8145b8 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -92,6 +92,15 @@ config PWM_BCM2835
> To compile this driver as a module, choose M here: the module
> will be called pwm-bcm2835.
>
> +config PWM_BERLIN
> + tristate "Berlin PWM support"
> + depends on ARCH_BERLIN
> + help
> + PWM framework driver for Berlin.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called pwm-berlin.
> +
> config PWM_BFIN
> tristate "Blackfin PWM support"
> depends on BFIN_GPTIMERS
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index ec50eb5b5a8f..670c5fce8bbb 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -6,6 +6,7 @@ obj-$(CONFIG_PWM_ATMEL_HLCDC_PWM) += pwm-atmel-hlcdc.o
> obj-$(CONFIG_PWM_ATMEL_TCB) += pwm-atmel-tcb.o
> obj-$(CONFIG_PWM_BCM_KONA) += pwm-bcm-kona.o
> obj-$(CONFIG_PWM_BCM2835)+= pwm-bcm2835.o
> +obj-$(CONFIG_PWM_BERLIN) += pwm-berlin.o
> obj-$(CONFIG_PWM_BFIN) += pwm-bfin.o
> obj-$(CONFIG_PWM_CLPS711X) += pwm-clps711x.o
> obj-$(CONFIG_PWM_EP93XX) += pwm-ep93xx.o
> diff --git a/drivers/pwm/pwm-berlin.c b/drivers/pwm/pwm-berlin.c
> new file mode 100644
> index ..f89e25ea5c6d
> --- /dev/null
> +++ b/drivers/pwm/pwm-berlin.c
> @@ -0,0 +1,227 @@
> +/*
> + * Marvell Berlin PWM driver
> + *
> + * Copyright (C) 2015 Marvell Technology Group Ltd.
> + *
> + * Antoine Tenart
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define BERLIN_PWM_EN0x0
> +#define BERLIN_PWM_CONTROL 0x4
> +#define BERLIN_PWM_DUTY 0x8
> +#define BERLIN_PWM_TCNT 0xc
> +
> +#define BERLIN_PWM_ENABLEBIT(0)
> +#define BERLIN_PWM_DISABLE 0x0
> +#define BERLIN_PWM_INVERT_POLARITY BIT(3)
> +#define BERLIN_PWM_PRESCALE_MASK 0x7
> +#define BERLIN_PWM_PRESCALE_MAX 4096
> +#define BERLIN_PWM_MAX_TCNT 65535
> +
> +struct berlin_pwm_chip {
> + struct pwm_chip chip;
> + struct clk *clk;
> + void __iomem *base;
> + spinlock_t lock;
> +};
> +
> +#define to_berlin_pwm_chip(chip) \
> + container_of((chip), struct berlin_pwm_chip, chip)
> +
> +#define berlin_pwm_readl(chip, channel, offset) \
> + readl((chip)->base + (channel) * 0x10 + offset)
> +#define berlin_pwm_writel(val, chip, channel, offset)\
> + writel(val, (chip)->base + (channel) * 0x10 + offset)
It's better to use relaxed version. In some platforms with PL310 such as
BG2Q, the writel/readl will cost much time on spinning the lock if there's
heavy L2 cache maintenance ongoing, this time cost is not necessary.
And IIRC, in patch V2 review, Sebastian doesn't object to relaxed version.
Thanks,
Jisheng
> +
> +/* prescaler table: {1, 4, 8, 16, 64, 256, 1024, 4096} */
> +static const u32 prescaler_diff_table[] = {
> + 1, 4, 2, 2, 4, 4, 4, 4,
> +};
> +
> +static int berlin_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> + int duty_ns, int period_ns)
> +{
> + struct berlin_pwm_chip *berlin_chip = to_berlin_pwm_chip(chip);
> + int ret, prescale = 0;
> + u32 val, duty, period;
> + u64 cycles;
> +
> + cycles = clk_get_rate(berlin_chip->clk);
> + cycles *= period_ns;
> + do_div(cycles, NSEC_PER_SEC);
> +
> + while (cycles > BERLIN_PWM_MAX_TCNT)
> + do_div(cycles, prescaler_diff_table[++prescale]);
> +
> + if (cycles > BERLIN_PWM_MAX_TCNT)
> + return -EINVAL;
> +
> + period = cycles;
> + cycles *= duty_ns;
> + do_div(cycles, period_ns);
> + duty = cycles;
> +
> + ret = clk_prepare_enable(berlin_chip->clk);
> + if (ret)
> + return ret;
> +
> + spin_lock(_chip->lock);
> +
> + val = berlin_pwm_readl(berlin_chip, pwm->hwpwm, BERLIN_PWM_CONTROL);
> + val &= ~BERLIN_PWM_PRESCALE_MASK;
> + val |= prescale;
> + berlin_pwm_writel(val, berlin_chip, pwm->hwpwm, BERLIN_PWM_CONTROL);
> +
> + berlin_pwm_writel(duty, berlin_chip, pwm->hwpwm, BERLIN_PWM_DUTY);
> + berlin_pwm_writel(period,
Re: [PATCH 1/2] crypto: export crypto_alg_list and rwsem
On Thu, Aug 13, 2015 at 11:24:13AM +0900, Joonsoo Kim wrote: > Until now, zram uses compression algorithm through direct call > to core algorithm function, but, it has drawback that we need to add > compression algorithm manually to zram. If we don't do that, we cannot > utilize various compression algorithms in the system. To improve this > situation, zram will be changed to use crypto subsystem in following > patch. There is one problem with this change. Zram has a interface > that what compression algorithm it can support. Although crypto subsystem > has /proc interface to search all of crypto algorithm, but, there is > no way to get just compression algorithm in cryto subsystem. To implement > it on zram-side, crypto_alg_list and rwsem should be exported so > this patch do it. > > Signed-off-by: Joonsoo Kim Nack. We already have a netlink interface that can be used to query algorithms and the type information is present in the report. The interface is crypto_user and should be used instead of exporting the raw list. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] MODSIGN: Use PKCS#7 for module signatures [ver #8]
Okay, I've fixed both of those bugs with patches tagged on the end of the commit sequence. Here's a revised pull request with a new tag. Do you want me to generate a complete new request message? David --- The following changes since commit 459c15e53cf7e4e88a78ecfb109af5a267c5500a: Merge tag 'asn1-fixes-20150805' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs into next (2015-08-07 13:27:58 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git tags/modsign-pkcs7-20150812-3 for you to fetch changes up to e9a5e8cc55286941503f36c5b7485a5aa923b3f1: sign-file: Fix warning about BIO_reset() return value (2015-08-13 04:03:12 +0100) Module signing with PKCS#7 David Howells (19): ASN.1: Add an ASN.1 compiler option to dump the element tree ASN.1: Copy string names to tokens in ASN.1 compiler X.509: Extract both parts of the AuthorityKeyIdentifier X.509: Support X.509 lookup by Issuer+Serial form AuthorityKeyIdentifier PKCS#7: Allow detached data to be supplied for signature checking purposes MODSIGN: Provide a utility to append a PKCS#7 signature to a module MODSIGN: Use PKCS#7 messages as module signatures system_keyring.c doesn't need to #include module-internal.h MODSIGN: Extract the blob PKCS#7 signature verifier from module signing PKCS#7: Check content type and versions X.509: Change recorded SKID & AKID to not include Subject or Issuer PKCS#7: Support CMS messages also [RFC5652] sign-file: Generate CMS message as signature instead of PKCS#7 PKCS#7: Improve and export the X.509 ASN.1 time object decoder KEYS: Add a name for PKEY_ID_PKCS7 PKCS#7: Appropriately restrict authenticated attributes and content type sign-file: Document dependency on OpenSSL devel libraries PKCS#7: Add MODULE_LICENSE() to test module sign-file: Fix warning about BIO_reset() return value David Woodhouse (9): modsign: Abort modules_install when signing fails modsign: Allow password to be specified for signing key modsign: Allow signing key to be PKCS#11 modsign: Allow external signing key to be specified modsign: Extract signing cert from CONFIG_MODULE_SIG_KEY if needed modsign: Use single PEM file for autogenerated key modsign: Add explicit CONFIG_SYSTEM_TRUSTED_KEYS option extract-cert: Cope with multiple X.509 certificates in a single file modsign: Use extract-cert to process CONFIG_SYSTEM_TRUSTED_KEYS Luis R. Rodriguez (1): sign-file: Add option to only create signature file .gitignore| 1 + Documentation/kbuild/kbuild.txt | 5 + Documentation/module-signing.txt | 54 +++- Makefile | 8 +- arch/x86/kernel/kexec-bzimage64.c | 4 +- crypto/asymmetric_keys/Makefile | 8 +- crypto/asymmetric_keys/asymmetric_type.c | 11 + crypto/asymmetric_keys/pkcs7.asn1 | 22 +- crypto/asymmetric_keys/pkcs7_key_type.c | 17 +- crypto/asymmetric_keys/pkcs7_parser.c | 269 ++- crypto/asymmetric_keys/pkcs7_parser.h | 20 +- crypto/asymmetric_keys/pkcs7_trust.c | 10 +- crypto/asymmetric_keys/pkcs7_verify.c | 145 -- crypto/asymmetric_keys/public_key.c | 1 + crypto/asymmetric_keys/verify_pefile.c| 7 +- crypto/asymmetric_keys/x509_akid.asn1 | 35 +++ crypto/asymmetric_keys/x509_cert_parser.c | 231 ++-- crypto/asymmetric_keys/x509_parser.h | 12 +- crypto/asymmetric_keys/x509_public_key.c | 95 --- include/crypto/pkcs7.h| 13 +- include/crypto/public_key.h | 18 +- include/keys/system_keyring.h | 7 + include/linux/oid_registry.h | 4 +- include/linux/verify_pefile.h | 6 +- init/Kconfig | 59 - kernel/Makefile | 112 +--- kernel/module_signing.c | 213 ++- kernel/system_certificates.S | 3 + kernel/system_keyring.c | 53 +++- scripts/Makefile | 4 + scripts/Makefile.modinst | 2 +- scripts/asn1_compiler.c | 229 ++-- scripts/extract-cert.c| 166 scripts/sign-file | 421 -- scripts/sign-file.c | 260 ++ 35 files changed, 1597 insertions(+), 928 deletions(-) create mode 100644 crypto/asymmetric_keys/x509_akid.asn1 create mode 100644 scripts/extract-cert.c delete mode 100755 scripts/sign-file create mode 100755 scripts/sign-fi
[PATCH v5 1/5] mm: move __phys_to_pfn and __pfn_to_phys to asm/generic/memory_model.h
From: Christoph Hellwig Three architectures already define these, and we'll need them genericly soon. Signed-off-by: Christoph Hellwig Signed-off-by: Dan Williams --- arch/arm/include/asm/memory.h |6 -- arch/arm64/include/asm/memory.h |6 -- arch/unicore32/include/asm/memory.h |6 -- include/asm-generic/memory_model.h |6 ++ 4 files changed, 6 insertions(+), 18 deletions(-) diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h index b7f6fb462ea0..98d58bb04ac5 100644 --- a/arch/arm/include/asm/memory.h +++ b/arch/arm/include/asm/memory.h @@ -119,12 +119,6 @@ #endif /* - * Convert a physical address to a Page Frame Number and back - */ -#define__phys_to_pfn(paddr)((unsigned long)((paddr) >> PAGE_SHIFT)) -#define__pfn_to_phys(pfn) ((phys_addr_t)(pfn) << PAGE_SHIFT) - -/* * Convert a page to/from a physical address */ #define page_to_phys(page) (__pfn_to_phys(page_to_pfn(page))) diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h index f800d45ea226..d808bb688751 100644 --- a/arch/arm64/include/asm/memory.h +++ b/arch/arm64/include/asm/memory.h @@ -81,12 +81,6 @@ #define __phys_to_virt(x) ((unsigned long)((x) - PHYS_OFFSET + PAGE_OFFSET)) /* - * Convert a physical address to a Page Frame Number and back - */ -#define__phys_to_pfn(paddr)((unsigned long)((paddr) >> PAGE_SHIFT)) -#define__pfn_to_phys(pfn) ((phys_addr_t)(pfn) << PAGE_SHIFT) - -/* * Convert a page to/from a physical address */ #define page_to_phys(page) (__pfn_to_phys(page_to_pfn(page))) diff --git a/arch/unicore32/include/asm/memory.h b/arch/unicore32/include/asm/memory.h index debafc40200a..3bb0a29fd2d7 100644 --- a/arch/unicore32/include/asm/memory.h +++ b/arch/unicore32/include/asm/memory.h @@ -61,12 +61,6 @@ #endif /* - * Convert a physical address to a Page Frame Number and back - */ -#define__phys_to_pfn(paddr)((paddr) >> PAGE_SHIFT) -#define__pfn_to_phys(pfn) ((pfn) << PAGE_SHIFT) - -/* * Convert a page to/from a physical address */ #define page_to_phys(page) (__pfn_to_phys(page_to_pfn(page))) diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_model.h index 14909b0b9cae..f20f407ce45d 100644 --- a/include/asm-generic/memory_model.h +++ b/include/asm-generic/memory_model.h @@ -69,6 +69,12 @@ }) #endif /* CONFIG_FLATMEM/DISCONTIGMEM/SPARSEMEM */ +/* + * Convert a physical address to a Page Frame Number and back + */ +#define__phys_to_pfn(paddr)((unsigned long)((paddr) >> PAGE_SHIFT)) +#define__pfn_to_phys(pfn) ((pfn) << PAGE_SHIFT) + #define page_to_pfn __page_to_pfn #define pfn_to_page __pfn_to_page -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 3/5] dax: drop size parameter to ->direct_access()
None of the implementations currently use it. The common
bdev_direct_access() entry point handles all the size checks before
calling ->direct_access().
Signed-off-by: Christoph Hellwig
Signed-off-by: Dan Williams
---
arch/powerpc/sysdev/axonram.c |2 +-
drivers/block/brd.c |6 +-
drivers/nvdimm/pmem.c |2 +-
drivers/s390/block/dcssblk.c |4 ++--
fs/block_dev.c|2 +-
include/linux/blkdev.h|2 +-
6 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/sysdev/axonram.c b/arch/powerpc/sysdev/axonram.c
index ee90db17b097..e8657d3bc588 100644
--- a/arch/powerpc/sysdev/axonram.c
+++ b/arch/powerpc/sysdev/axonram.c
@@ -141,7 +141,7 @@ axon_ram_make_request(struct request_queue *queue, struct
bio *bio)
*/
static long
axon_ram_direct_access(struct block_device *device, sector_t sector,
- void **kaddr, unsigned long *pfn, long size)
+ void **kaddr, unsigned long *pfn)
{
struct axon_ram_bank *bank = device->bd_disk->private_data;
loff_t offset = (loff_t)sector << AXON_RAM_SECTOR_SHIFT;
diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index 64ab4951e9d6..41528857c70d 100644
--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -371,7 +371,7 @@ static int brd_rw_page(struct block_device *bdev, sector_t
sector,
#ifdef CONFIG_BLK_DEV_RAM_DAX
static long brd_direct_access(struct block_device *bdev, sector_t sector,
- void **kaddr, unsigned long *pfn, long size)
+ void **kaddr, unsigned long *pfn)
{
struct brd_device *brd = bdev->bd_disk->private_data;
struct page *page;
@@ -384,10 +384,6 @@ static long brd_direct_access(struct block_device *bdev,
sector_t sector,
*kaddr = page_address(page);
*pfn = page_to_pfn(page);
- /*
-* TODO: If size > PAGE_SIZE, we could look to see if the next page in
-* the file happens to be mapped to the next page of physical RAM.
-*/
return PAGE_SIZE;
}
#else
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index eb7552d939e1..5e019a6942ce 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -92,7 +92,7 @@ static int pmem_rw_page(struct block_device *bdev, sector_t
sector,
}
static long pmem_direct_access(struct block_device *bdev, sector_t sector,
- void **kaddr, unsigned long *pfn, long size)
+ void **kaddr, unsigned long *pfn)
{
struct pmem_device *pmem = bdev->bd_disk->private_data;
size_t offset = sector << 9;
diff --git a/drivers/s390/block/dcssblk.c b/drivers/s390/block/dcssblk.c
index da212813f2d5..2f1734ba0e22 100644
--- a/drivers/s390/block/dcssblk.c
+++ b/drivers/s390/block/dcssblk.c
@@ -29,7 +29,7 @@ static int dcssblk_open(struct block_device *bdev, fmode_t
mode);
static void dcssblk_release(struct gendisk *disk, fmode_t mode);
static void dcssblk_make_request(struct request_queue *q, struct bio *bio);
static long dcssblk_direct_access(struct block_device *bdev, sector_t secnum,
-void **kaddr, unsigned long *pfn, long size);
+void **kaddr, unsigned long *pfn);
static char dcssblk_segments[DCSSBLK_PARM_LEN] = "\0";
@@ -879,7 +879,7 @@ fail:
static long
dcssblk_direct_access (struct block_device *bdev, sector_t secnum,
- void **kaddr, unsigned long *pfn, long size)
+ void **kaddr, unsigned long *pfn)
{
struct dcssblk_dev_info *dev_info;
unsigned long offset, dev_sz;
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 198243717da5..3a8ac7edfbf4 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -462,7 +462,7 @@ long bdev_direct_access(struct block_device *bdev, sector_t
sector,
sector += get_start_sect(bdev);
if (sector % (PAGE_SIZE / 512))
return -EINVAL;
- avail = ops->direct_access(bdev, sector, addr, pfn, size);
+ avail = ops->direct_access(bdev, sector, addr, pfn);
if (!avail)
return -ERANGE;
return min(avail, size);
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index d4068c17d0df..ff47d5498133 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1556,7 +1556,7 @@ struct block_device_operations {
int (*ioctl) (struct block_device *, fmode_t, unsigned, unsigned long);
int (*compat_ioctl) (struct block_device *, fmode_t, unsigned, unsigned
long);
long (*direct_access)(struct block_device *, sector_t,
- void **, unsigned long *pfn, long size);
+ void **, unsigned long *pfn);
unsigned int (*check_events) (struct gendisk *disk,
unsigned int clearing);
/* ->media_changed() is DEPRECATED, use
[PATCH v5 5/5] scatterlist: convert to __pfn_t
__pfn_t has flags for sg_chain and sg_last, use it to replace the
(struct page *) entry in struct scatterlist.
Signed-off-by: Dan Williams
---
include/linux/mm.h |9 +++
include/linux/scatterlist.h | 111 ++-
samples/kfifo/dma-example.c |8 ++-
3 files changed, 91 insertions(+), 37 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index c4683ea2fcab..348f69467f54 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -992,6 +992,15 @@ static inline __pfn_t page_to_pfn_t(struct page *page)
return pfn;
}
+static inline __pfn_t nth_pfn(__pfn_t pfn, unsigned int n)
+{
+ __pfn_t ret;
+
+ ret.val = (__pfn_t_to_pfn(pfn) + n) << PAGE_SHIFT
+ | (pfn.val & PFN_MASK);
+ return ret;
+}
+
/*
* Some inline functions in vmstat.h depend on page_zone()
*/
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index 698e906ca730..c612599bb155 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -11,7 +11,7 @@ struct scatterlist {
#ifdef CONFIG_DEBUG_SG
unsigned long sg_magic;
#endif
- unsigned long page_link;
+ __pfn_t pfn;
unsigned intoffset;
unsigned intlength;
dma_addr_t dma_address;
@@ -44,14 +44,14 @@ struct sg_table {
/*
* Notes on SG table design.
*
- * We use the unsigned long page_link field in the scatterlist struct to place
+ * We use the __pfn_t pfn field in the scatterlist struct to place
* the page pointer AND encode information about the sg table as well. The two
* lower bits are reserved for this information.
*
- * If bit 0 is set, then the page_link contains a pointer to the next sg
+ * If PFN_SG_CHAIN is set, then the pfn contains a pointer to the next sg
* table list. Otherwise the next entry is at sg + 1.
*
- * If bit 1 is set, then this sg entry is the last element in a list.
+ * If PFN_SG_LAST is set, then this sg entry is the last element in a list.
*
* See sg_next().
*
@@ -64,10 +64,31 @@ struct sg_table {
* a valid sg entry, or whether it points to the start of a new scatterlist.
* Those low bits are there for everyone! (thanks mason :-)
*/
-#define sg_is_chain(sg)((sg)->page_link & 0x01)
-#define sg_is_last(sg) ((sg)->page_link & 0x02)
-#define sg_chain_ptr(sg) \
- ((struct scatterlist *) ((sg)->page_link & ~0x03))
+static inline bool sg_is_chain(struct scatterlist *sg)
+{
+ return (sg->pfn.val & PFN_SG_CHAIN) == PFN_SG_CHAIN;
+}
+
+static inline bool sg_is_last(struct scatterlist *sg)
+{
+ return (sg->pfn.val & PFN_SG_LAST) == PFN_SG_LAST;
+}
+
+static inline struct scatterlist *sg_chain_ptr(struct scatterlist *sg)
+{
+ return (struct scatterlist *) (sg->pfn.val
+ & ~(PFN_SG_CHAIN | PFN_SG_LAST));
+}
+
+static inline void sg_assign_pfn(struct scatterlist *sg, __pfn_t pfn)
+{
+#ifdef CONFIG_DEBUG_SG
+ BUG_ON(sg->sg_magic != SG_MAGIC);
+ BUG_ON(sg_is_chain(sg));
+#endif
+ pfn.val &= ~PFN_SG_LAST;
+ sg->pfn.val = (sg->pfn.val & PFN_SG_LAST) | pfn.val;
+}
/**
* sg_assign_page - Assign a given page to an SG entry
@@ -81,18 +102,20 @@ struct sg_table {
**/
static inline void sg_assign_page(struct scatterlist *sg, struct page *page)
{
- unsigned long page_link = sg->page_link & 0x3;
+ __pfn_t pfn = page_to_pfn_t(page);
- /*
-* In order for the low bit stealing approach to work, pages
-* must be aligned at a 32-bit boundary as a minimum.
-*/
- BUG_ON((unsigned long) page & 0x03);
-#ifdef CONFIG_DEBUG_SG
- BUG_ON(sg->sg_magic != SG_MAGIC);
- BUG_ON(sg_is_chain(sg));
-#endif
- sg->page_link = page_link | (unsigned long) page;
+ /* check that a __pfn_t has enough bits to encode a page */
+ BUG_ON(pfn.val & (PFN_SG_LAST | PFN_SG_CHAIN));
+
+ sg_assign_pfn(sg, pfn);
+}
+
+static inline void sg_set_pfn(struct scatterlist *sg, __pfn_t pfn,
+ unsigned int len, unsigned int offset)
+{
+ sg_assign_pfn(sg, pfn);
+ sg->offset = offset;
+ sg->length = len;
}
/**
@@ -112,18 +135,34 @@ static inline void sg_assign_page(struct scatterlist *sg,
struct page *page)
static inline void sg_set_page(struct scatterlist *sg, struct page *page,
unsigned int len, unsigned int offset)
{
- sg_assign_page(sg, page);
- sg->offset = offset;
- sg->length = len;
+ sg_set_pfn(sg, page_to_pfn_t(page), len, offset);
+}
+
+static inline bool sg_has_page(struct scatterlist *sg)
+{
+ return __pfn_t_has_page(sg->pfn);
}
static inline struct page *sg_page(struct scatterlist *sg)
{
+ __pfn_t pfn = sg->pfn;
+ struct page *page;
+
+ WARN_ONCE(!sg_has_page(sg), "scatterlist references unmapped memory\n");
+
#ifdef CONFIG_DEBUG_SG
BUG_ON(sg->sg_magic != SG_MAGIC);
[PATCH v5 4/5] dax: fix mapping lifetime handling, convert to __pfn_t + kmap_atomic_pfn_t()
The primary source for non-page-backed page-frames to enter the system
is via the pmem driver's ->direct_access() method. The pfns returned by
the top-level bdev_direct_access() may be passed to any other subsystem
in the kernel and those sub-systems either need to assume that the pfn
is page backed (CONFIG_DEV_PFN=n) or be prepared to handle non-page
backed case (CONFIG_DEV_PFN=y). Currently the pfns returned by
->direct_access() are only ever used by vm_insert_mixed() which does not
care if the pfn is mapped. As we go to add more usages of these pfns
add the type-safety of __pfn_t.
This also simplifies the calling convention of ->direct_access() by not
returning the virtual address in the same call. This annotates cases
where the kernel is directly accessing pmem outside the driver, and
makes the valid lifetime of the reference explicit. This property may
be useful in the future for invalidating mappings to pmem, but for now
it provides some protection against the "pmem disable vs still-in-use"
race.
Note that axon_ram_direct_access and dcssblk_direct_access were
previously making potentially incorrect assumptions about the addresses
they passed to virt_to_phys().
[hch: various minor updates]
Signed-off-by: Christoph Hellwig
Signed-off-by: Dan Williams
---
arch/powerpc/platforms/Kconfig |1 +
arch/powerpc/sysdev/axonram.c | 24
drivers/block/brd.c|5 +--
drivers/nvdimm/Kconfig |1 +
drivers/nvdimm/pmem.c | 24 +++-
drivers/s390/block/Kconfig |1 +
drivers/s390/block/dcssblk.c | 23 ++--
fs/Kconfig |1 +
fs/block_dev.c |4 +-
fs/dax.c | 79 +---
include/linux/blkdev.h |7 ++--
include/linux/mm.h | 12 ++
12 files changed, 129 insertions(+), 53 deletions(-)
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index b7f9c408bf24..6b1c2f2e5fb4 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -307,6 +307,7 @@ config CPM2
config AXON_RAM
tristate "Axon DDR2 memory device driver"
depends on PPC_IBM_CELL_BLADE && BLOCK
+ select KMAP_PFN
default m
help
It registers one block device per Axon's DDR2 memory bank found
diff --git a/arch/powerpc/sysdev/axonram.c b/arch/powerpc/sysdev/axonram.c
index e8657d3bc588..7c5a1563c0fd 100644
--- a/arch/powerpc/sysdev/axonram.c
+++ b/arch/powerpc/sysdev/axonram.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include
#include
@@ -141,14 +142,12 @@ axon_ram_make_request(struct request_queue *queue, struct
bio *bio)
*/
static long
axon_ram_direct_access(struct block_device *device, sector_t sector,
- void **kaddr, unsigned long *pfn)
+ __pfn_t *pfn)
{
struct axon_ram_bank *bank = device->bd_disk->private_data;
loff_t offset = (loff_t)sector << AXON_RAM_SECTOR_SHIFT;
- *kaddr = (void *)(bank->ph_addr + offset);
- *pfn = virt_to_phys(*kaddr) >> PAGE_SHIFT;
-
+ *pfn = phys_to_pfn_t(bank->ph_addr + offset, PFN_DEV);
return bank->size - offset;
}
@@ -165,9 +164,13 @@ static int axon_ram_probe(struct platform_device *device)
{
static int axon_ram_bank_id = -1;
struct axon_ram_bank *bank;
- struct resource resource;
+ struct resource *resource;
int rc = 0;
+ resource = devm_kzalloc(>dev, sizeof(*resource), GFP_KERNEL);
+ if (!resource)
+ return -ENOMEM;
+
axon_ram_bank_id++;
dev_info(>dev, "Found memory controller on %s\n",
@@ -184,13 +187,13 @@ static int axon_ram_probe(struct platform_device *device)
bank->device = device;
- if (of_address_to_resource(device->dev.of_node, 0, ) != 0) {
+ if (of_address_to_resource(device->dev.of_node, 0, resource) != 0) {
dev_err(>dev, "Cannot access device tree\n");
rc = -EFAULT;
goto failed;
}
- bank->size = resource_size();
+ bank->size = resource_size(resource);
if (bank->size == 0) {
dev_err(>dev, "No DDR2 memory found for %s%d\n",
@@ -202,7 +205,7 @@ static int axon_ram_probe(struct platform_device *device)
dev_info(>dev, "Register DDR2 memory device %s%d with %luMB\n",
AXON_RAM_DEVICE_NAME, axon_ram_bank_id, bank->size >>
20);
- bank->ph_addr = resource.start;
+ bank->ph_addr = resource->start;
bank->io_addr = (unsigned long) ioremap_prot(
bank->ph_addr, bank->size, _PAGE_NO_CACHE);
if (bank->io_addr == 0) {
@@ -211,6 +214,11 @@ static int axon_ram_probe(struct platform_device *device)
goto failed;
}
+ rc = devm_register_kmap_pfn_range(>dev, resource,
+
[PATCH v5 2/5] allow mapping page-less memremaped areas into KVA
Introduce a type that encapsulates a page-frame-number that can also be
used to encode other information. This other information is the
traditional "page_link" encoding in a scatterlist, but can also denote
"device memory". Where "device memory" is a set of pfns that are not
part of the kernel's linear mapping, but are accessed via the same
memory controller as ram. The motivation for this conversion is large
capacity persistent memory that does not enjoy struct page coverage,
entries in 'memmap' by default.
This type will be used in replace usage of 'struct page *' in cases
where only a pfn is required, i.e. scatterlists for drivers, dma mapping
api, and potentially biovecs for the block layer. The operations in
those i/o paths that formerly required a 'struct page *' are converted
to use __pfn_t aware equivalent helpers.
It turns out that while 'struct page' references are used broadly in the
kernel I/O stacks the usage of 'struct page' based capabilities is very
shallow for block-i/o. It is only used for populating bio_vecs and
scatterlists for the retrieval of dma addresses, and for temporary
kernel mappings (kmap). Aside from kmap, these usages can be trivially
converted to operate on a pfn.
Indeed, kmap_atomic() is more problematic as it uses mm infrastructure,
via struct page, to setup and track temporary kernel mappings. It would
be unfortunate if the kmap infrastructure escaped its 32-bit/HIGHMEM
bonds and leaked into 64-bit code. Thankfully, it seems all that is
needed here is to convert kmap_atomic() callers, that want to opt-in to
supporting persistent memory, to use a new kmap_atomic_pfn_t(). Where
kmap_atomic_pfn_t() is enabled to re-use the existing ioremap() mapping
established by the driver for persistent memory.
Note, that as far as conceptually understanding __pfn_t is concerned,
'persistent memory' is really any address range in host memory not
covered by memmap. Contrast this with pure iomem that is on an mmio
mapped bus like PCI and cannot be converted to a dma_addr_t by "pfn <<
PAGE_SHIFT".
It would be unfortunate if the kmap infrastructure escaped its current
32-bit/HIGHMEM bonds and leaked into 64-bit code. Instead, if the user
has enabled CONFIG_DEV_PFN we direct the kmap_atomic_pfn_t()
implementation to scan a list of pre-mapped persistent memory address
ranges inserted by the pmem driver.
The __pfn_t to resource lookup is indeed inefficient walking of a linked list,
but there are two mitigating factors:
1/ The number of persistent memory ranges is bounded by the number of
DIMMs which is on the order of 10s of DIMMs, not hundreds.
2/ The lookup yields the entire range, if it becomes inefficient to do a
kmap_atomic_pfn_t() a PAGE_SIZE at a time the caller can take
advantage of the fact that the lookup can be amortized for all kmap
operations it needs to perform in a given range.
[hch: various changes]
Signed-off-by: Christoph Hellwig
Signed-off-by: Dan Williams
---
include/linux/kmap_pfn.h | 31
include/linux/mm.h | 57 ++
mm/Kconfig |3 +
mm/Makefile |1
mm/kmap_pfn.c| 117 ++
5 files changed, 209 insertions(+)
create mode 100644 include/linux/kmap_pfn.h
create mode 100644 mm/kmap_pfn.c
diff --git a/include/linux/kmap_pfn.h b/include/linux/kmap_pfn.h
new file mode 100644
index ..fa44971d8e95
--- /dev/null
+++ b/include/linux/kmap_pfn.h
@@ -0,0 +1,31 @@
+#ifndef _LINUX_KMAP_PFN_H
+#define _LINUX_KMAP_PFN_H 1
+
+#include
+
+struct device;
+struct resource;
+#ifdef CONFIG_KMAP_PFN
+extern void *kmap_atomic_pfn_t(__pfn_t pfn);
+extern void kunmap_atomic_pfn_t(void *addr);
+extern int devm_register_kmap_pfn_range(struct device *dev,
+ struct resource *res, void *base);
+#else
+static inline void *kmap_atomic_pfn_t(__pfn_t pfn)
+{
+ return kmap_atomic(__pfn_t_to_page(pfn));
+}
+
+static inline void kunmap_atomic_pfn_t(void *addr)
+{
+ __kunmap_atomic(addr);
+}
+
+static inline int devm_register_kmap_pfn_range(struct device *dev,
+ struct resource *res, void *base)
+{
+ return 0;
+}
+#endif /* CONFIG_KMAP_PFN */
+
+#endif /* _LINUX_KMAP_PFN_H */
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 84b05ebedb2d..57ba5ca6be72 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -924,6 +924,63 @@ static inline void set_page_links(struct page *page, enum
zone_type zone,
}
/*
+ * __pfn_t: encapsulates a page-frame number that is optionally backed
+ * by memmap (struct page). This type will be used in place of a
+ * 'struct page *' instance in contexts where unmapped memory (usually
+ * persistent memory) is being referenced (scatterlists for drivers,
+ * biovecs for the block layer, etc). Whether a __pfn_t has a struct
+ * page backing is indicated by flags in the low bits of the value;
+ */
+typedef struct {
+ unsigned long val;
+}
[PATCH v5 0/5] introduce __pfn_t for unmapped pfn I/O and DAX lifetime
Changes since v4 [1]: 1/ Allow up to PAGE_SHIFT bits in PFN_ flags. Previously the __pfn_t value was a union with a 'struct page *', but now __pfn_t_to_page() internally does a pfn_to_page() instead of type-punning the value. (Linus, Matthew) 2/ Move the definition to include/linux/mm.h and squash the kmap_atomic_pfn_t() definition into the same patch. (Christoph) 3/ Kill dax_get_pfn(). Now replaced with dax_map_bh() (Matthew) 4/ The scatterlist cleanup patches are moved to their own series being carried by Christoph. [1]: https://lists.01.org/pipermail/linux-nvdimm/2015-June/001094.html --- We want persistent memory to have 4 modes of access: 1/ Block device: persistent memory treated as a ram disk (done) 2/ DAX: userspace mmap (done) 3/ Kernel "page-less". (this series) 4/ Kernel and userspace references to page-mapped persistent memory (future series) The "kernel 'page-less'" case leverages the fact that a 'struct page' object is not necessarily required for describing a DMA transfer from a device to a persistent memory address. A pfn will do, but code needs to be careful to not perform a pfn_to_page() operation on unmapped persistent memory. The __pfn_t type enforces that safety and kmap_atomic_pfn_t() covers cases where the I/O stack needs to touch the buffer on its way to the low-level-device-driver (i.e. current usages of kmap_atomic() in the block-layer). A subsequent patch series will add struct page coverage for persistent, "device", memory. We also use kmap_atomic_pfn_t() to solve races of pmem driver unbind vs usage in DAX. rcu_read_lock() protects the driver from unbinding while a mapping is held. --- Christoph Hellwig (1): mm: move __phys_to_pfn and __pfn_to_phys to asm/generic/memory_model.h Dan Williams (4): allow mapping page-less memremaped areas into KVA dax: drop size parameter to ->direct_access() dax: fix mapping lifetime handling, convert to __pfn_t + kmap_atomic_pfn_t() scatterlist: convert to __pfn_t arch/arm/include/asm/memory.h |6 -- arch/arm64/include/asm/memory.h |6 -- arch/powerpc/platforms/Kconfig |1 arch/powerpc/sysdev/axonram.c | 24 +-- arch/unicore32/include/asm/memory.h |6 -- drivers/block/brd.c |9 +-- drivers/nvdimm/Kconfig |1 drivers/nvdimm/pmem.c | 24 --- drivers/s390/block/Kconfig |1 drivers/s390/block/dcssblk.c| 23 ++- fs/Kconfig |1 fs/block_dev.c |4 + fs/dax.c| 79 +--- include/asm-generic/memory_model.h |6 ++ include/linux/blkdev.h |7 +- include/linux/kmap_pfn.h| 31 + include/linux/mm.h | 78 +++ include/linux/scatterlist.h | 111 +++-- mm/Kconfig |3 + mm/Makefile |1 mm/kmap_pfn.c | 117 +++ samples/kfifo/dma-example.c |8 +- 22 files changed, 435 insertions(+), 112 deletions(-) create mode 100644 include/linux/kmap_pfn.h create mode 100644 mm/kmap_pfn.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] [RFC 1/1] drm/i915 : Wait until SYSTEM_RUNNING before loading CSR firmware
On Wednesday 15 July 2015 11:34:43 Daniel Vetter wrote:
> On Tue, Jul 14, 2015 at 01:37:32PM -0700, Greg KH wrote:
> > On Tue, Jul 14, 2015 at 11:22:35AM +0200, Daniel Vetter wrote:
> > > On Mon, Jul 13, 2015 at 09:36:45AM -0700, jay.p.pa...@intel.com wrote:
> > > > From: Jay Patel
> > > >
> > > > NOTE: This is an interim solution which is targeted towards
> > > > Chrome OS/Android to be used until a long term solution is available.
> > > >
> > > > In this patch, request_firmware() is called in a worker thread
> > > > which initially waits for file system to be initialized and then
> > > > attempts to load the firmware.
> > >
> > > Aside: I posted a bunch of proof-of-principle patches to clean up dmc
> > > loading and convert over to using an explicit workqueue. They're being
> > > tested/made-to-actually-work right now I think.
> > >
> > > > "request_firmware_nowait()" is also using an asynchronous thread
> > > > running concurrently with the rest of the system initialization.
> > > > However, it tries to load firmware only once without checking the
> > > > sytem status and fails most of the time.
> > > >
> > > > Change-Id: I2cb16a768e54a85f48a6682d9690b4c8af844668
> >
> > What's this line for? :)
> >
> > > > Signed-off-by: Jay Patel
> > > > ---
> > > >
> > > > drivers/gpu/drm/i915/i915_drv.c | 2 ++
> > > > drivers/gpu/drm/i915/intel_csr.c | 58
> > > > 2 files changed, 49
> > > > insertions(+), 11 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > > b/drivers/gpu/drm/i915/i915_drv.c index 8c8407d..eb6f7e3 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > > @@ -559,6 +559,7 @@ void intel_hpd_cancel_work(struct drm_i915_private
> > > > *dev_priv)> > >
> > > > void i915_firmware_load_error_print(const char *fw_path, int err)
> > > > {
> > > >
> > > > DRM_ERROR("failed to load firmware %s (%d)\n", fw_path, err);
> > > >
> > > > + DRM_ERROR("The firmware file may be missing\n");
> > > >
> > > > /*
> > > >
> > > > * If the reason is not known assume -ENOENT since that's the
> > > > most
> > > >
> > > > @@ -574,6 +575,7 @@ void i915_firmware_load_error_print(const char
> > > > *fw_path, int err)> > >
> > > > "The driver is built-in, so to load the firmware you need
> > > > to\n"
> > > > "include it either in the kernel (see CONFIG_EXTRA_FIRMWARE)
> > > > or\n"
> > > > "in your initrd/initramfs image.\n");
> > > >
> > > > +
> > > >
> > > > }
> > > >
> > > > static void intel_suspend_encoders(struct drm_i915_private *dev_priv)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_csr.c
> > > > b/drivers/gpu/drm/i915/intel_csr.c index 9311cdd..8d1f08c 100644
> > > > --- a/drivers/gpu/drm/i915/intel_csr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_csr.c
> > > > @@ -349,7 +349,7 @@ static void finish_csr_load(const struct firmware
> > > > *fw, void *context)> > >
> > > > /* load csr program during system boot, as needed for DC states
> > > > */
> > > > intel_csr_load_program(dev);
> > > > fw_loaded = true;
> > > >
> > > > -
> > > > + DRM_INFO("CSR Firmware Loaded\n");
> > > >
> > > > out:
> > > > if (fw_loaded)
> > > >
> > > > intel_runtime_pm_put(dev_priv);
> > > >
> > > > @@ -359,11 +359,46 @@ out:
> > > > release_firmware(fw);
> > > >
> > > > }
> > > >
> > > > +struct csr_firmware_work {
> > > > + struct work_struct work;
> > > > + struct module *module;
> > > > + struct drm_device *dev;
> > > > +};
> > > > +
> > > > +/* csr_firmware_work_func() - thread function for loading the
> > > > firmware*/
> > > > +static void csr_firmware_work_func(struct work_struct *work)
> > > > +{
> > > > + const struct firmware *fw;
> > > > + const struct csr_firmware_work *fw_work = container_of(work,
struct
> > > > csr_firmware_work, work); + int ret;
> > > > + struct drm_device *dev = fw_work->dev;
> > > > + struct drm_i915_private *dev_priv = dev->dev_private;
> > > > + struct intel_csr *csr = _priv->csr;
> > > > +
> > > > + /* Wait until root filesystem is loaded in case the firmware
> > > > +* is not built-in but in /lib/firmware */
> > > > + while(system_state != SYSTEM_RUNNING){
> > > > + msleep(500);
> > > > + }
> > >
> > > Yeah, not going to merge that right now until we've had a decent
> > > discussion with Greg KH (since imo his stance of every driver creating
> > > it's own retry loop just doesn't work, especially not with gfx where
> > > init
> > > is hairy and you just don't want to retry without end).
> >
> > Exactly, this type of thing isn't good at all (especially given that
> > the code isn't even checkpatch clean...)
> >
> > Don't do this. If you really want to somehow handle built-in drivers
> > that need
Re: [GIT PULL] MODSIGN: Use PKCS#7 for module signatures [ver #8]
David Howells wrote: > > I'm still seeing these warnings: > > > > scripts/sign-file.c: In function ‘main’: > > scripts/sign-file.c:188: warning: value computed is not used > > Ummm... What do you see on line 188? "BIO_reset(b);"? If so, that seems to > be an openssl bug. b is created four lines above and definitely used on the > following line, so the problem must lie with the BIO_reset() function or > macro. It seems that the definition of BIO_reset() is the same in 1.0.1e as in 1.0.1k. I was assuming that the value computed that is not being used is 'b' or some internal state, but I can't see how that is the case. I think it's actually the result of the function - which is being cast, otherwise your compiler would just ignore it. I presume you're using the RHEL-6 compiler? David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 09/16] PM / hibernate: Reserve hibernation key and erase footprints
Hi Chun-yi,
On Tue, 2015-08-11 at 14:16 +0800, Lee, Chun-Yi wrote:
> +/* A page used to keep hibernation keys */
> +static struct hibernation_keys *hibernation_keys;
> +
> +void __init parse_hibernation_keys(u64 phys_addr, u32 data_len)
> +{
> + struct setup_data *hibernation_setup_data;
> +
> + /* Reserve keys memory, will copy and erase in init_hibernation_keys()
> */
> + keys_phys_addr = phys_addr + sizeof(struct setup_data);
> + memblock_reserve(keys_phys_addr, sizeof(struct hibernation_keys));
> +
> + /* clear hibernation_data */
> + hibernation_setup_data = early_memremap(phys_addr, data_len);
> + if (!hibernation_setup_data)
> + return;
> +
should we invoke memblock_free if early_memremap failed?
Best Regards,
Yu
Re: [PATCH V10] fixup: audit: implement audit by executable
On Wednesday, August 12, 2015 11:19:44 AM Richard Guy Briggs wrote: > On 15/08/12, Paul Moore wrote: > > On Wednesday, August 12, 2015 05:48:48 AM Richard Guy Briggs wrote: > > > Do you plan to push this fix to next? > > > > Patience. Yes, I'll be pushing this to next sometime this week; as usual > > I'll send mail when I do. > > Ok, no problem, I'm not rushing. I was unsure what your intentions were > or whether there was more to do to help it happen. It's merged. I still don't know why I'm seeing that error, but the patch is obviously correct so I'm just going to merge it anyway and chalk it up to some compiler/sparse oddity. As far as patch follow-ups, if you haven't heard back from me after four days or so (yes, that is as arbitrary as it sounds), it isn't a bad idea to send a follow-up, especially if it is a critical patch, to make sure I've seen the patch (things do occasionally fall through the cracks). However, if it is only been a day or two and I haven't responded, rest assured I've likely seen your patch I'm just dealing with something else at the moment and haven't had the time to review/comment/merge your patch. -- paul moore security @ redhat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] power: align wakeup_sources format
From: yangdongdong
This aligns every column of elements in wakeup_sources to
conveniently check any specific column for suspicious power
consumption wakeup source or for other easily readable purpose.
Signed-off-by: yangdongdong
---
drivers/base/power/wakeup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
index 51f15bc..b6fe9e6 100644
--- a/drivers/base/power/wakeup.c
+++ b/drivers/base/power/wakeup.c
@@ -998,7 +998,7 @@ static int print_wakeup_source_stats(struct seq_file *m,
active_time = ktime_set(0, 0);
}
- seq_printf(m,
"%-12s\t%lu\t\t%lu\t\t%lu\t\t%lu\t\t%lld\t\t%lld\t\t%lld\t\t%lld\t\t%lld\n",
+ seq_printf(m,
"%-32s\t%lu\t\t%lu\t\t%lu\t\t%lu\t\t%lld\t\t%lld\t\t%lld\t\t%lld\t\t%lld\n",
ws->name, active_count, ws->event_count,
ws->wakeup_count, ws->expire_count,
ktime_to_ms(active_time), ktime_to_ms(total_time),
@@ -1018,7 +1018,7 @@ static int wakeup_sources_stats_show(struct seq_file *m,
void *unused)
{
struct wakeup_source *ws;
- seq_puts(m, "name\t\tactive_count\tevent_count\twakeup_count\t"
+ seq_puts(m, "name\t\t\t\t\tactive_count\tevent_count\twakeup_count\t"
"expire_count\tactive_since\ttotal_time\tmax_time\t"
"last_change\tprevent_suspend_time\n");
--
2.5.0
The signed name has been updated.
Thanks,
yangdongdong
On Wed, Aug 12, 2015 at 02:12:38PM +0800, check.ker...@gmail.com wrote:
> From: yangdongdong
As mentioned before, please fix this.
The signed name is updated from "Andy Yang" to yangdongdong.
Best Regards,
Andy
On Wed, Aug 12, 2015 at 12:31:14PM +0800, check.ker...@gmail.com wrote:
> From: yangdongdong
Use the same name here as you used for the signed-off-by: line please.
Please fix and resend.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, vsyscall: add CONFIG to control default
On Wed, Aug 12, 2015 at 05:55:19PM -0700, Kees Cook wrote:
> Most modern systems can run with vsyscall=none. In an effort to provide
> a way for build-time defaults to lack legacy settings, this adds a new
> CONFIG to select the type of vsyscall mapping to use, similar to the
> existing "vsyscall" command line parameter.
>
> Signed-off-by: Kees Cook
Seems reasonable to me. One question, though: is there *any* reason to
choose "native" over "emulate"? (Does "emulate" have a sufficient
performance penalty to matter, and do people running old glibc really
care about that performance while still not wanting to upgrade?)
If there is a reason, could you please document it in the
descriptions of the "native" and "emulate" options (as an upside and a
downside, respectively)? If there isn't, you might consider a patch to
remove "native".
> arch/x86/Kconfig | 49
> +++
> arch/x86/entry/vsyscall/vsyscall_64.c | 9 ++-
> 2 files changed, 57 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index b3a1a5d77d92..fbd0fad714a1 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2010,6 +2010,55 @@ config COMPAT_VDSO
> If unsure, say N: if you are compiling your own kernel, you
> are unlikely to be using a buggy version of glibc.
>
> +choice
> + prompt "vsyscall table for legacy applications"
> + depends on X86_64
> + default LEGACY_VSYSCALL_EMULATE
> + help
> + Legacy user code that does not know how to find the vDSO expects
> + to be able to issue three syscalls by calling fixed addresses in
> + kernel space. Since this location is not randomized with ASLR,
> + it can be used to assist security vulnerability exploitation.
> +
> + This setting can be changed at boot time via the kernel command
> + line parameter vsyscall=[native|emulate|none].
> +
> + On a system with recent enough glibc (2.14 or newer) and no
> + static binaries, you can say None without a performance penalty
> + to improve security.
> +
> + If unsure, select "Emulate".
> +
> + config LEGACY_VSYSCALL_NATIVE
> + bool "Native"
> + help
> + Actual executable code is located in the fixed vsyscall
> + address mapping, implementing time() efficiently. Since
> + this makes the mapping executable, it can be used during
> + security vulnerability exploitation (traditionally as
> + ROP gadgets). This configuration is not recommended.
> +
> + config LEGACY_VSYSCALL_EMULATE
> + bool "Emulate"
> + help
> + The kernel traps and emulates calls into the fixed
> + vsyscall address mapping. This makes the mapping
> + non-executable, but it still contains known contents,
> + which could be used in certain rare security vulnerability
> + exploits. This configuration is recommended when userspace
> + still uses the vsyscall area.
> +
> + config LEGACY_VSYSCALL_NONE
> + bool "None"
> + help
> + There will be no vsyscall mapping at all. This will
> + eliminate any risk of ASLR bypass due to the vsyscall
> + fixed address mapping. Attempts to use the vsyscalls
> + will be reported to dmesg, so that either old or
> + malicious userspace programs can be identified.
> +
> +endchoice
> +
> config CMDLINE_BOOL
> bool "Built-in kernel command line"
> ---help---
> diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c
> b/arch/x86/entry/vsyscall/vsyscall_64.c
> index 2dcc6ff6fdcc..47e2904b043b 100644
> --- a/arch/x86/entry/vsyscall/vsyscall_64.c
> +++ b/arch/x86/entry/vsyscall/vsyscall_64.c
> @@ -38,7 +38,14 @@
> #define CREATE_TRACE_POINTS
> #include "vsyscall_trace.h"
>
> -static enum { EMULATE, NATIVE, NONE } vsyscall_mode = EMULATE;
> +static enum { EMULATE, NATIVE, NONE } vsyscall_mode =
> +#ifdef CONFIG_LEGACY_VSYSCALL_NATIVE
> + NATIVE;
> +#elif CONFIG_LEGACY_VSYSCALL_NONE
> + NONE;
> +#else
> + EMULATE;
> +#endif
>
> static int __init vsyscall_setup(char *str)
> {
> --
> 1.9.1
>
>
> --
> Kees Cook
> Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] crypto: export crypto_alg_list and rwsem
Until now, zram uses compression algorithm through direct call
to core algorithm function, but, it has drawback that we need to add
compression algorithm manually to zram. If we don't do that, we cannot
utilize various compression algorithms in the system. To improve this
situation, zram will be changed to use crypto subsystem in following
patch. There is one problem with this change. Zram has a interface
that what compression algorithm it can support. Although crypto subsystem
has /proc interface to search all of crypto algorithm, but, there is
no way to get just compression algorithm in cryto subsystem. To implement
it on zram-side, crypto_alg_list and rwsem should be exported so
this patch do it.
Signed-off-by: Joonsoo Kim
---
crypto/internal.h | 2 --
include/linux/crypto.h | 4
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/crypto/internal.h b/crypto/internal.h
index 00e42a3..806f17a 100644
--- a/crypto/internal.h
+++ b/crypto/internal.h
@@ -45,8 +45,6 @@ struct crypto_larval {
u32 mask;
};
-extern struct list_head crypto_alg_list;
-extern struct rw_semaphore crypto_alg_sem;
extern struct blocking_notifier_head crypto_chain;
#ifdef CONFIG_PROC_FS
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 81ef938..ab39f4b 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -24,6 +24,10 @@
#include
#include
#include
+#include
+
+extern struct list_head crypto_alg_list;
+extern struct rw_semaphore crypto_alg_sem;
/*
* Autoloaded crypto modules should only use a prefixed name to avoid allowing
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] zram: use crypto API to compress the page
Until now, zram uses compression algorithm through direct call
to core algorithm function, but, it has drawback that we need to add
compression algorithm manually to zram if needed. Without this work,
we cannot utilize various compression algorithms in the system.
Moreover, to add new compression algorithm, we need to know how to use it
and this is somewhat time-consuming.
When I tested new algorithms such as zlib, these problems make me hard
to test them. To prevent these problem in the future, I think that
using crypto API to compress the page is better approach and this patch
implements it.
The reason we need to support vairous compression algorithms is that
zram's performance is highly depend on workload and compression algorithm
and architecture. Every compression algorithm has it's own strong point.
For example, zlib is the best for compression ratio, but, it's
(de)compression speed is rather slow. Against my expectation, in my kernel
build test with zram swap, in low-memory condition on x86, zlib shows best
performance than others. In this case, I guess that compression ratio is
the most important factor. Unlike this situation, on ARM, maybe fast
(de)compression speed is the most important because it's computation speed
is slower than x86.
We can't expect what algorithm is the best fit for one's system, because
it needs too complex calculation. We need to test it in case by case and
easy to use new compression algorithm by this patch will help
that situation.
Signed-off-by: Joonsoo Kim
---
drivers/block/zram/Kconfig | 13 +--
drivers/block/zram/Makefile| 4 +-
drivers/block/zram/zcomp.c | 87 ++
drivers/block/zram/zcomp.h | 34 +
drivers/block/zram/zcomp_lz4.c | 47 ---
drivers/block/zram/zcomp_lz4.h | 17 -
drivers/block/zram/zcomp_lzo.c | 47 ---
drivers/block/zram/zcomp_lzo.h | 17 -
drivers/block/zram/zram_drv.c | 28 +-
9 files changed, 66 insertions(+), 228 deletions(-)
delete mode 100644 drivers/block/zram/zcomp_lz4.c
delete mode 100644 drivers/block/zram/zcomp_lz4.h
delete mode 100644 drivers/block/zram/zcomp_lzo.c
delete mode 100644 drivers/block/zram/zcomp_lzo.h
diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig
index 386ba3d..36ec96f 100644
--- a/drivers/block/zram/Kconfig
+++ b/drivers/block/zram/Kconfig
@@ -1,8 +1,7 @@
config ZRAM
tristate "Compressed RAM block device support"
depends on BLOCK && SYSFS && ZSMALLOC
- select LZO_COMPRESS
- select LZO_DECOMPRESS
+ select CRYPTO_LZO
default n
help
Creates virtual block devices called /dev/zramX (X = 0, 1, ...).
@@ -14,13 +13,3 @@ config ZRAM
disks and maybe many more.
See zram.txt for more information.
-
-config ZRAM_LZ4_COMPRESS
- bool "Enable LZ4 algorithm support"
- depends on ZRAM
- select LZ4_COMPRESS
- select LZ4_DECOMPRESS
- default n
- help
- This option enables LZ4 compression algorithm support. Compression
- algorithm can be changed using `comp_algorithm' device attribute.
\ No newline at end of file
diff --git a/drivers/block/zram/Makefile b/drivers/block/zram/Makefile
index be0763f..9e2b79e 100644
--- a/drivers/block/zram/Makefile
+++ b/drivers/block/zram/Makefile
@@ -1,5 +1,3 @@
-zram-y := zcomp_lzo.o zcomp.o zram_drv.o
-
-zram-$(CONFIG_ZRAM_LZ4_COMPRESS) += zcomp_lz4.o
+zram-y := zcomp.o zram_drv.o
obj-$(CONFIG_ZRAM) += zram.o
diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
index 965d1af..3dc9bfa 100644
--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -13,12 +13,9 @@
#include
#include
#include
+#include
#include "zcomp.h"
-#include "zcomp_lzo.h"
-#ifdef CONFIG_ZRAM_LZ4_COMPRESS
-#include "zcomp_lz4.h"
-#endif
/*
* single zcomp_strm backend
@@ -43,36 +40,17 @@ struct zcomp_strm_multi {
wait_queue_head_t strm_wait;
};
-static struct zcomp_backend *backends[] = {
- _lzo,
-#ifdef CONFIG_ZRAM_LZ4_COMPRESS
- _lz4,
-#endif
- NULL
-};
-
-static struct zcomp_backend *find_backend(const char *compress)
-{
- int i = 0;
- while (backends[i]) {
- if (sysfs_streq(compress, backends[i]->name))
- break;
- i++;
- }
- return backends[i];
-}
-
static void zcomp_strm_free(struct zcomp *comp, struct zcomp_strm *zstrm)
{
- if (zstrm->private)
- comp->backend->destroy(zstrm->private);
+ if (zstrm->tfm)
+ crypto_free_comp(zstrm->tfm);
free_pages((unsigned long)zstrm->buffer, 1);
kfree(zstrm);
}
/*
- * allocate new zcomp_strm structure with ->private initialized by
- * backend, return NULL on error
+ * allocate new zcomp_strm structure with initializing crypto data structure,
+ * return NULL on error
*/
UPON YOUR REPLY I WILL EXPLAIN.
Dear Friend, Greetings and I hope you are fine. I have a business venture that will be of mutual benefits and the deal is worth 11.8 Million Dollars coming from a certain dormant account in my Bank in Burkina Faso, West Africa and once you indicate your interest I will furnish you with details that will make this deal a worthwhile venture. I will be waiting for your response. Best regards Mr. James Kadiogo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] printk: rebalance printk
On 2015年08月12日 20:31, Peter Hurley wrote:
> On 08/11/2015 02:16 PM, Greg Kroah-Hartman wrote:
>> On Tue, Aug 11, 2015 at 07:23:01PM +0800, Pan Xinhui wrote:
>>> From: Pan Xinhui
>>>
>>> printk can be called in any context, It's very useful to output debug
>>> info.
>>>
>>> But it might cause very bad issues on some special cases. For example,
>>> some driver hit errors, and it dumps many messages like reg values, etc.
>>>
>>> Sometimes, printk is called when irqs disabled. This is OKay if there is
>>> a few messages. But What would happen if many messages outputted by other
>>> drivers at same time.
>>>
>>> Here is the scenario.
>>> CPUACPUB
>>> local_irq_save(flags);
>>> printk()
>>> while(..) { --> console_unlock
>>> printk(...);
>>> //hundreds or thousands loops
>>> } //all messages flushed out to consoles
>>> local_irq_restore(flags);
>>>
>>
>> Where are you seeing this type of scenario "in the wild"? Or is this
>> just a "debug/bringup hardware" issue?
>
> There have been problem reports of big machines getting soft-lockup/RCU stall
> warnings with serial console attached. I think SLES is carrying patches
> from Jan Kara to try to workaround this issue.
>
>
commit 5874af2003b1053128d655710140e3187226 ("printk: enable interrupts
before calling console_trylock_for_printk()")
does help much in most cases. Thanks Jan Kara for that patch!
However there are still some corner cases like that I mentioned above.
As preempt is disabled in console_unlock(), Even applying my patch,
softlockup/RCU warning still goes out.
I am very looking forward to Jan Kara's new patch to walk around it. Of course
I will also try to work out a pre-review patch with my new idea
to fix these softlockpup/RCU warning.
Thanks
xinhui
>> We shouldn't be ever stuck in a
>> printk that prints hundreds or thousands of loops, if so, we need to fix
>> the kernel code that does that, as we do have control over this.
>
> The loop referred to here is the loop in console_unlock(). Essentially
> what happens is one cpu can get trapped in the console_unlock() output
> loop; printk()'s from other cpus are only appending to the logbuf since
> they can't acquire the console_lock (which is owned by the one cpu trapped
> in the output loop).
>
> Regards,
> Peter Hurley
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm, vmscan: Do not wait for page writeback for GFP_NOFS allocations
On Fri, 7 Aug 2015, Nikolay Borisov wrote: > On 08/04/2015 09:32 AM, Hugh Dickins wrote: > > > > And I've done quite a bit of testing. The loads that hung at the > > weekend have been running nicely for 24 hours now, no problem with the > > writeback hang and no problem with the dcache ENOTDIR issue. Though > > I've no idea of what recent VM change turned this into a hot issue. > > > > Are these production loads you are referring to that have been able to > reproduce the issue or are they some synthetic ones which? So far I > haven't been able to reproduce the issue using artifical loads so I'm > interested in incorporating this into my test set setup if it's available? Not production loads, no, just an artificial load. But not very good at reproducing the hang: variable, but took hours, and only showed up on one faster machine; I had to run the load for 2 days, then again 2 days, to feel confident that this hang was fixed. And I'm sorry, but describing it in full detail is not something I find time to do, in days or in years - partly because once I try to detail it, I need to simplify this and streamline that, and it turns into something else. As happened when I sent it, offlist, to someone in 2009: I looked back at that with a view to forwarding to you, but a lot of the details don't match what I reverted to or advanced to doing since. Broadly, it's a pair of repeated make -j20 kernel builds, one in tmpfs, one in ext4 over loop over tmpfs, in limited memory 700M with 1.5G swap. And to test this particular hang, it needed to use memcg (of what's now branded an "insane" variety, CONFIG_CGROUP_WRITEBACK=n): I was using 1G not 700M ram for this, but 300M memcg limit and 250M soft limit on each memcg that was hosting one of the pair of repeated builds. It can be difficult to tune the right balance, swapping heavily but not OOMing: it's a 2.6.24 tree I've gone back to building, because that's so much smaller than current, with a greater proportion active in the build. Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[auxdisplay: ks0108] BUG: unable to handle kernel
_init+0x16/0x16 [1.164185] [<410693af>] ? parse_args+0x1df/0x410 [1.164185] [<410693af>] ? parse_args+0x1df/0x410 [1.164918] [<4108940b>] ? trace_hardirqs_on+0xb/0x10 [1.164918] [<4108940b>] ? trace_hardirqs_on+0xb/0x10 [1.165703] [<41b9ac44>] ? kernel_init_freeable+0x16c/0x209 [1.165703] [<41b9ac44>] ? kernel_init_freeable+0x16c/0x209 [1.166575] [<41b9ac64>] kernel_init_freeable+0x18c/0x209 [1.166575] [<41b9ac64>] kernel_init_freeable+0x18c/0x209 [1.167415] [<4168cbe0>] kernel_init+0x10/0xe0 [1.167415] [<4168cbe0>] kernel_init+0x10/0xe0 [1.168108] [<41073827>] ? schedule_tail+0x17/0x60 [1.168108] [<41073827>] ? schedule_tail+0x17/0x60 [1.168853] [<416a2de0>] ret_from_kernel_thread+0x20/0x30 [1.168853] [<416a2de0>] ret_from_kernel_thread+0x20/0x30 [1.169692] [<4168cbd0>] ? rest_init+0x120/0x120 [1.169692] [<4168cbd0>] ? rest_init+0x120/0x120 [1.170413] Code: [1.170413] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 55 55 89 89 e5 e5 53 53 3e 3e 8d 8d 74 74 26 26 00 00 88 88 c3 c3 a1 a1 60 60 9d 9d b1 b1 41 41 80 80 f3 f3 0b 0b e8 e8 78 78 60 60 e9 e9 ff ff a1 a1 b4 b4 e5 e5 4c 4c 42 42 0f 0f b6 b6 d3 d3 <8b> <8b> 88 88 68 68 03 03 00 00 00 00 ff ff 51 51 08 08 5b 5b 5d 5d c3 c3 8d 8d 74 74 26 26 00 00 55 55 89 89 e5 e5 83 83 ec ec [1.174047] EIP: [<41505410>] [1.174047] EIP: [<41505410>] ks0108_writecontrol+0x20/0x30ks0108_writecontrol+0x20/0x30 SS:ESP 0068:40279ee8 SS:ESP 0068:40279ee8 [1.175861] CR2: 0368 [1.175861] CR2: 0368 [1.176733] ---[ end trace 056a83ef0ca6f477 ]--- [1.176733] ---[ end trace 056a83ef0ca6f477 ]--- git bisect start edd64b4503c85c2d642642794ab1c64407c72488 f7644cbfcdf03528f0f450f3940c4985b2291f49 -- git bisect good 46b1af674a6ee5e8328b91d951e528abfa680bf9 # 07:48 20+ 0 Merge remote-tracking branch 'libata/for-next' git bisect good 46793eca8e66413b01ba764287873676b0f675bf # 07:56 22+ 0 Merge remote-tracking branch 'dwmw2-iommu/master' git bisect good 9609a634ad3be39e30538d98b1a6d9ff2dc2127d # 08:04 22+ 0 Merge remote-tracking branch 'xen-tip/linux-next' git bisect good 4c6aa4371b3a17bdbe8ab8dee2de788b38ae9235 # 08:18 22+ 2 Merge remote-tracking branch 'tty/tty-next' git bisect good e3274851f81a7691f8def456b5f1511a814a29a1 # 08:21 20+ 0 Merge remote-tracking branch 'staging/staging-next' git bisect bad 9fd60ea25e73d0ad256084e0edbef8da17b9 # 08:27 0- 20 Merge remote-tracking branch 'extcon/extcon-next' git bisect bad 184e046f36dc25859b57140eb9f5de565de65be2 # 08:28 0- 13 Merge remote-tracking branch 'char-misc/char-misc-next' git bisect good cc2dd4027a43bb36c846f195a764edabc0828602 # 08:37 20+ 0 mshyperv: fix recognition of Hyper-V guest crash MSR's git bisect good 414a1417d7b35e0e72edb16e45840e242cb6b52e # 08:49 20+ 0 coresight-etm3x: Change the name of the ctxid_val to ctxid_pid git bisect bad 2af38ab572b031a4111f01153cc020b1038b427b # 08:56 0- 12 nvmem: Add bindings for simple nvmem framework git bisect good d25ded8d3c6ecc3043763d4330c964603dc61bd4 # 09:06 22+ 0 char/nvram: Use bitwise OR to obtain Atari video mode data git bisect bad 4edd70c133f3921c594883d8f9da31a7261f8b4f # 09:15 0- 18 auxdisplay: ks0108: use new parport device model git bisect good 7faad1dfbbe008fe564d94c1b154695fcc13d748 # 09:17 22+ 0 auxdisplay: ks0108: start using pr_* git bisect good c9efdbe63410984668a4983cc46e31a7b3f0c74e # 09:31 22+ 0 auxdisplay: ks0108: use min_t # first bad commit: [4edd70c133f3921c594883d8f9da31a7261f8b4f] auxdisplay: ks0108: use new parport device model git bisect good c9efdbe63410984668a4983cc46e31a7b3f0c74e # 09:41 61+ 0 auxdisplay: ks0108: use min_t # extra tests with DEBUG_INFO git bisect bad 4edd70c133f3921c594883d8f9da31a7261f8b4f # 09:49 0- 38 auxdisplay: ks0108: use new parport device model # extra tests on HEAD of linux-next/master git bisect bad c1a0c66f231dcfd156cee1233709e62cb0a13378 # 09:49 0- 28 Add linux-next specific files for 20150812 # extra tests on tree/branch linux-next/master git bisect bad c1a0c66f231dcfd156cee1233709e62cb0a13378 # 09:49 0- 28 Add linux-next specific files for 20150812 # extra tests with first bad commit reverted git bisect good bdcdcda8490c19adf40e96a2b499cce221449929 # 10:02 63+ 0 Revert "auxdisplay: ks0108: use new parport device model" # extra tests on tree/branch linus/master git bisect good 30065bfda900a844d9c88bc4d5d298025a4fef5e # 10:12 66+ 0 Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux # extra tests on tree/branch linux-next/master git bisect bad c1a0c66f231dcfd156ce
Re: [PATCH] spi: Mediatek: fix endian warnings
Hello Mark, This patch is applied, should I append a new patch or you rollback it? Thanks. On Wed, 2015-08-12 at 16:45 +0200, Jonas Gorski wrote: > Hi, > > On Tue, Aug 11, 2015 at 12:43 PM, Leilk Liu wrote: > > This patch fixes endian warnings detected by sparse: > > - sparse: incorrect type in argument 1 (different base types) > > expected unsigned int [unsigned] val > > got restricted __le32 [usertype] > > - sparse: incorrect type in argument 1 (different base types) > > expected unsigned int [unsigned] val > > got restricted __le32 [usertype] > > This doesn't "fix" the warning, it only hides the warning and leaves > the actual issue unfixed. > > > > > Signed-off-by: Leilk Liu > > --- > > drivers/spi/spi-mt65xx.c | 6 -- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c > > index 4676b01..ae645fa 100644 > > --- a/drivers/spi/spi-mt65xx.c > > +++ b/drivers/spi/spi-mt65xx.c > > @@ -359,9 +359,11 @@ static void mtk_spi_setup_dma_addr(struct spi_master > > *master, > > struct mtk_spi *mdata = spi_master_get_devdata(master); > > > > if (mdata->tx_sgl) > > - writel(cpu_to_le32(xfer->tx_dma), mdata->base + > > SPI_TX_SRC_REG); > > + writel((__force u32)cpu_to_le32(xfer->tx_dma), > > + mdata->base + SPI_TX_SRC_REG); > > if (mdata->rx_sgl) > > - writel(cpu_to_le32(xfer->rx_dma), mdata->base + > > SPI_RX_DST_REG); > > + writel((__force u32)cpu_to_le32(xfer->rx_dma), > > + mdata->base + SPI_RX_DST_REG); > > The issue here is that writel already does a cpu_to_le32 conversion, > so the extra cpu_to_le32 calls are actually bogus and need to be > removed. Else it will do a double conversion on big endian systems, > resulting in the data being written in big endian. > > > Jonas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] MODSIGN: Use PKCS#7 for module signatures [ver #8]
James Morris wrote: > I'm still seeing these warnings: > > scripts/sign-file.c: In function ‘main’: > scripts/sign-file.c:188: warning: value computed is not used Ummm... What do you see on line 188? "BIO_reset(b);"? If so, that seems to be an openssl bug. b is created four lines above and definitely used on the following line, so the problem must lie with the BIO_reset() function or macro. You're using an older version of openssl-devel than I am (1.0.1e rather than 1.0.1k) so I suspect this has been fixed. Can you have a look how this is defined for you? I see: /usr/include/openssl/bio.h:#define BIO_reset(b) (int)BIO_ctrl(b,BIO_CTRL_RESET,0,NULL) and: /usr/include/openssl/bio.h:long BIO_ctrl(BIO *bp,int cmd,long larg,void *parg); > WARNING: modpost: missing MODULE_LICENSE() in > crypto/asymmetric_keys/pkcs7_test_key.o The issue actually pre-dates this patchset so is independent of it. I can stack a patch onto the end of my series to fix this. I've pushed a new tag with this patch (revised request-pull below in case you feel inclined to pull it - or I can generate a whole new request message if you'd prefer). David --- The following changes since commit 459c15e53cf7e4e88a78ecfb109af5a267c5500a: Merge tag 'asn1-fixes-20150805' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs into next (2015-08-07 13:27:58 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git tags/modsign-pkcs7-20150812-2 for you to fetch changes up to 772111ab01eace6a7e4cf821a4348cec64a97c92: PKCS#7: Add MODULE_LICENSE() to test module (2015-08-13 02:51:33 +0100) Module signing with PKCS#7 David Howells (18): ASN.1: Add an ASN.1 compiler option to dump the element tree ASN.1: Copy string names to tokens in ASN.1 compiler X.509: Extract both parts of the AuthorityKeyIdentifier X.509: Support X.509 lookup by Issuer+Serial form AuthorityKeyIdentifier PKCS#7: Allow detached data to be supplied for signature checking purposes MODSIGN: Provide a utility to append a PKCS#7 signature to a module MODSIGN: Use PKCS#7 messages as module signatures system_keyring.c doesn't need to #include module-internal.h MODSIGN: Extract the blob PKCS#7 signature verifier from module signing PKCS#7: Check content type and versions X.509: Change recorded SKID & AKID to not include Subject or Issuer PKCS#7: Support CMS messages also [RFC5652] sign-file: Generate CMS message as signature instead of PKCS#7 PKCS#7: Improve and export the X.509 ASN.1 time object decoder KEYS: Add a name for PKEY_ID_PKCS7 PKCS#7: Appropriately restrict authenticated attributes and content type sign-file: Document dependency on OpenSSL devel libraries PKCS#7: Add MODULE_LICENSE() to test module David Woodhouse (9): modsign: Abort modules_install when signing fails modsign: Allow password to be specified for signing key modsign: Allow signing key to be PKCS#11 modsign: Allow external signing key to be specified modsign: Extract signing cert from CONFIG_MODULE_SIG_KEY if needed modsign: Use single PEM file for autogenerated key modsign: Add explicit CONFIG_SYSTEM_TRUSTED_KEYS option extract-cert: Cope with multiple X.509 certificates in a single file modsign: Use extract-cert to process CONFIG_SYSTEM_TRUSTED_KEYS Luis R. Rodriguez (1): sign-file: Add option to only create signature file .gitignore| 1 + Documentation/kbuild/kbuild.txt | 5 + Documentation/module-signing.txt | 54 +++- Makefile | 8 +- arch/x86/kernel/kexec-bzimage64.c | 4 +- crypto/asymmetric_keys/Makefile | 8 +- crypto/asymmetric_keys/asymmetric_type.c | 11 + crypto/asymmetric_keys/pkcs7.asn1 | 22 +- crypto/asymmetric_keys/pkcs7_key_type.c | 17 +- crypto/asymmetric_keys/pkcs7_parser.c | 269 ++- crypto/asymmetric_keys/pkcs7_parser.h | 20 +- crypto/asymmetric_keys/pkcs7_trust.c | 10 +- crypto/asymmetric_keys/pkcs7_verify.c | 145 -- crypto/asymmetric_keys/public_key.c | 1 + crypto/asymmetric_keys/verify_pefile.c| 7 +- crypto/asymmetric_keys/x509_akid.asn1 | 35 +++ crypto/asymmetric_keys/x509_cert_parser.c | 231 ++-- crypto/asymmetric_keys/x509_parser.h | 12 +- crypto/asymmetric_keys/x509_public_key.c | 95 --- include/crypto/pkcs7.h| 13 +- include/crypto/public_key.h | 18 +- include/keys/system_keyring.h | 7 + include/linux/oid_registry.h | 4 +- include/linux/verify_pefile.h
Re: [PATCH v8 00/21] Compile-time stack validation
On Wed, Aug 12, 2015 at 04:24:49PM -0500, Chris J Arges wrote: > > > > > Thanks for trying it out. I couldn't figure out how to recreate this > > exact error, but I played around with "make mrproper" and saw some > > probably related errors. Does this fix it? > > > > ---8<--- > > > > Subject: [PATCH] stackvalidate: fix circular build dependencies > > > > After "make mrproper" with CONFIG_STACK_VALIDATION enabled, I get the > > following errors: > > > > make[2]: *** No rule to make target 'arch/x86/purgatory/purgatory.o', > > needed by 'arch/x86/purgatory/purgatory.ro'. Stop. > > make[3]: *** No rule to make target 'scripts/mod/empty.o', needed by > > 'scripts/mod/elfconfig.h'. Stop. > > > > These are caused by circular dependencies. The %.o pattern rules in > > scripts/Makefile.build have the stackvalidate binary listed as a > > dependency. But stackvalidate gets built *after* archprepare and > > scripts/mod, both of which build objects using the %.o pattern rules. > > > > The STACKVALIDATE and STACKVALIDATE_foo.o variables are already used to > > determine whether to validate a given object. Also use them to > > determine whether to create the pattern rule dependency. > > > > Signed-off-by: Josh Poimboeuf > > --- > > scripts/Makefile.build | 7 +-- > > scripts/mod/Makefile | 2 ++ > > 2 files changed, 7 insertions(+), 2 deletions(-) > > > > diff --git a/scripts/Makefile.build b/scripts/Makefile.build > > index a1270d3..ec96c51 100644 > > --- a/scripts/Makefile.build > > +++ b/scripts/Makefile.build > > @@ -243,7 +243,7 @@ endif > > > > ifdef CONFIG_STACK_VALIDATION > > > > -stackvalidate = $(objtree)/scripts/stackvalidate/stackvalidate > > +__stackvalidate = $(objtree)/scripts/stackvalidate/stackvalidate > > > > ifndef CONFIG_FRAME_POINTER > > nofp = --no-frame-pointer > > @@ -251,9 +251,12 @@ endif > > > > # Set STACKVALIDATE_foo.o=n to skip stack validation for a file. > > # Set STACKVALIDATE=n to skip stack validation for a directory. > > +stackvalidate = $(if $(patsubst n%,, \ > > + $(STACKVALIDATE_$(basetarget).o)$(STACKVALIDATE)y), \ > > + $(__stackvalidate)) > > cmd_stackvalidate = $(if $(patsubst n%,, \ > > $(STACKVALIDATE_$(basetarget).o)$(STACKVALIDATE)y), \ > > - $(stackvalidate) $(nofp) "$(@)";) > > + $(__stackvalidate) $(nofp) "$(@)";) > > > > endif # CONFIG_STACK_VALIDATION > > > > diff --git a/scripts/mod/Makefile b/scripts/mod/Makefile > > index c11212f..374c413 100644 > > --- a/scripts/mod/Makefile > > +++ b/scripts/mod/Makefile > > @@ -1,3 +1,5 @@ > > +STACKVALIDATE := n > > + > > hostprogs-y:= modpost mk_elfconfig > > always := $(hostprogs-y) empty.o > > > > > > Josh, > > I still get build failures and I've pared it down to x86_64 defconfig plus: > CONFIG_MODVERSIONS=y > CONFIG_STACK_VALIDATION=y Are you still seeing the same error as before? I think the errors you saw were caused by stackvalidate choking on scripts/mod/empty.o. But I don't see how that's still possible with the above patch since I set STACKVALIDATE to 'n' in scripts/mod/Makefile which should tell it to skip the directory. > And it seems like some modules may get the .tmp_foo.o treatment while > others end up foo.o so something like the following will not work: > > cmd_stackvalidate = $(if $(patsubst n%,, \ > $(STACKVALIDATE_$(basetarget).o)$(STACKVALIDATE)y), \ > $(__stackvalidate) $(nofp) "$(@D)/.tmp_$(@F)";) > > In addition, I'm not sure if skipping modules like STACKVALIDATE_foo.o=n > will still function properly for modversioned modules. I'm not sure that's really a problem, since I don't think we'll need to skip validation of any module code. It's only used for skipping code which runs outside of the kernel's normal operation (e.g., boot, vdso, kexec). -- Josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drm/exynos: Staticize local function in exynos_drm_gem.c
The exynos_drm_gem_mmap_buffer() is not used outside so make it static.
Signed-off-by: Krzysztof Kozlowski
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 0d5b9698d384..d9f6de012235 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -318,7 +318,7 @@ void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
drm_gem_object_unreference_unlocked(obj);
}
-int exynos_drm_gem_mmap_buffer(struct exynos_drm_gem_obj *exynos_gem_obj,
+static int exynos_drm_gem_mmap_buffer(struct exynos_drm_gem_obj
*exynos_gem_obj,
struct vm_area_struct *vma)
{
struct drm_device *drm_dev = exynos_gem_obj->base.dev;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-discuss] [BELATED CORE TOPIC] context tracking / nohz / RCU state
On Thu, Aug 13, 2015 at 12:03 AM, Paul E. McKenney wrote: > On Wed, Aug 12, 2015 at 04:27:34PM +0200, Frederic Weisbecker wrote: >> On Tue, Aug 11, 2015 at 08:42:58PM +0200, Luis R. Rodriguez wrote: >> > On Tue, Aug 11, 2015 at 10:49:36AM -0700, Andy Lutomirski wrote: >> > > This is a bit late, but here goes anyway. >> > > >> > > Having played with the x86 context tracking hooks for awhile, I think >> > > it would be nice if core code that needs to be aware of CPU context >> > > (kernel, user, idle, guest, etc) could come up with single, >> > > comprehensible, easily validated set of hooks that arch code is >> > > supposed to call. >> > > >> > > Currently we have: >> > > >> > > - RCU hooks, which come in a wide variety to notify about IRQs, NMIs, >> > > etc. >> > > >> > > - Context tracking hooks. Only used by some arches. Calling these >> > > calls the RCU hooks for you in most cases. They have weird >> > > interactions with interrupts and they're slow. >> > > >> > > - vtime. Beats the heck out of me. >> > > >> > > - Whatever deferred things Christoph keeps reminding us about. >> > > >> > > Honestly, I don't fully understand what all these hooks are supposed >> > > to do, nor do I care all that much. From my perspective, the code >> > > code should be able to do whatever it wants and rely on appropriate >> > > notifications from arch code. It would be great if we could come up >> > > with something straightforward that covers everything. For example: >> > > >> > > user_mode_to_kernel_mode() >> > > kernel_mode_to_user_mode() >> > > kernel_mode_to_guest_mode() >> > > in_a_periodic_tick() >> > > starting_nmi() >> > > ending_nmi() >> > > may_i_turn_off_ticks_right_now() >> > > or, better yet: >> > > i_am_turning_off_ticks_right_now_and_register_your_own_darned_hrtimer_if_thats_a_problem() >> > > >> > > Some arches may need: >> > > >> > > i_am_lame_and_forgot_my_previous_context() >> > >> > Can all this information be generalized with some basic core hooks >> > or could some of this contextual informatioin typically vary depending >> > on the sequence we are in ? It sounds like its the later and that's >> > the issue ? >> >> That's what we do with context tracking. It tracks the context (user/kernel) >> and stores these informations. And indeed the contextual informations can >> vary >> depending for example if an exception triggered in userspace or kernelspace. > > Another question of interest is "Can things be arranged so that RCU uses > the context-tracking information directly in place of rcu_dynticks?" > In theory, the answer is clearly "yes", but the reason that RCU's > accounting is heavyweight is the need to get precise state readout on > other CPUs. So it is quite possible that making RCU directly use the > context-tracking information will make that tracking slower and more > complex, so that the overall effect will be zero net improvement. rcu_dynticks can be directly renamed and moved to context-tracking code. ^_^. If there any other code need to access the context-tracking information, rearranging the code will be better. I once tried to use pure context-tracking information to implement rcu_sys_is_idle(), the rearranging is needed, and it is to complicated to continue. Current rcu_sys_is_idle() is complicated though. > > But it does seem worth a look. > > Thanx, Paul > > ___ > Ksummit-discuss mailing list > ksummit-disc...@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [f2fs-dev] [PATCH 2/2 v3] f2fs: skip checkpoint if there is no dirty segments
Change log from v2:
- consider omitting current dirty segments
>From 181cb245f6a406e89c00976f65a5727956a72942 Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim
Date: Tue, 11 Aug 2015 21:59:49 -0700
Subject: [PATCH] f2fs: skip checkpoint if there is no dirty and prefree
segments
We should avoid needless checkpoints when there is no dirty and prefree segment.
eviewed-by: Chao Yu
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/gc.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index fcb263a..81de28d8 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -792,7 +792,8 @@ static void do_garbage_collect(struct f2fs_sb_info *sbi,
unsigned int segno,
int f2fs_gc(struct f2fs_sb_info *sbi)
{
- unsigned int segno, i;
+ unsigned int segno = NULL_SEGNO;
+ unsigned int i;
int gc_type = BG_GC;
int nfree = 0;
int ret = -1;
@@ -811,10 +812,11 @@ gc_more:
if (gc_type == BG_GC && has_not_enough_free_secs(sbi, nfree)) {
gc_type = FG_GC;
- write_checkpoint(sbi, );
+ if (__get_victim(sbi, , gc_type) || prefree_segments(sbi))
+ write_checkpoint(sbi, );
}
- if (!__get_victim(sbi, , gc_type))
+ if (segno == NULL_SEGNO && !__get_victim(sbi, , gc_type))
goto stop;
ret = 0;
--
2.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] vfio: Enable VFIO device for powerpc
ec53500f "kvm: Add VFIO device" added a special KVM pseudo-device which is used to handle any necessary interactions between KVM and VFIO. Currently that device is built on x86 and ARM, but not powerpc, although powerpc does support both KVM and VFIO. This makes things awkward in userspace Currently qemu prints an alarming error message if you attempt to use VFIO and it can't initialize the KVM VFIO device. We don't want to remove the warning, because lack of the KVM VFIO device could mean coherency problems on x86. On powerpc, however, the error is harmless but looks disturbing, and a test based on host architecture in qemu would be ugly, and break if we do need the KVM VFIO device for something important in future. There's nothing preventing the KVM VFIO device from being built for powerpc, so this patch turns it on. It won't actually do anything, since we don't define any of the arch_*() hooks, but it will make qemu happy and we can extend it in future if we need to. Signed-off-by: David Gibson Reviewed-by: Eric Auger --- arch/powerpc/kvm/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Alex (Graf), sorry, forgot to send this to you on my first posting of this patch, but I'm guessing it's your tree it should go in via. Resending, with Eric's reviewed-by line folded in. Please apply. diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile index 0570eef..7f7b6d8 100644 --- a/arch/powerpc/kvm/Makefile +++ b/arch/powerpc/kvm/Makefile @@ -8,7 +8,7 @@ ccflags-y := -Ivirt/kvm -Iarch/powerpc/kvm KVM := ../../../virt/kvm common-objs-y = $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o \ - $(KVM)/eventfd.o + $(KVM)/eventfd.o $(KVM)/vfio.o CFLAGS_e500_mmu.o := -I. CFLAGS_e500_mmu_host.o := -I. -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Patch "x86/asm/entry/64: Remove pointless jump to irq_return" has been added to the 4.1-stable tree
This is a note to let you know that I've just added the patch titled x86/asm/entry/64: Remove pointless jump to irq_return to the 4.1-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: x86-asm-entry-64-remove-pointless-jump-to-irq_return.patch and it can be found in the queue-4.1 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >From 5ca6f70f387b4f82903037cc3c5488e2c97dcdbc Mon Sep 17 00:00:00 2001 From: Andy Lutomirski Date: Thu, 4 Jun 2015 13:24:29 -0700 Subject: x86/asm/entry/64: Remove pointless jump to irq_return From: Andy Lutomirski commit 5ca6f70f387b4f82903037cc3c5488e2c97dcdbc upstream. INTERRUPT_RETURN turns into a jmp instruction. There's no need for extra indirection. Signed-off-by: Andy Lutomirski Cc: Cc: Andrew Morton Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/2f2318653dbad284a59311f13f08cea71298fd7c.1433449436.git.l...@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman --- arch/x86/kernel/entry_64.S |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) --- a/arch/x86/kernel/entry_64.S +++ b/arch/x86/kernel/entry_64.S @@ -793,8 +793,6 @@ retint_kernel: restore_c_regs_and_iret: RESTORE_C_REGS REMOVE_PT_GPREGS_FROM_STACK 8 - -irq_return: INTERRUPT_RETURN ENTRY(native_iret) @@ -1640,7 +1638,7 @@ nmi_restore: /* Clear the NMI executing stack variable */ movq $0, 5*8(%rsp) - jmp irq_return + INTERRUPT_RETURN CFI_ENDPROC END(nmi) Patches currently in stable-queue which might be from l...@kernel.org are queue-4.1/x86-nmi-enable-nested-do_nmi-handling-for-64-bit-kernels.patch queue-4.1/x86-nmi-64-switch-stacks-on-userspace-nmi-entry.patch queue-4.1/x86-nmi-64-remove-asm-code-that-saves-cr2.patch queue-4.1/x86-nmi-64-use-df-to-avoid-userspace-rsp-confusing-nested-nmi-detection.patch queue-4.1/x86-asm-entry-64-remove-pointless-jump-to-irq_return.patch queue-4.1/x86-nmi-64-reorder-nested-nmi-checks.patch queue-4.1/x86-nmi-64-improve-nested-nmi-comments.patch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] MODSIGN: Use PKCS#7 for module signatures [ver #8]
On Wed, 12 Aug 2015, David Howells wrote: > Hi James, > > Can you pull this into security/next please? Its aim is twofold: firstly, > make the module signatures of PKCS#7/CMS format rather than a home-brewed > format and secondly to pave the way for use of the signing code for > firmware signatures (to follow later). I'm still seeing these warnings: scripts/sign-file.c: In function ‘main’: scripts/sign-file.c:188: warning: value computed is not used WARNING: modpost: missing MODULE_LICENSE() in crypto/asymmetric_keys/pkcs7_test_key.o -- James Morris
[PATCH 7/7] ARM: bcm2835: Add VC4 to the device tree.
Signed-off-by: Eric Anholt
---
arch/arm/boot/dts/bcm2835.dtsi | 43 ++
1 file changed, 43 insertions(+)
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 8f3ba88..dda67aa 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -1,4 +1,5 @@
#include
+#include
#include "skeleton.dtsi"
/ {
@@ -167,6 +168,48 @@
arm-pmu {
compatible = "arm,arm1176-pmu";
};
+
+ hdmi: brcm,vc4-hdmi@7e902000 {
+ compatible = "brcm,vc4-hdmi";
+ reg = <0x7e902000 0x600>,
+ <0x7e808000 0x100>;
+ interrupts = <2 8>, <2 9>;
+ ddc = <>;
+ hpd-gpio = < 46 GPIO_ACTIVE_HIGH>;
+ crtc = <>;
+ };
+
+ pv0: brcm,vc4-pixelvalve@7e206000 {
+ compatible = "brcm,vc4-pixelvalve";
+ reg = <0x7e206000 0x100>;
+ interrupts = <2 13>; /* pwa2 */
+ };
+
+ pv1: brcm,vc4-pixelvalve@7e207000 {
+ compatible = "brcm,vc4-pixelvalve";
+ reg = <0x7e207000 0x100>;
+ interrupts = <2 14>; /* pwa1 */
+ };
+
+ pv2: brcm,vc4-pixelvalve@7e807000 {
+ compatible = "brcm,vc4-pixelvalve";
+ reg = <0x7e807000 0x100>;
+ interrupts = <2 10>; /* pixelvalve */
+ };
+
+ hvs: brcm,hvs@7e40 {
+ compatible = "brcm,vc4-hvs";
+ reg = <0x7e40 0x6000>;
+ interrupts = <2 1>;
+ };
+
+ vc4: vc4@0x7e4c {
+ compatible = "brcm,vc4";
+
+ crtcs = <>, <>, <>;
+ encoders = <>;
+ hvss = <>;
+ };
};
clocks {
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
what's cooking in zram for 4.2
Hello Karel, ... planned to write this earlier. zram will see some user-space visible improvements in 4.2 we'd love to let you know about -- on-demand device creation/removal. For that purpose we introduce zram control sysfs class, which has two sysfs attrs: - hot_add -- add a new zram device - hot_remove -- remove a specific (device_id) zram device -- hot_add sysfs attr is read-only and has only automatic device id assignment mode. Read operation performed on this attr creates a new zram device and returns back its device_id (or error (ret < 0)). Usage example: # add a new zram device cat /sys/class/zram-control/hot_add 2 an example of returning error code (-ENOMEM in this case) cat /sys/class/zram-control/hot_add cat: /sys/class/zram-control/hot_add: Cannot allocate memory -- hot_remove is write only and requires a valid zram device_id as its input parameter: # remove a specific zram device echo 4 > /sys/class/zram-control/hot_remove -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi.
This is the start of a full VC4 driver. Right now this just supports
configuring the display using a pre-existing video mode (because
changing the pixel clock isn't available yet, and doesn't work when it
is). However, this is enough for fbcon and bringing up X using
xf86-video-modesetting.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/vc4/Kconfig | 14 +
drivers/gpu/drm/vc4/Makefile | 18 ++
drivers/gpu/drm/vc4/vc4_bo.c | 54
drivers/gpu/drm/vc4/vc4_crtc.c| 583 ++
drivers/gpu/drm/vc4/vc4_debugfs.c | 38 +++
drivers/gpu/drm/vc4/vc4_drv.c | 249 +++
drivers/gpu/drm/vc4/vc4_drv.h | 123 +++
drivers/gpu/drm/vc4/vc4_hdmi.c| 651 ++
drivers/gpu/drm/vc4/vc4_hvs.c | 172 ++
drivers/gpu/drm/vc4/vc4_kms.c | 84 +
drivers/gpu/drm/vc4/vc4_plane.c | 320 +++
drivers/gpu/drm/vc4/vc4_regs.h| 562
14 files changed, 2871 insertions(+)
create mode 100644 drivers/gpu/drm/vc4/Kconfig
create mode 100644 drivers/gpu/drm/vc4/Makefile
create mode 100644 drivers/gpu/drm/vc4/vc4_bo.c
create mode 100644 drivers/gpu/drm/vc4/vc4_crtc.c
create mode 100644 drivers/gpu/drm/vc4/vc4_debugfs.c
create mode 100644 drivers/gpu/drm/vc4/vc4_drv.c
create mode 100644 drivers/gpu/drm/vc4/vc4_drv.h
create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi.c
create mode 100644 drivers/gpu/drm/vc4/vc4_hvs.c
create mode 100644 drivers/gpu/drm/vc4/vc4_kms.c
create mode 100644 drivers/gpu/drm/vc4/vc4_plane.c
create mode 100644 drivers/gpu/drm/vc4/vc4_regs.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index c46ca31..1730a76 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -240,3 +240,5 @@ source "drivers/gpu/drm/sti/Kconfig"
source "drivers/gpu/drm/amd/amdkfd/Kconfig"
source "drivers/gpu/drm/imx/Kconfig"
+
+source "drivers/gpu/drm/vc4/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 5713d05..b991ac5 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_DRM_MGA) += mga/
obj-$(CONFIG_DRM_I810) += i810/
obj-$(CONFIG_DRM_I915) += i915/
obj-$(CONFIG_DRM_MGAG200) += mgag200/
+obj-$(CONFIG_DRM_VC4) += vc4/
obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
obj-$(CONFIG_DRM_SIS) += sis/
obj-$(CONFIG_DRM_SAVAGE)+= savage/
diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
new file mode 100644
index 000..130cc94
--- /dev/null
+++ b/drivers/gpu/drm/vc4/Kconfig
@@ -0,0 +1,14 @@
+config DRM_VC4
+ tristate "Broadcom VC4 Graphics"
+ depends on ARCH_BCM2835
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
+ select DRM_KMS_CMA_HELPER
+ help
+ Choose this option if you have a system that has a Broadcom
+ VC4 GPU, such as the Raspberry Pi or other BCM2708/BCM2835.
+
+ This driver requires that "avoid_warnings=2" be present in
+ the config.txt for the firmware, to keep it from smashing
+ our display setup.
diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
new file mode 100644
index 000..4aa07ca
--- /dev/null
+++ b/drivers/gpu/drm/vc4/Makefile
@@ -0,0 +1,18 @@
+ccflags-y := -Iinclude/drm
+
+# Please keep these build lists sorted!
+
+# core driver code
+vc4-y := \
+ vc4_bo.o \
+ vc4_crtc.o \
+ vc4_drv.o \
+ vc4_kms.o \
+ vc4_hdmi.o \
+ vc4_hvs.o \
+ vc4_plane.o \
+ $()
+
+vc4-$(CONFIG_DEBUG_FS) += vc4_debugfs.o
+
+obj-$(CONFIG_DRM_VC4) += vc4.o
diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
new file mode 100644
index 000..fee8cac
--- /dev/null
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -0,0 +1,54 @@
+/*
+ * Copyright © 2015 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/* DOC: VC4 GEM BO management support.
+ *
+ * The VC4 GPU architecture (both scanout and rendering) has direct
+ * access to system memory with no MMU in between. To support it, we
+ * use the GEM CMA helper functions to allocate contiguous ranges of
+ * physical memory for our BOs.
+ */
+
+#include "vc4_drv.h"
+
+struct vc4_bo *vc4_bo_create(struct drm_device *dev, size_t size)
+{
+ struct drm_gem_cma_object *cma_obj;
+
+ cma_obj = drm_gem_cma_create(dev, size);
+ if (IS_ERR(cma_obj))
+ return NULL;
+ else
+ return to_vc4_bo(_obj->base);
+}
+
+int vc4_dumb_create(struct drm_file *file_priv,
+ struct drm_device *dev,
+ struct drm_mode_create_dumb *args)
+{
+ int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
+
[PATCH 6/7] ARM: bcm2835: Add the DDC I2C controller to the device tree.
We need to use it for getting video modes over HDMI.
Signed-off-by: Eric Anholt
---
arch/arm/boot/dts/bcm2835.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 301c73f..8f3ba88 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -149,6 +149,15 @@
status = "disabled";
};
+ i2c2: i2c@7e805000 {
+ compatible = "brcm,bcm2835-i2c";
+ reg = <0x7e805000 0x1000>;
+ interrupts = <2 21>;
+ clocks = <_i2c>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
usb@7e98 {
compatible = "brcm,bcm2835-usb";
reg = <0x7e98 0x1>;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] drm/vc4: Add devicetree bindings for VC4.
Signed-off-by: Eric Anholt
---
.../devicetree/bindings/gpu/brcm,bcm-vc4.txt | 83 ++
1 file changed, 83 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
new file mode 100644
index 000..2b13e61
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
@@ -0,0 +1,83 @@
+Broadcom VC4 GPU
+
+The VC4 device present on the Raspberry Pi includes a display system
+with HDMI output and the HVS scaler for compositing display planes.
+
+Required properties for VC4:
+- compatible: Should be "brcm,vc4"
+- crtcs: List of references to pixelvalve scanout engines
+- hvss:List of references to HVS video scalers
+- encoders:List of references to output encoders (HDMI, SDTV)
+
+Required properties for Pixel Valve:
+- compatible: Should be "brcm,vc4-pixelvalve"
+- reg: Physical base address and length of the PV's registers
+- interrupts: The interrupt number
+ See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+
+Required properties for HVS:
+- compatible: Should be "brcm,vc4-hvs"
+- reg: Physical base address and length of the HVS's registers
+- interrupts: The interrupt number
+ See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+
+Required properties for HDMI
+- compatible: Should be "brcm,vc4-hdmi"
+- reg: Physical base address and length of the two register ranges
+ ("HDMI" and "HD")
+- interrupts: The interrupt numbers
+ See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+- ddc: phandle of the I2C controller used for DDC EDID probing
+- crtc:phandle to the pixelvalve CRTC the HDMI encoder is
attached to
+
+Optional properties for HDMI:
+- hpd-gpio:The GPIO pin for HDMI hotplug detect (if it doesn't appear
+ as an interrupt/status bit in the HDMI controller
+ itself). See bindings/pinctrl/brcm,bcm2835-gpio.txt
+
+Example:
+/ {
+ soc {
+ pv0: brcm,vc4-pixelvalve@7e206000 {
+ compatible = "brcm,vc4-pixelvalve";
+ reg = <0x7e206000 0x100>;
+ interrupts = <2 13>; /* pwa2 */
+ };
+
+ pv1: brcm,vc4-pixelvalve@7e207000 {
+ compatible = "brcm,vc4-pixelvalve";
+ reg = <0x7e207000 0x100>;
+ interrupts = <2 14>; /* pwa1 */
+ };
+
+ pv2: brcm,vc4-pixelvalve@7e807000 {
+ compatible = "brcm,vc4-pixelvalve";
+ reg = <0x7e807000 0x100>;
+ interrupts = <2 10>; /* pixelvalve */
+ };
+
+ hvs: brcm,hvs@7e40 {
+ compatible = "brcm,vc4-hvs";
+ reg = <0x7e40 0x6000>;
+ interrupts = <2 1>;
+ };
+
+ hdmi: brcm,vc4-hdmi@7e902000 {
+ compatible = "brcm,vc4-hdmi";
+ reg = <0x7e902000 0x600>,
+ <0x7e808000 0x100>;
+ interrupts = <2 8>, <2 9>;
+ ddc = <>;
+ hpd-gpio = < 46 GPIO_ACTIVE_HIGH>;
+ crtc = <>;
+ };
+
+ vc4: vc4@0x7e4c {
+ compatible = "brcm,vc4";
+
+ crtcs = <>, <>, <>;
+ encoders = <>;
+ hvss = <>;
+ };
+ };
+};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Raspberry Pi KMS-only driver
Here's the first patch series for graphics on the Raspberry Pi. It brings up fbcon on KMS, and the xf86-video-modesetting driver runs so you can do X with no further userspace drivers. Right now this series doesn't support changing video modes away from the firmware boot setup, because when I set the pixel clock using the rpi-dt-clocks series I end up with a black display. even on no-op modesets. I've dropped all of the 3D bits from this series, to simplify this review stage. See vc4-kms-v3d-rpi2 for a series that works with the current Mesa driver, based on downstream 2709. I squashed all of my messy KMS series down, but kept Derek's patches separate to make sure he gets credit. This code can also be found at: https://github.com/anholt/linux/tree/vc4-kms-squash -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/7] MAINTAINERS: Add myself for the new VC4 (RPi GPU) graphics driver.
Signed-off-by: Eric Anholt --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 8133cef..d0dc42c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3573,6 +3573,12 @@ S: Maintained F: drivers/gpu/drm/rockchip/ F: Documentation/devicetree/bindings/video/rockchip* +DRM DRIVERS FOR VC4 +M: Eric Anholt +T: git git://github.com/anholt/linux +S: Maintained +F: drivers/gpu/drm/vc4/* + DSBR100 USB FM RADIO DRIVER M: Alexey Klimov L: linux-me...@vger.kernel.org -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] drm/vc4: Allow vblank to be disabled
From: Derek Foreman Signed-off-by: Derek Foreman Signed-off-by: Eric Anholt --- drivers/gpu/drm/vc4/vc4_kms.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c index a34439f..f881cd4 100644 --- a/drivers/gpu/drm/vc4/vc4_kms.c +++ b/drivers/gpu/drm/vc4/vc4_kms.c @@ -77,6 +77,8 @@ int vc4_kms_load(struct drm_device *dev) dev->mode_config.funcs = _mode_funcs; dev->mode_config.preferred_depth = 24; + dev->vblank_disable_allowed = true; + ret = vc4_init_modeset_objects(dev); if (ret) goto fail; -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] drm/vc4: Use the fbdev_cma helpers
From: Derek Foreman
Keep the fbdev_cma pointer around so we can use it on hotplog and close
to ensure the frame buffer console is in a useful state.
Signed-off-by: Derek Foreman
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_drv.c | 15 +++
drivers/gpu/drm/vc4/vc4_drv.h | 2 ++
drivers/gpu/drm/vc4/vc4_kms.c | 18 +++---
3 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 9ecf4b8b..90414d1 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include "drm_fb_cma_helper.h"
#include "vc4_drv.h"
#include "vc4_regs.h"
@@ -70,6 +71,11 @@ static int vc4_drm_load(struct drm_device *dev, unsigned
long flags)
static int vc4_drm_unload(struct drm_device *dev)
{
+ struct vc4_dev *vc4 = to_vc4_dev(dev);
+
+ if (vc4->fbdev)
+ drm_fbdev_cma_fini(vc4->fbdev);
+
drm_mode_config_cleanup(dev);
component_unbind_all(dev->dev, dev);
@@ -85,6 +91,14 @@ static void vc4_drm_preclose(struct drm_device *dev, struct
drm_file *file)
vc4_cancel_page_flip(crtc, file);
}
+static void vc4_lastclose(struct drm_device *dev)
+{
+ struct vc4_dev *vc4 = to_vc4_dev(dev);
+
+ if (vc4->fbdev)
+ drm_fbdev_cma_restore_mode(vc4->fbdev);
+}
+
static const struct file_operations vc4_drm_fops = {
.owner = THIS_MODULE,
.open = drm_open,
@@ -109,6 +123,7 @@ static struct drm_driver vc4_drm_driver = {
DRIVER_PRIME),
.load = vc4_drm_load,
.unload = vc4_drm_unload,
+ .lastclose = vc4_lastclose,
.set_busid = drm_platform_set_busid,
.preclose = vc4_drm_preclose,
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 1b0a0b0..6edc14b 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -15,6 +15,8 @@ struct vc4_dev {
struct vc4_hdmi *hdmi;
struct vc4_hvs *hvs;
struct vc4_crtc *crtc[3];
+
+ struct drm_fbdev_cma *fbdev;
};
static inline struct vc4_dev *
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index e5e96bc..a34439f 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -21,7 +21,16 @@
#include "drm_fb_cma_helper.h"
#include "vc4_drv.h"
+static void vc4_output_poll_changed(struct drm_device *dev)
+{
+ struct vc4_dev *vc4 = to_vc4_dev(dev);
+
+ if (vc4->fbdev)
+ drm_fbdev_cma_hotplug_event(vc4->fbdev);
+}
+
static const struct drm_mode_config_funcs vc4_mode_funcs = {
+ .output_poll_changed = vc4_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
.fb_create = drm_fb_cma_create,
@@ -54,6 +63,7 @@ fail:
int vc4_kms_load(struct drm_device *dev)
{
+ struct vc4_dev *vc4 = to_vc4_dev(dev);
int ret;
ret = drm_vblank_init(dev, dev->mode_config.num_crtc);
@@ -73,9 +83,11 @@ int vc4_kms_load(struct drm_device *dev)
drm_mode_config_reset(dev);
- drm_fbdev_cma_init(dev, 32,
- dev->mode_config.num_crtc,
- dev->mode_config.num_connector);
+ vc4->fbdev = drm_fbdev_cma_init(dev, 32,
+ dev->mode_config.num_crtc,
+ dev->mode_config.num_connector);
+ if (IS_ERR(vc4->fbdev))
+ vc4->fbdev = NULL;
drm_kms_helper_poll_init(dev);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [REPOST PATCH] kexec: Remove the unnecessary conditional judgement to simplify the code logic
On Tue, Jul 28, 2015 at 12:46:42PM +0800, Minfei Huang wrote:
> Transforming PFN(Page Frame Number) to struct page is never failure, so
> we can simplify the code logic to do the image->control_page assignment
> directly in the loop, and remove the unnecessary conditional judgement.
>
> Signed-off-by: Minfei Huang
> Acked-by: Dave Young
> Acked-by: Vivek Goyal
Andrew, could you consider picking this up.
It seems to have been sufficiently reviewed, acked, etc...
> ---
> kernel/kexec.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 6f1ed75..cf82474 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -807,11 +807,10 @@ static struct page
> *kimage_alloc_crash_control_pages(struct kimage *image,
> /* If I don't overlap any segments I have found my hole! */
> if (i == image->nr_segments) {
> pages = pfn_to_page(hole_start >> PAGE_SHIFT);
> + image->control_page = hole_end;
> break;
> }
> }
> - if (pages)
> - image->control_page = hole_end;
>
> return pages;
> }
> --
> 2.4.0
>
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86, vsyscall: add CONFIG to control default
Most modern systems can run with vsyscall=none. In an effort to provide
a way for build-time defaults to lack legacy settings, this adds a new
CONFIG to select the type of vsyscall mapping to use, similar to the
existing "vsyscall" command line parameter.
Signed-off-by: Kees Cook
---
arch/x86/Kconfig | 49 +++
arch/x86/entry/vsyscall/vsyscall_64.c | 9 ++-
2 files changed, 57 insertions(+), 1 deletion(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b3a1a5d77d92..fbd0fad714a1 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2010,6 +2010,55 @@ config COMPAT_VDSO
If unsure, say N: if you are compiling your own kernel, you
are unlikely to be using a buggy version of glibc.
+choice
+ prompt "vsyscall table for legacy applications"
+ depends on X86_64
+ default LEGACY_VSYSCALL_EMULATE
+ help
+ Legacy user code that does not know how to find the vDSO expects
+ to be able to issue three syscalls by calling fixed addresses in
+ kernel space. Since this location is not randomized with ASLR,
+ it can be used to assist security vulnerability exploitation.
+
+ This setting can be changed at boot time via the kernel command
+ line parameter vsyscall=[native|emulate|none].
+
+ On a system with recent enough glibc (2.14 or newer) and no
+ static binaries, you can say None without a performance penalty
+ to improve security.
+
+ If unsure, select "Emulate".
+
+ config LEGACY_VSYSCALL_NATIVE
+ bool "Native"
+ help
+ Actual executable code is located in the fixed vsyscall
+ address mapping, implementing time() efficiently. Since
+ this makes the mapping executable, it can be used during
+ security vulnerability exploitation (traditionally as
+ ROP gadgets). This configuration is not recommended.
+
+ config LEGACY_VSYSCALL_EMULATE
+ bool "Emulate"
+ help
+ The kernel traps and emulates calls into the fixed
+ vsyscall address mapping. This makes the mapping
+ non-executable, but it still contains known contents,
+ which could be used in certain rare security vulnerability
+ exploits. This configuration is recommended when userspace
+ still uses the vsyscall area.
+
+ config LEGACY_VSYSCALL_NONE
+ bool "None"
+ help
+ There will be no vsyscall mapping at all. This will
+ eliminate any risk of ASLR bypass due to the vsyscall
+ fixed address mapping. Attempts to use the vsyscalls
+ will be reported to dmesg, so that either old or
+ malicious userspace programs can be identified.
+
+endchoice
+
config CMDLINE_BOOL
bool "Built-in kernel command line"
---help---
diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c
b/arch/x86/entry/vsyscall/vsyscall_64.c
index 2dcc6ff6fdcc..47e2904b043b 100644
--- a/arch/x86/entry/vsyscall/vsyscall_64.c
+++ b/arch/x86/entry/vsyscall/vsyscall_64.c
@@ -38,7 +38,14 @@
#define CREATE_TRACE_POINTS
#include "vsyscall_trace.h"
-static enum { EMULATE, NATIVE, NONE } vsyscall_mode = EMULATE;
+static enum { EMULATE, NATIVE, NONE } vsyscall_mode =
+#ifdef CONFIG_LEGACY_VSYSCALL_NATIVE
+ NATIVE;
+#elif CONFIG_LEGACY_VSYSCALL_NONE
+ NONE;
+#else
+ EMULATE;
+#endif
static int __init vsyscall_setup(char *str)
{
--
1.9.1
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the gpio tree
Hi Chanwoo,
On Thu, 13 Aug 2015 09:19:12 +0900 Chanwoo Choi wrote:
>
> Hi Stephen,
>
> On 08/13/2015 08:02 AM, Stephen Rothwell wrote:
> > Hi Uwe,
> >
> > On Wed, 12 Aug 2015 22:16:42 +0200 Uwe Kleine-König
> > wrote:
> >>
> >> On Wed, Aug 12, 2015 at 06:10:45PM +1000, Stephen Rothwell wrote:
> >>> After merging the gpio tree, today's linux-next build (powerpc
> >>> allyesconfig) failed like this:
> >>>
> >>> drivers/extcon/extcon-palmas.c:211:25: error: too few arguments to
> >>> function 'devm_gpiod_get_optional'
> >>> palmas_usb->id_gpiod = devm_gpiod_get_optional(>dev, "id");
> >>> ^
> >>> In file included from /home/sfr/next/next/include/asm-generic/gpio.h:13:0,
> >>> from /home/sfr/next/next/include/linux/gpio.h:51,
> >>> from /home/sfr/next/next/include/linux/of_gpio.h:20,
> >>> from /home/sfr/next/next/include/linux/mfd/palmas.h:24,
> >>> from
> >>> /home/sfr/next/next/drivers/extcon/extcon-palmas.c:28:
> >>> /home/sfr/next/next/include/linux/gpio/consumer.h:80:32: note: declared
> >>> here
> >>> struct gpio_desc *__must_check devm_gpiod_get_optional(struct device
> >>> *dev,
> >>> ^
> >>>
> >>> Caused by commit
> >>>
> >>> b17d1bf16cc7 ("gpio: make flags mandatory for gpiod_get functions")
> >>>
> >>> interacting with commit
> >>>
> >>> 92b7cb5dc885 ("extcon: palmas: Support GPIO based USB ID detection")
> >> that commit is not correct. After
> >>
> >>palmas_usb->id_gpiod = devm_gpiod_get_optional(>dev, "id");
> >>
> >> it does
> >>
> >>palmas_usb->gpio_id_irq = gpiod_to_irq(palmas_usb->id_gpiod);
> >>
> >> without setting the gpio to input. So the right fix is not to add
> >> GPIOD_ASIS but GPIOD_IN.
> >
> > OK, I have fixed my merge fix patch, but can you submit a correct patch
> > to the extcon tree maintainer, please? I assume it can be fixed in
> > that tree right now, right?
> >
>
> I'll fix it as Uwe comment as following:
>
> --- a/drivers/extcon/extcon-palmas.c
> +++ b/drivers/extcon/extcon-palmas.c
> @@ -208,7 +208,8 @@ static int palmas_usb_probe(struct platform_device *pdev)
> palmas_usb->wakeup = pdata->wakeup;
> }
>
> - palmas_usb->id_gpiod = devm_gpiod_get_optional(>dev, "id");
> + palmas_usb->id_gpiod =
> + devm_gpiod_get_optional(>dev, "id", GPIOD_IN);
> if (IS_ERR(palmas_usb->id_gpiod)) {
> dev_err(>dev, "failed to get id gpio\n");
> return PTR_ERR(palmas_usb->id_gpiod);
>
> I'll send it to LKML and apply it on extcon-next tree.
Thanks.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Aug 12 (include/linux/pci.h)
Hi Randy,
On Wed, 12 Aug 2015 17:16:39 -0700 Randy Dunlap wrote:
>
> On 08/12/15 15:58, Tadeusz Struk wrote:
> > Hi,
> > On 08/12/2015 02:53 PM, Stephen Rothwell wrote:
> >> On Wed, 12 Aug 2015 11:05:36 -0700 Randy Dunlap
> >> wrote:
>
> on i386 or x86_64:
>
> Many (repeated) errors like this one:
>
> ../include/linux/pci.h:390:12: error: âstruct pci_devâ has no member
> named âphysfnâ
>
> when CONFIG_PCI_ATS is not enabled.
> >> Maybe caused by commit
> >>
> >> dd0f368398ea ("crypto: qat - Add qat dh895xcc VF driver")
> >>
> >> from the crypto tree Which adds a
> >>
> >> select PCI_IOV
> >>
> >> to drivers/crypto/qat/Kconfig without the necessary
> >>
> >> select PCI
> >>
> >> but PCI_IOV selects PCI_ATS, so I am not sure what happened here. I am
> >> assuming that your config has PCI_IOV enabled? What about PCI?
> >
> > There is a patch submitted, but not yet applied
> > https://patchwork.kernel.org/patch/6994171/
> > maybe it will help?
>
> Yes, that works for me. Thanks.
Thanks for doing that.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status
On Wed, Aug 12, 2015 at 01:30:27PM -0700, David Rientjes wrote:
> On Wed, 12 Aug 2015, Naoya Horiguchi wrote:
>
> > Currently there's no easy way to get per-process usage of hugetlb pages,
> > which
> > is inconvenient because userspace applications which use hugetlb typically
> > want
> > to control their processes on the basis of how much memory (including
> > hugetlb)
> > they use. So this patch simply provides easy access to the info via
> > /proc/PID/status.
> >
> > With this patch, for example, /proc/PID/status shows a line like this:
> >
> > HugetlbPages: 20480 kB (10x2048kB)
> >
> > If your system supports and enables multiple hugepage sizes, the line looks
> > like this:
> >
> > HugetlbPages:1069056 kB (1x1048576kB 10x2048kB)
> >
> > , so you can easily know how many hugepages in which pagesize are used by a
> > process.
> >
> > Signed-off-by: Naoya Horiguchi
>
> I'm happy with this and thanks very much for going the extra mile and
> breaking the usage down by hstate size.
Great to hear that.
> I'd be interested in the comments of others, though, to see if there is
> any reservation about the hstate size breakdown. It may actually find no
> current customer who is interested in parsing it. (If we keep it, I would
> suggest the 'x' change to '*' similar to per-order breakdowns in
> show_mem()). It may also be possible to add it later if a definitive
> usecase is presented.
I'm fine to change to '*'.
Thanks,
Naoya Horiguchi
---
From: Naoya Horiguchi
Subject: [PATCH] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status
Currently there's no easy way to get per-process usage of hugetlb pages, which
is inconvenient because userspace applications which use hugetlb typically want
to control their processes on the basis of how much memory (including hugetlb)
they use. So this patch simply provides easy access to the info via
/proc/PID/status.
With this patch, for example, /proc/PID/status shows a line like this:
HugetlbPages: 20480 kB (10*2048kB)
If your system supports and enables multiple hugepage sizes, the line looks
like this:
HugetlbPages:1069056 kB (1*1048576kB 10*2048kB)
, so you can easily know how many hugepages in which pagesize are used by a
process.
Signed-off-by: Naoya Horiguchi
---
Documentation/filesystems/proc.txt | 3 +++
fs/proc/task_mmu.c | 1 +
include/linux/hugetlb.h| 20
include/linux/mm_types.h | 10 ++
mm/hugetlb.c | 27 +++
mm/rmap.c | 4 +++-
6 files changed, 64 insertions(+), 1 deletion(-)
diff --git a/Documentation/filesystems/proc.txt
b/Documentation/filesystems/proc.txt
index 22e40211ef64..f561fc46e41b 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -174,6 +174,7 @@ For example, to get the status information of a process,
all you have to do is
VmLib: 1412 kB
VmPTE:20 kb
VmSwap:0 kB
+ HugetlbPages: 0 kB (0*2048kB)
Threads:1
SigQ: 0/28578
SigPnd:
@@ -237,6 +238,8 @@ Table 1-2: Contents of the status files (as of 4.1)
VmPTE size of page table entries
VmPMD size of second level page tables
VmSwap size of swap usage (the number of referred
swapents)
+ HugetlbPagessize of hugetlb memory portions (with additional
info
+ about number of mapped hugepages for each page
size)
Threads number of threads
SigQnumber of signals queued/max. number for queue
SigPnd bitmap of pending signals for the thread
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 2c37938b82ee..b3cf7fa9ef6c 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -69,6 +69,7 @@ void task_mem(struct seq_file *m, struct mm_struct *mm)
ptes >> 10,
pmds >> 10,
swap << (PAGE_SHIFT-10));
+ hugetlb_report_usage(m, mm);
}
unsigned long task_vsize(struct mm_struct *mm)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index d891f949466a..64aa4db01f48 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -469,6 +469,18 @@ static inline spinlock_t *huge_pte_lockptr(struct hstate
*h,
#define hugepages_supported() (HPAGE_SHIFT != 0)
#endif
+void hugetlb_report_usage(struct seq_file *m, struct mm_struct *mm);
+
+static inline void inc_hugetlb_count(struct mm_struct *mm, struct hstate *h)
+{
+ atomic_long_inc(>hugetlb_usage.count[hstate_index(h)]);
+}
+
+static inline void dec_hugetlb_count(struct mm_struct *mm, struct hstate *h)
+{
+ atomic_long_dec(>hugetlb_usage.count[hstate_index(h)]);
+}
+
#else /* CONFIG_HUGETLB_PAGE */
struct hstate {};
#define alloc_huge_page_node(h, nid) NULL
@@ -504,6 +516,14
Re: [PATCH] extcon: fix signedness issues
Hi Brian, On 08/13/2015 07:57 AM, Brian Norris wrote: > On Tue, Aug 11, 2015 at 03:56:44PM +0900, Chanwoo Choi wrote: >> I knew this issue. So patch[1] fixed it already. > > Awesome. > > FWIW, my Google-fu fails to find this patch on any mail archive; just > your pull request. You can check it on patch[3]. As I add commit message of patch[1], I modified the patch title. [3] https://lkml.org/lkml/2015/8/4/89 Thanks, Chanwoo Choi > >> I sent the extcon pull request[2] including patch[1] for Linux 4.3. >> >> [1] >> http://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/commit/?h=extcon-next=a598af7f0279195abffbfb9bf2070457e9c89ff3 >> [2] https://lkml.org/lkml/2015/8/11/5 > > Regards, > Brian > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4.2-rc4] acpi|drm|i915: circular locking dependency: acpi_video_get_backlight_type
On Monday, August 10, 2015 08:29:00 PM Sedat Dilek wrote:
> On Sat, Aug 1, 2015 at 2:23 PM, Sedat Dilek wrote:
> > On Mon, Jul 27, 2015 at 12:33 AM, Sedat Dilek wrote:
> >> Hi,
> >>
> >> this my first build of a 4.2-rcN Linux-kernel and I see this...
> >>
> >
> > Just FYI:
> >
> > I am *not* seeing this with drm-intel-nightly from below url.
> >
> > Also, I plan to test Linux v4.2-rc5.
> >
>
> [ CC Linus ]
>
> Knock Knock Knock.
The lock this is related to has been introduced by a commit from Hans (CCed).
Unfortunately, I'm out of office this week and I'll be traveling next week,
so my personal ability to look into this issue is rather limited ATM. Sorry
about that.
> This issue still remains here (with CONFIG_DRM_I915=m)...
>
> [ 18.269792] ==
> [ 18.269798] [ INFO: possible circular locking dependency detected ]
> [ 18.269805] 4.2.0-rc6-1-iniza-small #1 Not tainted
> [ 18.269810] ---
> [ 18.269816] modprobe/727 is trying to acquire lock:
> [ 18.269822] (init_mutex){+.+.+.}, at: []
> acpi_video_get_backlight_type+0x17/0x164 [video]
> [ 18.269840]
> [ 18.269840] but task is already holding lock:
> [ 18.269848] (&(_notifier)->rwsem){..}, at:
> [] __blocking_notifier_call_chain+0x39/0x70
> [ 18.269864]
> [ 18.269864] which lock already depends on the new lock.
> [ 18.269864]
> [ 18.269875]
> [ 18.269875] the existing dependency chain (in reverse order) is:
> [ 18.269884]
> ...
>
> Full dmesg log and kernel-config attached.
>
> Shall I add Rusty and modules/modprobe folks?
>
> - Sedat -
>
> > - Sedat -
> >
> > [1]
> > http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-08-01-unstable/
> > [2]
> > http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2015-08-01-unstable/linux-image-4.2.0-994-generic_4.2.0-994.201508010158_amd64.deb
> >
> >> [ 24.001043] [drm] Memory usable by graphics device = 2048M
> >> [ 24.001118] [drm] Replacing VGA console driver
> >> [ 24.011642] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> >> [ 24.011646] [drm] Driver supports precise vblank timestamp query.
> >> [ 24.012480] vgaarb: device changed decodes:
> >> PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
> >> [ 24.028005]
> >> [ 24.028014] ==
> >> [ 24.028020] [ INFO: possible circular locking dependency detected ]
> >> [ 24.028027] 4.2.0-rc4-1-iniza-small #1 Not tainted
> >> [ 24.028032] ---
> >> [ 24.028038] modprobe/740 is trying to acquire lock:
> >> [ 24.028043] (init_mutex){+.+.+.}, at: []
> >> acpi_video_get_backlight_type+0x17/0x164 [video]
> >> [ 24.028060]
> >> [ 24.028060] but task is already holding lock:
> >> [ 24.028068] (&(_notifier)->rwsem){..}, at:
> >> [] __blocking_notifier_call_chain+0x39/0x70
> >> [ 24.028083]
> >> [ 24.028083] which lock already depends on the new lock.
> >> [ 24.028083]
> >> [ 24.028095]
> >> [ 24.028095] the existing dependency chain (in reverse order) is:
> >> [ 24.028103]
> >> [ 24.028103] -> #1 (&(_notifier)->rwsem){..}:
> >> [ 24.028113][] lock_acquire+0xcf/0x280
> >> [ 24.028121][] down_write+0x49/0x80
> >> [ 24.028129][]
> >> blocking_notifier_chain_register+0x21/0xb0
> >> [ 24.028138][]
> >> backlight_register_notifier+0x18/0x20
> >> [ 24.028147][]
> >> acpi_video_get_backlight_type+0xfa/0x164 [video]
> >> [ 24.028158][] 0xa00a20e9
> >> [ 24.028164][] do_one_initcall+0x88/0x1c0
> >> [ 24.028172][] do_init_module+0x61/0x1ec
> >> [ 24.028179][] load_module+0x2008/0x25c0
> >> [ 24.028187][] SyS_init_module+0x126/0x140
> >> [ 24.028194][]
> >> entry_SYSCALL_64_fastpath+0x16/0x7a
> >> [ 24.028202]
> >> [ 24.028202] -> #0 (init_mutex){+.+.+.}:
> >> [ 24.028211][] __lock_acquire+0x1f5d/0x21c0
> >> [ 24.028218][] lock_acquire+0xcf/0x280
> >> [ 24.028225][] mutex_lock_nested+0x65/0x3c0
> >> [ 24.028233][]
> >> acpi_video_get_backlight_type+0x17/0x164 [video]
> >> [ 24.028243][]
> >> acpi_video_backlight_notify+0x19/0x2f [video]
> >> [ 24.028253][] notifier_call_chain+0x5d/0x80
> >> [ 24.028260][]
> >> __blocking_notifier_call_chain+0x51/0x70
> >> [ 24.028269][]
> >> blocking_notifier_call_chain+0x16/0x20
> >> [ 24.028278][]
> >> backlight_device_register+0x197/0x240
> >> [ 24.028286][]
> >> intel_backlight_register+0xb3/0x180 [i915]
> >> [ 24.028336][]
> >> intel_modeset_gem_init+0x176/0x190 [i915]
> >> [ 24.028371][] i915_driver_load+0xf12/0x14d0
> >> [i915]
> >> [ 24.028406][] drm_dev_register+0xb1/0x100
> >> [drm]
> >> [ 24.028425][] drm_get_pci_dev+0x8d/0x1e0
Re: [PATCH] ARM: dts: exynos4412-odroidu3: Enable SPI1.
On 12.08.2015 20:27, Alexis Ballier wrote:
> SPI1 is available on IO Port #2 (as depicted on their website) in
> PCB Revision 0.5 of Hardkernel Odroid U3 board.
> The shield connects a 256KiB spi-nor flash on that bus.
>
> Signed-off-by: Alexis Ballier
> ---
> arch/arm/boot/dts/exynos4412-odroidu3.dts | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
> b/arch/arm/boot/dts/exynos4412-odroidu3.dts
> index 44684e5..37698e4 100644
> --- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
> +++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
> @@ -61,3 +61,10 @@
> "Speakers", "SPKL",
> "Speakers", "SPKR";
> };
> +
> +_1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <_bus>;
> + cs-gpios = < 5 0>;
Please use GPIO_ACTIVE_HIGH.
Best regards,
Krzysztof
> + status = "okay";
> +};
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] extcon: palmas: Fix build break due to devm_gpiod_get_optional API change
Commit b17d1bf16cc7 ("gpio: make flags mandatory for gpiod_get functions")
changes the prototype of devm_gpiod_get_optional() API which should include
the falgs mandatory.
Reported-by: Stephen Rothwell
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon-palmas.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
index 662e91778cb0..308928d44ead 100644
--- a/drivers/extcon/extcon-palmas.c
+++ b/drivers/extcon/extcon-palmas.c
@@ -208,7 +208,8 @@ static int palmas_usb_probe(struct platform_device *pdev)
palmas_usb->wakeup = pdata->wakeup;
}
- palmas_usb->id_gpiod = devm_gpiod_get_optional(>dev, "id");
+ palmas_usb->id_gpiod = devm_gpiod_get_optional(>dev, "id",
+ GPIOD_IN);
if (IS_ERR(palmas_usb->id_gpiod)) {
dev_err(>dev, "failed to get id gpio\n");
return PTR_ERR(palmas_usb->id_gpiod);
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] sched: sync with the prev cfs when changing cgroup within a cpu
From: Byungchul Park
change from v3 to v4
* adjust cfs load in "queued" case, too
change from v2 to v3
* rebase to tip git
change from v1 to v2
* use #ifdef CONFIG_SMP to load tracking code
* make commit message compact which made confused
->8-
>From 1d5bcc21cece51eca250986846ed9b01a174bd54 Mon Sep 17 00:00:00 2001
From: Byungchul Park
Date: Thu, 13 Aug 2015 09:18:07 +0900
Subject: [PATCH v4] sched: sync with the prev cfs when changing cgroup within
a cpu
current code seems to be wrong with cfs_rq's avg loads when changing
a task's cgroup(=cfs_rq) to another. i tested with "echo pid > cgroup" and
found that e.g. cfs_rq->avg.load_avg became larger and larger whenever i
changed a cgroup to another again and again.
we have to sync se's average load with both *prev* cfs_rq and next cfs_rq
when changing its group.
Signed-off-by: Byungchul Park
---
kernel/sched/fair.c | 34 --
1 file changed, 24 insertions(+), 10 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 2a33d7b..979ca2c 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -8017,23 +8017,37 @@ static void task_move_group_fair(struct task_struct *p,
int queued)
if (!queued && (!se->sum_exec_runtime || p->state == TASK_WAKING))
queued = 1;
+ cfs_rq = cfs_rq_of(se);
if (!queued)
- se->vruntime -= cfs_rq_of(se)->min_vruntime;
+ se->vruntime -= cfs_rq->min_vruntime;
+
+#ifdef CONFIG_SMP
+ /* synchronize task with its prev cfs_rq */
+ if (!queued)
+ __update_load_avg(cfs_rq->avg.last_update_time,
cpu_of(rq_of(cfs_rq)),
+ >avg, se->on_rq *
scale_load_down(se->load.weight),
+ cfs_rq->curr == se, NULL);
+
+ /* remove our load when we leave */
+ cfs_rq->avg.load_avg = max_t(long, cfs_rq->avg.load_avg -
se->avg.load_avg, 0);
+ cfs_rq->avg.load_sum = max_t(s64, cfs_rq->avg.load_sum -
se->avg.load_sum, 0);
+ cfs_rq->avg.util_avg = max_t(long, cfs_rq->avg.util_avg -
se->avg.util_avg, 0);
+ cfs_rq->avg.util_sum = max_t(s32, cfs_rq->avg.util_sum -
se->avg.util_sum, 0);
+#endif
set_task_rq(p, task_cpu(p));
se->depth = se->parent ? se->parent->depth + 1 : 0;
- if (!queued) {
- cfs_rq = cfs_rq_of(se);
+ cfs_rq = cfs_rq_of(se);
+ if (!queued)
se->vruntime += cfs_rq->min_vruntime;
#ifdef CONFIG_SMP
- /* Virtually synchronize task with its new cfs_rq */
- p->se.avg.last_update_time = cfs_rq->avg.last_update_time;
- cfs_rq->avg.load_avg += p->se.avg.load_avg;
- cfs_rq->avg.load_sum += p->se.avg.load_sum;
- cfs_rq->avg.util_avg += p->se.avg.util_avg;
- cfs_rq->avg.util_sum += p->se.avg.util_sum;
+ /* Virtually synchronize task with its new cfs_rq */
+ p->se.avg.last_update_time = cfs_rq->avg.last_update_time;
+ cfs_rq->avg.load_avg += p->se.avg.load_avg;
+ cfs_rq->avg.load_sum += p->se.avg.load_sum;
+ cfs_rq->avg.util_avg += p->se.avg.util_avg;
+ cfs_rq->avg.util_sum += p->se.avg.util_sum;
#endif
- }
}
void free_fair_sched_group(struct task_group *tg)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] m68k/coldfire: use PFN_DOWN macro
Hi Alexander, On 12/08/15 17:14, Alexander Kuleshov wrote: > Replace ((x) >> PAGE_SHIFT) with the predefined PFN_DOWN macro. > > Signed-off-by: Alexander Kuleshov This one looks good. Applied to m68knommu git tree (for-next branch). Thanks Greg > --- > arch/m68k/coldfire/m54xx.c | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/arch/m68k/coldfire/m54xx.c b/arch/m68k/coldfire/m54xx.c > index 075aaab..f7836c6 100644 > --- a/arch/m68k/coldfire/m54xx.c > +++ b/arch/m68k/coldfire/m54xx.c > @@ -25,6 +25,7 @@ > #include > #ifdef CONFIG_MMU > #include > +#include > #endif > > /***/ > @@ -91,13 +92,13 @@ static void __init mcf54xx_bootmem_alloc(void) > m68k_memory[0].size = _ramend - _rambase; > > /* compute total pages in system */ > - num_pages = (_ramend - _rambase) >> PAGE_SHIFT; > + num_pages = PFN_DOWN(_ramend - _rambase); > > /* page numbers */ > memstart = PAGE_ALIGN(_ramstart); > - min_low_pfn = _rambase >> PAGE_SHIFT; > - start_pfn = memstart >> PAGE_SHIFT; > - max_low_pfn = _ramend >> PAGE_SHIFT; > + min_low_pfn = PFN_DOWN(_rambase); > + start_pfn = PFN_DOWN(memstart); > + max_low_pfn = PFN_DOWN(_ramend); > high_memory = (void *)_ramend; > > m68k_virt_to_node_shift = fls(_ramend - _rambase - 1) - 6; > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 3/8] cleanup IORESOURCE_CACHEABLE vs ioremap()
Quoting Arnd:
I was thinking the opposite approach and basically removing all uses
of IORESOURCE_CACHEABLE from the kernel. There are only a handful of
them.and we can probably replace them all with hardcoded
ioremap_cached() calls in the cases they are actually useful.
All existing usages of IORESOURCE_CACHEABLE call ioremap() instead of
ioremap_nocache() if the resource is cacheable, however ioremap() is
uncached by default. Clearly none of the existing usages care about the
cacheability. Particularly devm_ioremap_resource() never worked as
advertised since it always fell back to plain ioremap().
Clean this up as the new direction we want is to convert
ioremap_() usages to memremap(..., flags).
Suggested-by: Arnd Bergmann
Signed-off-by: Dan Williams
---
arch/arm/mach-clps711x/board-cdb89712.c |2 +-
arch/powerpc/kernel/pci_of_scan.c |2 +-
arch/sparc/kernel/pci.c |3 +--
drivers/pci/probe.c |3 +--
drivers/pnp/manager.c |2 --
drivers/scsi/aic94xx/aic94xx_init.c |7 +--
drivers/scsi/arcmsr/arcmsr_hba.c|5 +
drivers/scsi/mvsas/mv_init.c| 15 ---
drivers/video/fbdev/ocfb.c |1 -
lib/devres.c| 13 -
lib/pci_iomap.c |7 ++-
11 files changed, 16 insertions(+), 44 deletions(-)
diff --git a/arch/arm/mach-clps711x/board-cdb89712.c
b/arch/arm/mach-clps711x/board-cdb89712.c
index 1ec378c334e5..972abdb10028 100644
--- a/arch/arm/mach-clps711x/board-cdb89712.c
+++ b/arch/arm/mach-clps711x/board-cdb89712.c
@@ -95,7 +95,7 @@ static struct physmap_flash_data cdb89712_bootrom_pdata
__initdata = {
static struct resource cdb89712_bootrom_resources[] __initdata = {
DEFINE_RES_NAMED(CS7_PHYS_BASE, SZ_128, "BOOTROM", IORESOURCE_MEM |
-IORESOURCE_CACHEABLE | IORESOURCE_READONLY),
+IORESOURCE_READONLY),
};
static struct platform_device cdb89712_bootrom_pdev __initdata = {
diff --git a/arch/powerpc/kernel/pci_of_scan.c
b/arch/powerpc/kernel/pci_of_scan.c
index 42e02a2d570b..d4726addff0b 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -102,7 +102,7 @@ static void of_pci_parse_addrs(struct device_node *node,
struct pci_dev *dev)
res = >resource[(i - PCI_BASE_ADDRESS_0) >> 2];
} else if (i == dev->rom_base_reg) {
res = >resource[PCI_ROM_RESOURCE];
- flags |= IORESOURCE_READONLY | IORESOURCE_CACHEABLE;
+ flags |= IORESOURCE_READONLY;
} else {
printk(KERN_ERR "PCI: bad cfg reg num 0x%x\n", i);
continue;
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index c928bc64b4ba..04da147e0712 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -231,8 +231,7 @@ static void pci_parse_of_addrs(struct platform_device *op,
res = >resource[(i - PCI_BASE_ADDRESS_0) >> 2];
} else if (i == dev->rom_base_reg) {
res = >resource[PCI_ROM_RESOURCE];
- flags |= IORESOURCE_READONLY | IORESOURCE_CACHEABLE
- | IORESOURCE_SIZEALIGN;
+ flags |= IORESOURCE_READONLY | IORESOURCE_SIZEALIGN;
} else {
printk(KERN_ERR "PCI: bad cfg reg num 0x%x\n", i);
continue;
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index cefd636681b6..8ed37dd04056 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -326,8 +326,7 @@ static void pci_read_bases(struct pci_dev *dev, unsigned
int howmany, int rom)
struct resource *res = >resource[PCI_ROM_RESOURCE];
dev->rom_base_reg = rom;
res->flags = IORESOURCE_MEM | IORESOURCE_PREFETCH |
- IORESOURCE_READONLY | IORESOURCE_CACHEABLE |
- IORESOURCE_SIZEALIGN;
+ IORESOURCE_READONLY | IORESOURCE_SIZEALIGN;
__pci_read_base(dev, pci_bar_mem32, res, rom);
}
}
diff --git a/drivers/pnp/manager.c b/drivers/pnp/manager.c
index 9357aa779048..7ad3295752ef 100644
--- a/drivers/pnp/manager.c
+++ b/drivers/pnp/manager.c
@@ -97,8 +97,6 @@ static int pnp_assign_mem(struct pnp_dev *dev, struct pnp_mem
*rule, int idx)
/* ??? rule->flags restricted to 8 bits, all tests bogus ??? */
if (!(rule->flags & IORESOURCE_MEM_WRITEABLE))
res->flags |= IORESOURCE_READONLY;
- if (rule->flags & IORESOURCE_MEM_CACHEABLE)
- res->flags |= IORESOURCE_CACHEABLE;
if (rule->flags & IORESOURCE_MEM_RANGELENGTH)
res->flags |= IORESOURCE_RANGELENGTH;
if (rule->flags &
[PATCH v5 5/8] visorbus: switch from ioremap_cache to memremap
In preparation for deprecating ioremap_cache() convert its usage in
visorbus to memremap.
Cc: Benjamin Romer
Cc: David Kershner
Acked-by: Greg Kroah-Hartman
Signed-off-by: Dan Williams
---
drivers/staging/unisys/visorbus/visorchannel.c | 16 +---
drivers/staging/unisys/visorbus/visorchipset.c | 17 +
2 files changed, 18 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/unisys/visorbus/visorchannel.c
b/drivers/staging/unisys/visorbus/visorchannel.c
index 20b63496e9f2..19c4a78a3617 100644
--- a/drivers/staging/unisys/visorbus/visorchannel.c
+++ b/drivers/staging/unisys/visorbus/visorchannel.c
@@ -21,6 +21,7 @@
*/
#include
+#include
#include "version.h"
#include "visorbus.h"
@@ -36,7 +37,7 @@ static const uuid_le spar_video_guid =
SPAR_CONSOLEVIDEO_CHANNEL_PROTOCOL_GUID;
struct visorchannel {
u64 physaddr;
ulong nbytes;
- void __iomem *mapped;
+ void *mapped;
bool requested;
struct channel_header chan_hdr;
uuid_le guid;
@@ -93,7 +94,7 @@ visorchannel_create_guts(u64 physaddr, unsigned long
channel_bytes,
}
}
- channel->mapped = ioremap_cache(physaddr, size);
+ channel->mapped = memremap(physaddr, size, MEMREMAP_WB);
if (!channel->mapped) {
release_mem_region(physaddr, size);
goto cleanup;
@@ -113,7 +114,7 @@ visorchannel_create_guts(u64 physaddr, unsigned long
channel_bytes,
if (uuid_le_cmp(guid, NULL_UUID_LE) == 0)
guid = channel->chan_hdr.chtype;
- iounmap(channel->mapped);
+ memunmap(channel->mapped);
if (channel->requested)
release_mem_region(channel->physaddr, channel->nbytes);
channel->mapped = NULL;
@@ -126,7 +127,8 @@ visorchannel_create_guts(u64 physaddr, unsigned long
channel_bytes,
}
}
- channel->mapped = ioremap_cache(channel->physaddr, channel_bytes);
+ channel->mapped = memremap(channel->physaddr, channel_bytes,
+ MEMREMAP_WB);
if (!channel->mapped) {
release_mem_region(channel->physaddr, channel_bytes);
goto cleanup;
@@ -167,7 +169,7 @@ visorchannel_destroy(struct visorchannel *channel)
if (!channel)
return;
if (channel->mapped) {
- iounmap(channel->mapped);
+ memunmap(channel->mapped);
if (channel->requested)
release_mem_region(channel->physaddr, channel->nbytes);
}
@@ -241,7 +243,7 @@ visorchannel_read(struct visorchannel *channel, ulong
offset,
if (offset + nbytes > channel->nbytes)
return -EIO;
- memcpy_fromio(local, channel->mapped + offset, nbytes);
+ memcpy(local, channel->mapped + offset, nbytes);
return 0;
}
@@ -262,7 +264,7 @@ visorchannel_write(struct visorchannel *channel, ulong
offset,
memcpy(>chan_hdr + offset, local, copy_size);
}
- memcpy_toio(channel->mapped + offset, local, nbytes);
+ memcpy(channel->mapped + offset, local, nbytes);
return 0;
}
diff --git a/drivers/staging/unisys/visorbus/visorchipset.c
b/drivers/staging/unisys/visorbus/visorchipset.c
index bb8087e70127..e3c55ccf929b 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -119,7 +119,7 @@ static struct visorchannel *controlvm_channel;
/* Manages the request payload in the controlvm channel */
struct visor_controlvm_payload_info {
- u8 __iomem *ptr;/* pointer to base address of payload pool */
+ u8 *ptr;/* pointer to base address of payload pool */
u64 offset; /* offset from beginning of controlvm
* channel to beginning of payload * pool */
u32 bytes; /* number of bytes in payload pool */
@@ -401,21 +401,22 @@ parser_init_byte_stream(u64 addr, u32 bytes, bool local,
bool *retry)
p = __va((unsigned long) (addr));
memcpy(ctx->data, p, bytes);
} else {
- void __iomem *mapping;
+ void *mapping;
if (!request_mem_region(addr, bytes, "visorchipset")) {
rc = NULL;
goto cleanup;
}
- mapping = ioremap_cache(addr, bytes);
+ mapping = memremap(addr, bytes, MEMREMAP_WB);
if (!mapping) {
release_mem_region(addr, bytes);
rc = NULL;
goto cleanup;
}
- memcpy_fromio(ctx->data, mapping, bytes);
+ memcpy(ctx->data, mapping, bytes);
release_mem_region(addr, bytes);
+ memunmap(mapping);
}
ctx->byte_stream = true;
@@ -1327,7 +1328,7 @@ static
Re: linux-next: build failure after merge of the gpio tree
Hi Stephen,
On 08/13/2015 08:02 AM, Stephen Rothwell wrote:
> Hi Uwe,
>
> On Wed, 12 Aug 2015 22:16:42 +0200 Uwe Kleine-König
> wrote:
>>
>> On Wed, Aug 12, 2015 at 06:10:45PM +1000, Stephen Rothwell wrote:
>>> After merging the gpio tree, today's linux-next build (powerpc
>>> allyesconfig) failed like this:
>>>
>>> drivers/extcon/extcon-palmas.c:211:25: error: too few arguments to function
>>> 'devm_gpiod_get_optional'
>>> palmas_usb->id_gpiod = devm_gpiod_get_optional(>dev, "id");
>>> ^
>>> In file included from /home/sfr/next/next/include/asm-generic/gpio.h:13:0,
>>> from /home/sfr/next/next/include/linux/gpio.h:51,
>>> from /home/sfr/next/next/include/linux/of_gpio.h:20,
>>> from /home/sfr/next/next/include/linux/mfd/palmas.h:24,
>>> from /home/sfr/next/next/drivers/extcon/extcon-palmas.c:28:
>>> /home/sfr/next/next/include/linux/gpio/consumer.h:80:32: note: declared here
>>> struct gpio_desc *__must_check devm_gpiod_get_optional(struct device *dev,
>>> ^
>>>
>>> Caused by commit
>>>
>>> b17d1bf16cc7 ("gpio: make flags mandatory for gpiod_get functions")
>>>
>>> interacting with commit
>>>
>>> 92b7cb5dc885 ("extcon: palmas: Support GPIO based USB ID detection")
>> that commit is not correct. After
>>
>> palmas_usb->id_gpiod = devm_gpiod_get_optional(>dev, "id");
>>
>> it does
>>
>> palmas_usb->gpio_id_irq = gpiod_to_irq(palmas_usb->id_gpiod);
>>
>> without setting the gpio to input. So the right fix is not to add
>> GPIOD_ASIS but GPIOD_IN.
>
> OK, I have fixed my merge fix patch, but can you submit a correct patch
> to the extcon tree maintainer, please? I assume it can be fixed in
> that tree right now, right?
>
I'll fix it as Uwe comment as following:
--- a/drivers/extcon/extcon-palmas.c
+++ b/drivers/extcon/extcon-palmas.c
@@ -208,7 +208,8 @@ static int palmas_usb_probe(struct platform_device *pdev)
palmas_usb->wakeup = pdata->wakeup;
}
- palmas_usb->id_gpiod = devm_gpiod_get_optional(>dev, "id");
+ palmas_usb->id_gpiod =
+ devm_gpiod_get_optional(>dev, "id", GPIOD_IN);
if (IS_ERR(palmas_usb->id_gpiod)) {
dev_err(>dev, "failed to get id gpio\n");
return PTR_ERR(palmas_usb->id_gpiod);
I'll send it to LKML and apply it on extcon-next tree.
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 1/8] mm: enhance region_is_ram() to region_intersects()
region_is_ram() is used to prevent the establishment of aliased mappings
to physical "System RAM" with incompatible cache settings. However, it
uses "-1" to indicate both "unknown" memory ranges (ranges not described
by platform firmware) and "mixed" ranges (where the parameters describe
a range that partially overlaps "System RAM").
Fix this up by explicitly tracking the "unknown" vs "mixed" resource
cases and returning REGION_INTERSECTS, REGION_MIXED, or REGION_DISJOINT.
This re-write also adds support for detecting when the requested region
completely eclipses all of a resource. Note, the implementation treats
overlaps between "unknown" and the requested memory type as
REGION_INTERSECTS.
Finally, other memory types can be passed in by name, for now the only
usage "System RAM".
Suggested-by: Luis R. Rodriguez
Reviewed-by: Toshi Kani
Signed-off-by: Dan Williams
---
include/linux/mm.h |9 +++-
kernel/resource.c | 61 +++-
2 files changed, 44 insertions(+), 26 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 2e872f92dbac..84b05ebedb2d 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -369,7 +369,14 @@ static inline int put_page_unless_one(struct page *page)
}
extern int page_is_ram(unsigned long pfn);
-extern int region_is_ram(resource_size_t phys_addr, unsigned long size);
+
+enum {
+ REGION_INTERSECTS,
+ REGION_DISJOINT,
+ REGION_MIXED,
+};
+
+int region_intersects(resource_size_t offset, size_t size, const char *type);
/* Support for virtually mapped pages */
struct page *vmalloc_to_page(const void *addr);
diff --git a/kernel/resource.c b/kernel/resource.c
index fed052a1bc9f..f150dbbe6f62 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -492,40 +492,51 @@ int __weak page_is_ram(unsigned long pfn)
}
EXPORT_SYMBOL_GPL(page_is_ram);
-/*
- * Search for a resouce entry that fully contains the specified region.
- * If found, return 1 if it is RAM, 0 if not.
- * If not found, or region is not fully contained, return -1
+/**
+ * region_intersects() - determine intersection of region with known resources
+ * @start: region start address
+ * @size: size of region
+ * @name: name of resource (in iomem_resource)
*
- * Used by the ioremap functions to ensure the user is not remapping RAM and is
- * a vast speed up over walking through the resource table page by page.
+ * Check if the specified region partially overlaps or fully eclipses a
+ * resource identified by @name. Return REGION_DISJOINT if the region
+ * does not overlap @name, return REGION_MIXED if the region overlaps
+ * @type and another resource, and return REGION_INTERSECTS if the
+ * region overlaps @type and no other defined resource. Note, that
+ * REGION_INTERSECTS is also returned in the case when the specified
+ * region overlaps RAM and undefined memory holes.
+ *
+ * region_intersect() is used by memory remapping functions to ensure
+ * the user is not remapping RAM and is a vast speed up over walking
+ * through the resource table page by page.
*/
-int region_is_ram(resource_size_t start, unsigned long size)
+int region_intersects(resource_size_t start, size_t size, const char *name)
{
- struct resource *p;
- resource_size_t end = start + size - 1;
unsigned long flags = IORESOURCE_MEM | IORESOURCE_BUSY;
- const char *name = "System RAM";
- int ret = -1;
+ resource_size_t end = start + size - 1;
+ int type = 0; int other = 0;
+ struct resource *p;
read_lock(_lock);
for (p = iomem_resource.child; p ; p = p->sibling) {
- if (p->end < start)
- continue;
-
- if (p->start <= start && end <= p->end) {
- /* resource fully contains region */
- if ((p->flags != flags) || strcmp(p->name, name))
- ret = 0;
- else
- ret = 1;
- break;
- }
- if (end < p->start)
- break; /* not found */
+ bool is_type = strcmp(p->name, name) == 0 && p->flags == flags;
+
+ if (start >= p->start && start <= p->end)
+ is_type ? type++ : other++;
+ if (end >= p->start && end <= p->end)
+ is_type ? type++ : other++;
+ if (p->start >= start && p->end <= end)
+ is_type ? type++ : other++;
}
read_unlock(_lock);
- return ret;
+
+ if (other == 0)
+ return type ? REGION_INTERSECTS : REGION_DISJOINT;
+
+ if (type)
+ return REGION_MIXED;
+
+ return REGION_DISJOINT;
}
void __weak arch_remove_reservations(struct resource *avail)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
[PATCH v5 6/8] pmem: convert to generic memremap
Kill arch_memremap_pmem() and just let the architecture specify the
flags to be passed to memremap(). Default to writethrough by default.
Cc: Ross Zwisler
Suggested-by: Christoph Hellwig
Signed-off-by: Dan Williams
---
arch/x86/include/asm/io.h |6 +-
include/linux/pmem.h | 28 +---
tools/testing/nvdimm/Kbuild |4 ++--
tools/testing/nvdimm/test/iomap.c | 34 +-
4 files changed, 37 insertions(+), 35 deletions(-)
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index cc9c61bc1abe..d241fbd5c87b 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -248,11 +248,7 @@ static inline void flush_write_buffers(void)
#endif
}
-static inline void __pmem *arch_memremap_pmem(resource_size_t offset,
- unsigned long size)
-{
- return (void __force __pmem *) ioremap_cache(offset, size);
-}
+#define ARCH_MEMREMAP_PMEM MEMREMAP_WB
#endif /* __KERNEL__ */
diff --git a/include/linux/pmem.h b/include/linux/pmem.h
index d2114045a6c4..093c35ecefcc 100644
--- a/include/linux/pmem.h
+++ b/include/linux/pmem.h
@@ -28,12 +28,6 @@ static inline bool __arch_has_wmb_pmem(void)
return false;
}
-static inline void __pmem *arch_memremap_pmem(resource_size_t offset,
- unsigned long size)
-{
- return NULL;
-}
-
static inline void arch_memcpy_to_pmem(void __pmem *dst, const void *src,
size_t n)
{
@@ -43,8 +37,8 @@ static inline void arch_memcpy_to_pmem(void __pmem *dst,
const void *src,
/*
* Architectures that define ARCH_HAS_PMEM_API must provide
- * implementations for arch_memremap_pmem(), arch_memcpy_to_pmem(),
- * arch_wmb_pmem(), and __arch_has_wmb_pmem().
+ * implementations for arch_memcpy_to_pmem(), arch_wmb_pmem(), and
+ * __arch_has_wmb_pmem().
*/
static inline void memcpy_from_pmem(void *dst, void __pmem const *src, size_t
size)
@@ -54,7 +48,7 @@ static inline void memcpy_from_pmem(void *dst, void __pmem
const *src, size_t si
static inline void memunmap_pmem(void __pmem *addr)
{
- iounmap((void __force __iomem *) addr);
+ memunmap((void __force *) addr);
}
/**
@@ -85,18 +79,12 @@ static inline bool arch_has_pmem_api(void)
* default_memremap_pmem + default_memcpy_to_pmem is sufficient for
* making data durable relative to i/o completion.
*/
-static void default_memcpy_to_pmem(void __pmem *dst, const void *src,
+static inline void default_memcpy_to_pmem(void __pmem *dst, const void *src,
size_t size)
{
memcpy((void __force *) dst, src, size);
}
-static void __pmem *default_memremap_pmem(resource_size_t offset,
- unsigned long size)
-{
- return (void __pmem __force *)ioremap_wt(offset, size);
-}
-
/**
* memremap_pmem - map physical persistent memory for pmem api
* @offset: physical address of persistent memory
@@ -112,9 +100,11 @@ static void __pmem *default_memremap_pmem(resource_size_t
offset,
static inline void __pmem *memremap_pmem(resource_size_t offset,
unsigned long size)
{
- if (arch_has_pmem_api())
- return arch_memremap_pmem(offset, size);
- return default_memremap_pmem(offset, size);
+#ifdef ARCH_MEMREMAP_PMEM
+ return (void __pmem *) memremap(offset, size, ARCH_MEMREMAP_PMEM);
+#else
+ return (void __pmem *) memremap(offset, size, MEMREMAP_WT);
+#endif
}
/**
diff --git a/tools/testing/nvdimm/Kbuild b/tools/testing/nvdimm/Kbuild
index f56914c7929b..8032a49f7873 100644
--- a/tools/testing/nvdimm/Kbuild
+++ b/tools/testing/nvdimm/Kbuild
@@ -1,7 +1,7 @@
-ldflags-y += --wrap=ioremap_wt
ldflags-y += --wrap=ioremap_wc
ldflags-y += --wrap=devm_ioremap_nocache
-ldflags-y += --wrap=ioremap_cache
+ldflags-y += --wrap=memremap
+ldflags-y += --wrap=memunmap
ldflags-y += --wrap=ioremap_nocache
ldflags-y += --wrap=iounmap
ldflags-y += --wrap=__request_region
diff --git a/tools/testing/nvdimm/test/iomap.c
b/tools/testing/nvdimm/test/iomap.c
index 64bfaa50831c..21288f34a5ca 100644
--- a/tools/testing/nvdimm/test/iomap.c
+++ b/tools/testing/nvdimm/test/iomap.c
@@ -80,11 +80,20 @@ void __iomem *__wrap_devm_ioremap_nocache(struct device
*dev,
}
EXPORT_SYMBOL(__wrap_devm_ioremap_nocache);
-void __iomem *__wrap_ioremap_cache(resource_size_t offset, unsigned long size)
+void *__wrap_memremap(resource_size_t offset, size_t size,
+ unsigned long flags)
{
- return __nfit_test_ioremap(offset, size, ioremap_cache);
+ struct nfit_test_resource *nfit_res;
+
+ rcu_read_lock();
+ nfit_res = get_nfit_res(offset);
+ rcu_read_unlock();
+ if (nfit_res)
+ return (void __iomem *) nfit_res->buf + offset
+ - nfit_res->res->start;
+ return memremap(offset, size, flags);
}
-EXPORT_SYMBOL(__wrap_ioremap_cache);
+EXPORT_SYMBOL(__wrap_memremap);
void __iomem *__wrap_ioremap_nocache(resource_size_t
[PATCH v5 4/8] arch: introduce memremap()
Existing users of ioremap_cache() are mapping memory that is known in
advance to not have i/o side effects. These users are forced to cast
away the __iomem annotation, or otherwise neglect to fix the sparse
errors thrown when dereferencing pointers to this memory. Provide
memremap() as a non __iomem annotated ioremap_*() in the case when
ioremap is otherwise a pointer to cacheable memory. Empirically,
ioremap_() call sites are seeking memory-like semantics
(e.g. speculative reads, and prefetching permitted).
memremap() is a break from the ioremap implementation pattern of adding
a new memremap_() for each mapping type and having silent
compatibility fall backs. Instead, the implementation defines flags
that are passed to the central memremap() and if a mapping type is not
supported by an arch memremap returns NULL.
We introduce a memremap prototype as a trivial wrapper of
ioremap_cache() and ioremap_wt(). Later, once all ioremap_cache() and
ioremap_wt() usage has been removed from drivers we teach archs to
implement arch_memremap() with the ability to strictly enforce the
mapping type.
Cc: Arnd Bergmann
Reviewed-by: Christoph Hellwig
Signed-off-by: Dan Williams
---
arch/ia64/include/asm/io.h |1
arch/sh/include/asm/io.h |1
arch/xtensa/include/asm/io.h |1
include/linux/io.h |9
kernel/Makefile |2 +
kernel/memremap.c| 98 ++
6 files changed, 112 insertions(+)
create mode 100644 kernel/memremap.c
diff --git a/arch/ia64/include/asm/io.h b/arch/ia64/include/asm/io.h
index 80a7e34be009..9041bbe2b7b4 100644
--- a/arch/ia64/include/asm/io.h
+++ b/arch/ia64/include/asm/io.h
@@ -435,6 +435,7 @@ static inline void __iomem * ioremap_cache (unsigned long
phys_addr, unsigned lo
{
return ioremap(phys_addr, size);
}
+#define ioremap_cache ioremap_cache
/*
diff --git a/arch/sh/include/asm/io.h b/arch/sh/include/asm/io.h
index 728c4c571f40..6194e20fccca 100644
--- a/arch/sh/include/asm/io.h
+++ b/arch/sh/include/asm/io.h
@@ -342,6 +342,7 @@ ioremap_cache(phys_addr_t offset, unsigned long size)
{
return __ioremap_mode(offset, size, PAGE_KERNEL);
}
+#define ioremap_cache ioremap_cache
#ifdef CONFIG_HAVE_IOREMAP_PROT
static inline void __iomem *
diff --git a/arch/xtensa/include/asm/io.h b/arch/xtensa/include/asm/io.h
index c39bb6e61911..867840f5400f 100644
--- a/arch/xtensa/include/asm/io.h
+++ b/arch/xtensa/include/asm/io.h
@@ -57,6 +57,7 @@ static inline void __iomem *ioremap_cache(unsigned long
offset,
else
BUG();
}
+#define ioremap_cache ioremap_cache
#define ioremap_wc ioremap_nocache
#define ioremap_wt ioremap_nocache
diff --git a/include/linux/io.h b/include/linux/io.h
index fb5a99800e77..3fcf6256c088 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -121,4 +121,13 @@ static inline int arch_phys_wc_index(int handle)
#endif
#endif
+enum {
+ /* See memremap() kernel-doc for usage description... */
+ MEMREMAP_WB = 1 << 0,
+ MEMREMAP_WT = 1 << 1,
+};
+
+void *memremap(resource_size_t offset, size_t size, unsigned long flags);
+void memunmap(void *addr);
+
#endif /* _LINUX_IO_H */
diff --git a/kernel/Makefile b/kernel/Makefile
index 43c4c920f30a..92866d36e376 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -99,6 +99,8 @@ obj-$(CONFIG_JUMP_LABEL) += jump_label.o
obj-$(CONFIG_CONTEXT_TRACKING) += context_tracking.o
obj-$(CONFIG_TORTURE_TEST) += torture.o
+obj-$(CONFIG_HAS_IOMEM) += memremap.o
+
$(obj)/configs.o: $(obj)/config_data.h
# config_data.h contains the same information as ikconfig.h but gzipped.
diff --git a/kernel/memremap.c b/kernel/memremap.c
new file mode 100644
index ..a293de52e837
--- /dev/null
+++ b/kernel/memremap.c
@@ -0,0 +1,98 @@
+/*
+ * Copyright(c) 2015 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+#include
+#include
+#include
+
+#ifndef ioremap_cache
+/* temporary while we convert existing ioremap_cache users to memremap */
+__weak void __iomem *ioremap_cache(resource_size_t offset, unsigned long size)
+{
+ return ioremap(offset, size);
+}
+#endif
+
+/**
+ * memremap() - remap an iomem_resource as cacheable memory
+ * @offset: iomem resource start address
+ * @size: size of remap
+ * @flags: either MEMREMAP_WB or MEMREMAP_WT
+ *
+ * memremap() is "ioremap" for cases where it is known that the resource
+ * being mapped does not have i/o side effects and the __iomem
+ * annotation is not applicable.
+ *
+ *
[PATCH v5 8/8] pmem: switch to devm_ allocations
From: Christoph Hellwig
Signed-off-by: Christoph Hellwig
[djbw: tools/testing/nvdimm/ and memumap_pmem support]
Signed-off-by: Dan Williams
---
drivers/nvdimm/pmem.c | 36 +
include/linux/pmem.h | 14 ++-
tools/testing/nvdimm/Kbuild |4 ++-
tools/testing/nvdimm/test/iomap.c | 46 +
4 files changed, 47 insertions(+), 53 deletions(-)
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index bcf48f133443..eb7552d939e1 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -119,7 +119,7 @@ static struct pmem_device *pmem_alloc(struct device *dev,
{
struct pmem_device *pmem;
- pmem = kzalloc(sizeof(*pmem), GFP_KERNEL);
+ pmem = devm_kzalloc(dev, sizeof(*pmem), GFP_KERNEL);
if (!pmem)
return ERR_PTR(-ENOMEM);
@@ -128,19 +128,16 @@ static struct pmem_device *pmem_alloc(struct device *dev,
if (!arch_has_pmem_api())
dev_warn(dev, "unable to guarantee persistence of writes\n");
- if (!request_mem_region(pmem->phys_addr, pmem->size, dev_name(dev))) {
+ if (!devm_request_mem_region(dev, pmem->phys_addr, pmem->size,
+ dev_name(dev))) {
dev_warn(dev, "could not reserve region [0x%pa:0x%zx]\n",
>phys_addr, pmem->size);
- kfree(pmem);
return ERR_PTR(-EBUSY);
}
- pmem->virt_addr = memremap_pmem(pmem->phys_addr, pmem->size);
- if (!pmem->virt_addr) {
- release_mem_region(pmem->phys_addr, pmem->size);
- kfree(pmem);
+ pmem->virt_addr = memremap_pmem(dev, pmem->phys_addr, pmem->size);
+ if (!pmem->virt_addr)
return ERR_PTR(-ENXIO);
- }
return pmem;
}
@@ -210,20 +207,12 @@ static int pmem_rw_bytes(struct nd_namespace_common *ndns,
return 0;
}
-static void pmem_free(struct pmem_device *pmem)
-{
- memunmap_pmem(pmem->virt_addr);
- release_mem_region(pmem->phys_addr, pmem->size);
- kfree(pmem);
-}
-
static int nd_pmem_probe(struct device *dev)
{
struct nd_region *nd_region = to_nd_region(dev->parent);
struct nd_namespace_common *ndns;
struct nd_namespace_io *nsio;
struct pmem_device *pmem;
- int rc;
ndns = nvdimm_namespace_common_probe(dev);
if (IS_ERR(ndns))
@@ -236,16 +225,14 @@ static int nd_pmem_probe(struct device *dev)
dev_set_drvdata(dev, pmem);
ndns->rw_bytes = pmem_rw_bytes;
+
if (is_nd_btt(dev))
- rc = nvdimm_namespace_attach_btt(ndns);
- else if (nd_btt_probe(ndns, pmem) == 0) {
+ return nvdimm_namespace_attach_btt(ndns);
+
+ if (nd_btt_probe(ndns, pmem) == 0)
/* we'll come back as btt-pmem */
- rc = -ENXIO;
- } else
- rc = pmem_attach_disk(ndns, pmem);
- if (rc)
- pmem_free(pmem);
- return rc;
+ return -ENXIO;
+ return pmem_attach_disk(ndns, pmem);
}
static int nd_pmem_remove(struct device *dev)
@@ -256,7 +243,6 @@ static int nd_pmem_remove(struct device *dev)
nvdimm_namespace_detach_btt(to_nd_btt(dev)->ndns);
else
pmem_detach_disk(pmem);
- pmem_free(pmem);
return 0;
}
diff --git a/include/linux/pmem.h b/include/linux/pmem.h
index 093c35ecefcc..20c367cd76e6 100644
--- a/include/linux/pmem.h
+++ b/include/linux/pmem.h
@@ -46,9 +46,9 @@ static inline void memcpy_from_pmem(void *dst, void __pmem
const *src, size_t si
memcpy(dst, (void __force const *) src, size);
}
-static inline void memunmap_pmem(void __pmem *addr)
+static inline void memunmap_pmem(struct device *dev, void __pmem *addr)
{
- memunmap((void __force *) addr);
+ devm_memunmap(dev, (void __force *) addr);
}
/**
@@ -97,13 +97,15 @@ static inline void default_memcpy_to_pmem(void __pmem *dst,
const void *src,
* wmb_pmem() arrange for the data to be written through the
* cache to persistent media.
*/
-static inline void __pmem *memremap_pmem(resource_size_t offset,
- unsigned long size)
+static inline void __pmem *memremap_pmem(struct device *dev,
+ resource_size_t offset, unsigned long size)
{
#ifdef ARCH_MEMREMAP_PMEM
- return (void __pmem *) memremap(offset, size, ARCH_MEMREMAP_PMEM);
+ return (void __pmem *) devm_memremap(dev, offset, size,
+ ARCH_MEMREMAP_PMEM);
#else
- return (void __pmem *) memremap(offset, size, MEMREMAP_WT);
+ return (void __pmem *) devm_memremap(dev, offset, size,
+ MEMREMAP_WT);
#endif
}
diff --git a/tools/testing/nvdimm/Kbuild b/tools/testing/nvdimm/Kbuild
index 8032a49f7873..04c5fc09576d 100644
--- a/tools/testing/nvdimm/Kbuild
+++ b/tools/testing/nvdimm/Kbuild
@@ -1,9 +1,9 @@
[PATCH v5 7/8] devres: add devm_memremap
From: Christoph Hellwig
Signed-off-by: Christoph Hellwig
Signed-off-by: Dan Williams
---
include/linux/io.h |4
kernel/memremap.c | 39 +++
2 files changed, 43 insertions(+)
diff --git a/include/linux/io.h b/include/linux/io.h
index 3fcf6256c088..d8d749abd665 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -80,6 +80,10 @@ int check_signature(const volatile void __iomem *io_addr,
const unsigned char *signature, int length);
void devm_ioremap_release(struct device *dev, void *res);
+void *devm_memremap(struct device *dev, resource_size_t offset,
+ size_t size, unsigned long flags);
+void devm_memunmap(struct device *dev, void *addr);
+
/*
* Some systems do not have legacy ISA devices.
* /dev/port is not a valid interface on these systems.
diff --git a/kernel/memremap.c b/kernel/memremap.c
index a293de52e837..5c9b55eaf121 100644
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -10,6 +10,7 @@
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*/
+#include
#include
#include
#include
@@ -96,3 +97,41 @@ void memunmap(void *addr)
iounmap((void __iomem *) addr);
}
EXPORT_SYMBOL(memunmap);
+
+static void devm_memremap_release(struct device *dev, void *res)
+{
+ memunmap(res);
+}
+
+static int devm_memremap_match(struct device *dev, void *res, void *match_data)
+{
+ return *(void **)res == match_data;
+}
+
+void *devm_memremap(struct device *dev, resource_size_t offset,
+ size_t size, unsigned long flags)
+{
+ void **ptr, *addr;
+
+ ptr = devres_alloc(devm_memremap_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ addr = memremap(offset, size, flags);
+ if (addr) {
+ *ptr = addr;
+ devres_add(dev, ptr);
+ } else
+ devres_free(ptr);
+
+ return addr;
+}
+EXPORT_SYMBOL(devm_memremap);
+
+void devm_memunmap(struct device *dev, void *addr)
+{
+ WARN_ON(devres_destroy(dev, devm_memremap_release, devm_memremap_match,
+ addr));
+ memunmap(addr);
+}
+EXPORT_SYMBOL(devm_memunmap);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 2/8] arch, drivers: don't include directly, use instead
Preparation for uniform definition of ioremap, ioremap_wc, ioremap_wt,
and ioremap_cache, tree-wide.
Acked-by: Christoph Hellwig
Signed-off-by: Dan Williams
---
arch/arm/mach-shmobile/pm-rcar.c|2 +-
arch/ia64/kernel/cyclone.c |2 +-
drivers/isdn/icn/icn.h |2 +-
drivers/mtd/devices/slram.c |2 +-
drivers/mtd/nand/diskonchip.c |2 +-
drivers/mtd/onenand/generic.c |2 +-
drivers/scsi/sun3x_esp.c|2 +-
drivers/staging/comedi/drivers/ii_pci20kc.c |1 +
drivers/tty/serial/8250/8250_core.c |2 +-
drivers/video/fbdev/s1d13xxxfb.c|3 +--
drivers/video/fbdev/stifb.c |1 +
include/linux/io-mapping.h |2 +-
include/linux/mtd/map.h |2 +-
include/video/vga.h |2 +-
14 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-shmobile/pm-rcar.c b/arch/arm/mach-shmobile/pm-rcar.c
index 00022ee56f80..9d3dde00c2fe 100644
--- a/arch/arm/mach-shmobile/pm-rcar.c
+++ b/arch/arm/mach-shmobile/pm-rcar.c
@@ -12,7 +12,7 @@
#include
#include
#include
-#include
+#include
#include "pm-rcar.h"
/* SYSC */
diff --git a/arch/ia64/kernel/cyclone.c b/arch/ia64/kernel/cyclone.c
index 4826ff957a3d..5fa3848ba224 100644
--- a/arch/ia64/kernel/cyclone.c
+++ b/arch/ia64/kernel/cyclone.c
@@ -4,7 +4,7 @@
#include
#include
#include
-#include
+#include
/* IBM Summit (EXA) Cyclone counter code*/
#define CYCLONE_CBAR_ADDR 0xFEB00CD0
diff --git a/drivers/isdn/icn/icn.h b/drivers/isdn/icn/icn.h
index b713466997a0..f8f2e76d34bf 100644
--- a/drivers/isdn/icn/icn.h
+++ b/drivers/isdn/icn/icn.h
@@ -38,7 +38,7 @@ typedef struct icn_cdef {
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/drivers/mtd/devices/slram.c b/drivers/mtd/devices/slram.c
index 2fc4957cbe7f..a70eb83e68f1 100644
--- a/drivers/mtd/devices/slram.c
+++ b/drivers/mtd/devices/slram.c
@@ -41,7 +41,7 @@
#include
#include
#include
-#include
+#include
#include
diff --git a/drivers/mtd/nand/diskonchip.c b/drivers/mtd/nand/diskonchip.c
index 7da266a53979..0802158a3f75 100644
--- a/drivers/mtd/nand/diskonchip.c
+++ b/drivers/mtd/nand/diskonchip.c
@@ -24,7 +24,7 @@
#include
#include
#include
-#include
+#include
#include
#include
diff --git a/drivers/mtd/onenand/generic.c b/drivers/mtd/onenand/generic.c
index 32a216d31141..ab7bda0bb245 100644
--- a/drivers/mtd/onenand/generic.c
+++ b/drivers/mtd/onenand/generic.c
@@ -18,7 +18,7 @@
#include
#include
#include
-#include
+#include
/*
* Note: Driver name and platform data format have been updated!
diff --git a/drivers/scsi/sun3x_esp.c b/drivers/scsi/sun3x_esp.c
index e26e81de7c45..d50c5ed8f428 100644
--- a/drivers/scsi/sun3x_esp.c
+++ b/drivers/scsi/sun3x_esp.c
@@ -12,9 +12,9 @@
#include
#include
#include
+#include
#include
-#include
#include
#include
diff --git a/drivers/staging/comedi/drivers/ii_pci20kc.c
b/drivers/staging/comedi/drivers/ii_pci20kc.c
index 0768bc42a5db..14ef1f67dd42 100644
--- a/drivers/staging/comedi/drivers/ii_pci20kc.c
+++ b/drivers/staging/comedi/drivers/ii_pci20kc.c
@@ -28,6 +28,7 @@
*/
#include
+#include
#include "../comedidev.h"
/*
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 37fff12dd4d0..fe902ff52e58 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -38,11 +38,11 @@
#include
#include
#include
+#include
#ifdef CONFIG_SPARC
#include
#endif
-#include
#include
#include "8250.h"
diff --git a/drivers/video/fbdev/s1d13xxxfb.c b/drivers/video/fbdev/s1d13xxxfb.c
index 83433cb0dfba..96aa46dc696c 100644
--- a/drivers/video/fbdev/s1d13xxxfb.c
+++ b/drivers/video/fbdev/s1d13xxxfb.c
@@ -32,8 +32,7 @@
#include
#include
#include
-
-#include
+#include
#include
diff --git a/drivers/video/fbdev/stifb.c b/drivers/video/fbdev/stifb.c
index 735355b0e023..7df4228e25f0 100644
--- a/drivers/video/fbdev/stifb.c
+++ b/drivers/video/fbdev/stifb.c
@@ -64,6 +64,7 @@
#include
#include
#include
+#include
#include /* for HP-UX compatibility */
#include
diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
index c27dde7215b5..e399029b68c5 100644
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -21,7 +21,7 @@
#include
#include
#include
-#include
+#include
#include
/*
diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h
index 29975c73a953..366cf77953b5 100644
--- a/include/linux/mtd/map.h
+++ b/include/linux/mtd/map.h
@@ -27,9 +27,9 @@
#include
#include
#include
+#include
#include
-#include
#include
#ifdef CONFIG_MTD_MAP_BANK_WIDTH_1
diff --git a/include/video/vga.h b/include/video/vga.h
index
