[sparc32] userland unaligned access

[sparc32] userland unaligned access

[Al Viro]

	We have
asmlinkage void user_unaligned_trap(struct pt_regs *regs, unsigned int insn)
{
        enum direction dir;

        if(!(current->thread.flags & SPARC_FLAG_UNALIGNED) ||
           (((insn >> 30) & 3) != 3))
                goto kill_user;

there, followed by some work on emulating the insn.  So while the default
behaviour is to hit the process with SIGBUS, it can overridden by setting
SPARC_FLAG_UNALIGNED in current->thread.flags.  Fair enough, but...  Just
what could possibly set that flag?

That stuff had been introduced back in 2.1.9 and even there (or through
the 2.2, etc.) I don't see anything that would ever set it.

Am I missing something, or had it really been dead code all along?

Re: [sparc32] userland unaligned access

[David Miller]

From: Al Viro <viro@zeniv.linux.org.uk>
Date: Thu, 20 Aug 2020 20:36:12 +0100

> 	We have
> asmlinkage void user_unaligned_trap(struct pt_regs *regs, unsigned int insn)
> {
>         enum direction dir;
> 
>         if(!(current->thread.flags & SPARC_FLAG_UNALIGNED) ||
>            (((insn >> 30) & 3) != 3))
>                 goto kill_user;
> 
> there, followed by some work on emulating the insn.  So while the default
> behaviour is to hit the process with SIGBUS, it can overridden by setting
> SPARC_FLAG_UNALIGNED in current->thread.flags.  Fair enough, but...  Just
> what could possibly set that flag?
> 
> That stuff had been introduced back in 2.1.9 and even there (or through
> the 2.2, etc.) I don't see anything that would ever set it.
> 
> Am I missing something, or had it really been dead code all along?

Relic from the SunOS and/or Solaris syscall emulation probably.

Re: [sparc32] userland unaligned access

[Al Viro]

On Thu, Aug 20, 2020 at 03:51:22PM -0700, David Miller wrote:
> From: Al Viro <viro@zeniv.linux.org.uk>
> Date: Thu, 20 Aug 2020 20:36:12 +0100
> 
> > 	We have
> > asmlinkage void user_unaligned_trap(struct pt_regs *regs, unsigned int insn)
> > {
> >         enum direction dir;
> > 
> >         if(!(current->thread.flags & SPARC_FLAG_UNALIGNED) ||
> >            (((insn >> 30) & 3) != 3))
> >                 goto kill_user;
> > 
> > there, followed by some work on emulating the insn.  So while the default
> > behaviour is to hit the process with SIGBUS, it can overridden by setting
> > SPARC_FLAG_UNALIGNED in current->thread.flags.  Fair enough, but...  Just
> > what could possibly set that flag?
> > 
> > That stuff had been introduced back in 2.1.9 and even there (or through
> > the 2.2, etc.) I don't see anything that would ever set it.
> > 
> > Am I missing something, or had it really been dead code all along?
> 
> Relic from the SunOS and/or Solaris syscall emulation probably.

Thought so, but...  no such thing in either.  And it's not done from assembler -
arch/sparc64 used to access ->tss.flags that way (and that was only for
SPARC_FLAG_NEWCHILD), but arch/sparc never did...

I don't have sunos toolchain to try and build such a binary and test it on
a 2.2 kernel, but I would be rather surprised if that had been it.

Anyway, it really looks like that's dead code these days...

Re: [sparc32] userland unaligned access

[David Miller]

From: Al Viro <viro@zeniv.linux.org.uk>
Date: Fri, 21 Aug 2020 00:37:30 +0100

> On Thu, Aug 20, 2020 at 03:51:22PM -0700, David Miller wrote:
>> From: Al Viro <viro@zeniv.linux.org.uk>
>> Date: Thu, 20 Aug 2020 20:36:12 +0100
>> 
>> > 	We have
>> > asmlinkage void user_unaligned_trap(struct pt_regs *regs, unsigned int insn)
>> > {
>> >         enum direction dir;
>> > 
>> >         if(!(current->thread.flags & SPARC_FLAG_UNALIGNED) ||
>> >            (((insn >> 30) & 3) != 3))
>> >                 goto kill_user;
>> > 
>> > there, followed by some work on emulating the insn.  So while the default
>> > behaviour is to hit the process with SIGBUS, it can overridden by setting
>> > SPARC_FLAG_UNALIGNED in current->thread.flags.  Fair enough, but...  Just
>> > what could possibly set that flag?
>> > 
>> > That stuff had been introduced back in 2.1.9 and even there (or through
>> > the 2.2, etc.) I don't see anything that would ever set it.
>> > 
>> > Am I missing something, or had it really been dead code all along?
>> 
>> Relic from the SunOS and/or Solaris syscall emulation probably.
> 
> Thought so, but...  no such thing in either.  And it's not done from assembler -
> arch/sparc64 used to access ->tss.flags that way (and that was only for
> SPARC_FLAG_NEWCHILD), but arch/sparc never did...
> 
> I don't have sunos toolchain to try and build such a binary and test it on
> a 2.2 kernel, but I would be rather surprised if that had been it.
> 
> Anyway, it really looks like that's dead code these days...

%100 it is dead code.

Re: [sparc32] userland unaligned access

[Al Viro]

On Thu, Aug 20, 2020 at 04:47:08PM -0700, David Miller wrote:

> > I don't have sunos toolchain to try and build such a binary and test it on
> > a 2.2 kernel, but I would be rather surprised if that had been it.
> > 
> > Anyway, it really looks like that's dead code these days...
> 
> %100 it is dead code.

	Could you check if you are OK with
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git #work.sparc?

Re: [sparc32] userland unaligned access

[David Miller]

From: Al Viro <viro@zeniv.linux.org.uk>
Date: Fri, 21 Aug 2020 01:00:02 +0100

> On Thu, Aug 20, 2020 at 04:47:08PM -0700, David Miller wrote:
> 
>> > I don't have sunos toolchain to try and build such a binary and test it on
>> > a 2.2 kernel, but I would be rather surprised if that had been it.
>> > 
>> > Anyway, it really looks like that's dead code these days...
>> 
>> %100 it is dead code.
> 
> 	Could you check if you are OK with
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git #work.sparc?

Looks good to me.

Re: [sparc32] userland unaligned access

[Steven Sistare]

On 8/20/2020 7:47 PM, David Miller wrote:
> From: Al Viro <viro@zeniv.linux.org.uk>
> Date: Fri, 21 Aug 2020 00:37:30 +0100
> 
>> On Thu, Aug 20, 2020 at 03:51:22PM -0700, David Miller wrote:
>>> From: Al Viro <viro@zeniv.linux.org.uk>
>>> Date: Thu, 20 Aug 2020 20:36:12 +0100
>>>
>>>> 	We have
>>>> asmlinkage void user_unaligned_trap(struct pt_regs *regs, unsigned int insn)
>>>> {
>>>>         enum direction dir;
>>>>
>>>>         if(!(current->thread.flags & SPARC_FLAG_UNALIGNED) ||
>>>>            (((insn >> 30) & 3) != 3))
>>>>                 goto kill_user;
>>>>
>>>> there, followed by some work on emulating the insn.  So while the default
>>>> behaviour is to hit the process with SIGBUS, it can overridden by setting
>>>> SPARC_FLAG_UNALIGNED in current->thread.flags.  Fair enough, but...  Just
>>>> what could possibly set that flag?
>>>>
>>>> That stuff had been introduced back in 2.1.9 and even there (or through
>>>> the 2.2, etc.) I don't see anything that would ever set it.
>>>>
>>>> Am I missing something, or had it really been dead code all along?
>>>
>>> Relic from the SunOS and/or Solaris syscall emulation probably.
>>
>> Thought so, but...  no such thing in either.  And it's not done from assembler -
>> arch/sparc64 used to access ->tss.flags that way (and that was only for
>> SPARC_FLAG_NEWCHILD), but arch/sparc never did...
>>
>> I don't have sunos toolchain to try and build such a binary and test it on
>> a 2.2 kernel, but I would be rather surprised if that had been it.
>>
>> Anyway, it really looks like that's dead code these days...
> 
> %100 it is dead code.

This flag would be enabled by trap ST_FIX_ALIGN, fast trap 6, defined
under Software Trap Types in SCD 2.4.  From the history, ttable_64.S has never
supported it.  Compilers are encouraged to instead support unaligned access
by installing a utrap handler and emulating in userland. Studio on Solaris
generated ST_FIX_ALIGN for 32-bit apps and utrap for 64 bit.

- Steve