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

RFC Xishi Qiu 5 participants 10 messages Jan 12, 2016 – Jan 18, 2016

Share & tools

Xishi Qiu

author

2016-01-12 02:47 UTC #0 lore raw

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

Xishi Qiu

author

2016-01-12 03:32 UTC #1 lore raw

Quoted 8 lines · Xishi Qiu

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

Steve Capper

2016-01-12 10:59 UTC #2 lore raw

Quoted 29 lines · Xishi Qiu

Quoted 8 lines · Xishi Qiu

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

Quoted 11 lines

[  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,

Signature · 1 line

Steve

Xishi Qiu

author

2016-01-13 01:16 UTC #3 lore raw

Quoted 49 lines · Steve Capper

Quoted 29 lines · Xishi Qiu

Quoted 8 lines · Xishi Qiu

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

Quoted 11 lines

[  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

Quoted 6 lines

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

Quoted 1 line

Cheers,

Mark Rutland

2016-01-13 11:09 UTC #4 lore raw

Quoted 54 lines · Xishi Qiu

Quoted 52 lines · Steve Capper
Quoted 29 lines · Xishi Qiu
Quoted 8 lines · Xishi Qiu
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
Quoted 11 lines
[  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

Quoted 8 lines

Quoted 3 lines
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.

Quoted 2 lines

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.

Quoted 1 line

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

Using __ia64__ only covers Itanium.

Quoted 1 line

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

Christopher Covington

2016-01-13 17:00 UTC #5 lore raw

Quoted 84 lines · Mark Rutland

Quoted 54 lines · Xishi Qiu
Quoted 52 lines · Steve Capper
Quoted 29 lines · Xishi Qiu
Quoted 8 lines · Xishi Qiu
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
Quoted 11 lines
[  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
Quoted 8 lines
Quoted 3 lines
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.
Quoted 2 lines
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.

Quoted 4 lines

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

Signature · 3 lines

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

Mark Rutland

2016-01-13 18:47 UTC #6 lore raw

Quoted 17 lines · Christopher Covington

Quoted 11 lines · Mark Rutland
Quoted 2 lines · Xishi Qiu
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.
Quoted 4 lines
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.

Quoted 4 lines

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.

Quoted 4 lines

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.

Xishi Qiu

author

2016-01-14 01:48 UTC #7 lore raw

In reply to Mark Rutland

Quoted 66 lines · Mark Rutland

Quoted 54 lines · Xishi Qiu
Quoted 52 lines · Steve Capper
Quoted 29 lines · Xishi Qiu
Quoted 8 lines · Xishi Qiu
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
Quoted 11 lines
[  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
Quoted 8 lines
Quoted 3 lines
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.

Quoted 11 lines

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.
Quoted 2 lines
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

Quoted 29 lines

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.
Quoted 1 line
Does "__ia64__" mean Itanium arch or all the 64-bit arch?
Using __ia64__ only covers Itanium.
Quoted 1 line
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
.

Mark Rutland

2016-01-14 10:34 UTC #8 lore raw

Quoted 33 lines · Xishi Qiu

Quoted 31 lines · Mark Rutland
Quoted 11 lines · Xishi Qiu
Quoted 10 lines · Steve Capper
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
Quoted 8 lines
Quoted 3 lines
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.

Quoted 8 lines

Quoted 3 lines
Quoted 2 lines
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.

Jon Masters

2016-01-18 07:23 UTC #9 lore raw

In reply to Mark Rutland

Hi Mark, Xishi,

Quoted 11 lines · Mark Rutland

Quoted 10 lines · Xishi Qiu
Quoted 8 lines · Steve Capper
Quoted 7 lines · Xishi Qiu
Quoted 5 lines · Xishi Qiu
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?

As noted by others, this is a problem with interpretation by certain userspace (probably not restricted to mozjs) applications of their ability to use the high order bits of a VA. It's actually been flagged a few times by others in both RHEL(SA) and Fedora as well, but I've pointed out (at least in the former) that we're not building with a 48-bit VA currently so it won't be as visible for the moment. That means if you're consuming a Cent7 kernel from Jim/etc. it'll probably not fall over out of the box (copying him so he knows about this - it's been coming up a bit over the past few days in some other conversation).

This definitely needs fixing in upstream polkit builds, and a general education exercise needs to be initiated so that people don't get this wrong in future (but it's guaranteed that they will). FWIW my personal opinion is that tagged pointers are dangerous and should never have happened (because you can't trust people/there will be code out there for years that will have broken assumptions and never be fixed).

Jon.