[Linux-Xtensa] fixup handlers in fast_syscall_xtensa (and fast_syscall_spill_registers)

Marc Gauthier marc at cadence.com
Thu Aug 7 17:29:12 UTC 2014


The syscall-based atomic is mainly for configs without S32C1I.
This might come up mostly with uCLinux (which isn't maintained
for Xtensa at this time that I know of?), although it's possible
to configure a core with MMU but not S32C1I.  Linux compatibility
checking on the Xtensa Processor Generator requires configuring
S32C1I, so this isn't normally an issue for most customers.

-Marc


> -----Original Message-----
> From: Max Filippov [mailto:jcmvbkbc at gmail.com]
> Sent: Wednesday, August 06, 2014 16:48
> To: Chris Zankel
> Cc: linux-xtensa at linux-xtensa.org; Marc Gauthier
> Subject: Re: fixup handlers in fast_syscall_xtensa (and
> fast_syscall_spill_registers)
> 
> Hi Chris,
> 
> On Fri, Aug 1, 2014 at 5:53 AM, Max Filippov <jcmvbkbc at gmail.com>
> wrote:
> > On Fri, Aug 1, 2014 at 5:23 AM, Chris Zankel <chris at zankel.net>
> wrote:
> >> The other thing is that both system calls are somewhat deprecated,
> are they
> >> not?
> >
> > They look like that. There's no more users of it in the kernel, and
> the mainline
> > uClibc never used it. And I haven't been around long enough to know
> their
> > origin.
> >
> >>> Seems to me that we need to treat exceptions raised in fast
> handlers like
> >>> kernel exceptions, not like user. That will allow using pagefault
> handler
> >>> level
> >>> fixups and returning EINVAL from syscalls.
> >>> What do you think is the best way to handle this situation?
> >>
> >> It's definitely broken, so would be good to fix it. The options are:
> >>
> >> a. deprecate it and remove the code; if removed later, change the
> comment
> >
> > My favourite option (:
> 
> So I've sent a proposed patch where I put these syscalls under CONFIG_*
> symbols that will be disabled by default for new builds. So that people
> that
> might be using them are still able to use them, with their existing
> issues,
> and new kernels don't suffer from these issues and don't need
> complications
> related to delivery of signals raised in double exceptions only needed
> for
> these two syscalls.
> 
> --
> Thanks.
> -- Max


More information about the linux-xtensa mailing list