From: sramana@codeaurora.org (Srinivas Ramana)
To: linux-arm-kernel@lists.infradead.org
Subject: LDM/STM alignment fixups on arm64
Date: Thu, 20 Apr 2017 16:50:30 +0530 [thread overview]
Message-ID: <58F8997E.8040907@codeaurora.org> (raw)
In-Reply-To: <20170419155801.GC3238@e104818-lin.cambridge.arm.com>
On 04/19/2017 09:28 PM, Catalin Marinas wrote:
> On Wed, Apr 19, 2017 at 06:20:10PM +0530, Srinivas Ramana wrote:
>> On 04/19/2017 03:28 PM, Russell King - ARM Linux wrote:
>>> On Wed, Apr 19, 2017 at 12:03:58PM +0530, Srinivas Ramana wrote:
>>>> While understanding how the alignment are handled on arm and arm64, we came
>>>> across the fixups for LDM/LDRD/STM on arm where as these fixups are not
>>>> present on arm64.
>>>>
>>>> There may be some specific reason why these fixups are not ported to arm64.
>>>> Can you please help us understand this?
>>>>
>>>> With this difference in how kernel handles 32-bit apps on arm and arm64,
>>>> there can be apps which are working without abort on arm, but fail on arm64
>>>> (SIGBUS). We have tried to get some history on web, but not successful.
>>>>
>>>> If this is indeed missing on arm64, do you see any issue if its ported (does
>>>> it fail any guidance)?
>>>
>>> Do you have an application that fails because of this? Your email makes
>>> it sound very theoretical.
>>
>> I don't have any application with me right now. But i just tried passing an
>> intentional misaligned address in a test program. When i say intentional,
>> please note this code is buggy and should be fixed.
>>
>> So, my question is when arm has such fixups to handle such cases and do
>> gracefully, is there any reason why those fixups are not ported to arm64?
>
> As Russell said, until we find some application in the wild I wouldn't
> rush to provide such emulation. Such code is either broken or relying on
> undefined C behaviour so they should rather be fixed. As with the
> deprecated/obsolete ARMv7 instructions (SWP, CP15 barriers), we
> initially decided not to implement the emulation in the arm64 kernel,
> though we eventually accepted it. But in those cases the instructions
> were once real and used correctly. The unaligned LDM/STM or LDRD/STRD
> have never been supported by the ARM architecture. They were added to
> cope with some unaligned accesses in the Linux kernel network stack (in
> hindsight, they should have not been provided to user but maybe there
> were good reasons, I don't know the full history here).
>
Sure. Thanks. I think i got some context and guidance now.
>> Again, I do agree that apps has to fix these instances, but we do have
>> fixups in arch/arm.
>
> I also think the default on arch/arm should be SIGBUS for these
> instructions on ARMv7 but this was discussed before on the list.
>
>> I do see that the compiler can detect (if its not intentionally induced)
>> such cases and avoiding to generate LDM/STM and generates multiple LDR/STR.
>> So, I just want to know if it is safe to assume that the compiler would take
>> care of all such misaligned addresses passed to LDM/STM?
>
> The compiler won't detect if you break its alignment assumptions (i.e.
> in your example pointers to struct locat are 64-bit aligned as per the
> EABI/PCS). If you want the compiler to assume unaligned struct pointers,
> you'd have to mark the structure with the packed attribute (with the
> additional padding if necessary, not in your example though).
>
You are right. with __packed__ attribute compiler detects the
unalignment (added a char to the test structure in my program), I could
see that compiler generates multiple LDRs instead of LDM.
Thanks for the details.
Thanks,
-- Srinivas R
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
prev parent reply other threads:[~2017-04-20 11:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-19 6:33 LDM/STM alignment fixups on arm64 Srinivas Ramana
2017-04-19 9:58 ` Russell King - ARM Linux
2017-04-19 12:50 ` Srinivas Ramana
2017-04-19 13:17 ` Russell King - ARM Linux
2017-04-19 15:58 ` Catalin Marinas
2017-04-20 11:20 ` Srinivas Ramana [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=58F8997E.8040907@codeaurora.org \
--to=sramana@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).