* [PATCH] arm64: mm: Fix false positives in set_pte_at access/dirty race detection
From: Will Deacon @ 2017-12-12 11:43 UTC (permalink / raw)
To: linux-arm-kernel
Jiankang reports that our race detection in set_pte_at is firing when
copying the page tables in dup_mmap as a result of a fork(). In this
situation, the page table isn't actually live and so there is no way
that we can race with a concurrent update from the hardware page table
walker.
This patch reworks the race detection so that we require either the
mm to match the current active_mm (i.e. currently installed in our TTBR0)
or the mm_users count to be greater than 1, implying that the page table
could be live in another CPU. The mm_users check might still be racy,
but we'll avoid false positives and it's not realistic to validate that
all the necessary locks are held as part of this assertion.
Cc: Yisheng Xie <xieyisheng1@huawei.com>
Reported-by: Jiankang Chen <chenjiankang1@huawei.com>
Tested-by: Jiankang Chen <chenjiankang1@huawei.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/pgtable.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 3ff03a755c32..bdcc7f1c9d06 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -42,6 +42,8 @@
#include <asm/cmpxchg.h>
#include <asm/fixmap.h>
#include <linux/mmdebug.h>
+#include <linux/mm_types.h>
+#include <linux/sched.h>
extern void __pte_error(const char *file, int line, unsigned long val);
extern void __pmd_error(const char *file, int line, unsigned long val);
@@ -215,9 +217,6 @@ static inline void set_pte(pte_t *ptep, pte_t pte)
}
}
-struct mm_struct;
-struct vm_area_struct;
-
extern void __sync_icache_dcache(pte_t pteval, unsigned long addr);
/*
@@ -246,7 +245,8 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
* hardware updates of the pte (ptep_set_access_flags safely changes
* valid ptes without going through an invalid entry).
*/
- if (pte_valid(*ptep) && pte_valid(pte)) {
+ if (IS_ENABLED(CONFIG_DEBUG_VM) && pte_valid(*ptep) && pte_valid(pte) &&
+ (mm == current->active_mm || atomic_read(&mm->mm_users) > 1)) {
VM_WARN_ONCE(!pte_young(pte),
"%s: racy access flag clearing: 0x%016llx -> 0x%016llx",
__func__, pte_val(*ptep), pte_val(pte));
--
2.1.4
^ permalink raw reply related
* mainline/master boot bisection: v4.15-rc3 on peach-pi #3228-staging
From: Marek Szyprowski @ 2017-12-12 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABxcv=mUHgTxvYpOYstE7rQn8fKS3QGiTT=FzBUc8DREvVuTeQ@mail.gmail.com>
Hi All,
On 2017-12-11 23:28, Javier Martinez Canillas wrote:
> [adding Marek and Shuah to cc list]
>
> On Mon, Dec 11, 2017 at 6:05 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>> On Mon, Dec 11, 2017 at 11:30 AM, Guillaume Tucker
>> <guillaume.tucker@collabora.com> wrote:
>>> Hi Daniel,
>>>
>>> Please see below, I've had several bisection results pointing at
>>> that commit over the week-end on mainline but also on linux-next
>>> and net-next. While the peach-pi is a bit flaky at the moment
>>> and is likely to have more than one issue, it does seem like this
>>> commit is causing some well reproducible kernel hang.
>>>
>>> Here's a re-run with v4.15-rc3 showing the issue:
>>>
>>> https://lava.collabora.co.uk/scheduler/job/1018478
>>>
>>> and here's another one with the change mentioned below reverted:
>>>
>>> https://lava.collabora.co.uk/scheduler/job/1018479
>>>
>>> They both show a warning about "unbalanced disables for lcd_vdd",
>>> I don't know if this is related as I haven't investigated any
>>> further. It does appear to reliably hang with v4.15-rc3 and
>>> boot most of the time with the commit reverted though.
>>>
>>> The automated kernelci.org bisection is still an experimental
>>> tool and it may well be a false positive, so please take this
>>> result with a pinch of salt...
>> The patch just very minimal moves the connector cleanup around (so
>> timing change), but except when you unload a driver (or maybe that
>> funny EPROBE_DEFER stuff) it shouldn't matter. So if you don't have
>> more info than "seems to hang a bit more" I have no idea what's wrong.
>> The patch itself should work, at least it survived quite some serious
>> testing we do on everything.
>> -Daniel
>>
> Marek was pointing to a different culprit [0] in this [1] thread. I
> see that both commits made it to v4.15-rc3, which is the first version
> where boot fails. So maybe is a combination of both? Or rather
> reverting one patch masks the error in the other.
>
> I've access to the machine but unfortunately not a lot of time to dig
> on this, I could try to do it in the weekend though.
After a recent discussion on the Javier's patch:
https://patchwork.kernel.org/patch/10106417/
I've managed to reproduce this issue also on Exynos5250 based Samsung
Snow Chromebook and investigate a bit.
It is caused by a deadlock in the main kernel workqueue. Here are details:
1. Exynos DRM fails to initialize due to missing regulators and gets moved
to deferred probe device list
2. Deferred probe is triggered and kernel "events" workqueue calls
deferred_probe_work_func()
3. exynos_drm_bind() is called, component_bind_all() fails due to missing
Exynos Mixer device
4. error handling path is executed in exynos_drm_bind(), which calls
drm_mode_config_cleanup()
5. drm_mode_config_cleanup() calls flush_scheduled_work(), what causes
deadlock.
Do You have idea how to fix this issue properly?
Taking a look at git blame, this indeed shows that the issue has been
introduced by the commit a703c55004e1 ("drm: safely free connectors from
connector_ite"), which added a call to flush_scheduled_work() in
drm_mode_config_cleanup().
drm_mode_config_cleanup() should avoid calling flush_scheduled_work() if
called from the workqueue, but I don't have idea how to check that. The
other way of fixing it would be to resurrect separate workqueue for DRM
related events.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [RFC PATCH][resend] pciehp: fix a race between pciehp and removing operations by sysfs
From: Xiongfeng Wang @ 2017-12-12 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513067384-10914-1-git-send-email-wangxiongfeng2@huawei.com>
This patch seems to introduce another issue. pciehp_power_thread() use
'container_of' to get the 'slot' according to 'work_struct'.
If the 'slot' has been freed before that, there will be an issue.
On 2017/12/12 16:29, Xiongfeng Wang wrote:
> When the Attention button on a PCIE slot is pressed, 5 seconds later,
> pciehp_power_thread() will be scheduled on slot->wq. This function will
> get a global mutex lock 'pci_rescan_remove_lock' in
> pciehp_unconfigure_device().
>
> At the same time, we remove the pcie port by sysfs, which results in
> pci_stop_and_remove_bus_device_locked() called. This function will get
> the global mutex lock 'pci_rescan_remove_lock', and then release the
> struct 'ctrl', which will wait until the work_struct on slot->wq is
> finished.
>
> If pci_stop_and_remove_bus_device_locked() got the mutex lock, and
> before it drains workqueue slot->wq, pciehp_power_thread() is scheduled
> on slot->wq and tries to get the mutex lock. Then
> pci_stop_and_remove_bus_device_locked() tries to drain workqueue
> slot->wq and wait until work struct 'pciehp_power_thread()' is finished.
> Then a hung_task happens.
>
> This patch solve this problem by schedule 'pciehp_power_thread()' on a
> system workqueue instead of slot->wq.
>
> The Call Trace we got is as following.
>
> INFO: task kworker/0:2:4413 blocked for more than 120 seconds.
> Tainted: P W O 4.12.0-rc1 #1
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> kworker/0:2 D 0 4413 2 0x00000000
> Workqueue: pciehp-0 pciehp_power_thread
> Call trace:
> [<ffff0000080861d4>] __switch_to+0x94/0xa8
> [<ffff000008bea9c0>] __schedule+0x1b0/0x708
> [<ffff000008beaf58>] schedule+0x40/0xa4
> [<ffff000008beb33c>] schedule_preempt_disabled+0x28/0x40
> [<ffff000008bec1dc>] __mutex_lock.isra.8+0x148/0x50c
> [<ffff000008bec5c4>] __mutex_lock_slowpath+0x24/0x30
> [<ffff000008bec618>] mutex_lock+0x48/0x54
> [<ffff0000084d8188>] pci_lock_rescan_remove+0x20/0x28
> [<ffff0000084f87c0>] pciehp_unconfigure_device+0x54/0x1cc
> [<ffff0000084f8260>] pciehp_disable_slot+0x4c/0xbc
> [<ffff0000084f8370>] pciehp_power_thread+0xa0/0xb8
> [<ffff0000080e9ce8>] process_one_work+0x13c/0x3f8
> [<ffff0000080ea004>] worker_thread+0x60/0x3e4
> [<ffff0000080f0814>] kthread+0x10c/0x138
> [<ffff0000080836c0>] ret_from_fork+0x10/0x50
> INFO: task bash:31732 blocked for more than 120 seconds.
> Tainted: P W O 4.12.0-rc1 #1
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> bash D 0 31732 1 0x00000009
> Call trace:
> [<ffff0000080861d4>] __switch_to+0x94/0xa8
> [<ffff000008bea9c0>] __schedule+0x1b0/0x708
> [<ffff000008beaf58>] schedule+0x40/0xa4
> [<ffff000008bee7b4>] schedule_timeout+0x1a0/0x340
> [<ffff000008bebb88>] wait_for_common+0x108/0x1bc
> [<ffff000008bebc64>] wait_for_completion+0x28/0x34
> [<ffff0000080e7594>] flush_workqueue+0x130/0x488
> [<ffff0000080e79b0>] drain_workqueue+0xc4/0x164
> [<ffff0000080ec3cc>] destroy_workqueue+0x28/0x1f4
> [<ffff0000084fa094>] pciehp_release_ctrl+0x34/0xe0
> [<ffff0000084f75b0>] pciehp_remove+0x30/0x3c
> [<ffff0000084f24d8>] pcie_port_remove_service+0x3c/0x54
> [<ffff00000876b1e4>] device_release_driver_internal+0x150/0x1d0
> [<ffff00000876b28c>] device_release_driver+0x28/0x34
> [<ffff00000876a018>] bus_remove_device+0xe0/0x11c
> [<ffff000008766348>] device_del+0x200/0x304
> [<ffff00000876646c>] device_unregister+0x20/0x38
> [<ffff0000084f2560>] remove_iter+0x44/0x54
> [<ffff000008765230>] device_for_each_child+0x4c/0x90
> [<ffff0000084f2c98>] pcie_port_device_remove+0x2c/0x48
> [<ffff0000084f2f48>] pcie_portdrv_remove+0x60/0x6c
> [<ffff0000084e3de4>] pci_device_remove+0x48/0x110
> [<ffff00000876b1e4>] device_release_driver_internal+0x150/0x1d0
> [<ffff00000876b28c>] device_release_driver+0x28/0x34
> [<ffff0000084db028>] pci_stop_bus_device+0x9c/0xac
> [<ffff0000084db190>] pci_stop_and_remove_bus_device_locked+0x24/0x3c
> [<ffff0000084e5eb0>] remove_store+0x74/0x80
> [<ffff000008764680>] dev_attr_store+0x44/0x5c
> [<ffff0000082e7e1c>] sysfs_kf_write+0x5c/0x74
> [<ffff0000082e7014>] kernfs_fop_write+0xcc/0x1dc
> [<ffff0000082602e0>] __vfs_write+0x48/0x13c
> [<ffff00000826174c>] vfs_write+0xa8/0x198
> [<ffff000008262ce8>] SyS_write+0x54/0xb0
> [<ffff000008083730>] el0_svc_naked+0x24/0x28
>
> Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
> ---
> drivers/pci/hotplug/pciehp_ctrl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/hotplug/pciehp_ctrl.c b/drivers/pci/hotplug/pciehp_ctrl.c
> index 83f3d4a..9d39d85 100644
> --- a/drivers/pci/hotplug/pciehp_ctrl.c
> +++ b/drivers/pci/hotplug/pciehp_ctrl.c
> @@ -221,7 +221,7 @@ static void pciehp_queue_power_work(struct slot *p_slot, int req)
> info->p_slot = p_slot;
> INIT_WORK(&info->work, pciehp_power_thread);
> info->req = req;
> - queue_work(p_slot->wq, &info->work);
> + schedule_work(&info->work);
> }
>
> void pciehp_queue_pushbutton_work(struct work_struct *work)
>
^ permalink raw reply
* [RFC] KVM API extensions for SVE
From: Dave Martin @ 2017-12-12 11:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211192432.GL910@cbox>
On Mon, Dec 11, 2017 at 08:24:32PM +0100, Christoffer Dall wrote:
> On Mon, Dec 11, 2017 at 02:51:36PM +0000, Dave Martin wrote:
> > On Fri, Nov 24, 2017 at 03:45:38PM +0100, Christoffer Dall wrote:
[...]
> > > So you're saying even if we try the "expose full width and read back
> > > hidden values" approach, those hidden values may be changed when
> > > executing the guest, due to the KVM implementation or the way hardware
> > > works, is that the point?
> >
> > Basically yes.
> >
> > > I think the KVM interface should be designed similarly to being able to
> > > probe a hardware CPU's register state at various stages of execution.
> > >
> > > So, for example, if you write content to hidden bits in the SVE
> > > registers from EL2 on real hardware and limit the length using ZCR_EL2,
> > > and then run a bunch of code in EL1/0, and then come back to EL2 and
> > > examine the registers again, then we should model that behavior in
> > > software.
> > >
> > > In other words, I think we have to model this more closely to what
> > > guarantees ZCR_EL2 gives us, and not ZCR_EL1, and choose something
> > > architecturally compliant which is reasonable to implement.
> >
> > So, we imagine that provided the vcpu is not run in the meantime,
> > all accesses to SVE regs via the KVM reg API act like they are executed
> > at EL2?
>
> Yes, userspace probing virtual EL1 state should be like EL2 probing EL1
> state on hardware.
>
> >
> > That doesn't seem unreasonable, and it removes any ordering requirement
> > between ZCR_EL1 and the SVE regs providing that the vcpu isn't set
> > running in the meantime. There is no userspace access to ZCR_EL2 at
> > all, if we go with the model of configuring that via attributes that
> > must be configured before vcpu startup -- in which case there is no
> > ordering requirement there.
> >
> > The extra bits beyond ZCR_EL1.LEN may disappear as soon as the vcpu
> > is run, but that is architecturally consistent behaviour at least.
> >
>
> Yes, I think we agree here. It will all be interesting with nested
> virtualization where we have to start exposing ZCR_EL2, but that's not
> for today.
OK, that sounds reasonable. There are a couple of options open for the
nested virt case, but we don't need to worry about it now in any case.
Cheers
---Dave
^ permalink raw reply
* [PATCH v5 15/30] arm64/sve: Signal handling support
From: Dave Martin @ 2017-12-12 11:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212104030.GG28301@arm.com>
On Tue, Dec 12, 2017 at 10:40:30AM +0000, Will Deacon wrote:
> On Mon, Dec 11, 2017 at 11:23:09AM -0800, Kees Cook wrote:
> > On Mon, Dec 11, 2017 at 6:07 AM, Will Deacon <will.deacon@arm.com> wrote:
> > > On Thu, Dec 07, 2017 at 10:50:38AM -0800, Kees Cook wrote:
> > >> My question is mainly: why not just use copy_*() everywhere instead?
> > >> Having these things so spread out makes it fragile, and there's very
> > >> little performance benefit from using __copy_*() over copy_*().
> > >
> > > I think that's more of a general question. Why not just remove the __
> > > versions from the kernel entirely if they're not worth the perf?
> >
> > That has been something Linus has strongly suggested in the past, so
> > I've kind of been looking for easy places to drop the __copy_*
> > versions. :)
>
> Tell you what then: I'll Ack the arm64 patch if it's part of a series
> removing the thing entirely :p
>
> I guess we'd still want to the validation of the whole sigframe though,
> so we don't end up pushing half a signal stack before running into an
> access_ok failure?
That's an interesting question. In many cases access_ok() might become
redundant, but for syscalls that you don't want to have side-effects
on user memory on failure it's still relevant.
In the signal case we'd still an encompassing access_ok() to prevent
stack guard overruns, because the signal frame can be large and isn't
written or read contiguously or in a well-defined order.
Cheers
---Dave
^ permalink raw reply
* [PATCH 4/4] [v4] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Andy Shevchenko @ 2017-12-12 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYer_Q5R4XhWTX3=jwshcKZRSDY9=gOvSeUPsQHbUw6vw@mail.gmail.com>
On Tue, 2017-12-12 at 11:42 +0100, Linus Walleij wrote:
> On Sat, Dec 2, 2017 at 12:28 AM, Timur Tabi <timur@codeaurora.org>
> wrote:
> > + /* The number of GPIOs in the approved list */
> > + ret = device_property_read_u16_array(&pdev->dev,
> > "gpios",
> > + NULL, 0);
> > + if (ret < 0) {
> > + dev_err(&pdev->dev, "missing 'gpios'
> > property\n");
> > + return ret;
> > + }
>
> This is in direct conflict with the existing "gpios" binding in device
> tree.
>
> Where is this name coming from? ACPI standards?
Not ACPI standards as of my knowledge. ACPI standard defines a common
scheme how to define properties, it doesn't tell anything about property
names or any mappings between names to values or names to "OS
subsystem").
As for GPIO we just follow *de facto* what DT has right now, i.e. "xxx-
gpio" or "xxx-gpios" pattern is used to map ACPI standard resource to a
GPIO name. That's how GPIO ACPI lib is being developed.
> If device tree and ACPI start defining things which are in direct
> conflict
> we can just shut down this device_property() business altogether,
> it will never work that way.
This is fully understandable. Also it works in other direction, i.e. if
DT will break the established thing it will break also ACPI and built-in
device properties.
We are keeping an eye on this not to happen as much as we can in any
direction.
So, summarize above, I don't see any impediments (except maybe very
broken ARM64 firmware that is already on devices on market) to make it
properly from the beginning.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Guillaume Tucker @ 2017-12-12 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1bbedec6-6250-f02a-bf9a-4b9849833de2@samsung.com>
On 12/12/17 10:55, Marek Szyprowski wrote:
> Hi Guillaume,
>
> On 2017-12-12 11:43, Guillaume Tucker wrote:
>> On 12/12/17 10:17, Marek Szyprowski wrote:
>>> Hi Krzysztof,
>>>
>>> On 2017-12-12 11:09, Krzysztof Kozlowski wrote:
>>>> On Tue, Dec 12, 2017 at 10:55 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>>> On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
>>>>> <javierm@redhat.com> wrote:
>>>>>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
>>>>>> Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
>>>>>> for each Exynos 542x DTS. But unfortunately it missed to enable it for the
>>>>>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
>>>>>>
>>>>>> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x Mixer nodes")
>>>>>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>>>>>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> Changes in v2:
>>>>>> - Remove RFT tag.
>>>>> Thanks guys! However I still would like to see a tested-by for this on
>>>>> Peach Pi (AFAIU, Marek's only acked the code/solution).
>>>> On the other hand I could just apply it for my for-next branch and
>>>> we'll see if it fixes kernel-ci boot tests... Not a nice way of
>>>> testing but apparently no one has Peach Pi.
>>>
>>> Frankly, I don't expect that this will solve the boot hang issue on PeachPi.
>>> However it should at least hide the unbalanced regulator issue.
>>
>> We have a peach-pi in our LAVA lab so I've tested it and
>> actually, it does fix the hang on v4.15-rc3:
>>
>> ? https://lava.collabora.co.uk/scheduler/job/1019877
>> ? https://lava.collabora.co.uk/scheduler/job/1019878
>>
>> I ran it twice and it booted both times.? I also ran the same
>> boot tests with the same kernel but the dtb from v4.15-rc3
>> without the fix to double check and these failed:
>>
>> ? https://lava.collabora.co.uk/scheduler/job/1019879
>> ? https://lava.collabora.co.uk/scheduler/job/1019880
>>
>>
>> Tested-by: Guillaume Tucker <guillaume.tucker@collabora.com>
>>
>>
>> Thanks for the fix!
>
> Well, thanks for the test! It proves that there the boot failure is
> caused by an issue somewhere in the error path of Exynos DRM, Analogix
> DP, Simple Panel or other drivers.
>
> This patch simply hides it by fixing the source issue of the Exynos
> DRM initialization failure. :-)
>
> I hope Javier will be able to investigate the discussed hang issue
> later, as fixing it is also imho important.
Sure. This device tree change is needed to get HDMI to work so
it's still a fix for that. Also it's good to know that nothing
else breaks when the driver issue is "hidden". Might be worth
testing on -next as well as it might help spot any new issues
that haven't been merged in mainline yet, or in general give
another data point.
Guillaume
^ permalink raw reply
* [PATCH 07/12] arm64: mm: Place kImage at bottom of VA space
From: Steve Capper @ 2017-12-12 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204181213.or2t24rdh6uwj3iu@capper-debian.cambridge.arm.com>
On Mon, Dec 04, 2017 at 06:12:13PM +0000, Steve Capper wrote:
> On Mon, Dec 04, 2017 at 05:27:10PM +0000, Ard Biesheuvel wrote:
> > On 4 December 2017 at 17:18, Steve Capper <steve.capper@arm.com> wrote:
> > > Hi Ard,
> > >
> > > On Mon, Dec 04, 2017 at 04:25:18PM +0000, Ard Biesheuvel wrote:
> > >> 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 ].
> > >
> > > Yes, yes it does. Sorry about this. I had very carefully tested KASLR
> > > with custom offsets... on my early page table code. I will have a think
> > > about this.
> > >
> > > From a KASLR side, my (renewed) understanding is that a virtual address
> > > as low as possible is desired for the kimage start as that affords the
> > > most wiggle room?
> > >
> >
> > Well, the nice thing about the current arrangement is that the default
> > is adjacent to the vmalloc space so any non-zero [bounded] offset
> > produces a valid placement. Addition with subtraction is easy, so
> > which side the default placement happens to be at does not really
> > matter. Having to implement additional bounds checking in the early
> > KASLR init code to stay clear of the PCI I/O or fixmap regions sounds
> > a bit more cumbersome.
> >
>
> I *think* I can fix KASAN_SHADOW_END to be 0xFFFF200000000000 on both 48-bit
> and 52-bit VA configurations. Thus I may be able to enable 52-bit VA with
> minimal disruption to the layout of the VA space (i.e. no need to change
> the layout) if I also depend on CONFIG_RELOCATABLE.
>
Unfortunately, having KASAN_SHADOW_END at 0xFFFF2000000000000 doesn't
work with 52-bit VAs as this would place it in the direct linear map
area.
So I think we need to flip the two halves of the kernel address space in
order to accommodate inline KASAN that operates under multiple VA space
sizes (I couldn't figure out any way to patch the inline KASAN instrumentation).
Cheers,
--
Steve
^ permalink raw reply
* [PATCH 1/6] ARM: stm32: prepare stm32 family to welcome armv7 architecture
From: afzal mohammed @ 2017-12-12 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a2rrpFuwET8r1H0YWVABbCZr5c2ySrKCgA4mfoZPfWp6Q@mail.gmail.com>
Hi,
On Mon, Dec 11, 2017 at 02:40:43PM +0100, Arnd Bergmann wrote:
> On Mon, Dec 11, 2017 at 11:25 AM, Linus Walleij
> >> This patch prepares the STM32 machine for the integration of Cortex-A
> >> based microprocessor (MPU), on top of the existing Cortex-M
> >> microcontroller family (MCU). Since both MCUs and MPUs are sharing
> >> common hardware blocks we can keep using ARCH_STM32 flag for most of
> >> them. If a hardware block is specific to one family we can use either
> >> ARCH_STM32_MCU or ARCH_STM32_MPU flag.
> To what degree do we need to treat them as separate families
> at all then? I wonder if the MCU/MPU distinction is always that
> clear along the Cortex-M/Cortex-A separation,
> What
> exactly would we miss if we do away with the ARCH_STM32_MCU
> symbol here?
Based on this patch series, the only difference seems to be w.r.t ARM
components, not peripherals outside ARM subystem. Vybrid VF610 is a
similar case, though not identical (it can have both instead of
either), deals w/o extra symbols,
8064887e02fd6 (ARM: vf610: enable Cortex-M4 configuration on Vybrid SoC)
> especially if
> we ever get to a chip that has both types of cores.
Your wish fulfilled, Vybrid VF610 has both A5 & M4F and mainline Linux
boots on both (simultaneously as well), and the second Linux support,
i.e. on M4 went thr' your keyboard, see above commit :)
There are quite a few others as well, TI's AM335x (A8 + M3), AM437x
(A9 + M3), AM57x (A15 + M4), but of these Cortex M's, the one in AM57x
only can be Linux'able. On others they are meant for PM with limited
resources.
> > So yesterdays application processors are todays MCU processors.
> >
> > I said this on a lecture for control systems a while back and
> > stated it as a reason I think RTOSes are not really seeing a bright
> > future compared to Linux.
> I think there is still lots of room for smaller RTOS in the long run,
Me being an electrical engineer & worked to some extent in motor
control on RTOS/no OS (the value of my opinion is questionable
though), the thought of handling the same in Linux (even RT) sends
shivers down my spine. Here, case being considered is the type of
motor (like permanent magnet ones) where each phase of the motor has
to be properly excited during every PWM period (say every 100us,
depending on the feedback, algorithm, other synchronization) w/o which
the motor that has been told to run might try to fly. This is
different from stepper motor where if control misbehaves/stops nothing
harmful normally happens.
But my opinion is a kind of knee-jerk reaction and based on prevalent
atitude in that field, hmm.., probably i should attempt it first.
Regards
afzal
^ permalink raw reply
* [PATCH] s5p-mfc: Fix encoder menu controls initialization
From: Sylwester Nawrocki @ 2017-12-12 11:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20171212110322epcas2p11e3f36ba3de73a03f062b7877d797d2a@epcas2p1.samsung.com>
This patch fixes the menu_skip_mask field initialization
and addresses a following issue found by the SVACE static
analysis:
* NO_EFFECT.SELF: assignment to self in expression 'cfg.menu_skip_mask = cfg.menu_skip_mask'
No effect at drivers/media/platform/s5p-mfc/s5p_mfc_enc.c:2083
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 2a5fd7c42cd5..0d5d465561be 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -2080,7 +2080,7 @@ int s5p_mfc_enc_ctrls_setup(struct s5p_mfc_ctx *ctx)
if (cfg.type == V4L2_CTRL_TYPE_MENU) {
cfg.step = 0;
- cfg.menu_skip_mask = cfg.menu_skip_mask;
+ cfg.menu_skip_mask = controls[i].menu_skip_mask;
cfg.qmenu = mfc51_get_menu(cfg.id);
} else {
cfg.step = controls[i].step;
--
2.14.2
^ permalink raw reply related
* [PATCH 04/12] arm64: Initialise high_memory global variable earlier
From: Steve Capper @ 2017-12-12 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211120022.ujdc37dp3iawzrem@armageddon.cambridge.arm.com>
On Mon, Dec 11, 2017 at 12:00:22PM +0000, Catalin Marinas wrote:
> On Mon, Dec 04, 2017 at 02:13:05PM +0000, Steve Capper wrote:
> > The high_memory global variable is used by
> > cma_declare_contiguous(.) before it is defined.
> >
> > We don't notice this as we compute __pa(high_memory - 1), and it looks
> > like we're processing a VA from the direct linear map.
> >
> > This problem becomes apparent when we flip the kernel virtual address
> > space and the linear map is moved to the bottom of the kernel VA space.
> >
> > This patch moves the initialisation of high_memory before it used.
> >
> > Signed-off-by: Steve Capper <steve.capper@arm.com>
>
> It looks like we've had this bug since 3.18 (f7426b983a6a, "mm: cma:
> adjust address limit to avoid hitting low/high memory boundary"). It may
> be worth adding a cc stable on this patch.
Thanks Catalin,
Will add a fixes and cc stable.
Cheers,
--
Steve
>
> --
> Catalin
^ permalink raw reply
* [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Marek Szyprowski @ 2017-12-12 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ad03e2a8-00eb-464e-6983-374f83b9abf5@collabora.com>
Hi Guillaume,
On 2017-12-12 11:43, Guillaume Tucker wrote:
> On 12/12/17 10:17, Marek Szyprowski wrote:
>> Hi Krzysztof,
>>
>> On 2017-12-12 11:09, Krzysztof Kozlowski wrote:
>>> On Tue, Dec 12, 2017 at 10:55 AM, Krzysztof Kozlowski
>>> <krzk@kernel.org> wrote:
>>>> On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
>>>> <javierm@redhat.com> wrote:
>>>>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to
>>>>> Exynos 542x
>>>>> Mixer nodes") disabled the Mixer node by default in the DTSI and
>>>>> enabled
>>>>> for each Exynos 542x DTS. But unfortunately it missed to enable it
>>>>> for the
>>>>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC
>>>>> variant.
>>>>>
>>>>> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to
>>>>> Exynos 542x Mixer nodes")
>>>>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>>>>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>
>>>>> ---
>>>>>
>>>>> Changes in v2:
>>>>> - Remove RFT tag.
>>>> Thanks guys! However I still would like to see a tested-by for this on
>>>> Peach Pi (AFAIU, Marek's only acked the code/solution).
>>> On the other hand I could just apply it for my for-next branch and
>>> we'll see if it fixes kernel-ci boot tests... Not a nice way of
>>> testing but apparently no one has Peach Pi.
>>
>> Frankly, I don't expect that this will solve the boot hang issue on
>> PeachPi.
>> However it should at least hide the unbalanced regulator issue.
>
> We have a peach-pi in our LAVA lab so I've tested it and
> actually, it does fix the hang on v4.15-rc3:
>
> ? https://lava.collabora.co.uk/scheduler/job/1019877
> ? https://lava.collabora.co.uk/scheduler/job/1019878
>
> I ran it twice and it booted both times.? I also ran the same
> boot tests with the same kernel but the dtb from v4.15-rc3
> without the fix to double check and these failed:
>
> ? https://lava.collabora.co.uk/scheduler/job/1019879
> ? https://lava.collabora.co.uk/scheduler/job/1019880
>
>
> Tested-by: Guillaume Tucker <guillaume.tucker@collabora.com>
>
>
> Thanks for the fix!
Well, thanks for the test! It proves that there the boot failure is
caused by an issue somewhere in the error path of Exynos DRM, Analogix
DP, Simple Panel or other drivers.
This patch simply hides it by fixing the source issue of the Exynos
DRM initialization failure. :-)
I hope Javier will be able to investigate the discussed hang issue
later, as fixing it is also imho important.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [RFC PATCH 1/3] dt-bindings: pinctrl: sunxi: document new generic binding
From: Linus Walleij @ 2017-12-12 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <be52417d-9509-f638-65b6-f455fade0c39@arm.com>
On Wed, Dec 6, 2017 at 1:55 AM, Andr? Przywara <andre.przywara@arm.com> wrote:
> On 01/12/17 09:56, Linus Walleij wrote:
>> It is a valid cause. Just
>> has to be weighed with other stuff, like maintainability, debuggability,
>> maintainers viewpoint. ...
>
> So to keep Maxime happy I actually designed this "driver" more like a
> shim: to generate the table the current driver expects from the DT, and
> actually not touching the existing driver at all.
> So maintainability should actually be less of a concern: the driver will
> just work with whatever one throws at it from the DT side, without
> requiring frequent changes or additions.
> In the moment we still need to write, review and merge *data* files for
> each new SoC. And as I mentioned before, Allwinner decided to push for
> new, slightly different chips every few months, so there will be more to
> come. With at least the pinctrl driver out of the way we have one
> problem less to worry about.
I think you need mainly to convince Maxime that this is something that
he wants to maintain, going forward.
I am as subsystem maintainer pretty pleased as long as standard
properties etc are used to encode the data into the devicetree, and
DT maintrainers are not actively vetoing what you do.
If it leads to a conflict between Allwinner maintainers it is not worth the
effort for reasons that are social rather than technical. To me it is a very
nice but as with all volunteer communities also very vulnerable
endavour.
Please make sure not to push your point so hard that it hurts your
our your colleagues feelings.
I know people are passionate about their ideas, which is usally good
but also scare me sometimes because they sometimes become so
passionate that it makes them bad team players.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Krzysztof Kozlowski @ 2017-12-12 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ad03e2a8-00eb-464e-6983-374f83b9abf5@collabora.com>
On Tue, Dec 12, 2017 at 11:43 AM, Guillaume Tucker
<guillaume.tucker@collabora.com> wrote:
> On 12/12/17 10:17, Marek Szyprowski wrote:
>>
>> Hi Krzysztof,
>>
>> On 2017-12-12 11:09, Krzysztof Kozlowski wrote:
>>>
>>> On Tue, Dec 12, 2017 at 10:55 AM, Krzysztof Kozlowski <krzk@kernel.org>
>>> wrote:
>>>>
>>>> On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
>>>> <javierm@redhat.com> wrote:
>>>>>
>>>>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos
>>>>> 542x
>>>>> Mixer nodes") disabled the Mixer node by default in the DTSI and
>>>>> enabled
>>>>> for each Exynos 542x DTS. But unfortunately it missed to enable it for
>>>>> the
>>>>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC
>>>>> variant.
>>>>>
>>>>> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos
>>>>> 542x Mixer nodes")
>>>>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>>>>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>
>>>>> ---
>>>>>
>>>>> Changes in v2:
>>>>> - Remove RFT tag.
>>>>
>>>> Thanks guys! However I still would like to see a tested-by for this on
>>>> Peach Pi (AFAIU, Marek's only acked the code/solution).
>>>
>>> On the other hand I could just apply it for my for-next branch and
>>> we'll see if it fixes kernel-ci boot tests... Not a nice way of
>>> testing but apparently no one has Peach Pi.
>>
>>
>> Frankly, I don't expect that this will solve the boot hang issue on
>> PeachPi.
>> However it should at least hide the unbalanced regulator issue.
>
>
> We have a peach-pi in our LAVA lab so I've tested it and
> actually, it does fix the hang on v4.15-rc3:
>
> https://lava.collabora.co.uk/scheduler/job/1019877
> https://lava.collabora.co.uk/scheduler/job/1019878
>
> I ran it twice and it booted both times. I also ran the same
> boot tests with the same kernel but the dtb from v4.15-rc3
> without the fix to double check and these failed:
>
> https://lava.collabora.co.uk/scheduler/job/1019879
> https://lava.collabora.co.uk/scheduler/job/1019880
>
>
> Tested-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Thank you!
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Javier Martinez Canillas @ 2017-12-12 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ad03e2a8-00eb-464e-6983-374f83b9abf5@collabora.com>
[adding Inki to cc list]
Hello Guillaume,
On 12/12/2017 11:43 AM, Guillaume Tucker wrote:
> On 12/12/17 10:17, Marek Szyprowski wrote:
>> Hi Krzysztof,
>>
>> On 2017-12-12 11:09, Krzysztof Kozlowski wrote:
>>> On Tue, Dec 12, 2017 at 10:55 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>> On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
>>>> <javierm@redhat.com> wrote:
>>>>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
>>>>> Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
>>>>> for each Exynos 542x DTS. But unfortunately it missed to enable it for the
>>>>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
>>>>>
>>>>> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x Mixer nodes")
>>>>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>>>>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>
>>>>> ---
>>>>>
>>>>> Changes in v2:
>>>>> - Remove RFT tag.
>>>> Thanks guys! However I still would like to see a tested-by for this on
>>>> Peach Pi (AFAIU, Marek's only acked the code/solution).
>>> On the other hand I could just apply it for my for-next branch and
>>> we'll see if it fixes kernel-ci boot tests... Not a nice way of
>>> testing but apparently no one has Peach Pi.
>>
>> Frankly, I don't expect that this will solve the boot hang issue on PeachPi.
>> However it should at least hide the unbalanced regulator issue.
>
> We have a peach-pi in our LAVA lab so I've tested it and
> actually, it does fix the hang on v4.15-rc3:
>
> https://lava.collabora.co.uk/scheduler/job/1019877
> https://lava.collabora.co.uk/scheduler/job/1019878
>
> I ran it twice and it booted both times. I also ran the same
> boot tests with the same kernel but the dtb from v4.15-rc3
> without the fix to double check and these failed:
>
> https://lava.collabora.co.uk/scheduler/job/1019879
> https://lava.collabora.co.uk/scheduler/job/1019880
>
>
> Tested-by: Guillaume Tucker <guillaume.tucker@collabora.com>
>
>
> Thanks for the fix!
>
Thanks for testing!
Now, I think the exynos-drm driver should cope with an incorrect DTB and
don't crash the machine, the driver should only fail to probe and lead
to a working machine with no display.
But as mentioned, that's a different issue and orthogonal to the DTS fix.
> Guillaume
>
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
^ permalink raw reply
* [PATCH V2 1/2] arm64: Re-order reserved_ttbr0 in linker script
From: Steve Capper @ 2017-12-12 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-urwMWX-Tj+WPt=GaqXd09O1zrLYYLf1Jf__Lod7VLtg@mail.gmail.com>
On Mon, Dec 04, 2017 at 02:13:38PM +0000, Ard Biesheuvel wrote:
> On 23 November 2017 at 16:40, Steve Capper <steve.capper@arm.com> wrote:
> > Currently one resolves the location of the reserved_ttbr0 for PAN by
> > taking a positive offset from swapper_pg_dir. In a future patch we wish
> > to extend the swapper s.t. its size is determined at link time rather
> > than compile time, rendering SWAPPER_DIR_SIZE unsuitable for such a low
> > level calculation.
> >
> > In this patch we re-arrange the order of the linker script s.t. instead
> > one computes reserved_ttbr0 by subtracting RESERVED_TTBR0_SIZE from
> > swapper_pg_dir.
> >
> > Signed-off-by: Steve Capper <steve.capper@arm.com>
> > Acked-by: Mark Rutland <mark.rutland@arm.com>
> > ---
> > arch/arm64/include/asm/asm-uaccess.h | 6 +++---
> > arch/arm64/include/asm/uaccess.h | 2 +-
> > arch/arm64/kernel/vmlinux.lds.S | 5 ++---
> > 3 files changed, 6 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/asm-uaccess.h b/arch/arm64/include/asm/asm-uaccess.h
> > index b3da6c886835..e09f02cd3e7a 100644
> > --- a/arch/arm64/include/asm/asm-uaccess.h
> > +++ b/arch/arm64/include/asm/asm-uaccess.h
> > @@ -12,9 +12,9 @@
> > */
> > #ifdef CONFIG_ARM64_SW_TTBR0_PAN
> > .macro __uaccess_ttbr0_disable, tmp1
> > - mrs \tmp1, ttbr1_el1 // swapper_pg_dir
> > - add \tmp1, \tmp1, #SWAPPER_DIR_SIZE // reserved_ttbr0 at the end of swapper_pg_dir
> > - msr ttbr0_el1, \tmp1 // set reserved TTBR0_EL1
> > + mrs \tmp1, ttbr1_el1 // swapper_pg_dir
> > + sub \tmp1, \tmp1, #RESERVED_TTBR0_SIZE // reserved_ttbr0 just before swapper_pg_dir
> > + msr ttbr0_el1, \tmp1 // set reserved TTBR0_EL1
> > isb
> > .endm
> >
> > diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> > index fc0f9eb66039..66170fd4b58f 100644
> > --- a/arch/arm64/include/asm/uaccess.h
> > +++ b/arch/arm64/include/asm/uaccess.h
> > @@ -108,7 +108,7 @@ static inline void __uaccess_ttbr0_disable(void)
> > unsigned long ttbr;
> >
> > /* reserved_ttbr0 placed at the end of swapper_pg_dir */
>
> You missed a comment here ^^^
>
Thanks, I will update this.
> > - ttbr = read_sysreg(ttbr1_el1) + SWAPPER_DIR_SIZE;
> > + ttbr = read_sysreg(ttbr1_el1) - RESERVED_TTBR0_SIZE;
> > write_sysreg(ttbr, ttbr0_el1);
> > isb();
> > }
> > diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
> > index 7da3e5c366a0..2a9475733e84 100644
> > --- a/arch/arm64/kernel/vmlinux.lds.S
> > +++ b/arch/arm64/kernel/vmlinux.lds.S
> > @@ -206,13 +206,12 @@ SECTIONS
> > . = ALIGN(PAGE_SIZE);
> > idmap_pg_dir = .;
> > . += IDMAP_DIR_SIZE;
> > - swapper_pg_dir = .;
> > - . += SWAPPER_DIR_SIZE;
> > -
> > #ifdef CONFIG_ARM64_SW_TTBR0_PAN
> > reserved_ttbr0 = .;
> > . += RESERVED_TTBR0_SIZE;
> > #endif
> > + swapper_pg_dir = .;
> > + . += SWAPPER_DIR_SIZE;
> >
> > __pecoff_data_size = ABSOLUTE(. - __initdata_begin);
> > _end = .;
>
> With that fixed,
>
> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Thanks Ard!
Cheers,
--
Steve
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply
* [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Guillaume Tucker @ 2017-12-12 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a42670aa-b3df-7a53-8ed2-f3acd97fd0d4@samsung.com>
On 12/12/17 10:17, Marek Szyprowski wrote:
> Hi Krzysztof,
>
> On 2017-12-12 11:09, Krzysztof Kozlowski wrote:
>> On Tue, Dec 12, 2017 at 10:55 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>> On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
>>> <javierm@redhat.com> wrote:
>>>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
>>>> Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
>>>> for each Exynos 542x DTS. But unfortunately it missed to enable it for the
>>>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
>>>>
>>>> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x Mixer nodes")
>>>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>>>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>
>>>> ---
>>>>
>>>> Changes in v2:
>>>> - Remove RFT tag.
>>> Thanks guys! However I still would like to see a tested-by for this on
>>> Peach Pi (AFAIU, Marek's only acked the code/solution).
>> On the other hand I could just apply it for my for-next branch and
>> we'll see if it fixes kernel-ci boot tests... Not a nice way of
>> testing but apparently no one has Peach Pi.
>
> Frankly, I don't expect that this will solve the boot hang issue on PeachPi.
> However it should at least hide the unbalanced regulator issue.
We have a peach-pi in our LAVA lab so I've tested it and
actually, it does fix the hang on v4.15-rc3:
https://lava.collabora.co.uk/scheduler/job/1019877
https://lava.collabora.co.uk/scheduler/job/1019878
I ran it twice and it booted both times. I also ran the same
boot tests with the same kernel but the dtb from v4.15-rc3
without the fix to double check and these failed:
https://lava.collabora.co.uk/scheduler/job/1019879
https://lava.collabora.co.uk/scheduler/job/1019880
Tested-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Thanks for the fix!
Guillaume
^ permalink raw reply
* [PATCH 4/4] [v4] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Linus Walleij @ 2017-12-12 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512170904-4749-5-git-send-email-timur@codeaurora.org>
On Sat, Dec 2, 2017 at 12:28 AM, Timur Tabi <timur@codeaurora.org> wrote:
> /* Query the number of GPIOs from ACPI */
> ret = device_property_read_u32(&pdev->dev, "num-gpios", &num_gpios);
> if (ret < 0) {
> - dev_warn(&pdev->dev, "missing num-gpios property\n");
> + dev_err(&pdev->dev, "missing 'num-gpios' property\n");
> return ret;
> }
It's unfortunate that this driver uses the undocumented "num-gpios"
when the device tree bindings already has standardized "ngpios"
as the name for this.
Maybe it was not standardized back in 2015 when this driver was merged.
Or we were all sloppy :/
> + /* The number of GPIOs in the approved list */
> + ret = device_property_read_u16_array(&pdev->dev, "gpios",
> + NULL, 0);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "missing 'gpios' property\n");
> + return ret;
> + }
This is in direct conflict with the existing "gpios" binding in device tree.
Where is this name coming from? ACPI standards?
If device tree and ACPI start defining things which are in direct conflict
we can just shut down this device_property() business altogether,
it will never work that way.
I would try to merge a DT bindings doc defining "valid-gpios" or something
like this, can we proceed like that?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 2/2] acpi, x86: Use SPCR table for earlycon on x86
From: Ingo Molnar @ 2017-12-12 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211155059.17062-3-prarit@redhat.com>
* Prarit Bhargava <prarit@redhat.com> wrote:
> The ACPI SPCR code has been used to define an earlycon console for ARM64
> and can be used for x86.
>
> Modify the ACPI SPCR parsing code to account for console behaviour
> differences between ARM64 and x86. Initialize the SPCR code from
> x86 ACPI initialization code.
>
> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
> Cc: linux-doc at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-pm at vger.kernel.org
> Cc: linux-acpi at vger.kernel.org
> Cc: linux-serial at vger.kernel.org
> Cc: Bhupesh Sharma <bhsharma@redhat.com>
> Cc: Lv Zheng <lv.zheng@intel.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86 at kernel.org
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Timur Tabi <timur@codeaurora.org>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 3 +++
> arch/arm64/kernel/acpi.c | 2 +-
> arch/x86/kernel/acpi/boot.c | 4 ++++
> drivers/acpi/Kconfig | 2 +-
> drivers/acpi/spcr.c | 7 +++++--
> include/linux/acpi.h | 7 +++++--
> 6 files changed, 19 insertions(+), 6 deletions(-)
LGTM from an x86 perspective:
Acked-by: Ingo Molnar <mingo@kernel.org>
(assuming it causes no regressions in linux-next.)
Since patch #1 affects ARM64 significantly, once that patch is acceptable to the
arm64 folks feel free to upstream this second patch via the ARM64 tree as well.
Thanks,
Ingo
^ permalink raw reply
* [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Javier Martinez Canillas @ 2017-12-12 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPc1_n2cdgjuFbA9jNdcSXxfr8Zjf=fUx_jt_N3+LP0n8A@mail.gmail.com>
Hello Krzysztof,
On 12/12/2017 11:09 AM, Krzysztof Kozlowski wrote:
> On Tue, Dec 12, 2017 at 10:55 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
>> <javierm@redhat.com> wrote:
>>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
>>> Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
>>> for each Exynos 542x DTS. But unfortunately it missed to enable it for the
>>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
>>>
>>> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x Mixer nodes")
>>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>
>>> ---
>>>
>>> Changes in v2:
>>> - Remove RFT tag.
I removed the tag because Marek acked it and the patch has merits on its own
regardless of the boot issue (it just introduces a change that was missed in
the mentioned commit).
>>
>> Thanks guys! However I still would like to see a tested-by for this on
>> Peach Pi (AFAIU, Marek's only acked the code/solution).
>
> On the other hand I could just apply it for my for-next branch and
> we'll see if it fixes kernel-ci boot tests... Not a nice way of
As Marek said this probably won't solve the issue, or at best it would just
mask it. Seems the problem is on the probe deferral path in exynos-drm driver.
> testing but apparently no one has Peach Pi.
>
I do have one, but I haven't used it for months and don't have time to setup
a test environment now. I will probably do that this weekend to dig deeper.
> Best regards,
> Krzysztof
>
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
^ permalink raw reply
* [PATCH v5 15/30] arm64/sve: Signal handling support
From: Will Deacon @ 2017-12-12 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGXu5j+2MNOnAfstr8RyD0Orrt37ewL8uE2N8e3fL--fNPs3TQ@mail.gmail.com>
On Mon, Dec 11, 2017 at 11:23:09AM -0800, Kees Cook wrote:
> On Mon, Dec 11, 2017 at 6:07 AM, Will Deacon <will.deacon@arm.com> wrote:
> > On Thu, Dec 07, 2017 at 10:50:38AM -0800, Kees Cook wrote:
> >> My question is mainly: why not just use copy_*() everywhere instead?
> >> Having these things so spread out makes it fragile, and there's very
> >> little performance benefit from using __copy_*() over copy_*().
> >
> > I think that's more of a general question. Why not just remove the __
> > versions from the kernel entirely if they're not worth the perf?
>
> That has been something Linus has strongly suggested in the past, so
> I've kind of been looking for easy places to drop the __copy_*
> versions. :)
Tell you what then: I'll Ack the arm64 patch if it's part of a series
removing the thing entirely :p
I guess we'd still want to the validation of the whole sigframe though,
so we don't end up pushing half a signal stack before running into an
access_ok failure?
Will
^ permalink raw reply
* arm64: unhandled level 0 translation fault
From: Will Deacon @ 2017-12-12 10:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXh_6FaV-SFGWxcBb1-NNGYngDrYnnWA=9Y6xmRAkcxqg@mail.gmail.com>
Hi Geert,
On Tue, Dec 12, 2017 at 11:20:09AM +0100, Geert Uytterhoeven wrote:
> During userspace (Debian jessie NFS root) boot on arm64:
>
> rpcbind[1083]: unhandled level 0 translation fault (11) at 0x00000008,
> esr 0x92000004, in dash[aaaaadf77000+1a000]
> CPU: 0 PID: 1083 Comm: rpcbind Not tainted
> 4.15.0-rc3-arm64-renesas-02176-g14f9a1826e48e355 #51
> Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+ (DT)
> pstate: 80000000 (Nzcv daif -PAN -UAO)
> pc : 0xaaaaadf8a51c
> lr : 0xaaaaadf8ac08
> sp : 0000ffffcffeac00
> x29: 0000ffffcffeac00 x28: 0000aaaaadfa1000
> x27: 0000ffffcffebf7c x26: 0000ffffcffead20
> x25: 0000aaaacea1c5f0 x24: 0000000000000000
> x23: 0000aaaaadfa1000 x22: 0000aaaaadfa1000
> x21: 0000000000000000 x20: 0000000000000008
> x19: 0000000000000000 x18: 0000ffffcffeb500
> x17: 0000ffffa22babfc x16: 0000aaaaadfa1ae8
> x15: 0000ffffa2363588 x14: ffffffffffffffff
> x13: 0000000000000020 x12: 0000000000000010
> x11: 0101010101010101 x10: 0000aaaaadfa1000
> x9 : 00000000ffffff81 x8 : 0000aaaaadfa2000
> x7 : 0000000000000000 x6 : 0000000000000000
> x5 : 0000aaaaadfa2338 x4 : 0000aaaaadfa2000
> x3 : 0000aaaaadfa2338 x2 : 0000000000000000
> x1 : 0000aaaaadfa28b0 x0 : 0000aaaaadfa4c30
>
> Sometimes it happens with other processes, but the main address, esr, and
> pstate values are always the same.
>
> I regularly run arm64/for-next/core (through bi-weekly renesas-drivers
> releases, so the last time was two weeks ago), but never saw the issue
> before until today, so probably v4.15-rc1 is OK.
> Unfortunately it doesn't happen during every boot, which makes it
> cumbersome to bisect.
>
> My first guess was UNMAP_KERNEL_AT_EL0, but even after disabling that,
> and even without today's arm64/for-next/core merged in, I still managed to
> reproduce the issue, so I believe it was introduced in v4.15-rc2 or
> v4.15-rc3.
Urgh, this looks nasty. Thanks for the report! A few questions:
- Can you share your .config somewhere please?
- What was your last known-good kernel?
- Have you seen it on any other Soc?
- What's the CPU in your SoC?
If I can reproduce the failure here, then I should be able to debug ASAP.
Cheers,
Will
^ permalink raw reply
* [PATCH v2 17/18] arm64: Kconfig: Add CONFIG_UNMAP_KERNEL_AT_EL0
From: Will Deacon @ 2017-12-12 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXn5vVxrtD=-+X_SQVX9PXcKQ=9Qh3Xx+M1MoCQ-EWRZQ@mail.gmail.com>
On Tue, Dec 12, 2017 at 09:44:09AM +0100, Geert Uytterhoeven wrote:
> Hi Will,
>
> On Thu, Nov 30, 2017 at 5:39 PM, Will Deacon <will.deacon@arm.com> wrote:
> > Add a Kconfig entry to control use of the entry trampoline, which allows
> > us to unmap the kernel whilst running in userspace and improve the
> > robustness of KASLR.
> >
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
>
> This is now commit 084eb77cd3a81134 in arm64/for-next/core.
>
> > ---
> > arch/arm64/Kconfig | 13 +++++++++++++
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index fdcc7b9bb15d..3af1657fcac3 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -833,6 +833,19 @@ config FORCE_MAX_ZONEORDER
> > However for 4K, we choose a higher default value, 11 as opposed to 10, giving us
> > 4M allocations matching the default size used by generic code.
> >
> > +config UNMAP_KERNEL_AT_EL0
> > + bool "Unmap kernel when running in userspace (aka \"KAISER\")"
>
> But I believe this is no longer called KAISER?
That's right, but KAISER is the original name in the paper and so I figured
it was worth mentioning just here to help people identify what this feature
is. The command line option is "kpti" to align with x86.
Will
^ permalink raw reply
* arm64: unhandled level 0 translation fault
From: Geert Uytterhoeven @ 2017-12-12 10:20 UTC (permalink / raw)
To: linux-arm-kernel
Hi Catalin, Will, et al,
During userspace (Debian jessie NFS root) boot on arm64:
rpcbind[1083]: unhandled level 0 translation fault (11) at 0x00000008,
esr 0x92000004, in dash[aaaaadf77000+1a000]
CPU: 0 PID: 1083 Comm: rpcbind Not tainted
4.15.0-rc3-arm64-renesas-02176-g14f9a1826e48e355 #51
Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+ (DT)
pstate: 80000000 (Nzcv daif -PAN -UAO)
pc : 0xaaaaadf8a51c
lr : 0xaaaaadf8ac08
sp : 0000ffffcffeac00
x29: 0000ffffcffeac00 x28: 0000aaaaadfa1000
x27: 0000ffffcffebf7c x26: 0000ffffcffead20
x25: 0000aaaacea1c5f0 x24: 0000000000000000
x23: 0000aaaaadfa1000 x22: 0000aaaaadfa1000
x21: 0000000000000000 x20: 0000000000000008
x19: 0000000000000000 x18: 0000ffffcffeb500
x17: 0000ffffa22babfc x16: 0000aaaaadfa1ae8
x15: 0000ffffa2363588 x14: ffffffffffffffff
x13: 0000000000000020 x12: 0000000000000010
x11: 0101010101010101 x10: 0000aaaaadfa1000
x9 : 00000000ffffff81 x8 : 0000aaaaadfa2000
x7 : 0000000000000000 x6 : 0000000000000000
x5 : 0000aaaaadfa2338 x4 : 0000aaaaadfa2000
x3 : 0000aaaaadfa2338 x2 : 0000000000000000
x1 : 0000aaaaadfa28b0 x0 : 0000aaaaadfa4c30
Sometimes it happens with other processes, but the main address, esr, and
pstate values are always the same.
I regularly run arm64/for-next/core (through bi-weekly renesas-drivers
releases, so the last time was two weeks ago), but never saw the issue
before until today, so probably v4.15-rc1 is OK.
Unfortunately it doesn't happen during every boot, which makes it
cumbersome to bisect.
My first guess was UNMAP_KERNEL_AT_EL0, but even after disabling that,
and even without today's arm64/for-next/core merged in, I still managed to
reproduce the issue, so I believe it was introduced in v4.15-rc2 or
v4.15-rc3.
Once, when the kernel message above wasn't shown, I got an error from
userspace, which may be related:
*** Error in `/bin/sh': free(): invalid pointer: 0x0000aaaadd970988 ***
Do you have a clue?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Marek Szyprowski @ 2017-12-12 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPc1_n2cdgjuFbA9jNdcSXxfr8Zjf=fUx_jt_N3+LP0n8A@mail.gmail.com>
Hi Krzysztof,
On 2017-12-12 11:09, Krzysztof Kozlowski wrote:
> On Tue, Dec 12, 2017 at 10:55 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
>> <javierm@redhat.com> wrote:
>>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
>>> Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
>>> for each Exynos 542x DTS. But unfortunately it missed to enable it for the
>>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
>>>
>>> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x Mixer nodes")
>>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>
>>> ---
>>>
>>> Changes in v2:
>>> - Remove RFT tag.
>> Thanks guys! However I still would like to see a tested-by for this on
>> Peach Pi (AFAIU, Marek's only acked the code/solution).
> On the other hand I could just apply it for my for-next branch and
> we'll see if it fixes kernel-ci boot tests... Not a nice way of
> testing but apparently no one has Peach Pi.
Frankly, I don't expect that this will solve the boot hang issue on PeachPi.
However it should at least hide the unbalanced regulator issue.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ 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