* [PATCH 2/3] arm64: don't override dma_max_pfn
From: Christoph Hellwig @ 2017-12-04 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204163601.3055-1-hch@lst.de>
The generic version now takes dma_pfn_offset into account, so there is no
more need for an architecture override.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm64/include/asm/dma-mapping.h | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h
index 0df756b24863..eada887a93bf 100644
--- a/arch/arm64/include/asm/dma-mapping.h
+++ b/arch/arm64/include/asm/dma-mapping.h
@@ -76,14 +76,5 @@ static inline void dma_mark_clean(void *addr, size_t size)
{
}
-/* Override for dma_max_pfn() */
-static inline unsigned long dma_max_pfn(struct device *dev)
-{
- dma_addr_t dma_max = (dma_addr_t)*dev->dma_mask;
-
- return (ulong)dma_to_phys(dev, dma_max) >> PAGE_SHIFT;
-}
-#define dma_max_pfn(dev) dma_max_pfn(dev)
-
#endif /* __KERNEL__ */
#endif /* __ASM_DMA_MAPPING_H */
--
2.14.2
^ permalink raw reply related
* [PATCH 1/3] dma-mapping: take dma_pfn_offset into account in dma_max_pfn
From: Christoph Hellwig @ 2017-12-04 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204163601.3055-1-hch@lst.de>
This makes sure the generic version can be used with architectures /
devices that have a DMA offset in the direct mapping.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
include/linux/dma-mapping.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index e8f8e8fb244d..86beb9861618 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -692,7 +692,7 @@ static inline int dma_set_seg_boundary(struct device *dev, unsigned long mask)
#ifndef dma_max_pfn
static inline unsigned long dma_max_pfn(struct device *dev)
{
- return *dev->dma_mask >> PAGE_SHIFT;
+ return (*dev->dma_mask >> PAGE_SHIFT) + dev->dma_pfn_offset;
}
#endif
--
2.14.2
^ permalink raw reply related
* replace PCI_DMA_BUS_IS_PHYS with a per-instance flag
From: Christoph Hellwig @ 2017-12-04 16:35 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
this small series tries to get rid of the global and misnamed
PCI_DMA_BUS_IS_PHYS flag, and replace it with a setting in each
struct dma_map_ops instance.
^ permalink raw reply
* [PATCH 03/10] net: ezchip: nps_enet: Fix platform_get_irq's error checking
From: David Miller @ 2017-12-04 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204162447.GT10595@n2100.armlinux.org.uk>
From: Russell King - ARM Linux <linux@armlinux.org.uk>
Date: Mon, 4 Dec 2017 16:24:47 +0000
> On Mon, Dec 04, 2017 at 11:20:49AM -0500, David Miller wrote:
>> From: Arvind Yadav <arvind.yadav.cs@gmail.com>
>> Date: Sun, 3 Dec 2017 00:56:15 +0530
>>
>> > The platform_get_irq() function returns negative if an error occurs.
>> > zero or positive number on success. platform_get_irq() error checking
>> > for zero is not correct. And remove unnecessary check for free_netdev().
>> >
>> > Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
>> > ---
>> > drivers/net/ethernet/ezchip/nps_enet.c | 7 +++----
>> > 1 file changed, 3 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/drivers/net/ethernet/ezchip/nps_enet.c b/drivers/net/ethernet/ezchip/nps_enet.c
>> > index 659f1ad..82dc6d0 100644
>> > --- a/drivers/net/ethernet/ezchip/nps_enet.c
>> > +++ b/drivers/net/ethernet/ezchip/nps_enet.c
>> > @@ -623,9 +623,9 @@ static s32 nps_enet_probe(struct platform_device *pdev)
>> >
>> > /* Get IRQ number */
>> > priv->irq = platform_get_irq(pdev, 0);
>> > - if (!priv->irq) {
>> > + if (priv->irq <= 0) {
>> > dev_err(dev, "failed to retrieve <irq Rx-Tx> value from device tree\n");
>> > - err = -ENODEV;
>> > + err = priv->irq ? priv->irq : -ENODEV;
>>
>> If platform_get_irq() returns "zero or positive number on success" then this
>> test is wrong and should be "if (priv->irq < 0)"
>>
>> Also, this series is a mix of different kinds of changes.
>>
>> Please separate out the platform IRQ error checking and just submit exactly
>> those changes as a patch series.
>>
>> The other bug fixes should be submitted outside of those changes since they
>> are unrelated.
>
> The issue of whether IRQ 0 is valid or not has been covered several times
> by Linus, and the result is that it is deemed by Linus that IRQ 0 is not
> a valid interrupt.
Then either platform_get_irq() as defined or this commit message (or both)
are wrong.
^ permalink raw reply
* [PATCH 07/12] arm64: mm: Place kImage at bottom of VA space
From: Ard Biesheuvel @ 2017-12-04 16:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204141313.31604-8-steve.capper@arm.com>
On 4 December 2017 at 14:13, Steve Capper <steve.capper@arm.com> wrote:
> Re-arrange the kernel memory map s.t. the kernel image resides in the
> bottom 514MB of memory.
I guess this breaks KASLR entirely, no? Given that it adds an offset
in the range [0 ... sizeof(VMALLOC_SPACE) /4 ].
In any case, it makes sense to keep the kernel VA space adjacent to
the VMALLOC space, rather than put stuff like PCI I/O and the fixmap
in between.
> With the modules, fixed map, PCI IO space placed
> above it. At the very bottom of the memory map we set aside a 2MB guard
> region to prevent ambiguity with PTR_ERR/ERR_PTR.
>
Interesting. In another thread, we discussed whether it is necessary
to prevent the linear map randomization code from allocating at the
very top [bottom in Steve-speak] of the kernel virtual address space,
and this is a thing I did not consider.
> Dynamically resizable objects such as KASAN shadow and sparsemem map
> are placed above the fixed size objects.
>
The current placement of the sparsemem map was carefully chosen so
that virt_to_page/page_to_virt translations are extremely cheap. Is
that still the case?
> This means that kernel addresses are now no longer directly dependent on
> VA space size.
>
> Signed-off-by: Steve Capper <steve.capper@arm.com>
> ---
> arch/arm64/include/asm/memory.h | 17 +++++++++--------
> arch/arm64/include/asm/pgtable.h | 4 ++--
> arch/arm64/mm/dump.c | 12 +++++++-----
> 3 files changed, 18 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 0a912eb3d74f..ba80561c6ed8 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -68,14 +68,15 @@
> #define PAGE_OFFSET (UL(0xffffffffffffffff) - \
> (UL(1) << VA_BITS) + 1)
> #define PAGE_OFFSET_END (VA_START)
> -#define KIMAGE_VADDR (MODULES_END)
> -#define MODULES_END (MODULES_VADDR + MODULES_VSIZE)
> -#define MODULES_VADDR (VA_START + KASAN_SHADOW_SIZE)
> +#define KIMAGE_VSIZE (SZ_512M)
> +#define KIMAGE_VADDR (UL(0) - SZ_2M - KIMAGE_VSIZE)
> #define MODULES_VSIZE (SZ_128M)
> -#define VMEMMAP_START (-VMEMMAP_SIZE)
> -#define PCI_IO_END (VMEMMAP_START - SZ_2M)
> +#define MODULES_END (KIMAGE_VADDR)
> +#define MODULES_VADDR (MODULES_END - MODULES_VSIZE)
> +#define PCI_IO_END (MODULES_VADDR - SZ_2M)
> #define PCI_IO_START (PCI_IO_END - PCI_IO_SIZE)
> -#define FIXADDR_TOP (PCI_IO_START - SZ_2M)
> +#define FIXADDR_TOP (PCI_IO_START - PGDIR_SIZE)
> +#define VMEMMAP_START (FIXADDR_START - VMEMMAP_SIZE)
>
> #define KERNEL_START _text
> #define KERNEL_END _end
> @@ -292,10 +293,10 @@ static inline void *phys_to_virt(phys_addr_t x)
> #define _virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
> #else
> #define __virt_to_pgoff(kaddr) (((u64)(kaddr) & ~PAGE_OFFSET) / PAGE_SIZE * sizeof(struct page))
> -#define __page_to_voff(kaddr) (((u64)(kaddr) & ~VMEMMAP_START) * PAGE_SIZE / sizeof(struct page))
> +#define __page_to_voff(kaddr) (((u64)(kaddr) - VMEMMAP_START) * PAGE_SIZE / sizeof(struct page))
>
> #define page_to_virt(page) ((void *)((__page_to_voff(page)) | PAGE_OFFSET))
> -#define virt_to_page(vaddr) ((struct page *)((__virt_to_pgoff(vaddr)) | VMEMMAP_START))
> +#define virt_to_page(vaddr) ((struct page *)((__virt_to_pgoff(vaddr)) + VMEMMAP_START))
>
> #define _virt_addr_valid(kaddr) pfn_valid((((u64)(kaddr) & ~PAGE_OFFSET) \
> + PHYS_OFFSET) >> PAGE_SHIFT)
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 054b37143a50..e8b4dcc11fed 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -30,8 +30,8 @@
> * VMALLOC_END: extends to the available space below vmmemmap, PCI I/O space
> * and fixed mappings
> */
> -#define VMALLOC_START (MODULES_END)
> -#define VMALLOC_END (- PUD_SIZE - VMEMMAP_SIZE - SZ_64K)
> +#define VMALLOC_START (VA_START + KASAN_SHADOW_SIZE)
> +#define VMALLOC_END (FIXADDR_TOP - PUD_SIZE)
>
> #define vmemmap ((struct page *)VMEMMAP_START - (memstart_addr >> PAGE_SHIFT))
>
> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
> index b7b09c0fc50d..e5d1b5f432fe 100644
> --- a/arch/arm64/mm/dump.c
> +++ b/arch/arm64/mm/dump.c
> @@ -36,17 +36,19 @@ static const struct addr_marker address_markers[] = {
> { KASAN_SHADOW_START, "Kasan shadow start" },
> { KASAN_SHADOW_END, "Kasan shadow end" },
> #endif
> - { MODULES_VADDR, "Modules start" },
> - { MODULES_END, "Modules end" },
> { VMALLOC_START, "vmalloc() Area" },
> { VMALLOC_END, "vmalloc() End" },
> +#ifdef CONFIG_SPARSEMEM_VMEMMAP
> + { VMEMMAP_START, "vmemmap start" },
> + { VMEMMAP_START + VMEMMAP_SIZE, "vmemmap end"},
> +#endif
> { FIXADDR_START, "Fixmap start" },
> { FIXADDR_TOP, "Fixmap end" },
> { PCI_IO_START, "PCI I/O start" },
> { PCI_IO_END, "PCI I/O end" },
> -#ifdef CONFIG_SPARSEMEM_VMEMMAP
> - { VMEMMAP_START, "vmemmap" },
> -#endif
> + { MODULES_VADDR, "Modules start" },
> + { MODULES_END, "Modules end" },
> + { KIMAGE_VADDR, "kImage start"},
> { -1, NULL },
> };
>
> --
> 2.11.0
>
^ permalink raw reply
* [PATCH 03/10] net: ezchip: nps_enet: Fix platform_get_irq's error checking
From: Russell King - ARM Linux @ 2017-12-04 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204.112049.2189145622743900344.davem@davemloft.net>
On Mon, Dec 04, 2017 at 11:20:49AM -0500, David Miller wrote:
> From: Arvind Yadav <arvind.yadav.cs@gmail.com>
> Date: Sun, 3 Dec 2017 00:56:15 +0530
>
> > The platform_get_irq() function returns negative if an error occurs.
> > zero or positive number on success. platform_get_irq() error checking
> > for zero is not correct. And remove unnecessary check for free_netdev().
> >
> > Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
> > ---
> > drivers/net/ethernet/ezchip/nps_enet.c | 7 +++----
> > 1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/ezchip/nps_enet.c b/drivers/net/ethernet/ezchip/nps_enet.c
> > index 659f1ad..82dc6d0 100644
> > --- a/drivers/net/ethernet/ezchip/nps_enet.c
> > +++ b/drivers/net/ethernet/ezchip/nps_enet.c
> > @@ -623,9 +623,9 @@ static s32 nps_enet_probe(struct platform_device *pdev)
> >
> > /* Get IRQ number */
> > priv->irq = platform_get_irq(pdev, 0);
> > - if (!priv->irq) {
> > + if (priv->irq <= 0) {
> > dev_err(dev, "failed to retrieve <irq Rx-Tx> value from device tree\n");
> > - err = -ENODEV;
> > + err = priv->irq ? priv->irq : -ENODEV;
>
> If platform_get_irq() returns "zero or positive number on success" then this
> test is wrong and should be "if (priv->irq < 0)"
>
> Also, this series is a mix of different kinds of changes.
>
> Please separate out the platform IRQ error checking and just submit exactly
> those changes as a patch series.
>
> The other bug fixes should be submitted outside of those changes since they
> are unrelated.
The issue of whether IRQ 0 is valid or not has been covered several times
by Linus, and the result is that it is deemed by Linus that IRQ 0 is not
a valid interrupt.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [RFC PATCH] arm64: deactivate saved ttbr when mm is deactivated
From: Vinayak Menon @ 2017-12-04 16:23 UTC (permalink / raw)
To: linux-arm-kernel
A case is observed where a wrong physical address is read,
resulting in a bus error and that happens soon after TTBR0 is
set to the saved ttbr by uaccess_ttbr0_enable. This is always
seen to happen in the exit path of the task.
exception
__arch_copy_from_user
__copy_from_user
probe_kernel_read
get_freepointer_safe
slab_alloc_node
slab_alloc
kmem_cache_alloc
kmem_cache_zalloc
fill_pool
__debug_object_init
debug_object_init
rcuhead_fixup_activate
debug_object_fixup
debug_object_activate
debug_rcu_head_queue
__call_rcu
ep_remove
eventpoll_release_file
__fput
____fput
task_work_run
do_exit
The mm has been released and the pgd is freed, but probe_kernel_read
invoked from slub results in call to __arch_copy_from_user. At the
entry to __arch_copy_from_user, when SW PAN is enabled, this results
in stale value being set to ttbr0. May be a speculative fetch aftwerwards
is resulting in invalid physical address access.
Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
---
I have not tested this patch to see if it fixes the problem.
Sending it early for comments.
arch/arm64/include/asm/mmu_context.h | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
index 3257895a..48a3f04 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -221,7 +221,16 @@ static inline void __switch_mm(struct mm_struct *next)
update_saved_ttbr0(tsk, next);
}
+#ifdef CONFIG_ARM64_SW_TTBR0_PAN
+static inline void deactivate_mm(struct task_struct *tsk, struct mm_struct *mm)
+{
+ if (system_uses_ttbr0_pan())
+ task_thread_info(tsk)->ttbr0 = __pa_symbol(empty_zero_page);
+}
+#else
#define deactivate_mm(tsk,mm) do { } while (0)
+#endif
+
#define activate_mm(prev,next) switch_mm(prev, next, current)
void verify_cpu_asid_bits(void);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH V5 4/7] OF: properties: Implement get_match_data() callback
From: Rob Herring @ 2017-12-04 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512188864-773-5-git-send-email-okaya@codeaurora.org>
On Fri, Dec 1, 2017 at 10:27 PM, Sinan Kaya <okaya@codeaurora.org> wrote:
> Now that we have a get_match_data() callback as part of the firmware node,
> implement the OF specific piece for it.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/of/property.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/of/property.c b/drivers/of/property.c
> index 264c355..adcde1a 100644
> --- a/drivers/of/property.c
> +++ b/drivers/of/property.c
> @@ -981,6 +981,22 @@ static int of_fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
> return 0;
> }
>
> +void *of_fwnode_get_match_data(const struct fwnode_handle *fwnode,
> + const struct device_driver *drv)
> +{
> + const struct device_node *node = to_of_node(fwnode);
> + const struct of_device_id *match;
> +
> + if (!node)
> + return NULL;
of_match_node checks this.
> +
> + match = of_match_node(drv->of_match_table, node);
> + if (!match)
> + return NULL;
> +
> + return (void *)match->data;
Don't need a cast here.
of_device_get_match_data() already does most of this, but getting a
device ptr from fwnode_handle may not be possible?
Rob
^ permalink raw reply
* [PATCH 03/10] net: ezchip: nps_enet: Fix platform_get_irq's error checking
From: David Miller @ 2017-12-04 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512242782-7134-4-git-send-email-arvind.yadav.cs@gmail.com>
From: Arvind Yadav <arvind.yadav.cs@gmail.com>
Date: Sun, 3 Dec 2017 00:56:15 +0530
> The platform_get_irq() function returns negative if an error occurs.
> zero or positive number on success. platform_get_irq() error checking
> for zero is not correct. And remove unnecessary check for free_netdev().
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
> ---
> drivers/net/ethernet/ezchip/nps_enet.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/ezchip/nps_enet.c b/drivers/net/ethernet/ezchip/nps_enet.c
> index 659f1ad..82dc6d0 100644
> --- a/drivers/net/ethernet/ezchip/nps_enet.c
> +++ b/drivers/net/ethernet/ezchip/nps_enet.c
> @@ -623,9 +623,9 @@ static s32 nps_enet_probe(struct platform_device *pdev)
>
> /* Get IRQ number */
> priv->irq = platform_get_irq(pdev, 0);
> - if (!priv->irq) {
> + if (priv->irq <= 0) {
> dev_err(dev, "failed to retrieve <irq Rx-Tx> value from device tree\n");
> - err = -ENODEV;
> + err = priv->irq ? priv->irq : -ENODEV;
If platform_get_irq() returns "zero or positive number on success" then this
test is wrong and should be "if (priv->irq < 0)"
Also, this series is a mix of different kinds of changes.
Please separate out the platform IRQ error checking and just submit exactly
those changes as a patch series.
The other bug fixes should be submitted outside of those changes since they
are unrelated.
^ permalink raw reply
* [PATCH 0/4] Move DP phy switch to PHY driver
From: Doug Anderson @ 2017-12-04 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4091462.xo23GTqF41@diego>
Hi,
On Sun, Dec 3, 2017 at 11:46 PM, Heiko St?bner <heiko@sntech.de> wrote:
> Hi Chris,
>
> Am Montag, 4. Dezember 2017, 10:47:08 CET schrieb Chris Zhong:
>> On 2017?12?02? 05:58, Heiko Stuebner wrote:
>> > Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson:
>> >> Hi,
>> >>
>> >> On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong <zyw@rock-chips.com> wrote:
>> >>> Hi Doug
>> >>>
>> >>> Thank you for mentioning this patch.
>> >>>
>> >>> I think the focus of the discussion is: can we put the grf control bit
>> >>> to
>> >>> dts.
>> >>>
>> >>> The RK3399 has 2 Type-C phy, but only one DP controller, this
>> >>> "uphy_dp_sel"
>> >>>
>> >>> can help to switch these 2 phy. So I think this bit can be considered as
>> >>> a
>> >>> part of
>> >>>
>> >>> Type-C phy, these 2 phy have different bits, just similar to other bits
>> >>> (such as "pipe-status").
>> >>>
>> >>> Put them to DTS file might be a accepted practice.
>> >>
>> >> I guess the first step would be finding the person to make a decision.
>> >> Is that Heiko? Olof? Kishon? Rob?. As I see it there are a few
>> >> options:
>> >>
>> >> 1. Land this series as-is. This makes the new bit work just like all
>> >> the other ones next to it. If anyone happens to try to use an old
>> >> device tree on a new kernel they'll break. Seems rather unlikely
>> >> given that the whole type C PHY is not really fully functional
>> >> upstream, but technically this is a no-no from a device tree
>> >> perspective.
>> >>
>> >> 2. Change the series to make this property optional. If it's not
>> >> there then the code behaves like it always did. This would address
>> >> the "compatibility" problem but likely wouldn't actually help any real
>> >> people, and it would be extra work.
>> >>
>> >> 3. Redo the driver to deprecate all the old offsets / bits and just
>> >> put the table in the driver, keyed off the compatible string and base
>> >> address if the IO memory.
>> >>
>> >>
>> >> I can't make this decision. It's up to those folks who would be
>> >> landing the patch and I'd be happy with any of them. What I'm less
>> >> happy with, however, is the indecision preventing forward progress.
>> >> We should pick one of the above things and land it. My own personal
>> >> bias is #1: just land the series. No real people will be hurt and
>> >> it's just adding another property that matches the ones next to it.
>> >
>> > I'd second that #1 . That whole type-c phy thingy never fully worked in
>> > the past (some for the never used dp output), so personally I don't have
>> > issues with going that route.
>> >
>> >> From a long term perspective (AKA how I'd write the next driver like
>> >>
>> >> this) I personally lean towards to "tables in the driver, not in the
>> >> device tree" but quite honestly I'm happy to take whatever direction
>> >> the maintainers give.
>> >
>> > It looks like we're in agreement here :-) . GRF stuff should not leak into
>> > the devicetree, as it causes endless headaches later. But I guess we'll
>> > need to live with the ones that happened so far.
>>
>> So, the first step is: move all the private property of tcphy to
>> drivers/phy/rockchip/phy-rockchip-typec.c.
>> Second step: new a member: uphy-dp-sel.
>> In my mind, we should have discussed these properties before, and then I
>> moved them all into DTS.
>
> Actually, I was agreeing with Doug, that we probably don't need to rework the
> type-c phy driver. As most properties for it are in the devicetree right now
> we'll need to support them for backwards-compatiblity anyway.
>
> And yes, there probably was discussion over dts vs. driver-table when the
> type-c driver was introduced, but I either missed it or wasn't firm enough
> back then ;-) .
>
> Hence the "we'll need to live with it" for the type-c phy, but should not
> do similar things in future drivers.
So I guess now we're just waiting for some agreement from Kishon that
he's willing to land the PHY change? Heiko: presumably you could
apply the DP change to drm-misc? ...or is there some other process
needed there?
-Doug
^ permalink raw reply
* [PATCH 05/12] arm64: mm: Remove VMALLOC checks from update_mapping_prot(.)
From: Ard Biesheuvel @ 2017-12-04 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204141313.31604-6-steve.capper@arm.com>
On 4 December 2017 at 14:13, Steve Capper <steve.capper@arm.com> wrote:
> update_mapping_prot assumes that it will be used on the VA for the
> kernel .text section. (Via the check virt >= VMALLOC_START)
>
> Recent kdump patches employ this function to modify the protection of
> the direct linear mapping (which is strictly speaking outside of this
> area), via mark_linear_text_alias_ro(.).
>
Isn't that a bug? Is it guaranteed that those protection attributes
can be modified without splitting live page tables, and the resulting
risk of TLB conflicts?
> We "get away" with this as the direct linear mapping currently follows
> the VA for the kernel text, so the check passes.
>
> This patch removes the check in update_mapping_prot allowing us to move
> the kernel VA layout without spuriously firing the warning.
>
> Signed-off-by: Steve Capper <steve.capper@arm.com>
> ---
> arch/arm64/mm/mmu.c | 6 ------
> 1 file changed, 6 deletions(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 58b1ed6fd7ec..c8f486384fe3 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -383,12 +383,6 @@ void __init create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
> static void update_mapping_prot(phys_addr_t phys, unsigned long virt,
> phys_addr_t size, pgprot_t prot)
> {
> - if (virt < VMALLOC_START) {
> - pr_warn("BUG: not updating mapping for %pa at 0x%016lx - outside kernel range\n",
> - &phys, virt);
> - return;
> - }
> -
> __create_pgd_mapping(init_mm.pgd, phys, virt, size, prot, NULL,
> NO_CONT_MAPPINGS);
>
> --
> 2.11.0
>
^ permalink raw reply
* [PATCH v4] usb: xhci: allow imod-interval to be configurable
From: Timur Tabi @ 2017-12-04 15:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2b252975-bf1f-7468-071e-f4a4aa2430a0@codeaurora.org>
On 12/04/2017 09:48 AM, Adam Wallis wrote:
> As noted in the patch description, xhci-plat devices will use a default of
> 40,000, while MTK devices will use a default of 5,000. This is also documented
> in the probe for each relevant driver. This is further confirmed in the
> description for each driver's binding TXT file.
Serves me right for reviewing patches before I've had my morning coffee.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v4] usb: xhci: allow imod-interval to be configurable
From: Adam Wallis @ 2017-12-04 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9cb2e5fc-1bec-c19c-c04e-fe56e5c1bc16@codeaurora.org>
Timur
On 12/4/2017 9:58 AM, Timur Tabi wrote:
> On 12/4/17 8:27 AM, Adam Wallis wrote:
>> If no interval is specified, the default of 40,000ns (IMOD=160) will be
>> used.
>
> ...
>
>> + - imod-interval-ns: default interrupt moderation interval is 5000ns
>
> ...
>
>> +? - imod-interval-ns: default interrupt moderation interval is 5000ns
>
> ...
>
>> +??? xhci->imod_interval = 5000;
>
> ...
>
>> +??? xhci->imod_interval = 40000;
>
> ...
>
>> +??? xhci->imod_interval = 40000;
>
> Is the default 5,000 or 40,000?? I can't tell.
>
As noted in the patch description, xhci-plat devices will use a default of
40,000, while MTK devices will use a default of 5,000. This is also documented
in the probe for each relevant driver. This is further confirmed in the
description for each driver's binding TXT file.
Adam
--
Adam Wallis
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 3/3] arm64/sve: KVM: Avoid dereference of dead task during guest entry
From: Dave Martin @ 2017-12-04 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_e3SKsreYHrZEBUMEME-pYtxTXW1P6xLUR6YMQfj0cZw@mail.gmail.com>
On Mon, Dec 04, 2017 at 01:53:21PM +0000, Ard Biesheuvel wrote:
> On 1 December 2017 at 15:19, Dave Martin <Dave.Martin@arm.com> wrote:
> > When deciding whether to invalidate FPSIMD state cached in the cpu,
> > the backend function sve_flush_cpu_state() attempts to dereference
> > __this_cpu_read(fpsimd_last_state). However, this is not safe:
> > there is no guarantee that the pointer is still valid, because the
> > task could have exited in the meantime. For this reason, this
> > percpu pointer should only be assigned or compared, never
> > dereferenced.
> >
>
> Doesn't that mean the pointer could also be pointing to the
> fpsimd_state of a newly created task that is completely unrelated?
> IOW, are you sure comparison is safe?
There are more conditions: the only place the determination is
made is for next, in fpsimd_thread_switch(next).
However, I can see your concern and I'm not sure how/if it is
resolved.
For the worst case, let's assume that some child forks off but
doesn't enter userspace yet, while another task round-robins
across all CPUs, interspersed with tasks that don't enter userspace.
So, we end up with
All cpu < NR_CPUS . per_cpu(fpsimd_last_state, cpu) == T.
Now, if T dies and a new task is allocated the same task_struct pointer,
then the _new_ T is guaranteed to get scheduled in on a CPU whose
per_cpu(fpsmid_last_state) == T.
Thus, new T can pick up old T's regs _unless_ new T's fpsimd_state.cpu
is invalid (i.e., NR_CPUS).
This is a separate bug from the one addressed by this patch though.
We can't go and harvest the bad pointers when old T exits, because
this might race new T being scheduled for real -- in any case it
would involve iterating over all CPUs which sounds racy and
inefficient.
So, I'd say we _must_ call fpsimd_flush_task_state() for every new
task. This may result in a redundant reload of the state, but this
is what would happen anyway if the pointers did not alias.
Does this sound real to you? If so, I'll try to write something.
And does this patch look reasonable to fix what it's trying to fix?
I wonder whether arch/arm has the same bug actually, since the kernel-
mode NEON logic was modelled from there IIUC (?)
Cheers
---Dave
^ permalink raw reply
* [PATCH v2 11/12] ARM: dts: imx6qdl-nitrogen6_max: Remove unneeded unit address
From: Gary Bisson @ 2017-12-04 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512390016-703-11-git-send-email-festevam@gmail.com>
Hi Fabio,
On Mon, Dec 04, 2017 at 10:20:15AM -0200, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Remove the unneeded unit address for the i2cmux nodes in order to fix
> the following build warnings with W=1:
>
> arch/arm/boot/dts/imx6q-nitrogen6_max.dtb: Warning (unit_address_vs_reg): Node /i2cmux at 2 has a unit name, but no reg property
> arch/arm/boot/dts/imx6q-nitrogen6_max.dtb: Warning (unit_address_vs_reg): Node /i2cmux at 3 has a unit name, but no reg property
>
> While at it, rename the i2cmux nodes and subnodes to make it clearer to which
> i2c controller the mux belongs to.
>
> Cc: Gary Bisson <gary.bisson@boundarydevices.com>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Gary Bisson <gary.bisson@boundarydevices.com>
Regards,
Gary
^ permalink raw reply
* [PATCH v4.14] Add support for bq27521 battery monitor
From: Andrew F. Davis @ 2017-12-04 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201230649.GA27533@amd>
On 12/01/2017 05:06 PM, Pavel Machek wrote:
> Hi!
>
>> This adds basic support for BQ27521 battery monitor, used in Nokia N9
>> and N950. In particular, battery voltage is important to be able to
>> tell when the battery is almost empty. Emptying battery on N950 is
>> pretty painful, as flasher needs to be used to recover phone in such
>> case.
>
> Sebastian, ping? This one should not be too controversial.
>
> If you could also apply the "shut down when battery is low", that
> would be nice.
>
> Thanks,
> Pavel
>
>> Signed-off-by: Pavel Machek <pavel@ucw.cz>
>>
>> diff --git a/drivers/power/supply/bq27xxx_battery.c b/drivers/power/supply/bq27xxx_battery.c
>> index 51f0961..f684288 100644
>> --- a/drivers/power/supply/bq27xxx_battery.c
>> +++ b/drivers/power/supply/bq27xxx_battery.c
>> @@ -323,6 +323,30 @@ static u8
>> [BQ27XXX_REG_AP] = INVALID_REG_ADDR,
>> BQ27XXX_DM_REG_ROWS,
>> },
>> + bq27521_regs[BQ27XXX_REG_MAX] = {
>> + [BQ27XXX_REG_CTRL] = 0x02,
>> + [BQ27XXX_REG_TEMP] = 0x0a,
>> + [BQ27XXX_REG_INT_TEMP] = INVALID_REG_ADDR,
>> + [BQ27XXX_REG_VOLT] = 0x0c,
>> + [BQ27XXX_REG_AI] = 0x0e,
>> + [BQ27XXX_REG_FLAGS] = 0x08,
>> + [BQ27XXX_REG_TTE] = INVALID_REG_ADDR,
>> + [BQ27XXX_REG_TTF] = INVALID_REG_ADDR,
>> + [BQ27XXX_REG_TTES] = INVALID_REG_ADDR,
>> + [BQ27XXX_REG_TTECP] = INVALID_REG_ADDR,
>> + [BQ27XXX_REG_NAC] = INVALID_REG_ADDR,
>> + [BQ27XXX_REG_FCC] = INVALID_REG_ADDR,
>> + [BQ27XXX_REG_CYCT] = INVALID_REG_ADDR,
>> + [BQ27XXX_REG_AE] = INVALID_REG_ADDR,
>> + [BQ27XXX_REG_SOC] = INVALID_REG_ADDR,
>> + [BQ27XXX_REG_DCAP] = INVALID_REG_ADDR,
>> + [BQ27XXX_REG_AP] = INVALID_REG_ADDR,
>> + [BQ27XXX_DM_CTRL] = INVALID_REG_ADDR,
>> + [BQ27XXX_DM_CLASS] = INVALID_REG_ADDR,
>> + [BQ27XXX_DM_BLOCK] = INVALID_REG_ADDR,
>> + [BQ27XXX_DM_DATA] = INVALID_REG_ADDR,
>> + [BQ27XXX_DM_CKSUM] = INVALID_REG_ADDR,
>> + },
>> bq27530_regs[BQ27XXX_REG_MAX] = {
>> [BQ27XXX_REG_CTRL] = 0x00,
>> [BQ27XXX_REG_TEMP] = 0x06,
>> @@ -557,6 +581,15 @@ static enum power_supply_property bq27520g4_props[] = {
>> POWER_SUPPLY_PROP_MANUFACTURER,
>> };
>>
>> +static enum power_supply_property bq27521_props[] = {
>> + POWER_SUPPLY_PROP_STATUS,
>> + POWER_SUPPLY_PROP_PRESENT,
>> + POWER_SUPPLY_PROP_VOLTAGE_NOW,
>> + POWER_SUPPLY_PROP_CURRENT_NOW,
>> + POWER_SUPPLY_PROP_TEMP,
>> + POWER_SUPPLY_PROP_TECHNOLOGY,
>> +};
>> +
>> static enum power_supply_property bq27530_props[] = {
>> POWER_SUPPLY_PROP_STATUS,
>> POWER_SUPPLY_PROP_PRESENT,
>> @@ -671,6 +704,7 @@ static struct bq27xxx_dm_reg bq27500_dm_regs[] = {
>> #define bq27520g2_dm_regs 0
>> #define bq27520g3_dm_regs 0
>> #define bq27520g4_dm_regs 0
>> +#define bq27521_dm_regs 0
>> #define bq27530_dm_regs 0
>> #define bq27531_dm_regs 0
>> #define bq27541_dm_regs 0
>> @@ -717,8 +751,8 @@ static struct bq27xxx_dm_reg bq27621_dm_regs[] = {
>> #endif
>>
>> #define BQ27XXX_O_ZERO 0x00000001
>> -#define BQ27XXX_O_OTDC 0x00000002
>> -#define BQ27XXX_O_UTOT 0x00000004
>> +#define BQ27XXX_O_OTDC 0x00000002 /* has OTC/OTD overtemperature flags */
>> +#define BQ27XXX_O_UTOT 0x00000004 /* has OT overtemperature flag */
These should get turned into BIT() macros, but that's not your problem
for this patch,
Acked-by: Andrew F. Davis <afd@ti.com>
>> #define BQ27XXX_O_CFGUP 0x00000008
>> #define BQ27XXX_O_RAM 0x00000010
>>
>> @@ -751,6 +785,7 @@ static struct {
>> [BQ27520G2] = BQ27XXX_DATA(bq27520g2, 0 , BQ27XXX_O_OTDC),
>> [BQ27520G3] = BQ27XXX_DATA(bq27520g3, 0 , BQ27XXX_O_OTDC),
>> [BQ27520G4] = BQ27XXX_DATA(bq27520g4, 0 , BQ27XXX_O_OTDC),
>> + [BQ27521] = BQ27XXX_DATA(bq27521, 0 , 0),
>> [BQ27530] = BQ27XXX_DATA(bq27530, 0 , BQ27XXX_O_UTOT),
>> [BQ27531] = BQ27XXX_DATA(bq27531, 0 , BQ27XXX_O_UTOT),
>> [BQ27541] = BQ27XXX_DATA(bq27541, 0 , BQ27XXX_O_OTDC),
>> diff --git a/drivers/power/supply/bq27xxx_battery_i2c.c b/drivers/power/supply/bq27xxx_battery_i2c.c
>> index 0b11ed4..6b25e5f 100644
>> --- a/drivers/power/supply/bq27xxx_battery_i2c.c
>> +++ b/drivers/power/supply/bq27xxx_battery_i2c.c
>> @@ -239,6 +239,7 @@ static const struct i2c_device_id bq27xxx_i2c_id_table[] = {
>> { "bq27520g2", BQ27520G2 },
>> { "bq27520g3", BQ27520G3 },
>> { "bq27520g4", BQ27520G4 },
>> + { "bq27521", BQ27521 },
>> { "bq27530", BQ27530 },
>> { "bq27531", BQ27531 },
>> { "bq27541", BQ27541 },
>> @@ -269,6 +270,7 @@ static const struct of_device_id bq27xxx_battery_i2c_of_match_table[] = {
>> { .compatible = "ti,bq27520g2" },
>> { .compatible = "ti,bq27520g3" },
>> { .compatible = "ti,bq27520g4" },
>> + { .compatible = "ti,bq27521" },
>> { .compatible = "ti,bq27530" },
>> { .compatible = "ti,bq27531" },
>> { .compatible = "ti,bq27541" },
>> diff --git a/include/linux/mfd/twl.h b/include/linux/mfd/twl.h
>> index 9ad7828..6547d30 100644
>> --- a/include/linux/mfd/twl.h
>> +++ b/include/linux/mfd/twl.h
>> @@ -70,6 +70,7 @@ enum twl4030_module_ids {
>> TWL4030_MODULE_INT,
>>
>> TWL5031_MODULE_ACCESSORY,
>> + TWL5031_MODULE_BCC,
>> TWL5031_MODULE_INTERRUPTS,
>>
>> TWL4030_MODULE_LAST,
>> diff --git a/include/linux/power/bq27xxx_battery.h b/include/linux/power/bq27xxx_battery.h
>> index 43194e0..d8d127a 100644
>> --- a/include/linux/power/bq27xxx_battery.h
>> +++ b/include/linux/power/bq27xxx_battery.h
>> @@ -15,6 +15,7 @@ enum bq27xxx_chip {
>> BQ27520G2, /* bq27520G2 */
>> BQ27520G3, /* bq27520G3 */
>> BQ27520G4, /* bq27520G4 */
>> + BQ27521, /* bq27521 */
>> BQ27530, /* bq27530, bq27531 */
>> BQ27531,
>> BQ27541, /* bq27541, bq27542, bq27546, bq27742 */
>>
>
>
>
^ permalink raw reply
* [PATCH v9 0/5] Add support for ThunderX2 pmu events using json files
From: Arnaldo Carvalho de Melo @ 2017-12-04 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKTKpr6kyfbmOcy3JNzQkefN+yhQrvu_2McZU=q=tK3_1G6tyg@mail.gmail.com>
Em Mon, Dec 04, 2017 at 10:11:01AM +0530, Ganapatrao Kulkarni escreveu:
> Hi perf maintainers,
>
> can this be queued to -next??
> please let me know, if have to rebase to any specific branch and send
> next version?
I went over the messages and saw the acks, will try and process it now.
Sorry for the delay, it fell thru the cracks :-\
- Arnaldo
>
> On Mon, Nov 27, 2017 at 3:34 PM, John Garry <john.garry@huawei.com> wrote:
> > On 07/11/2017 01:23, Will Deacon wrote:
> >>
> >> Hi Arnaldo,
> >>
> >> On Tue, Oct 17, 2017 at 12:02:17AM +0530, Ganapatrao Kulkarni wrote:
> >>>
> >>> Extending json/jevent framework for parsing arm64 event files.
> >>> Adding jevents for ThunderX2 implementation defined PMU events.
> >>>
> >>> v9:
> >>> - Rebased to [3] and resolved conficts in PATCH 1/5 and reworked PATCH
> >>> 3/5.
> >>> - Added PATCH 5 to fix segmentation fault in perf_pmu__find_map
> >>>
> >>> [3]
> >>> https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/log/?h=perf/core
> >>
> >>
> >> I'm happy with this version of the series (it's all Acked now), so would
> >> you
> >> be able to pick it up for mainline, please?
> >>
> >> Cheers,
> >>
> >
> > So this patchset has not been merged.
> >
> > We have a patchset waiting for HiSilicon hip08 support, which includes the
> > requested feature for the ARM64 IMP DEFINED recommended events
> > refactoring-out.
> >
> > We can send our hip08 patchset now as an RFC, based in this patchset.
> > Depending on the comments and general acceptance of the approaches, it may
> > be appropriate to merge the patchsets (or at least merge the refactoring
> > part).
> >
> > Thanks,
> > John
> >
> >
> >> Will
> >>
> >> .
> >>
> >
> >
>
> thanks
> Ganapat
^ permalink raw reply
* [PATCH v4] usb: xhci: allow imod-interval to be configurable
From: Timur Tabi @ 2017-12-04 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512397671-28733-1-git-send-email-awallis@codeaurora.org>
On 12/4/17 8:27 AM, Adam Wallis wrote:
> If no interval is specified, the default of 40,000ns (IMOD=160) will be
> used.
...
> + - imod-interval-ns: default interrupt moderation interval is 5000ns
...
> + - imod-interval-ns: default interrupt moderation interval is 5000ns
...
> + xhci->imod_interval = 5000;
...
> + xhci->imod_interval = 40000;
...
> + xhci->imod_interval = 40000;
Is the default 5,000 or 40,000? I can't tell.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 01/12] KVM: arm/arm64: vgic: Remove spurious call to kern_hyp_va
From: Suzuki K Poulose @ 2017-12-04 14:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204141313.31604-2-steve.capper@arm.com>
On 04/12/17 14:13, Steve Capper wrote:
> In save_elrsr(.), we use the following technique to ascertain the
> address of the vgic global state:
> (kern_hyp_va(&kvm_vgic_global_state))->nr_lr
>
> For arm, kern_hyp_va(va) == va, and this call effectively compiles out.
>
> For arm64, this call can be spurious as the address of kvm_vgic_global_state
> will usually be determined by relative page/absolute page offset relocation
> at link time. As the function is idempotent, having the call for arm64 does
> not cause any problems.
>
> Unfortunately, this is about to change for arm64 as we need to change
> the logic of kern_hyp_va to allow for kernel addresses that are outside
> the direct linear map.
>
> This patch removes the call to kern_hyp_va, and ensures that correct
> HYP addresses are computed via relative page offset addressing on arm64.
> This is achieved by a custom accessor, hyp_address(.), which on arm is a
> simple reference operator.
minor nit: I somehow feel that there word "symbol" should be part of the name of
the macro, to make it implicit that it can only be used on a symbol and not any
generic variable.
> diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
> index 08d3bb66c8b7..34a4ae906a97 100644
> --- a/arch/arm64/include/asm/kvm_hyp.h
> +++ b/arch/arm64/include/asm/kvm_hyp.h
> @@ -25,6 +25,16 @@
>
> #define __hyp_text __section(.hyp.text) notrace
>
> +#define hyp_address(symbol) \
> +({ \
> + typeof(&symbol) __ret; \
> + asm volatile( \
> + "adrp %[ptr], " #symbol "\n" \
> + "add %[ptr], %[ptr], :lo12:" #symbol "\n" \
> + : [ptr] "=r"(__ret)); \
> + __ret; \
> +})
> +
> - addr = kern_hyp_va((kern_hyp_va(&kvm_vgic_global_state))->vcpu_base_va);
> + addr = kern_hyp_va(hyp_address(kvm_vgic_global_state)->vcpu_base_va);
e.g, Like here, why do we use hyp_address only for the kvm_vgic_global_state and not
the dereferenced value. Having a name, say, hyp_symbol_address() makes it clear.
Otherwise, looks good to me.
Suzuki
^ permalink raw reply
* [PULL 00/19] KVM/ARM Fixes for v4.15
From: Christoffer Dall @ 2017-12-04 14:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204135622.21568-1-cdall@kernel.org>
Apologies for sending the cover-letter twice; my connection dropped
during my initial attempt to send this pull request, and I thought
nothing came through, but apparently that wasn't the case.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH v4] usb: xhci: allow imod-interval to be configurable
From: Adam Wallis @ 2017-12-04 14:27 UTC (permalink / raw)
To: linux-arm-kernel
The xHCI driver currently has the IMOD set to 160, which
translates to an IMOD interval of 40,000ns (160 * 250)ns
Commit 0cbd4b34cda9 ("xhci: mediatek: support MTK xHCI host controller")
introduced a QUIRK for the MTK platform to adjust this interval to 20,
which translates to an IMOD interval of 5,000ns (20 * 250)ns. This is
due to the fact that the MTK controller IMOD interval is 8 times
as much as defined in xHCI spec.
Instead of adding more quirk bits for additional platforms, this patch
introduces the ability for vendors to set the IMOD_INTERVAL as is
optimal for their platform. By using device_property_read_u32() on
"imod-interval-ns", the IMOD INTERVAL can be specified in nano seconds.
If no interval is specified, the default of 40,000ns (IMOD=160) will be
used.
No bounds checking has been implemented due to the fact that a vendor
may have violated the spec and would need to specify a value outside of
the max 8,000 IRQs/second limit specified in the xHCI spec.
Tested-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Adam Wallis <awallis@codeaurora.org>
---
changes from v3:
* Changed imod-interval to imod-interval-ns [Rob Herring/Chunfeng]
* Changed "modulation" to "moderation" throughout patch [Mathias]
changes from v2:
* Added PCI default value [Mathias]
* Removed xhci-mtk.h from xhci-plat.c [Chunfeng Yun]
* Removed MTK quirk from xhci-plat and moved logic to xhci-mtk [Chunfeng]
* Updated bindings Documentation to use proper units [Rob Herring]
* Added imod-interval description and example to MTK binding documentation
changes from v1:
* Removed device_property_read_u32() per suggestion from greg k-h
* Used ER_IRQ_INTERVAL_MASK in place of (u16) cast
Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt | 2 ++
Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
drivers/usb/host/xhci-mtk.c | 9 +++++++++
drivers/usb/host/xhci-pci.c | 3 +++
drivers/usb/host/xhci-plat.c | 5 +++++
drivers/usb/host/xhci.c | 7 ++-----
drivers/usb/host/xhci.h | 2 ++
7 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
index 3059596..9ff5602 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
@@ -46,6 +46,7 @@ Optional properties:
- pinctrl-names : a pinctrl state named "default" must be defined
- pinctrl-0 : pin control group
See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+ - imod-interval-ns: default interrupt moderation interval is 5000ns
Example:
usb30: usb at 11270000 {
@@ -66,6 +67,7 @@ usb30: usb at 11270000 {
usb3-lpm-capable;
mediatek,syscon-wakeup = <&pericfg>;
mediatek,wakeup-src = <1>;
+ imod-interval-ns = <10000>;
};
2nd: dual-role mode with xHCI driver
diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index ae6e484..969908d 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -29,6 +29,7 @@ Optional properties:
- usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM
- usb3-lpm-capable: determines if platform is USB3 LPM capable
- quirk-broken-port-ped: set if the controller has broken port disable mechanism
+ - imod-interval-ns: default interrupt moderation interval is 5000ns
Example:
usb at f0931000 {
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index b62a1d2..1cb2a8b 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -674,6 +674,15 @@ static int xhci_mtk_probe(struct platform_device *pdev)
xhci = hcd_to_xhci(hcd);
xhci->main_hcd = hcd;
+
+ /*
+ * imod_interval is the interrupt moderation value in nanoseconds.
+ * The increment interval is 8 times as much as that defined in
+ * the xHCI spec on MTK's controller.
+ */
+ xhci->imod_interval = 5000;
+ device_property_read_u32(dev, "imod-interval-ns", &xhci->imod_interval);
+
xhci->shared_hcd = usb_create_shared_hcd(driver, dev,
dev_name(dev), hcd);
if (!xhci->shared_hcd) {
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 7ef1274..4bcddd4 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -234,6 +234,9 @@ static int xhci_pci_setup(struct usb_hcd *hcd)
if (!xhci->sbrn)
pci_read_config_byte(pdev, XHCI_SBRN_OFFSET, &xhci->sbrn);
+ /* imod_interval is the interrupt moderation value in nanoseconds. */
+ xhci->imod_interval = 40000;
+
retval = xhci_gen_setup(hcd, xhci_pci_quirks);
if (retval)
return retval;
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 09f164f..6f03830 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -269,6 +269,11 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (device_property_read_bool(&pdev->dev, "quirk-broken-port-ped"))
xhci->quirks |= XHCI_BROKEN_PORT_PED;
+ /* imod_interval is the interrupt moderation value in nanoseconds. */
+ xhci->imod_interval = 40000;
+ device_property_read_u32(sysdev, "imod-interval-ns",
+ &xhci->imod_interval);
+
hcd->usb_phy = devm_usb_get_phy_by_phandle(sysdev, "usb-phy", 0);
if (IS_ERR(hcd->usb_phy)) {
ret = PTR_ERR(hcd->usb_phy);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2424d30..0b7755b 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -586,11 +586,8 @@ int xhci_run(struct usb_hcd *hcd)
"// Set the interrupt modulation register");
temp = readl(&xhci->ir_set->irq_control);
temp &= ~ER_IRQ_INTERVAL_MASK;
- /*
- * the increment interval is 8 times as much as that defined
- * in xHCI spec on MTK's controller
- */
- temp |= (u32) ((xhci->quirks & XHCI_MTK_HOST) ? 20 : 160);
+ temp |= (xhci->imod_interval / 250) & ER_IRQ_INTERVAL_MASK;
+
writel(temp, &xhci->ir_set->irq_control);
/* Set the HCD state before we enable the irqs */
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 99a014a..2a4177b 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1717,6 +1717,8 @@ struct xhci_hcd {
u8 max_interrupters;
u8 max_ports;
u8 isoc_threshold;
+ /* imod_interval in ns (I * 250ns) */
+ u32 imod_interval;
int event_ring_max;
/* 4KB min, 128MB max */
int page_size;
--
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [kernel-hardening][PATCH v3 3/3] arm: mm: dump: add checking for writable and executable pages
From: Jinbum Park @ 2017-12-04 14:27 UTC (permalink / raw)
To: linux-arm-kernel
Page mappings with full RWX permissions are a security risk.
x86, arm64 has an option to walk the page tables
and dump any bad pages.
(1404d6f13e47
("arm64: dump: Add checking for writable and exectuable pages"))
Add a similar implementation for arm.
Signed-off-by: Jinbum Park <jinb.park7@gmail.com>
---
v3: Reuse pg_level, prot_bits to check ro, nx prot.
arch/arm/Kconfig.debug | 27 +++++++++++++++++++++++
arch/arm/include/asm/ptdump.h | 8 +++++++
arch/arm/mm/dump.c | 51 +++++++++++++++++++++++++++++++++++++++++++
arch/arm/mm/init.c | 2 ++
4 files changed, 88 insertions(+)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index e7b94db..78a6470 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -20,6 +20,33 @@ config ARM_PTDUMP_DEBUGFS
kernel.
If in doubt, say "N"
+config DEBUG_WX
+ bool "Warn on W+X mappings at boot"
+ select ARM_PTDUMP_CORE
+ ---help---
+ Generate a warning if any W+X mappings are found at boot.
+
+ This is useful for discovering cases where the kernel is leaving
+ W+X mappings after applying NX, as such mappings are a security risk.
+
+ Look for a message in dmesg output like this:
+
+ arm/mm: Checked W+X mappings: passed, no W+X pages found.
+
+ or like this, if the check failed:
+
+ arm/mm: Checked W+X mappings: FAILED, <N> W+X pages found.
+
+ Note that even if the check fails, your kernel is possibly
+ still fine, as W+X mappings are not a security hole in
+ themselves, what they do is that they make the exploitation
+ of other unfixed kernel bugs easier.
+
+ There is no runtime or memory usage effect of this option
+ once the kernel has booted up - it's a one time check.
+
+ If in doubt, say "Y".
+
# RMK wants arm kernels compiled with frame pointers or stack unwinding.
# If you know what you are doing and are willing to live without stack
# traces, you can get a slightly smaller kernel by setting this option to
diff --git a/arch/arm/include/asm/ptdump.h b/arch/arm/include/asm/ptdump.h
index 3a6c0b7..b6a0162 100644
--- a/arch/arm/include/asm/ptdump.h
+++ b/arch/arm/include/asm/ptdump.h
@@ -43,6 +43,14 @@ static inline int ptdump_debugfs_register(struct ptdump_info *info,
}
#endif /* CONFIG_ARM_PTDUMP_DEBUGFS */
+void ptdump_check_wx(void);
+
#endif /* CONFIG_ARM_PTDUMP_CORE */
+#ifdef CONFIG_DEBUG_WX
+#define debug_checkwx() ptdump_check_wx()
+#else
+#define debug_checkwx() do { } while (0)
+#endif
+
#endif /* __ASM_PTDUMP_H */
diff --git a/arch/arm/mm/dump.c b/arch/arm/mm/dump.c
index 43a2bee..3e2e6f0 100644
--- a/arch/arm/mm/dump.c
+++ b/arch/arm/mm/dump.c
@@ -52,6 +52,8 @@ struct pg_state {
unsigned long start_address;
unsigned level;
u64 current_prot;
+ bool check_wx;
+ unsigned long wx_pages;
const char *current_domain;
};
@@ -194,6 +196,8 @@ struct pg_level {
const struct prot_bits *bits;
size_t num;
u64 mask;
+ const struct prot_bits *ro_bit;
+ const struct prot_bits *nx_bit;
};
static struct pg_level pg_level[] = {
@@ -203,9 +207,17 @@ struct pg_level {
}, { /* pmd */
.bits = section_bits,
.num = ARRAY_SIZE(section_bits),
+ #ifdef CONFIG_ARM_LPAE
+ .ro_bit = section_bits + 1,
+ #else
+ .ro_bit = section_bits,
+ #endif
+ .nx_bit = section_bits + ARRAY_SIZE(section_bits) - 2,
}, { /* pte */
.bits = pte_bits,
.num = ARRAY_SIZE(pte_bits),
+ .ro_bit = pte_bits + 1,
+ .nx_bit = pte_bits + 2,
},
};
@@ -226,6 +238,23 @@ static void dump_prot(struct pg_state *st, const struct prot_bits *bits, size_t
}
}
+static void note_prot_wx(struct pg_state *st, unsigned long addr)
+{
+ if (!st->check_wx)
+ return;
+ if ((st->current_prot & pg_level[st->level].ro_bit->mask) ==
+ pg_level[st->level].ro_bit->val)
+ return;
+ if ((st->current_prot & pg_level[st->level].nx_bit->mask) ==
+ pg_level[st->level].nx_bit->val)
+ return;
+
+ WARN_ONCE(1, "arm/mm: Found insecure W+X mapping at address %p/%pS\n",
+ (void *)st->start_address, (void *)st->start_address);
+
+ st->wx_pages += (addr - st->start_address) / PAGE_SIZE;
+}
+
static void note_page(struct pg_state *st, unsigned long addr,
unsigned int level, u64 val, const char *domain)
{
@@ -244,6 +273,7 @@ static void note_page(struct pg_state *st, unsigned long addr,
unsigned long delta;
if (st->current_prot) {
+ note_prot_wx(st, addr);
pt_dump_seq_printf(st->seq, "0x%08lx-0x%08lx ",
st->start_address, addr);
@@ -367,6 +397,7 @@ void ptdump_walk_pgd(struct seq_file *m, struct ptdump_info *info)
struct pg_state st = {
.seq = m,
.marker = info->markers,
+ .check_wx = false,
};
walk_pgd(&st, info->mm, info->base_addr);
@@ -391,6 +422,26 @@ static void ptdump_initialize(void)
.base_addr = 0,
};
+void ptdump_check_wx(void)
+{
+ struct pg_state st = {
+ .seq = NULL,
+ .marker = (struct addr_marker[]) {
+ { 0, NULL},
+ { -1, NULL},
+ },
+ .check_wx = true,
+ };
+
+ walk_pgd(&st, &init_mm, 0);
+ note_page(&st, 0, 0, 0, NULL);
+ if (st.wx_pages)
+ pr_warn("Checked W+X mappings: FAILED, %lu W+X pages found\n",
+ st.wx_pages);
+ else
+ pr_info("Checked W+X mappings: passed, no W+X pages found\n");
+}
+
static int ptdump_init(void)
{
ptdump_initialize();
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index a1f11a7..bd6f451 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -36,6 +36,7 @@
#include <asm/system_info.h>
#include <asm/tlb.h>
#include <asm/fixmap.h>
+#include <asm/ptdump.h>
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
@@ -738,6 +739,7 @@ static int __mark_rodata_ro(void *unused)
void mark_rodata_ro(void)
{
stop_machine(__mark_rodata_ro, NULL, NULL);
+ debug_checkwx();
}
void set_kernel_text_rw(void)
--
1.9.1
^ permalink raw reply related
* [kernel-hardening][PATCH v3 2/3] arm: mm: dump: make the page table dumping seq_file optional
From: Jinbum Park @ 2017-12-04 14:26 UTC (permalink / raw)
To: linux-arm-kernel
This patch makes the page table dumping seq_file optional.
It makes the page table dumping code usable for other cases.
This patch refers below commit of arm64.
(ae5d1cf358a5
("arm64: dump: Make the page table dumping seq_file optional"))
Signed-off-by: Jinbum Park <jinb.park7@gmail.com>
---
v3: No changes
arch/arm/mm/dump.c | 28 +++++++++++++++++++++-------
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mm/dump.c b/arch/arm/mm/dump.c
index 8dfe7c3..43a2bee 100644
--- a/arch/arm/mm/dump.c
+++ b/arch/arm/mm/dump.c
@@ -34,6 +34,18 @@
{ -1, NULL },
};
+#define pt_dump_seq_printf(m, fmt, args...) \
+({ \
+ if (m) \
+ seq_printf(m, fmt, ##args); \
+})
+
+#define pt_dump_seq_puts(m, fmt) \
+({ \
+ if (m) \
+ seq_printf(m, fmt); \
+})
+
struct pg_state {
struct seq_file *seq;
const struct addr_marker *marker;
@@ -210,7 +222,7 @@ static void dump_prot(struct pg_state *st, const struct prot_bits *bits, size_t
s = bits->clear;
if (s)
- seq_printf(st->seq, " %s", s);
+ pt_dump_seq_printf(st->seq, " %s", s);
}
}
@@ -224,7 +236,7 @@ static void note_page(struct pg_state *st, unsigned long addr,
st->level = level;
st->current_prot = prot;
st->current_domain = domain;
- seq_printf(st->seq, "---[ %s ]---\n", st->marker->name);
+ pt_dump_seq_printf(st->seq, "---[ %s ]---\n", st->marker->name);
} else if (prot != st->current_prot || level != st->level ||
domain != st->current_domain ||
addr >= st->marker[1].start_address) {
@@ -232,7 +244,7 @@ static void note_page(struct pg_state *st, unsigned long addr,
unsigned long delta;
if (st->current_prot) {
- seq_printf(st->seq, "0x%08lx-0x%08lx ",
+ pt_dump_seq_printf(st->seq, "0x%08lx-0x%08lx ",
st->start_address, addr);
delta = (addr - st->start_address) >> 10;
@@ -240,17 +252,19 @@ static void note_page(struct pg_state *st, unsigned long addr,
delta >>= 10;
unit++;
}
- seq_printf(st->seq, "%9lu%c", delta, *unit);
+ pt_dump_seq_printf(st->seq, "%9lu%c", delta, *unit);
if (st->current_domain)
- seq_printf(st->seq, " %s", st->current_domain);
+ pt_dump_seq_printf(st->seq, " %s",
+ st->current_domain);
if (pg_level[st->level].bits)
dump_prot(st, pg_level[st->level].bits, pg_level[st->level].num);
- seq_printf(st->seq, "\n");
+ pt_dump_seq_printf(st->seq, "\n");
}
if (addr >= st->marker[1].start_address) {
st->marker++;
- seq_printf(st->seq, "---[ %s ]---\n", st->marker->name);
+ pt_dump_seq_printf(st->seq, "---[ %s ]---\n",
+ st->marker->name);
}
st->start_address = addr;
st->current_prot = prot;
--
1.9.1
^ permalink raw reply related
* [kernel-hardening][PATCH v3 1/3] arm: mm: dump: make page table dumping reusable
From: Jinbum Park @ 2017-12-04 14:25 UTC (permalink / raw)
To: linux-arm-kernel
This patch refactors the arm page table dumping code,
so multiple tables may be registered with the framework.
This patch refers below commits of arm64.
(4674fdb9f149 ("arm64: mm: dump: make page table dumping reusable"))
(4ddb9bf83349 ("arm64: dump: Make ptdump debugfs a separate option"))
Signed-off-by: Jinbum Park <jinb.park7@gmail.com>
---
v3: No changes
arch/arm/Kconfig.debug | 6 +++-
arch/arm/include/asm/ptdump.h | 48 ++++++++++++++++++++++++++++++++
arch/arm/mm/Makefile | 3 +-
arch/arm/mm/dump.c | 65 +++++++++++++++++++------------------------
arch/arm/mm/ptdump_debugfs.c | 34 ++++++++++++++++++++++
5 files changed, 117 insertions(+), 39 deletions(-)
create mode 100644 arch/arm/include/asm/ptdump.h
create mode 100644 arch/arm/mm/ptdump_debugfs.c
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 17685e1..e7b94db 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -3,10 +3,14 @@ menu "Kernel hacking"
source "lib/Kconfig.debug"
-config ARM_PTDUMP
+config ARM_PTDUMP_CORE
+ def_bool n
+
+config ARM_PTDUMP_DEBUGFS
bool "Export kernel pagetable layout to userspace via debugfs"
depends on DEBUG_KERNEL
depends on MMU
+ select ARM_PTDUMP_CORE
select DEBUG_FS
---help---
Say Y here if you want to show the kernel pagetable layout in a
diff --git a/arch/arm/include/asm/ptdump.h b/arch/arm/include/asm/ptdump.h
new file mode 100644
index 0000000..3a6c0b7
--- /dev/null
+++ b/arch/arm/include/asm/ptdump.h
@@ -0,0 +1,48 @@
+/*
+ * Copyright (C) 2014 ARM Ltd.
+ *
+ * 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.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+#ifndef __ASM_PTDUMP_H
+#define __ASM_PTDUMP_H
+
+#ifdef CONFIG_ARM_PTDUMP_CORE
+
+#include <linux/mm_types.h>
+#include <linux/seq_file.h>
+
+struct addr_marker {
+ unsigned long start_address;
+ char *name;
+};
+
+struct ptdump_info {
+ struct mm_struct *mm;
+ const struct addr_marker *markers;
+ unsigned long base_addr;
+};
+
+void ptdump_walk_pgd(struct seq_file *s, struct ptdump_info *info);
+#ifdef CONFIG_ARM_PTDUMP_DEBUGFS
+int ptdump_debugfs_register(struct ptdump_info *info, const char *name);
+#else
+static inline int ptdump_debugfs_register(struct ptdump_info *info,
+ const char *name)
+{
+ return 0;
+}
+#endif /* CONFIG_ARM_PTDUMP_DEBUGFS */
+
+#endif /* CONFIG_ARM_PTDUMP_CORE */
+
+#endif /* __ASM_PTDUMP_H */
diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
index 01bcc33..28be5f4 100644
--- a/arch/arm/mm/Makefile
+++ b/arch/arm/mm/Makefile
@@ -13,7 +13,8 @@ obj-y += nommu.o
obj-$(CONFIG_ARM_MPU) += pmsa-v7.o
endif
-obj-$(CONFIG_ARM_PTDUMP) += dump.o
+obj-$(CONFIG_ARM_PTDUMP_CORE) += dump.o
+obj-$(CONFIG_ARM_PTDUMP_DEBUGFS) += ptdump_debugfs.o
obj-$(CONFIG_MODULES) += proc-syms.o
obj-$(CONFIG_DEBUG_VIRTUAL) += physaddr.o
diff --git a/arch/arm/mm/dump.c b/arch/arm/mm/dump.c
index fc3b440..8dfe7c3 100644
--- a/arch/arm/mm/dump.c
+++ b/arch/arm/mm/dump.c
@@ -21,11 +21,7 @@
#include <asm/fixmap.h>
#include <asm/memory.h>
#include <asm/pgtable.h>
-
-struct addr_marker {
- unsigned long start_address;
- const char *name;
-};
+#include <asm/ptdump.h>
static struct addr_marker address_markers[] = {
{ MODULES_VADDR, "Modules" },
@@ -335,50 +331,36 @@ static void walk_pud(struct pg_state *st, pgd_t *pgd, unsigned long start)
}
}
-static void walk_pgd(struct seq_file *m)
+static void walk_pgd(struct pg_state *st, struct mm_struct *mm,
+ unsigned long start)
{
- pgd_t *pgd = swapper_pg_dir;
- struct pg_state st;
- unsigned long addr;
+ pgd_t *pgd = pgd_offset(mm, 0UL);
unsigned i;
-
- memset(&st, 0, sizeof(st));
- st.seq = m;
- st.marker = address_markers;
+ unsigned long addr;
for (i = 0; i < PTRS_PER_PGD; i++, pgd++) {
- addr = i * PGDIR_SIZE;
+ addr = start + i * PGDIR_SIZE;
if (!pgd_none(*pgd)) {
- walk_pud(&st, pgd, addr);
+ walk_pud(st, pgd, addr);
} else {
- note_page(&st, addr, 1, pgd_val(*pgd), NULL);
+ note_page(st, addr, 1, pgd_val(*pgd), NULL);
}
}
-
- note_page(&st, 0, 0, 0, NULL);
}
-static int ptdump_show(struct seq_file *m, void *v)
+void ptdump_walk_pgd(struct seq_file *m, struct ptdump_info *info)
{
- walk_pgd(m);
- return 0;
-}
+ struct pg_state st = {
+ .seq = m,
+ .marker = info->markers,
+ };
-static int ptdump_open(struct inode *inode, struct file *file)
-{
- return single_open(file, ptdump_show, NULL);
+ walk_pgd(&st, info->mm, info->base_addr);
+ note_page(&st, 0, 0, 0, NULL);
}
-static const struct file_operations ptdump_fops = {
- .open = ptdump_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
-};
-
-static int ptdump_init(void)
+static void ptdump_initialize(void)
{
- struct dentry *pe;
unsigned i, j;
for (i = 0; i < ARRAY_SIZE(pg_level); i++)
@@ -387,9 +369,18 @@ static int ptdump_init(void)
pg_level[i].mask |= pg_level[i].bits[j].mask;
address_markers[2].start_address = VMALLOC_START;
+}
- pe = debugfs_create_file("kernel_page_tables", 0400, NULL, NULL,
- &ptdump_fops);
- return pe ? 0 : -ENOMEM;
+static struct ptdump_info kernel_ptdump_info = {
+ .mm = &init_mm,
+ .markers = address_markers,
+ .base_addr = 0,
+};
+
+static int ptdump_init(void)
+{
+ ptdump_initialize();
+ return ptdump_debugfs_register(&kernel_ptdump_info,
+ "kernel_page_tables");
}
__initcall(ptdump_init);
diff --git a/arch/arm/mm/ptdump_debugfs.c b/arch/arm/mm/ptdump_debugfs.c
new file mode 100644
index 0000000..be8d87b
--- /dev/null
+++ b/arch/arm/mm/ptdump_debugfs.c
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <linux/debugfs.h>
+#include <linux/seq_file.h>
+
+#include <asm/ptdump.h>
+
+static int ptdump_show(struct seq_file *m, void *v)
+{
+ struct ptdump_info *info = m->private;
+
+ ptdump_walk_pgd(m, info);
+ return 0;
+}
+
+static int ptdump_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, ptdump_show, inode->i_private);
+}
+
+static const struct file_operations ptdump_fops = {
+ .open = ptdump_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
+int ptdump_debugfs_register(struct ptdump_info *info, const char *name)
+{
+ struct dentry *pe;
+
+ pe = debugfs_create_file(name, 0400, NULL, info, &ptdump_fops);
+ return pe ? 0 : -ENOMEM;
+
+}
--
1.9.1
^ permalink raw reply related
* [kernel-hardening][PATCH v3 0/3] arm: Makes ptdump resuable and add WX page checking
From: Jinbum Park @ 2017-12-04 14:24 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Page table dumping code for arm64-x86 is reusable,
and they have function for WX page checking.
But arm doesn't have that.
This path series are to makes ptdump reusable,
and add WX page checking for arm.
This is heavily based on arm64 version.
v2 :
Fix a sender name of mail header, there was an mistake.
(from "jinb.park" to Jinbum Park)
Contents of patch-set are perfectly same.
v3 :
Take advantage of the existing pg_level and bits arrays
to check ro, nx prot.
jinb.park (3):
arm: mm: dump: make page table dumping reusable
arm: mm: dump: make the page table dumping seq_file optional
arm: mm: dump: add checking for writable and executable pages
arch/arm/Kconfig.debug | 33 +++++++++-
arch/arm/include/asm/ptdump.h | 56 ++++++++++++++++
arch/arm/mm/Makefile | 3 +-
arch/arm/mm/dump.c | 144 +++++++++++++++++++++++++++++-------------
arch/arm/mm/init.c | 2 +
arch/arm/mm/ptdump_debugfs.c | 34 ++++++++++
6 files changed, 226 insertions(+), 46 deletions(-)
create mode 100644 arch/arm/include/asm/ptdump.h
create mode 100644 arch/arm/mm/ptdump_debugfs.c
--
1.9.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox