Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1306944 > unrolled thread

[RFC] arm64: failed when run the command: timedatectl set-timezone Asia/Shanghai

Started byXishi Qiu <qiuxishi@huawei.com>
First post2016-01-12 03:50 +0100
Last post2016-01-14 11:40 +0100
Articles 9 — 4 participants

Back to article view | Back to linux.kernel

Contents

  [RFC] arm64: failed when run the command: timedatectl set-timezone  Asia/Shanghai Xishi Qiu <qiuxishi@huawei.com> - 2016-01-12 03:50 +0100
    Re: [RFC] arm64: failed when run the command: timedatectl set-timezone  Asia/Shanghai Xishi Qiu <qiuxishi@huawei.com> - 2016-01-12 04:40 +0100
      Re: [RFC] arm64: failed when run the command: timedatectl  set-timezone Asia/Shanghai Steve Capper <steve.capper@linaro.org> - 2016-01-12 12:00 +0100
        Re: [RFC] arm64: failed when run the command: timedatectl set-timezone  Asia/Shanghai Xishi Qiu <qiuxishi@huawei.com> - 2016-01-13 02:20 +0100
          Re: [RFC] arm64: failed when run the command: timedatectl  set-timezone Asia/Shanghai Mark Rutland <mark.rutland@arm.com> - 2016-01-13 12:10 +0100
            Re: [RFC] arm64: failed when run the command: timedatectl  set-timezone Asia/Shanghai Christopher Covington <cov@codeaurora.org> - 2016-01-13 18:10 +0100
              Re: [RFC] arm64: failed when run the command: timedatectl  set-timezone Asia/Shanghai Mark Rutland <mark.rutland@arm.com> - 2016-01-13 19:50 +0100
            Re: [RFC] arm64: failed when run the command: timedatectl set-timezone  Asia/Shanghai Xishi Qiu <qiuxishi@huawei.com> - 2016-01-14 03:00 +0100
              Re: [RFC] arm64: failed when run the command: timedatectl  set-timezone Asia/Shanghai Mark Rutland <mark.rutland@arm.com> - 2016-01-14 11:40 +0100

#1306944 — [RFC] arm64: failed when run the command: timedatectl set-timezone Asia/Shanghai

FromXishi Qiu <qiuxishi@huawei.com>
Date2016-01-12 03:50 +0100
Subject[RFC] arm64: failed when run the command: timedatectl set-timezone Asia/Shanghai
Message-ID<qPXbX-30c-1@gated-at.bofh.it>
Failed when run the command: timedatectl set-timezone Asia/Shanghai
But CONFIG_PGTABLE_LEVELS=3 is OK, and CONFIG_PGTABLE_LEVELS=4 is failed.
The kernel is v4.1, and this command need the lib polikit.

Is this the bug of kernel?

Thanks,
Xishi Qiu

[toc] | [next] | [standalone]

#1306965

FromXishi Qiu <qiuxishi@huawei.com>
Date2016-01-12 04:40 +0100
Message-ID<qPXYl-3Gv-1@gated-at.bofh.it>
In reply to#1306944
On 2016/1/12 10:47, Xishi Qiu wrote:

> Failed when run the command: timedatectl set-timezone Asia/Shanghai
> But CONFIG_PGTABLE_LEVELS=3 is OK, and CONFIG_PGTABLE_LEVELS=4 is failed.
> The kernel is v4.1, and this command need the lib polikit.
> 
> Is this the bug of kernel?
> 
> Thanks,
> Xishi Qiu

[  241.310558] polkitd[3531]: unhandled level 0 translation fault (11) at 0x7fff9010c040, esr 0x92000004
[  241.319838] pgd = ffff801fb3e05000
[  241.323259] [7fff9010c040] *pgd=0000000000000000

[  241.329407] CPU: 0 PID: 3531 Comm: polkitd Not tainted 4.1.12+ #1
[  241.336312] Hardware name: Huawei Taishan 2160 /BC11SPCA, BIOS 1.12 12/30/2015
[  241.343566] task: ffff801fb8772f00 ti: ffff80003f454000 task.ti: ffff80003f454000
[  241.351089] PC is at 0xffff91d281ec
[  241.354594] LR is at 0xffff91cb5b24
[  241.358099] pc : [<0000ffff91d281ec>] lr : [<0000ffff91cb5b24>] pstate: 20000000
[  241.365526] sp : 0000ffffd47a4380
[  241.368858] x29: 0000ffffd47a47c0 x28: 0000000078e8107e
[  241.374215] x27: 0000aaaafaf68020 x26: 00007fff9010c040
[  241.379571] x25: 0000aaaafaf6c2b0 x24: 0000ffff91ed4000
[  241.384931] x23: 0000000000000005 x22: 0000000000000000
[  241.390288] x21: 0000000000000000 x20: 0000000000000008
[  241.395644] x19: 0000ffff91ed4000 x18: 00000000000007df
[  241.401004] x17: 0000ffff91ed5740 x16: 0000ffff91ce84ec
[  241.406360] x15: 0000ffffd47a46a0 x14: 0000ffff91c07370
[  241.411716] x13: 00000000000003d0 x12: 0000ffff92340000
[  241.417074] x11: 0000000000000000 x10: 0101010101010101
[  241.422431] x9 : 0000ffff90108218 x8 : 00000000f20217f7
[  241.427786] x7 : 0000aaaafaf6db40 x6 : 0000ffff90109060
[  241.433146] x5 : 0000000000000000 x4 : 0000aaaafaf6dc30
[  241.438502] x3 : 0000000000000001 x2 : 0000000000000008
[  241.443858] x1 : 0000aaaafaf68020 x0 : 00007fff9010c040

[toc] | [prev] | [next] | [standalone]

#1307265 — Re: [RFC] arm64: failed when run the command: timedatectl set-timezone Asia/Shanghai

FromSteve Capper <steve.capper@linaro.org>
Date2016-01-12 12:00 +0100
SubjectRe: [RFC] arm64: failed when run the command: timedatectl set-timezone Asia/Shanghai
Message-ID<qQ4Qb-8ey-31@gated-at.bofh.it>
In reply to#1306965
On 12 January 2016 at 03:32, Xishi Qiu <qiuxishi@huawei.com> wrote:
> On 2016/1/12 10:47, Xishi Qiu wrote:
>
>> Failed when run the command: timedatectl set-timezone Asia/Shanghai
>> But CONFIG_PGTABLE_LEVELS=3 is OK, and CONFIG_PGTABLE_LEVELS=4 is failed.
>> The kernel is v4.1, and this command need the lib polikit.
>>
>> Is this the bug of kernel?
>>
>> Thanks,
>> Xishi Qiu
>
> [  241.310558] polkitd[3531]: unhandled level 0 translation fault (11) at 0x7fff9010c040, esr 0x92000004
> [  241.319838] pgd = ffff801fb3e05000
> [  241.323259] [7fff9010c040] *pgd=0000000000000000
>
> [  241.329407] CPU: 0 PID: 3531 Comm: polkitd Not tainted 4.1.12+ #1
> [  241.336312] Hardware name: Huawei Taishan 2160 /BC11SPCA, BIOS 1.12 12/30/2015
> [  241.343566] task: ffff801fb8772f00 ti: ffff80003f454000 task.ti: ffff80003f454000
> [  241.351089] PC is at 0xffff91d281ec
> [  241.354594] LR is at 0xffff91cb5b24
> [  241.358099] pc : [<0000ffff91d281ec>] lr : [<0000ffff91cb5b24>] pstate: 20000000
> [  241.365526] sp : 0000ffffd47a4380
> [  241.368858] x29: 0000ffffd47a47c0 x28: 0000000078e8107e
> [  241.374215] x27: 0000aaaafaf68020 x26: 00007fff9010c040
> [  241.379571] x25: 0000aaaafaf6c2b0 x24: 0000ffff91ed4000
> [  241.384931] x23: 0000000000000005 x22: 0000000000000000
> [  241.390288] x21: 0000000000000000 x20: 0000000000000008
> [  241.395644] x19: 0000ffff91ed4000 x18: 00000000000007df
> [  241.401004] x17: 0000ffff91ed5740 x16: 0000ffff91ce84ec
> [  241.406360] x15: 0000ffffd47a46a0 x14: 0000ffff91c07370
> [  241.411716] x13: 00000000000003d0 x12: 0000ffff92340000
> [  241.417074] x11: 0000000000000000 x10: 0101010101010101
> [  241.422431] x9 : 0000ffff90108218 x8 : 00000000f20217f7
> [  241.427786] x7 : 0000aaaafaf6db40 x6 : 0000ffff90109060
> [  241.433146] x5 : 0000000000000000 x4 : 0000aaaafaf6dc30
> [  241.438502] x3 : 0000000000000001 x2 : 0000000000000008
> [  241.443858] x1 : 0000aaaafaf68020 x0 : 00007fff9010c040
>
>
>

Hi Xishi,
This looks like a bug in the Mozilla Javascript engine (which is used
by polkitd). It incorrectly assumes that virtual addresses are at most
47 bit and uses the upper bits for pointer tagging.
When we enable a 48-bit VA on arm64, this then exacerbates the problem
(your VA of 0x7fff9010c040 should likely be 0xffff9010c040).

I have raised this issue at:
https://bugzilla.mozilla.org/show_bug.cgi?id=1143022

I'm not sure as to the best way of getting this fixed, I would suggest
adding to the bug report above as a first step.

Cheers,
-- 
Steve

[toc] | [prev] | [next] | [standalone]

#1307956

FromXishi Qiu <qiuxishi@huawei.com>
Date2016-01-13 02:20 +0100
Message-ID<qQigq-HG-15@gated-at.bofh.it>
In reply to#1307265
On 2016/1/12 18:59, Steve Capper wrote:

> On 12 January 2016 at 03:32, Xishi Qiu <qiuxishi@huawei.com> wrote:
>> On 2016/1/12 10:47, Xishi Qiu wrote:
>>
>>> Failed when run the command: timedatectl set-timezone Asia/Shanghai
>>> But CONFIG_PGTABLE_LEVELS=3 is OK, and CONFIG_PGTABLE_LEVELS=4 is failed.
>>> The kernel is v4.1, and this command need the lib polikit.
>>>
>>> Is this the bug of kernel?
>>>
>>> Thanks,
>>> Xishi Qiu
>>
>> [  241.310558] polkitd[3531]: unhandled level 0 translation fault (11) at 0x7fff9010c040, esr 0x92000004
>> [  241.319838] pgd = ffff801fb3e05000
>> [  241.323259] [7fff9010c040] *pgd=0000000000000000
>>
>> [  241.329407] CPU: 0 PID: 3531 Comm: polkitd Not tainted 4.1.12+ #1
>> [  241.336312] Hardware name: Huawei Taishan 2160 /BC11SPCA, BIOS 1.12 12/30/2015
>> [  241.343566] task: ffff801fb8772f00 ti: ffff80003f454000 task.ti: ffff80003f454000
>> [  241.351089] PC is at 0xffff91d281ec
>> [  241.354594] LR is at 0xffff91cb5b24
>> [  241.358099] pc : [<0000ffff91d281ec>] lr : [<0000ffff91cb5b24>] pstate: 20000000
>> [  241.365526] sp : 0000ffffd47a4380
>> [  241.368858] x29: 0000ffffd47a47c0 x28: 0000000078e8107e
>> [  241.374215] x27: 0000aaaafaf68020 x26: 00007fff9010c040
>> [  241.379571] x25: 0000aaaafaf6c2b0 x24: 0000ffff91ed4000
>> [  241.384931] x23: 0000000000000005 x22: 0000000000000000
>> [  241.390288] x21: 0000000000000000 x20: 0000000000000008
>> [  241.395644] x19: 0000ffff91ed4000 x18: 00000000000007df
>> [  241.401004] x17: 0000ffff91ed5740 x16: 0000ffff91ce84ec
>> [  241.406360] x15: 0000ffffd47a46a0 x14: 0000ffff91c07370
>> [  241.411716] x13: 00000000000003d0 x12: 0000ffff92340000
>> [  241.417074] x11: 0000000000000000 x10: 0101010101010101
>> [  241.422431] x9 : 0000ffff90108218 x8 : 00000000f20217f7
>> [  241.427786] x7 : 0000aaaafaf6db40 x6 : 0000ffff90109060
>> [  241.433146] x5 : 0000000000000000 x4 : 0000aaaafaf6dc30
>> [  241.438502] x3 : 0000000000000001 x2 : 0000000000000008
>> [  241.443858] x1 : 0000aaaafaf68020 x0 : 00007fff9010c040
>>
>>
>>
> 
> Hi Xishi,
> This looks like a bug in the Mozilla Javascript engine (which is used
> by polkitd). It incorrectly assumes that virtual addresses are at most
> 47 bit and uses the upper bits for pointer tagging.
> When we enable a 48-bit VA on arm64, this then exacerbates the problem
> (your VA of 0x7fff9010c040 should likely be 0xffff9010c040).
> 
> I have raised this issue at:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1143022
> 
> I'm not sure as to the best way of getting this fixed, I would suggest
> adding to the bug report above as a first step.
> 

Hi Steve,

I find another issue at:
https://bugzilla.redhat.com/show_bug.cgi?id=1242326

In your issue, Tom Schuster said it sounds like bug 910845
https://bugzilla.mozilla.org/show_bug.cgi?id=910845
Does "__ia64__" mean Itanium arch or all the 64-bit arch?

I'm not familiar with these rpms, so which fix is correct?

Thanks,
Xishi Qiu

> Cheers,

[toc] | [prev] | [next] | [standalone]

#1308291 — Re: [RFC] arm64: failed when run the command: timedatectl set-timezone Asia/Shanghai

FromMark Rutland <mark.rutland@arm.com>
Date2016-01-13 12:10 +0100
SubjectRe: [RFC] arm64: failed when run the command: timedatectl set-timezone Asia/Shanghai
Message-ID<qQrtn-7g1-9@gated-at.bofh.it>
In reply to#1307956
On Wed, Jan 13, 2016 at 09:16:43AM +0800, Xishi Qiu wrote:
> On 2016/1/12 18:59, Steve Capper wrote:
> 
> > On 12 January 2016 at 03:32, Xishi Qiu <qiuxishi@huawei.com> wrote:
> >> On 2016/1/12 10:47, Xishi Qiu wrote:
> >>
> >>> Failed when run the command: timedatectl set-timezone Asia/Shanghai
> >>> But CONFIG_PGTABLE_LEVELS=3 is OK, and CONFIG_PGTABLE_LEVELS=4 is failed.
> >>> The kernel is v4.1, and this command need the lib polikit.
> >>>
> >>> Is this the bug of kernel?
> >>>
> >>> Thanks,
> >>> Xishi Qiu
> >>
> >> [  241.310558] polkitd[3531]: unhandled level 0 translation fault (11) at 0x7fff9010c040, esr 0x92000004
> >> [  241.319838] pgd = ffff801fb3e05000
> >> [  241.323259] [7fff9010c040] *pgd=0000000000000000
> >>
> >> [  241.329407] CPU: 0 PID: 3531 Comm: polkitd Not tainted 4.1.12+ #1
> >> [  241.336312] Hardware name: Huawei Taishan 2160 /BC11SPCA, BIOS 1.12 12/30/2015
> >> [  241.343566] task: ffff801fb8772f00 ti: ffff80003f454000 task.ti: ffff80003f454000
> >> [  241.351089] PC is at 0xffff91d281ec
> >> [  241.354594] LR is at 0xffff91cb5b24
> >> [  241.358099] pc : [<0000ffff91d281ec>] lr : [<0000ffff91cb5b24>] pstate: 20000000
> >> [  241.365526] sp : 0000ffffd47a4380
> >> [  241.368858] x29: 0000ffffd47a47c0 x28: 0000000078e8107e
> >> [  241.374215] x27: 0000aaaafaf68020 x26: 00007fff9010c040
> >> [  241.379571] x25: 0000aaaafaf6c2b0 x24: 0000ffff91ed4000
> >> [  241.384931] x23: 0000000000000005 x22: 0000000000000000
> >> [  241.390288] x21: 0000000000000000 x20: 0000000000000008
> >> [  241.395644] x19: 0000ffff91ed4000 x18: 00000000000007df
> >> [  241.401004] x17: 0000ffff91ed5740 x16: 0000ffff91ce84ec
> >> [  241.406360] x15: 0000ffffd47a46a0 x14: 0000ffff91c07370
> >> [  241.411716] x13: 00000000000003d0 x12: 0000ffff92340000
> >> [  241.417074] x11: 0000000000000000 x10: 0101010101010101
> >> [  241.422431] x9 : 0000ffff90108218 x8 : 00000000f20217f7
> >> [  241.427786] x7 : 0000aaaafaf6db40 x6 : 0000ffff90109060
> >> [  241.433146] x5 : 0000000000000000 x4 : 0000aaaafaf6dc30
> >> [  241.438502] x3 : 0000000000000001 x2 : 0000000000000008
> >> [  241.443858] x1 : 0000aaaafaf68020 x0 : 00007fff9010c040
> >>
> >>
> >>
> > 
> > Hi Xishi,
> > This looks like a bug in the Mozilla Javascript engine (which is used
> > by polkitd). It incorrectly assumes that virtual addresses are at most
> > 47 bit and uses the upper bits for pointer tagging.
> > When we enable a 48-bit VA on arm64, this then exacerbates the problem
> > (your VA of 0x7fff9010c040 should likely be 0xffff9010c040).
> > 
> > I have raised this issue at:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1143022
> > 
> > I'm not sure as to the best way of getting this fixed, I would suggest
> > adding to the bug report above as a first step.
> > 
> 
> Hi Steve,
> 
> I find another issue at:
> https://bugzilla.redhat.com/show_bug.cgi?id=1242326

Per your question below, the proposed patch is incorrect.

Userspace can only assume ownership of the upper 8 bits, and only in the
cases described in [1]. Userspace MUST NOT assume it can use other bits
for its own purposes.

This was a deliberate decision such that the address space can be
enlarged in future. For example, ARMv8.2 expands addresses to 52 bits
[2], and addresses could grow further in future.

> In your issue, Tom Schuster said it sounds like bug 910845
> https://bugzilla.mozilla.org/show_bug.cgi?id=910845

Controlled allocation as in this patch is probably a workable approach.

However, the arm64 kernel can be built with a very small VA range, and
the base chosen is outside of the minimum range. The kernel currently
goes as low as 36 bits (with 16K pages), though the architectural
minimum seems to be 24 currently.

To be safe for all configurations, I guess the best option is to
allocate as close to zero as possible, or to dynamically choose a base
depending on the VA range. I'm not sure how to correctly determine the
VA range from userspace, however.

> Does "__ia64__" mean Itanium arch or all the 64-bit arch?

Using __ia64__ only covers Itanium.

> I'm not familiar with these rpms, so which fix is correct?

Hopefully that's answered above.

Thanks,
Mark.

[1]  https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm64/tagged-pointers.txt?h=v4.4&id=afd2ff9b7e1b367172f18ba7f693dfb62bdcb2dc
[2] https://community.arm.com/groups/processors/blog/2016/01/05/armv8-a-architecture-evolution

[toc] | [prev] | [next] | [standalone]

#1308636 — Re: [RFC] arm64: failed when run the command: timedatectl set-timezone Asia/Shanghai

FromChristopher Covington <cov@codeaurora.org>
Date2016-01-13 18:10 +0100
SubjectRe: [RFC] arm64: failed when run the command: timedatectl set-timezone Asia/Shanghai
Message-ID<qQx5O-2Pq-45@gated-at.bofh.it>
In reply to#1308291
On 01/13/2016 06:09 AM, Mark Rutland wrote:
> On Wed, Jan 13, 2016 at 09:16:43AM +0800, Xishi Qiu wrote:
>> On 2016/1/12 18:59, Steve Capper wrote:
>>
>>> On 12 January 2016 at 03:32, Xishi Qiu <qiuxishi@huawei.com> wrote:
>>>> On 2016/1/12 10:47, Xishi Qiu wrote:
>>>>
>>>>> Failed when run the command: timedatectl set-timezone Asia/Shanghai
>>>>> But CONFIG_PGTABLE_LEVELS=3 is OK, and CONFIG_PGTABLE_LEVELS=4 is failed.
>>>>> The kernel is v4.1, and this command need the lib polikit.
>>>>>
>>>>> Is this the bug of kernel?
>>>>>
>>>>> Thanks,
>>>>> Xishi Qiu
>>>>
>>>> [  241.310558] polkitd[3531]: unhandled level 0 translation fault (11) at 0x7fff9010c040, esr 0x92000004
>>>> [  241.319838] pgd = ffff801fb3e05000
>>>> [  241.323259] [7fff9010c040] *pgd=0000000000000000
>>>>
>>>> [  241.329407] CPU: 0 PID: 3531 Comm: polkitd Not tainted 4.1.12+ #1
>>>> [  241.336312] Hardware name: Huawei Taishan 2160 /BC11SPCA, BIOS 1.12 12/30/2015
>>>> [  241.343566] task: ffff801fb8772f00 ti: ffff80003f454000 task.ti: ffff80003f454000
>>>> [  241.351089] PC is at 0xffff91d281ec
>>>> [  241.354594] LR is at 0xffff91cb5b24
>>>> [  241.358099] pc : [<0000ffff91d281ec>] lr : [<0000ffff91cb5b24>] pstate: 20000000
>>>> [  241.365526] sp : 0000ffffd47a4380
>>>> [  241.368858] x29: 0000ffffd47a47c0 x28: 0000000078e8107e
>>>> [  241.374215] x27: 0000aaaafaf68020 x26: 00007fff9010c040
>>>> [  241.379571] x25: 0000aaaafaf6c2b0 x24: 0000ffff91ed4000
>>>> [  241.384931] x23: 0000000000000005 x22: 0000000000000000
>>>> [  241.390288] x21: 0000000000000000 x20: 0000000000000008
>>>> [  241.395644] x19: 0000ffff91ed4000 x18: 00000000000007df
>>>> [  241.401004] x17: 0000ffff91ed5740 x16: 0000ffff91ce84ec
>>>> [  241.406360] x15: 0000ffffd47a46a0 x14: 0000ffff91c07370
>>>> [  241.411716] x13: 00000000000003d0 x12: 0000ffff92340000
>>>> [  241.417074] x11: 0000000000000000 x10: 0101010101010101
>>>> [  241.422431] x9 : 0000ffff90108218 x8 : 00000000f20217f7
>>>> [  241.427786] x7 : 0000aaaafaf6db40 x6 : 0000ffff90109060
>>>> [  241.433146] x5 : 0000000000000000 x4 : 0000aaaafaf6dc30
>>>> [  241.438502] x3 : 0000000000000001 x2 : 0000000000000008
>>>> [  241.443858] x1 : 0000aaaafaf68020 x0 : 00007fff9010c040
>>>>
>>>>
>>>>
>>>
>>> Hi Xishi,
>>> This looks like a bug in the Mozilla Javascript engine (which is used
>>> by polkitd). It incorrectly assumes that virtual addresses are at most
>>> 47 bit and uses the upper bits for pointer tagging.
>>> When we enable a 48-bit VA on arm64, this then exacerbates the problem
>>> (your VA of 0x7fff9010c040 should likely be 0xffff9010c040).
>>>
>>> I have raised this issue at:
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1143022
>>>
>>> I'm not sure as to the best way of getting this fixed, I would suggest
>>> adding to the bug report above as a first step.
>>>
>>
>> Hi Steve,
>>
>> I find another issue at:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1242326
> 
> Per your question below, the proposed patch is incorrect.
> 
> Userspace can only assume ownership of the upper 8 bits, and only in the
> cases described in [1]. Userspace MUST NOT assume it can use other bits
> for its own purposes.
> 
> This was a deliberate decision such that the address space can be
> enlarged in future. For example, ARMv8.2 expands addresses to 52 bits
> [2], and addresses could grow further in future.
> 
>> In your issue, Tom Schuster said it sounds like bug 910845
>> https://bugzilla.mozilla.org/show_bug.cgi?id=910845
> 
> Controlled allocation as in this patch is probably a workable approach.
> 
> However, the arm64 kernel can be built with a very small VA range, and
> the base chosen is outside of the minimum range. The kernel currently
> goes as low as 36 bits (with 16K pages), though the architectural
> minimum seems to be 24 currently.
> 
> To be safe for all configurations, I guess the best option is to
> allocate as close to zero as possible, or to dynamically choose a base
> depending on the VA range. I'm not sure how to correctly determine the
> VA range from userspace, however.

Below is how I ended up determining TASK_SIZE for Checkpoint/Restore In
Userspace (CRIU).

https://github.com/xemul/criu/commit/c0c0546c31e6df4932669f4740197bb830a24c8d

If this is too hacky, my thought on a more proper interface would be to
parallel how PAGE_SIZE is communicated. TASK_SIZE could be added to the
ELF auxiliary vector, such that one could simply run `getconf TASK_SIZE`
and sysconf(TASK_SIZE).

Regards,
Christopher Covington

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[toc] | [prev] | [next] | [standalone]

#1308728 — Re: [RFC] arm64: failed when run the command: timedatectl set-timezone Asia/Shanghai

FromMark Rutland <mark.rutland@arm.com>
Date2016-01-13 19:50 +0100
SubjectRe: [RFC] arm64: failed when run the command: timedatectl set-timezone Asia/Shanghai
Message-ID<qQyEy-3Fw-11@gated-at.bofh.it>
In reply to#1308636
On Wed, Jan 13, 2016 at 12:00:30PM -0500, Christopher Covington wrote:
> On 01/13/2016 06:09 AM, Mark Rutland wrote:
> > On Wed, Jan 13, 2016 at 09:16:43AM +0800, Xishi Qiu wrote:
> >> In your issue, Tom Schuster said it sounds like bug 910845
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=910845
> > 
> > Controlled allocation as in this patch is probably a workable approach.
> > 
> > However, the arm64 kernel can be built with a very small VA range, and
> > the base chosen is outside of the minimum range. The kernel currently
> > goes as low as 36 bits (with 16K pages), though the architectural
> > minimum seems to be 24 currently.
> > 
> > To be safe for all configurations, I guess the best option is to
> > allocate as close to zero as possible, or to dynamically choose a base
> > depending on the VA range. I'm not sure how to correctly determine the
> > VA range from userspace, however.
> 
> Below is how I ended up determining TASK_SIZE for Checkpoint/Restore In
> Userspace (CRIU).
> 
> https://github.com/xemul/criu/commit/c0c0546c31e6df4932669f4740197bb830a24c8d

That's very scary. Any pages on a power of two boundary would get
unmapped, silently. That will corrupt data.

As above, the hard-code assumptions of a 39-bit minimum and a 48-bit
maximum are erroneous.

> If this is too hacky, my thought on a more proper interface would be to
> parallel how PAGE_SIZE is communicated. TASK_SIZE could be added to the
> ELF auxiliary vector, such that one could simply run `getconf TASK_SIZE`
> and sysconf(TASK_SIZE).

Assuming we don't have a reliable and safe mechanism already, something
like that sounds sensible to me.

Thanks,
Mark.

[toc] | [prev] | [next] | [standalone]

#1308959

FromXishi Qiu <qiuxishi@huawei.com>
Date2016-01-14 03:00 +0100
Message-ID<qQFmG-8hY-15@gated-at.bofh.it>
In reply to#1308291
On 2016/1/13 19:09, Mark Rutland wrote:

> On Wed, Jan 13, 2016 at 09:16:43AM +0800, Xishi Qiu wrote:
>> On 2016/1/12 18:59, Steve Capper wrote:
>>
>>> On 12 January 2016 at 03:32, Xishi Qiu <qiuxishi@huawei.com> wrote:
>>>> On 2016/1/12 10:47, Xishi Qiu wrote:
>>>>
>>>>> Failed when run the command: timedatectl set-timezone Asia/Shanghai
>>>>> But CONFIG_PGTABLE_LEVELS=3 is OK, and CONFIG_PGTABLE_LEVELS=4 is failed.
>>>>> The kernel is v4.1, and this command need the lib polikit.
>>>>>
>>>>> Is this the bug of kernel?
>>>>>
>>>>> Thanks,
>>>>> Xishi Qiu
>>>>
>>>> [  241.310558] polkitd[3531]: unhandled level 0 translation fault (11) at 0x7fff9010c040, esr 0x92000004
>>>> [  241.319838] pgd = ffff801fb3e05000
>>>> [  241.323259] [7fff9010c040] *pgd=0000000000000000
>>>>
>>>> [  241.329407] CPU: 0 PID: 3531 Comm: polkitd Not tainted 4.1.12+ #1
>>>> [  241.336312] Hardware name: Huawei Taishan 2160 /BC11SPCA, BIOS 1.12 12/30/2015
>>>> [  241.343566] task: ffff801fb8772f00 ti: ffff80003f454000 task.ti: ffff80003f454000
>>>> [  241.351089] PC is at 0xffff91d281ec
>>>> [  241.354594] LR is at 0xffff91cb5b24
>>>> [  241.358099] pc : [<0000ffff91d281ec>] lr : [<0000ffff91cb5b24>] pstate: 20000000
>>>> [  241.365526] sp : 0000ffffd47a4380
>>>> [  241.368858] x29: 0000ffffd47a47c0 x28: 0000000078e8107e
>>>> [  241.374215] x27: 0000aaaafaf68020 x26: 00007fff9010c040
>>>> [  241.379571] x25: 0000aaaafaf6c2b0 x24: 0000ffff91ed4000
>>>> [  241.384931] x23: 0000000000000005 x22: 0000000000000000
>>>> [  241.390288] x21: 0000000000000000 x20: 0000000000000008
>>>> [  241.395644] x19: 0000ffff91ed4000 x18: 00000000000007df
>>>> [  241.401004] x17: 0000ffff91ed5740 x16: 0000ffff91ce84ec
>>>> [  241.406360] x15: 0000ffffd47a46a0 x14: 0000ffff91c07370
>>>> [  241.411716] x13: 00000000000003d0 x12: 0000ffff92340000
>>>> [  241.417074] x11: 0000000000000000 x10: 0101010101010101
>>>> [  241.422431] x9 : 0000ffff90108218 x8 : 00000000f20217f7
>>>> [  241.427786] x7 : 0000aaaafaf6db40 x6 : 0000ffff90109060
>>>> [  241.433146] x5 : 0000000000000000 x4 : 0000aaaafaf6dc30
>>>> [  241.438502] x3 : 0000000000000001 x2 : 0000000000000008
>>>> [  241.443858] x1 : 0000aaaafaf68020 x0 : 00007fff9010c040
>>>>
>>>>
>>>>
>>>
>>> Hi Xishi,
>>> This looks like a bug in the Mozilla Javascript engine (which is used
>>> by polkitd). It incorrectly assumes that virtual addresses are at most
>>> 47 bit and uses the upper bits for pointer tagging.
>>> When we enable a 48-bit VA on arm64, this then exacerbates the problem
>>> (your VA of 0x7fff9010c040 should likely be 0xffff9010c040).
>>>
>>> I have raised this issue at:
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1143022
>>>
>>> I'm not sure as to the best way of getting this fixed, I would suggest
>>> adding to the bug report above as a first step.
>>>
>>
>> Hi Steve,
>>
>> I find another issue at:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1242326
> 
> Per your question below, the proposed patch is incorrect.
> 
> Userspace can only assume ownership of the upper 8 bits, and only in the
> cases described in [1]. Userspace MUST NOT assume it can use other bits
> for its own purposes.
> 
> This was a deliberate decision such that the address space can be
> enlarged in future. For example, ARMv8.2 expands addresses to 52 bits
> [2], and addresses could grow further in future.
> 
>> In your issue, Tom Schuster said it sounds like bug 910845
>> https://bugzilla.mozilla.org/show_bug.cgi?id=910845
> 

Hi Mark,

Thank you very much. So the patch above only cover Itanium, and there is
no solution for arm64 now, right? 

Thanks,
Xishi Qiu

> Controlled allocation as in this patch is probably a workable approach.
> 

> However, the arm64 kernel can be built with a very small VA range, and
> the base chosen is outside of the minimum range. The kernel currently
> goes as low as 36 bits (with 16K pages), though the architectural
> minimum seems to be 24 currently.
> 
> To be safe for all configurations, I guess the best option is to
> allocate as close to zero as possible, or to dynamically choose a base
> depending on the VA range. I'm not sure how to correctly determine the
> VA range from userspace, however.
> 
>> Does "__ia64__" mean Itanium arch or all the 64-bit arch?
> 
> Using __ia64__ only covers Itanium.
> 
>> I'm not familiar with these rpms, so which fix is correct?
> 
> Hopefully that's answered above.
> 
> Thanks,
> Mark.
> 
> [1]  https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm64/tagged-pointers.txt?h=v4.4&id=afd2ff9b7e1b367172f18ba7f693dfb62bdcb2dc
> [2] https://community.arm.com/groups/processors/blog/2016/01/05/armv8-a-architecture-evolution
> 
> .
>

[toc] | [prev] | [next] | [standalone]

#1309165 — Re: [RFC] arm64: failed when run the command: timedatectl set-timezone Asia/Shanghai

FromMark Rutland <mark.rutland@arm.com>
Date2016-01-14 11:40 +0100
SubjectRe: [RFC] arm64: failed when run the command: timedatectl set-timezone Asia/Shanghai
Message-ID<qQNtU-5HN-7@gated-at.bofh.it>
In reply to#1308959
On Thu, Jan 14, 2016 at 09:48:49AM +0800, Xishi Qiu wrote:
> On 2016/1/13 19:09, Mark Rutland wrote:
> 
> > On Wed, Jan 13, 2016 at 09:16:43AM +0800, Xishi Qiu wrote:
> >> On 2016/1/12 18:59, Steve Capper wrote:
> >>> Hi Xishi,
> >>> This looks like a bug in the Mozilla Javascript engine (which is used
> >>> by polkitd). It incorrectly assumes that virtual addresses are at most
> >>> 47 bit and uses the upper bits for pointer tagging.
> >>> When we enable a 48-bit VA on arm64, this then exacerbates the problem
> >>> (your VA of 0x7fff9010c040 should likely be 0xffff9010c040).
> >>>
> >>> I have raised this issue at:
> >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1143022
> >>>
> >>> I'm not sure as to the best way of getting this fixed, I would suggest
> >>> adding to the bug report above as a first step.
> >>>
> >>
> >> Hi Steve,
> >>
> >> I find another issue at:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1242326
> > 
> > Per your question below, the proposed patch is incorrect.
> > 
> > Userspace can only assume ownership of the upper 8 bits, and only in the
> > cases described in [1]. Userspace MUST NOT assume it can use other bits
> > for its own purposes.
> > 
> > This was a deliberate decision such that the address space can be
> > enlarged in future. For example, ARMv8.2 expands addresses to 52 bits
> > [2], and addresses could grow further in future.
> > 
> >> In your issue, Tom Schuster said it sounds like bug 910845
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=910845
> > 
> 
> Hi Mark,
> 
> Thank you very much. So the patch above only cover Itanium, and there is
> no solution for arm64 now, right? 

Yes, the patch only covers Itanium.

I am not aware of a patch solving the issue for arm64. I have not been
following the development of the Mozilla javasript engine.

The best thing to do is probably to respond to the first ticket
(https://bugzilla.mozilla.org/show_bug.cgi?id=1143022), querying whether
or not anyone is able to take a look at it. 

If you do, please cite this thread, in particular:

http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/399178.html), 

Which should help to avoid an erroneous solution.

Thanks,
Mark.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web