On Wed, Oct 31, 2018 at 02:19:07PM +0100, Jiri Kosina wrote:
> On Wed, 31 Oct 2018, Mark Rutland wrote:
>
> > I guess skipping the original function prologue would simplify the
> > implementation of the replacement function (and would mean that the regs
> > held th
Hi Torsten,
On Fri, Oct 26, 2018 at 04:21:48PM +0200, Torsten Duwe wrote:
> Use -fpatchable-function-entry (gcc8) to add 2 NOPs at the beginning
> of each function. Replace the first NOP thus generated with a quick LR
> saver (move it to scratch reg x9), so the 2nd replacement insn, the call
> to
Hi Torsten,
On Fri, Oct 26, 2018 at 04:21:48PM +0200, Torsten Duwe wrote:
> Use -fpatchable-function-entry (gcc8) to add 2 NOPs at the beginning
> of each function. Replace the first NOP thus generated with a quick LR
> saver (move it to scratch reg x9), so the 2nd replacement insn, the call
> to
On Mon, Oct 29, 2018 at 02:20:51PM +, Wiebe, Wladislav (Nokia - DE/Ulm)
wrote:
> When running into situations like:
> "Unhandled fault: synchronous external abort (0x210) at 0xXXX"
> or
> "Unhandled prefetch abort: synchronous external abort (0x210) at 0xXXX"
> it is useful to know the
On Mon, Oct 29, 2018 at 02:20:51PM +, Wiebe, Wladislav (Nokia - DE/Ulm)
wrote:
> When running into situations like:
> "Unhandled fault: synchronous external abort (0x210) at 0xXXX"
> or
> "Unhandled prefetch abort: synchronous external abort (0x210) at 0xXXX"
> it is useful to know the
Hi Josh,
I also have a few concerns here, as it is not clear to me precisely what is
required from arch code. Is there any documentation I should look at?
On Fri, Oct 26, 2018 at 10:37:04AM -0500, Josh Poimboeuf wrote:
> On Fri, Oct 26, 2018 at 04:21:57PM +0200, Torsten Duwe wrote:
> > Enhance
Hi Josh,
I also have a few concerns here, as it is not clear to me precisely what is
required from arch code. Is there any documentation I should look at?
On Fri, Oct 26, 2018 at 10:37:04AM -0500, Josh Poimboeuf wrote:
> On Fri, Oct 26, 2018 at 04:21:57PM +0200, Torsten Duwe wrote:
> > Enhance
On Mon, Oct 29, 2018 at 11:59:59AM +0530, Ashish Mhetre wrote:
> From: Alex Van Brunt
>
> Accessed bit is used to age a page and in generic implementation there is
> flush_tlb while clearing the accessed bit.
> Flushing a TLB is overhead on ARM64 as access flag faults don't get
> translation
On Mon, Oct 29, 2018 at 11:59:59AM +0530, Ashish Mhetre wrote:
> From: Alex Van Brunt
>
> Accessed bit is used to age a page and in generic implementation there is
> flush_tlb while clearing the accessed bit.
> Flushing a TLB is overhead on ARM64 as access flag faults don't get
> translation
On Thu, Oct 25, 2018 at 09:42:24PM +0530, Ashish Mhetre wrote:
> From: Alex Van Brunt
>
> Accessed bit is used to age a page and in generic implementation there is
> flush_tlb while clearing the accessed bit.
> Flushing a TLB is overhead on ARM64 as access flag faults don't get
> translation
On Thu, Oct 25, 2018 at 09:42:24PM +0530, Ashish Mhetre wrote:
> From: Alex Van Brunt
>
> Accessed bit is used to age a page and in generic implementation there is
> flush_tlb while clearing the accessed bit.
> Flushing a TLB is overhead on ARM64 as access flag faults don't get
> translation
On Wed, Oct 24, 2018 at 01:25:37AM +0800, Peng Hao wrote:
> Signed-off-by: Peng Hao
> ---
> .../devicetree/bindings/arm/pvpanic-mmio.txt | 26
> ++
> 1 file changed, 26 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/pvpanic-mmio.txt
>
> diff
On Wed, Oct 24, 2018 at 01:25:37AM +0800, Peng Hao wrote:
> Signed-off-by: Peng Hao
> ---
> .../devicetree/bindings/arm/pvpanic-mmio.txt | 26
> ++
> 1 file changed, 26 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/pvpanic-mmio.txt
>
> diff
On Wed, Oct 24, 2018 at 01:25:35AM +0800, Peng Hao wrote:
> pvpanic device is a qemu-specific emulation device. Pvpanic
> devices are now available for ARM64. This patch supports the APCI
> way to get device information.
This woule be better described as:
pvpanic: add MMIO support
On some
On Wed, Oct 24, 2018 at 01:25:35AM +0800, Peng Hao wrote:
> pvpanic device is a qemu-specific emulation device. Pvpanic
> devices are now available for ARM64. This patch supports the APCI
> way to get device information.
This woule be better described as:
pvpanic: add MMIO support
On some
On Mon, Oct 22, 2018 at 06:23:08PM +0800, Nick Hu wrote:
> Hi Mark,
>
> On Thu, Oct 18, 2018 at 10:31:32PM +0800, Mark Rutland wrote:
> > On Thu, Oct 18, 2018 at 04:43:17PM +0800, Nickhu wrote:
> > > The document for how to add NDS32 PMU
> > > in devicetree.
&
On Mon, Oct 22, 2018 at 06:23:08PM +0800, Nick Hu wrote:
> Hi Mark,
>
> On Thu, Oct 18, 2018 at 10:31:32PM +0800, Mark Rutland wrote:
> > On Thu, Oct 18, 2018 at 04:43:17PM +0800, Nickhu wrote:
> > > The document for how to add NDS32 PMU
> > > in devicetree.
&
On Mon, Oct 22, 2018 at 06:18:26PM +0800, Nick Hu wrote:
> On Thu, Oct 18, 2018 at 03:23:59PM +0100, Mark Rutland wrote:
> > On Thu, Oct 18, 2018 at 04:43:13PM +0800, Nickhu wrote:
> > > +static irqreturn_t nds32_pmu_handle_irq(int irq_num, void *dev)
> >
On Mon, Oct 22, 2018 at 06:18:26PM +0800, Nick Hu wrote:
> On Thu, Oct 18, 2018 at 03:23:59PM +0100, Mark Rutland wrote:
> > On Thu, Oct 18, 2018 at 04:43:13PM +0800, Nickhu wrote:
> > > +static irqreturn_t nds32_pmu_handle_irq(int irq_num, void *dev)
> >
On Thu, Oct 18, 2018 at 09:56:11AM +0800, peng.h...@zte.com.cn wrote:
> >Hi,
> >
> >[adding devicetree]
> >
> >On Wed, Oct 17, 2018 at 06:08:23PM +0800, Peng Hao wrote:
[...]
> >> +#define PVPANIC_MMIO_CRASHED(1 << 0)
> >
> >This looks like it's identical to PVPANIC_PANICKED in the existing
On Thu, Oct 18, 2018 at 09:56:11AM +0800, peng.h...@zte.com.cn wrote:
> >Hi,
> >
> >[adding devicetree]
> >
> >On Wed, Oct 17, 2018 at 06:08:23PM +0800, Peng Hao wrote:
[...]
> >> +#define PVPANIC_MMIO_CRASHED(1 << 0)
> >
> >This looks like it's identical to PVPANIC_PANICKED in the existing
On Thu, Oct 18, 2018 at 04:43:17PM +0800, Nickhu wrote:
> The document for how to add NDS32 PMU
> in devicetree.
>
> Signed-off-by: Nickhu
> ---
> Documentation/devicetree/bindings/nds32/pmu.txt | 17 +
> 1 file changed, 17 insertions(+)
> create mode 100644
On Thu, Oct 18, 2018 at 04:43:17PM +0800, Nickhu wrote:
> The document for how to add NDS32 PMU
> in devicetree.
>
> Signed-off-by: Nickhu
> ---
> Documentation/devicetree/bindings/nds32/pmu.txt | 17 +
> 1 file changed, 17 insertions(+)
> create mode 100644
On Thu, Oct 18, 2018 at 04:43:16PM +0800, Nickhu wrote:
> When there are multiple events map to the same counter, the counter
> counts inaccurately. This is because each counter only counts one event
> in the same time.
> So when there are multiple events map to same counter, they have to take
>
On Thu, Oct 18, 2018 at 04:43:16PM +0800, Nickhu wrote:
> When there are multiple events map to the same counter, the counter
> counts inaccurately. This is because each counter only counts one event
> in the same time.
> So when there are multiple events map to same counter, they have to take
>
On Thu, Oct 18, 2018 at 04:43:14PM +0800, Nickhu wrote:
> There two bitfield bug for perfomance counter
> in bitfield.h:
>
> PFM_CTL_offSEL1 21 --> 16
> PFM_CTL_offSEL2 27 --> 22
>
> This commit fix it.
>
> Signed-off-by: Nickhu
This patch should probably be move
On Thu, Oct 18, 2018 at 04:43:14PM +0800, Nickhu wrote:
> There two bitfield bug for perfomance counter
> in bitfield.h:
>
> PFM_CTL_offSEL1 21 --> 16
> PFM_CTL_offSEL2 27 --> 22
>
> This commit fix it.
>
> Signed-off-by: Nickhu
This patch should probably be move
HI,
On Thu, Oct 18, 2018 at 04:43:13PM +0800, Nickhu wrote:
> +#define PFM_CTL_OVF(idx) PFM_CTL_mskOVF ## idx
> +#define PFM_CTL_EN(idx) PFM_CTL_mskEN ## idx
> +#define PFM_CTL_OFFSEL(idx) PFM_CTL_offSEL ## idx
> +#define PFM_CTL_IE(idx)
HI,
On Thu, Oct 18, 2018 at 04:43:13PM +0800, Nickhu wrote:
> +#define PFM_CTL_OVF(idx) PFM_CTL_mskOVF ## idx
> +#define PFM_CTL_EN(idx) PFM_CTL_mskEN ## idx
> +#define PFM_CTL_OFFSEL(idx) PFM_CTL_offSEL ## idx
> +#define PFM_CTL_IE(idx)
Hi,
[adding devicetree]
On Wed, Oct 17, 2018 at 06:08:23PM +0800, Peng Hao wrote:
> Add a platform device driver, pvpanic-mmio that is similar
> to x86's pvpanic device.
It would be worth noting in the commit message that this is a
QEMU-specific device.
Is this already in upstream QEMU?
>
Hi,
[adding devicetree]
On Wed, Oct 17, 2018 at 06:08:23PM +0800, Peng Hao wrote:
> Add a platform device driver, pvpanic-mmio that is similar
> to x86's pvpanic device.
It would be worth noting in the commit message that this is a
QEMU-specific device.
Is this already in upstream QEMU?
>
On Wed, Oct 10, 2018 at 12:45:59PM +0200, Peter Zijlstra wrote:
> Hi all,
>
> There have been various issues and limitations with the way perf uses
> (task) contexts to track events. Most notable is the single hardware PMU
> task context, which has resulted in a number of yucky things (both
>
On Wed, Oct 10, 2018 at 12:45:59PM +0200, Peter Zijlstra wrote:
> Hi all,
>
> There have been various issues and limitations with the way perf uses
> (task) contexts to track events. Most notable is the single hardware PMU
> task context, which has resulted in a number of yucky things (both
>
On Tue, Oct 16, 2018 at 10:23:50AM +0200, Neil Armstrong wrote:
> Hi Mark,
>
> On 15/10/2018 18:42, Mark Rutland wrote:
> > On Mon, Oct 15, 2018 at 06:28:32PM +0200, Jerome Brunet wrote:
> >> Since commit 50d7ba36b916 ("arm64: export memblock_reserve()d
On Tue, Oct 16, 2018 at 10:23:50AM +0200, Neil Armstrong wrote:
> Hi Mark,
>
> On 15/10/2018 18:42, Mark Rutland wrote:
> > On Mon, Oct 15, 2018 at 06:28:32PM +0200, Jerome Brunet wrote:
> >> Since commit 50d7ba36b916 ("arm64: export memblock_reserve()d
On Mon, Oct 15, 2018 at 06:28:32PM +0200, Jerome Brunet wrote:
> Since commit 50d7ba36b916 ("arm64: export memblock_reserve()d regions via
> /proc/iomem")
> was merged Amlogic's boards using mainline u-boot started showing the
> following warning:
>
> WARNING: CPU: 0 PID: 1 at
On Mon, Oct 15, 2018 at 06:28:32PM +0200, Jerome Brunet wrote:
> Since commit 50d7ba36b916 ("arm64: export memblock_reserve()d regions via
> /proc/iomem")
> was merged Amlogic's boards using mainline u-boot started showing the
> following warning:
>
> WARNING: CPU: 0 PID: 1 at
On Mon, Oct 15, 2018 at 02:31:09PM +0200, Marek Szyprowski wrote:
> To get ARM Architected Timers working on Samsung Exynos SoCs, one has to
> first configure and enable Exynos Multi-Core Timer, because they both
> share some common hardware blocks.
Could you please elaborate on what exactly is
On Mon, Oct 15, 2018 at 02:31:09PM +0200, Marek Szyprowski wrote:
> To get ARM Architected Timers working on Samsung Exynos SoCs, one has to
> first configure and enable Exynos Multi-Core Timer, because they both
> share some common hardware blocks.
Could you please elaborate on what exactly is
On Fri, Oct 12, 2018 at 09:56:05AM +0100, Will Deacon wrote:
> On Fri, Oct 12, 2018 at 09:53:54AM +0100, Mark Rutland wrote:
> > On Thu, Oct 11, 2018 at 05:28:14PM +0100, Will Deacon wrote:
> > > On Fri, Oct 05, 2018 at 09:47:38AM +0100, Kristina Martsenko wrote:
>
On Fri, Oct 12, 2018 at 09:56:05AM +0100, Will Deacon wrote:
> On Fri, Oct 12, 2018 at 09:53:54AM +0100, Mark Rutland wrote:
> > On Thu, Oct 11, 2018 at 05:28:14PM +0100, Will Deacon wrote:
> > > On Fri, Oct 05, 2018 at 09:47:38AM +0100, Kristina Martsenko wrote:
>
On Wed, Oct 10, 2018 at 06:45:17AM +, Chunhui Li (李春辉) wrote:
> Hi Mark,
>
> kasan detect out-of-bounds in stacktrace.c line 70, it's already over
> READ_ONCE_NOCHECK, but still crash
> kernel-4.9/arch/arm64/kernel/stacktrace.c
> 69frame->sp = fp + 0x10;
> 70frame->fp =
On Wed, Oct 10, 2018 at 06:45:17AM +, Chunhui Li (李春辉) wrote:
> Hi Mark,
>
> kasan detect out-of-bounds in stacktrace.c line 70, it's already over
> READ_ONCE_NOCHECK, but still crash
> kernel-4.9/arch/arm64/kernel/stacktrace.c
> 69frame->sp = fp + 0x10;
> 70frame->fp =
On Tue, Oct 09, 2018 at 06:11:03PM +0800, Chunhui Li wrote:
> From: "chunhui.li"
>
>kasan detect unwind_frame out-of-bounds error when one task
> dump another, log as below
> BUG: KASAN: out-of-bounds in unwind_frame+0x140/0x20c Read of
> size 8 at addr ffea1e2378e0 by task
On Tue, Oct 09, 2018 at 06:11:03PM +0800, Chunhui Li wrote:
> From: "chunhui.li"
>
>kasan detect unwind_frame out-of-bounds error when one task
> dump another, log as below
> BUG: KASAN: out-of-bounds in unwind_frame+0x140/0x20c Read of
> size 8 at addr ffea1e2378e0 by task
On Tue, Sep 04, 2018 at 11:48:24AM +0100, Mark Rutland wrote:
> Hi Ingo,
>
> As previously requested, this is a (trivial) rebase of the remaining generated
> atomic patches atop of v4.19-rc2, avoiding any potential conflict with Peter's
> ldsem atomic cleanup patch that got taken
On Tue, Sep 04, 2018 at 11:48:24AM +0100, Mark Rutland wrote:
> Hi Ingo,
>
> As previously requested, this is a (trivial) rebase of the remaining generated
> atomic patches atop of v4.19-rc2, avoiding any potential conflict with Peter's
> ldsem atomic cleanup patch that got taken
On Fri, Oct 05, 2018 at 10:15:57AM +0530, Manjeet Pawar wrote:
> From: Rohit Thapliyal
>
> During user undefined instruction exception, the arm exception
> handler currently results in application crash through SIGILL.
> The bad instruction can be due to ddr/hardware issue.
If the DDR
On Fri, Oct 05, 2018 at 10:15:57AM +0530, Manjeet Pawar wrote:
> From: Rohit Thapliyal
>
> During user undefined instruction exception, the arm exception
> handler currently results in application crash through SIGILL.
> The bad instruction can be due to ddr/hardware issue.
If the DDR
On Tue, Oct 02, 2018 at 02:18:17PM +0200, Torsten Duwe wrote:
> Hi Mark,
Hi,
> thank you for your very detailed feedback, I'll incorporate it
> all into the next version, besides one issue:
>
> On Tue, Oct 02, 2018 at 12:27:41PM +0100, Mark Rutland wrote:
> >
> > Pl
On Tue, Oct 02, 2018 at 02:18:17PM +0200, Torsten Duwe wrote:
> Hi Mark,
Hi,
> thank you for your very detailed feedback, I'll incorporate it
> all into the next version, besides one issue:
>
> On Tue, Oct 02, 2018 at 12:27:41PM +0100, Mark Rutland wrote:
> >
> > Pl
Hi Hoan,
On Wed, Sep 19, 2018 at 06:44:30PM +, Hoan Tran wrote:
> This patch adds CPU hotplug support where the PMU migrates the context to
> another online CPU when its CPU is offline.
>
> It fixes the below issue where the user does offline the CPU which is assigned
> to this PMU.
>
>
Hi Hoan,
On Wed, Sep 19, 2018 at 06:44:30PM +, Hoan Tran wrote:
> This patch adds CPU hotplug support where the PMU migrates the context to
> another online CPU when its CPU is offline.
>
> It fixes the below issue where the user does offline the CPU which is assigned
> to this PMU.
>
>
On Mon, Oct 01, 2018 at 04:16:48PM +0200, Torsten Duwe wrote:
> Check for compiler support of -fpatchable-function-entry and use it
> to intercept functions immediately on entry, saving the LR in x9.
> patchable-function-entry in GCC disables IPA-RA, which means ABI
> register calling conventions
On Mon, Oct 01, 2018 at 04:16:48PM +0200, Torsten Duwe wrote:
> Check for compiler support of -fpatchable-function-entry and use it
> to intercept functions immediately on entry, saving the LR in x9.
> patchable-function-entry in GCC disables IPA-RA, which means ABI
> register calling conventions
On Fri, Sep 28, 2018 at 10:23:40AM -0700, Andi Kleen wrote:
> > There's also been prior discussion on these feature in other contexts
> > (e.g. android expoits resulting from out-of-tree drivers). It would be
> > nice to see those considered.
> >
> > IIRC The conclusion from prior discussions
On Fri, Sep 28, 2018 at 10:23:40AM -0700, Andi Kleen wrote:
> > There's also been prior discussion on these feature in other contexts
> > (e.g. android expoits resulting from out-of-tree drivers). It would be
> > nice to see those considered.
> >
> > IIRC The conclusion from prior discussions
On Fri, Sep 28, 2018 at 12:26:52PM +0200, Thomas Gleixner wrote:
> On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
>
> It would be very helpful if you cc all involved people on the cover letter
> instead of just cc'ing your own pile of email addresses. CC'ed now.
>
> > For situations where sysadmins
On Fri, Sep 28, 2018 at 12:26:52PM +0200, Thomas Gleixner wrote:
> On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
>
> It would be very helpful if you cc all involved people on the cover letter
> instead of just cc'ing your own pile of email addresses. CC'ed now.
>
> > For situations where sysadmins
On Thu, Sep 27, 2018 at 12:27:10PM -0700, Florian Fainelli wrote:
> When THUMB2_KERNEL is enabled, we would be setting the secondary core's
> entry point to secondary_startup() which is already Thumb2 code, utilize
> secondary_startup_arm() which takes care of doing the mode switching for
> us.
On Thu, Sep 27, 2018 at 12:27:10PM -0700, Florian Fainelli wrote:
> When THUMB2_KERNEL is enabled, we would be setting the secondary core's
> entry point to secondary_startup() which is already Thumb2 code, utilize
> secondary_startup_arm() which takes care of doing the mode switching for
> us.
On Thu, Sep 27, 2018 at 12:27:09PM -0700, Florian Fainelli wrote:
> When THUMB2_KERNEL is enabled, we would be failing to resume from an
> idle or system suspend call where the reentry point is set to
> cpu_resume() because that function is in Thumb2. Utilize
> cpu_resume_arm() for ARM 32-bit
On Thu, Sep 27, 2018 at 12:27:09PM -0700, Florian Fainelli wrote:
> When THUMB2_KERNEL is enabled, we would be failing to resume from an
> idle or system suspend call where the reentry point is set to
> cpu_resume() because that function is in Thumb2. Utilize
> cpu_resume_arm() for ARM 32-bit
On Tue, Sep 25, 2018 at 05:53:16PM +0800, Jun Yao wrote:
> On Mon, Sep 24, 2018 at 06:19:36PM +0100, Mark Rutland wrote:
> > I've pushed a branch with the cleanups I requested [1] folded in.
> >
> > I'm still a bit worried about the pgd lock, but otherwise I think this
&
On Tue, Sep 25, 2018 at 05:53:16PM +0800, Jun Yao wrote:
> On Mon, Sep 24, 2018 at 06:19:36PM +0100, Mark Rutland wrote:
> > I've pushed a branch with the cleanups I requested [1] folded in.
> >
> > I'm still a bit worried about the pgd lock, but otherwise I think this
&
Hi,
On Mon, Sep 17, 2018 at 12:43:27PM +0800, Jun Yao wrote:
> Version 5 changes:
> 1. Correct spelling and indentation errors[1].
> 2. Update init_mm.pgd by assembly[2].
> 3. Simplify set_p?d() by introducing set_swapper_pgd()[3].
> 4. Reduce unnecessary tlbi for every
Hi,
On Mon, Sep 17, 2018 at 12:43:27PM +0800, Jun Yao wrote:
> Version 5 changes:
> 1. Correct spelling and indentation errors[1].
> 2. Update init_mm.pgd by assembly[2].
> 3. Simplify set_p?d() by introducing set_swapper_pgd()[3].
> 4. Reduce unnecessary tlbi for every
On Mon, Sep 17, 2018 at 12:43:32PM +0800, Jun Yao wrote:
> Since we will move the swapper_pg_dir to rodata section, we need a
> way to update it. The fixmap can handle it. When the swapper_pg_dir
> needs to be updated, we map it dynamically. The map will be
> canceled after the update is complete.
On Mon, Sep 17, 2018 at 12:43:32PM +0800, Jun Yao wrote:
> Since we will move the swapper_pg_dir to rodata section, we need a
> way to update it. The fixmap can handle it. When the swapper_pg_dir
> needs to be updated, we map it dynamically. The map will be
> canceled after the update is complete.
On Mon, Sep 17, 2018 at 12:43:32PM +0800, Jun Yao wrote:
> Since we will move the swapper_pg_dir to rodata section, we need a
> way to update it. The fixmap can handle it. When the swapper_pg_dir
> needs to be updated, we map it dynamically. The map will be
> canceled after the update is complete.
On Mon, Sep 17, 2018 at 12:43:32PM +0800, Jun Yao wrote:
> Since we will move the swapper_pg_dir to rodata section, we need a
> way to update it. The fixmap can handle it. When the swapper_pg_dir
> needs to be updated, we map it dynamically. The map will be
> canceled after the update is complete.
On Mon, Sep 24, 2018 at 02:01:37PM +0100, Mark Rutland wrote:
> On Mon, Sep 17, 2018 at 12:43:28PM +0800, Jun Yao wrote:
> > To make the swapper_pg_dir read only, we will move it to the rodata
> > section. And force the kernel to set up the initial page table in
> > t
On Mon, Sep 24, 2018 at 02:01:37PM +0100, Mark Rutland wrote:
> On Mon, Sep 17, 2018 at 12:43:28PM +0800, Jun Yao wrote:
> > To make the swapper_pg_dir read only, we will move it to the rodata
> > section. And force the kernel to set up the initial page table in
> > t
On Mon, Sep 17, 2018 at 12:43:30PM +0800, Jun Yao wrote:
> Create the initial page table in the init_pg_dir. And update the
> init_mm.pgd to make sure that pgd_offset_k() works correctly. When
> the final page table is created, we redirect the init_mm.pgd to the
> swapper_pg_dir.
>
>
On Mon, Sep 17, 2018 at 12:43:30PM +0800, Jun Yao wrote:
> Create the initial page table in the init_pg_dir. And update the
> init_mm.pgd to make sure that pgd_offset_k() works correctly. When
> the final page table is created, we redirect the init_mm.pgd to the
> swapper_pg_dir.
>
>
x2, idmap_pg_dir
phys_to_ttbr x1, x1
phys_to_ttbr x2, x2
msr ttbr0_el1, x2 // load TTBR0
msr ttbr1_el1, x1 // load TTBR1
isb
... otherwhise, this patch looks sane to me, so with the above change:
Reviewed-by: Mark Rutland
Th
x2, idmap_pg_dir
phys_to_ttbr x1, x1
phys_to_ttbr x2, x2
msr ttbr0_el1, x2 // load TTBR0
msr ttbr1_el1, x1 // load TTBR1
isb
... otherwhise, this patch looks sane to me, so with the above change:
Reviewed-by: Mark Rutland
Th
On Mon, Sep 17, 2018 at 12:43:28PM +0800, Jun Yao wrote:
> To make the swapper_pg_dir read only, we will move it to the rodata
> section. And force the kernel to set up the initial page table in
> the init_pg_dir. After generating all levels page table, we copy
> only the top level into the
On Mon, Sep 17, 2018 at 12:43:28PM +0800, Jun Yao wrote:
> To make the swapper_pg_dir read only, we will move it to the rodata
> section. And force the kernel to set up the initial page table in
> the init_pg_dir. After generating all levels page table, we copy
> only the top level into the
On Wed, Aug 15, 2018 at 11:31:35AM -0700, Hoan Tran wrote:
> This patch adds CPU hotplug support where the PMU migrates the context to
> another online CPU when its CPU is offline.
>
> It fixes the below issue where the user does offline the CPU which is assigned
> to this PMU.
>
> Assuming,
On Wed, Aug 15, 2018 at 11:31:35AM -0700, Hoan Tran wrote:
> This patch adds CPU hotplug support where the PMU migrates the context to
> another online CPU when its CPU is offline.
>
> It fixes the below issue where the user does offline the CPU which is assigned
> to this PMU.
>
> Assuming,
hese patches seem to fix issues I've been seeing on arm64 for a while
but hadn't managed to track down.
For patches 1, 3, and 5, feel free to add:
Tested-by: Mark Rutland
On vanilla v4.19-rc2, the below reproducer would fire in seconds,
whereas with those patches applied, I have not seen issues afte
hese patches seem to fix issues I've been seeing on arm64 for a while
but hadn't managed to track down.
For patches 1, 3, and 5, feel free to add:
Tested-by: Mark Rutland
On vanilla v4.19-rc2, the below reproducer would fire in seconds,
whereas with those patches applied, I have not seen issues afte
On Mon, Sep 10, 2018 at 12:33:22PM +0100, Mark Rutland wrote:
> On Fri, Sep 07, 2018 at 06:48:10PM +0300, Andrey Ryabinin wrote:
> > On 09/07/2018 05:56 PM, Will Deacon wrote:
> > > I don't understand this bit: efistub uses the __pi_ prefixed
> > > versions of the
On Mon, Sep 10, 2018 at 12:33:22PM +0100, Mark Rutland wrote:
> On Fri, Sep 07, 2018 at 06:48:10PM +0300, Andrey Ryabinin wrote:
> > On 09/07/2018 05:56 PM, Will Deacon wrote:
> > > I don't understand this bit: efistub uses the __pi_ prefixed
> > > versions of the
On Fri, Sep 07, 2018 at 06:48:10PM +0300, Andrey Ryabinin wrote:
> On 09/07/2018 05:56 PM, Will Deacon wrote:
> > On Thu, Sep 06, 2018 at 08:05:33PM +0300, Andrey Ryabinin wrote:
> >> ARM64 has asm implementations of memchr(), memcmp(), str[r]chr(),
> >> str[n]cmp(), str[n]len(). KASAN don't see
On Fri, Sep 07, 2018 at 06:48:10PM +0300, Andrey Ryabinin wrote:
> On 09/07/2018 05:56 PM, Will Deacon wrote:
> > On Thu, Sep 06, 2018 at 08:05:33PM +0300, Andrey Ryabinin wrote:
> >> ARM64 has asm implementations of memchr(), memcmp(), str[r]chr(),
> >> str[n]cmp(), str[n]len(). KASAN don't see
Hi,
While fuzzing arm64 v4.19-rc2 with Syzkaller, I'm seeing a number of
splats (e.g. use-after-frees) in tty ioctl handling, e.g.
n_tty_set_termios. I've included one such splat at the end of this email.
It looks like syzbot has been hitting these (e.g. [1]) for a number of months,
so I guess
Hi,
While fuzzing arm64 v4.19-rc2 with Syzkaller, I'm seeing a number of
splats (e.g. use-after-frees) in tty ioctl handling, e.g.
n_tty_set_termios. I've included one such splat at the end of this email.
It looks like syzbot has been hitting these (e.g. [1]) for a number of months,
so I guess
Hi,
On Thu, Sep 06, 2018 at 01:05:35AM -0700, Atish Patra wrote:
> This patch enable support for cpu hotplug in RISC-V.
>
> In absence of generic cpu stop functions, WFI is used
> to put the cpu in low power state during offline. An IPI
> is sent to bring it out of WFI during online operation.
Hi,
On Thu, Sep 06, 2018 at 01:05:35AM -0700, Atish Patra wrote:
> This patch enable support for cpu hotplug in RISC-V.
>
> In absence of generic cpu stop functions, WFI is used
> to put the cpu in low power state during offline. An IPI
> is sent to bring it out of WFI during online operation.
functions rather
than macros.
* The prototypes for fallbacks are arragned consistently with the return
type on a separate line to try to keep to a sensible line length.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland
Acked-by: Peter Zijlstra (Intel
headers are up-to-date.
Signed-off-by: Mark Rutland
Cc: Boqun Feng
Cc: Ingo Molnar
Cc: Peter Zijlstra (Intel)
Cc: Will Deacon
---
Kbuild | 18 --
scripts/atomic/check-atomics.sh | 19 +++
2 files changed, 35 insertions(+), 2 deletions
wrappers).
Signed-off-by: Mark Rutland
Acked-by: Peter Zijlstra (Intel)
Acked-by: Will Deacon
Cc: Catalin Marinas
Cc: Ingo Molnar
---
arch/arm64/include/asm/atomic.h | 237 +-
arch/arm64/include/asm/atomic_ll_sc.h | 28 ++--
arch/arm64/include/asm
it into line with the
atomic_* and atomic64_* APIs.
Signed-off-by: Mark Rutland
Acked-by: Peter Zijlstra (Intel)
Acked-by: Will Deacon
Cc: Arnd Bergmann
Cc: Boqun Feng
Cc: Ingo Molnar
---
include/asm-generic/atomic-long.h | 1173 ++---
1 file changed, 958
atomics.
Signed-off-by: Mark Rutland
Acked-by: Peter Zijlstra (Intel)
Acked-by: Will Deacon
Cc: Alexander Potapenko
Cc: Andrey Ryabinin
Cc: Arnd Bergmann
Cc: Boqun Feng
Cc: Dmitry Vyukov
Cc: Ingo Molnar
---
include/asm-generic/atomic-instrumented.h | 1688 +
1
[2] https://lkml.kernel.org/r/20180621121321.4761-1-mark.rutl...@arm.com
[3] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git
atomics/generated
[4] https://lkml.kernel.org/r/20180625105952.3756-1-mark.rutl...@arm.com
Mark Rutland (6):
atomics: add common header generation files
functions rather
than macros.
* The prototypes for fallbacks are arragned consistently with the return
type on a separate line to try to keep to a sensible line length.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland
Acked-by: Peter Zijlstra (Intel
headers are up-to-date.
Signed-off-by: Mark Rutland
Cc: Boqun Feng
Cc: Ingo Molnar
Cc: Peter Zijlstra (Intel)
Cc: Will Deacon
---
Kbuild | 18 --
scripts/atomic/check-atomics.sh | 19 +++
2 files changed, 35 insertions(+), 2 deletions
wrappers).
Signed-off-by: Mark Rutland
Acked-by: Peter Zijlstra (Intel)
Acked-by: Will Deacon
Cc: Catalin Marinas
Cc: Ingo Molnar
---
arch/arm64/include/asm/atomic.h | 237 +-
arch/arm64/include/asm/atomic_ll_sc.h | 28 ++--
arch/arm64/include/asm
901 - 1000 of 8702 matches
Mail list logo
