| Message ID | 1360508248-25252-3-git-send-email-ben.dooks@codethink.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 10/02/2013 14:57, Ben Dooks wrote: > Since the new ASID code in [b5466f8728527a05a493cc4abe9e6f034a1bbaab] > was changed to use 64bit operations it has broken the BE operation > due > to an issue with the MM code accessing sub-fields of mm->context.id. Fixed the ref, new patch pushed to git.
On Sun, Feb 10, 2013 at 03:05:11PM +0000, Ben Dooks wrote: > On 10/02/2013 14:57, Ben Dooks wrote: >> Since the new ASID code in [b5466f8728527a05a493cc4abe9e6f034a1bbaab] >> was changed to use 64bit operations it has broken the BE operation due >> to an issue with the MM code accessing sub-fields of mm->context.id. > > Fixed the ref, new patch pushed to git. No you haven't. "Since the new ASID code in b5466f872 (ARM: mm: remove IPI broadcasting on ASID rollover)..." is the correct way to refer to another patch by commit ID - both the ID _and_ its summary line. You can use a short ID but it's a good idea to add a few additional characters to avoid future hash clashes.
On 10/02/13 23:29, Russell King - ARM Linux wrote: > On Sun, Feb 10, 2013 at 03:05:11PM +0000, Ben Dooks wrote: >> On 10/02/2013 14:57, Ben Dooks wrote: >>> Since the new ASID code in [b5466f8728527a05a493cc4abe9e6f034a1bbaab] >>> was changed to use 64bit operations it has broken the BE operation due >>> to an issue with the MM code accessing sub-fields of mm->context.id. >> >> Fixed the ref, new patch pushed to git. > > No you haven't. > > "Since the new ASID code in b5466f872 (ARM: mm: remove IPI broadcasting > on ASID rollover)..." > > is the correct way to refer to another patch by commit ID - both the ID > _and_ its summary line. You can use a short ID but it's a good idea to > add a few additional characters to avoid future hash clashes. My repo is showing: Since the new ASID code in b5466f8728527a05a493cc4abe9e6f034a1bbaab ("ARM: mm: remove IPI broadcasting on ASID rollover") was changed to use 64bit operations it has broken the BE operation due to an issue with the MM code accessing sub-fields of mm->context.id. Would you like the commit-id shortened? Is there anything else before this pair can be pulled?
On Mon, Feb 11, 2013 at 10:38:29AM +0000, Ben Dooks wrote: > On 10/02/13 23:29, Russell King - ARM Linux wrote: > > On Sun, Feb 10, 2013 at 03:05:11PM +0000, Ben Dooks wrote: > >> On 10/02/2013 14:57, Ben Dooks wrote: > >>> Since the new ASID code in [b5466f8728527a05a493cc4abe9e6f034a1bbaab] > >>> was changed to use 64bit operations it has broken the BE operation due > >>> to an issue with the MM code accessing sub-fields of mm->context.id. > >> > >> Fixed the ref, new patch pushed to git. > > > > No you haven't. > > > > "Since the new ASID code in b5466f872 (ARM: mm: remove IPI broadcasting > > on ASID rollover)..." > > > > is the correct way to refer to another patch by commit ID - both the ID > > _and_ its summary line. You can use a short ID but it's a good idea to > > add a few additional characters to avoid future hash clashes. > > My repo is showing: > > Since the new ASID code in b5466f8728527a05a493cc4abe9e6f034a1bbaab > ("ARM: mm: remove IPI broadcasting on ASID rollover") was changed to > use 64bit operations it has broken the BE operation due to an issue > with the MM code accessing sub-fields of mm->context.id. > > Would you like the commit-id shortened? > Is there anything else before this pair can be pulled? You can add my acked-by if you like: Acked-by: Will Deacon <will.deacon@arm.com> Given that these are two small patches without any dependencies, it's probably easier to stick them in the patch system (which will also resolve any confusion about the form of the final commits). Cheers, Will
diff --git a/arch/arm/mm/context.c b/arch/arm/mm/context.c index bc4a5e9..7a05111 100644 --- a/arch/arm/mm/context.c +++ b/arch/arm/mm/context.c @@ -34,6 +34,9 @@ * The ASID is used to tag entries in the CPU caches and TLBs. * The context ID is used by debuggers and trace logic, and * should be unique within all running processes. + * + * In big endian operation, the two 32 bit words are swapped if accesed by + * non 64-bit operations. */ #define ASID_FIRST_VERSION (1ULL << ASID_BITS) #define NUM_USER_ASIDS (ASID_FIRST_VERSION - 1) diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S index eb6aa73..f9a0aa7 100644 --- a/arch/arm/mm/proc-macros.S +++ b/arch/arm/mm/proc-macros.S @@ -38,9 +38,14 @@ /* * mmid - get context id from mm pointer (mm->context.id) + * note, this field is 64bit, so in big-endian the two words are swapped too. */ .macro mmid, rd, rn +#ifdef __ARMEB__ + ldr \rd, [\rn, #MM_CONTEXT_ID + 4 ] +#else ldr \rd, [\rn, #MM_CONTEXT_ID] +#endif .endm /*
Since the new ASID code in [b5466f8728527a05a493cc4abe9e6f034a1bbaab] was changed to use 64bit operations it has broken the BE operation due to an issue with the MM code accessing sub-fields of mm->context.id. When running in BE mode we see the values in mm->context.id are stored with the highest value first, so the LDR in the arch/arm/mm/proc-macros.S reads the wrong part of this field. To resolve this, change the LDR in the mmid macro to load from +4. Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> --- arch/arm/mm/context.c | 3 +++ arch/arm/mm/proc-macros.S | 5 +++++ 2 files changed, 8 insertions(+)