Bug 1394837 - AARCH64 - 48-bit VA
Summary: AARCH64 - 48-bit VA
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Changes Tracking
Version: 26
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jeremy Linton
QA Contact:
Simon Clark
URL:
Whiteboard: ChangeAcceptedF26, SystemWideChange
Depends On: 1395969 1429050
Blocks: ARMTracker
TreeView+ depends on / blocked
 
Reported: 2016-11-14 14:44 UTC by Jan Kurik
Modified: 2017-07-25 17:04 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-07-25 17:04:56 UTC


Attachments (Terms of Use)

Description Jan Kurik 2016-11-14 14:44:43 UTC
This is a tracking bug for Change: AARCH64 - 48-bit VA
For more details, see: https://fedoraproject.org//wiki/Changes/aarch64-48bitVA

Enable 48bit VA on AARCH64

Comment 1 Tomas Mraz 2017-02-22 13:39:05 UTC
js seems to crash on current aarch64 kernels - is this the cause? Will someone handle the patching and rebuild of js dependencies?

Comment 2 Peter Robinson 2017-02-22 17:25:27 UTC
(In reply to Tomas Mraz from comment #1)
> js seems to crash on current aarch64 kernels - is this the cause? Will
> someone handle the patching and rebuild of js dependencies?

You need to be a little more specific there, last I looked this issue was fixed on the js package as of 1.8.5-16

Comment 3 Tomas Mraz 2017-02-23 10:21:31 UTC
Hmm that's weird as the js keeps crashing (only on aarch64) even on js-1.8.5-26.fc26 (it does not crash when run on old kernel). Perhaps it regressed? I've tried to apply something similar as the patch on bug 1395969 and it allowed the build tests of js to progress further but later it crashed too. (It was not a serious attempt at fix as I do not know the js code, I just wanted to see if it is related.)
See https://bugzilla.redhat.com/show_bug.cgi?id=1424039 and https://bugzilla.redhat.com/show_bug.cgi?id=1423793 which are most probably the same issue.

Comment 4 Jan Kurik 2017-02-28 10:08:42 UTC
On 2017-Feb-28, we have reached the Fedora 26 Change Checkpoint: Completion deadline (testable).

At this point, all accepted changes should be substantially complete, and testable. Additionally, if a change is to be enabled by default, it must be enabled at Change Completion deadline as well.

Change tracking bug should be set to the MODIFIED state to indicate it achieved completeness.

Incomplete and non testable Changes will be reported to FESCo for 2017-Mar-03 meeting.

Comment 5 Fedora End Of Life 2017-02-28 10:36:43 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Comment 6 Jeremy Linton 2017-02-28 14:56:40 UTC
This was all working before the rebuild, but in that same timeframe gjs was upgraded, and the world was rebuilt with gcc7. So last week I also saw that gjs, firefox and quite a number of other things were no longer working. My plan is to start working through these issues.

Comment 7 Jeremy Linton 2017-03-03 17:18:33 UTC
Just to be clear here, I don't think the problems I see are related to 48-bit VAs.

That is because they are missing the 48-bit VA crash related signature. To expand upon this, crashes that are likely the result of 48-bit VAs are generally accesses to addresses that have their 47th address bit cleared. This is the result of pointer manipulations that incorrectly clear the 47th bit out of a valid address with that bit set. Futhermore these kinds of crashes can be fixed by rebooting to a 42-bit VA kernel. 

I don't see this behavior at the moment.

Comment 8 Jeremy Linton 2017-03-03 17:34:49 UTC
I should be consistent with my terminology. To clear up any confusion there with 48bit VA's valid user addresses might look like:

ffff9bae0000-ffffa2680000 r--p 00000000 08:04 17225985                   /usr/lib/locale/locale-archive
ffffc8e10000-ffffc8e40000 rw-p 00000000 00:00 0                          [stack]


In /proc/pid/maps.

An invalid stack access that faults would then look like:

fault @ 7FFFC8E30000, because the real address should be FFFFC8E30000 but someone cleared the 48th bit.

Comment 9 Jeremy Linton 2017-03-03 23:03:47 UTC
I have opened an additional bug about the gnome-shell/llvmpipe crash.

https://bugzilla.redhat.com/show_bug.cgi?id=1429050

Comment 10 Jan Kurik 2017-05-17 09:13:31 UTC
On 2017-May-16 we reached the "Change Checkpoint: 100% Code Complete Deadline" milestone for Fedora 26 release. At this point all the Changes not at least in "ON_QA" state should be brought to FESCo for review. Please update the state of this bug to "ON_QA" if it is already 100% completed. Please let me know in case you have any trouble with the implementation and the Change needs any help or review.

Thanks, Jan

Comment 11 Jan Kurik 2017-05-19 08:13:24 UTC
This Change is going to be reviewed on a FESCo meeting: https://pagure.io/fesco/issue/1710

Comment 12 Jeremy Linton 2017-05-19 14:57:22 UTC
Sorry, sort of new to the whole process.

Comment 13 Jeremy Linton 2017-05-19 15:34:59 UTC
[root@mammon-juno-f26 ~]# uname -a
Linux mammon-juno-f26.localdomain 4.11.0-2.fc26.aarch64 #1 SMP Tue May 9 15:09:58 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
[root@mammon-juno-f26 ~]# cat /proc/1/maps |grep stack
fffffe24b000-fffffe26c000 rw-p 00000000 00:00 0                          [stack]


I'm going to mark it verified as well.

Comment 14 Simon Clark 2017-07-02 18:03:51 UTC
I have added release notes text for this change to the draft F26 Release Notes here: https://pagure.io/release-notes/c/f28baf7c9f5482fe31a40d200f44ee70284f0eee?branch=f26

Please would you take a look at the draft and let me know if anything should be added or changed?

Comment 15 Jeremy Linton 2017-07-05 16:16:59 UTC
Sorry about the delay (OoO without data for a week or so). 

Anyway, the description refrenced in the change looks good.

Thanks,


Note You need to log in before you can comment on or make changes to this bug.