Re: [GIT] SPARC

[Konstantin Ryabitsev]

On Wed, Mar 10, 2021 at 11:40:47AM +0100, Geert Uytterhoeven wrote:
> > > (And yes, I prefer lore.kernel.org over marc, although for single
> > > patches it doesn't make much of a difference. For patch series, I find
> > > 'b4' so convenient that I definitely want the patch to show up on
> > > lore.kernel.org).
> >
> > Sadly, lore does not archive sparcli...@vger.kernel.org, so there
> > isn't much choice in this case.
> 
> Which is only an "ask Konstantin" (CCed) away, isn't it?

I'm in the process of creating the remainder of vger archives on lore, so it
would have happened anyway, but I'll bump sparclinux up in the queue.

Best,
-K

Re: [GIT] SPARC

[Geert Uytterhoeven]

Hi David,

Good to see you're back!

On Wed, Mar 10, 2021 at 1:27 AM David Miller  wrote:
> From: Linus Torvalds 
> Date: Tue, 9 Mar 2021 11:27:41 -0800
> > On Tue, Mar 9, 2021 at 11:08 AM David Miller  wrote:
> > (And yes, I prefer lore.kernel.org over marc, although for single
> > patches it doesn't make much of a difference. For patch series, I find
> > 'b4' so convenient that I definitely want the patch to show up on
> > lore.kernel.org).
>
> Sadly, lore does not archive sparcli...@vger.kernel.org, so there
> isn't much choice in this case.

Which is only an "ask Konstantin" (CCed) away, isn't it?

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [GIT] SPARC

[David Miller]

From: Linus Torvalds 
Date: Tue, 9 Mar 2021 17:17:24 -0800

> On Tue, Mar 9, 2021 at 5:15 PM David Miller  wrote:
>>
>> Somehow you pull didn't get commits:
> 
> Look closer at the pull date. That was before you had updated your branch.
> 
> I did a second pull just moments ago, I'll push it out (along with the
> networking one), after all my tests have passed.

Thank you.

Re: [GIT] SPARC

[Linus Torvalds]

On Tue, Mar 9, 2021 at 5:15 PM David Miller  wrote:
>
> Somehow you pull didn't get commits:

Look closer at the pull date. That was before you had updated your branch.

I did a second pull just moments ago, I'll push it out (along with the
networking one), after all my tests have passed.

Linus

Re: [GIT] SPARC

[David Miller]

From: David Miller 
Date: Tue, 09 Mar 2021 16:24:54 -0800 (PST)

> From: Linus Torvalds 
> Date: Tue, 9 Mar 2021 11:27:41 -0800
> 
>> On Tue, Mar 9, 2021 at 11:08 AM David Miller  wrote:
>> 
>> (And yes, I prefer lore.kernel.org over marc, although for single
>> patches it doesn't make much of a difference. For patch series, I find
>> 'b4' so convenient that I definitely want the patch to show up on
>> lore.kernel.org).
> 
> Sadly, lore does not archive sparcli...@vger.kernel.org, so there
> isn't much choice in this case.
>> 
>> I'll await your pull request or 'I have nothing else, take it from
>> xyz', this thread is otherwise archived for me as "done".
> 
> I added Rob's fix to the tree, here is a new pull request, thanks!
> 
> The following changes since commit 062c84fccc805738d76a2699c4d3c95184ec:
> 
>   Merge tag 'rproc-v5.12' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc 
> (2021-02-24 11:30:13 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org:/pub/scm/linux/kernel/git/davem/sparc.git 
> 

Somehow you pull didn't get commits:

commit 69264b4a43aff7307283e2bae29e9305ab6b7d47 (HEAD -> master, origin/master, 
origin/HEAD)
Author: Corentin Labbe 
Date:   Mon Mar 8 09:51:26 2021 +

sparc: sparc64_defconfig: remove duplicate CONFIGs

After my patch there is CONFIG_ATA defined twice.
Remove the duplicate one.
Same problem for CONFIG_HAPPYMEAL, except I added as builtin for boot
test with NFS.

Reported-by: Stephen Rothwell 
Fixes: a57cdeb369ef ("sparc: sparc64_defconfig: add necessary configs for 
qemu")
Signed-off-by: Corentin Labbe 
Signed-off-by: David S. Miller 

commit e5e8b80d352ec999d2bba3ea584f541c83f4ca3f
Author: Rob Gardner 
Date:   Sun Feb 28 22:48:16 2021 -0700

sparc64: Fix opcode filtering in handling of no fault loads

is_no_fault_exception() has two bugs which were discovered via random
opcode testing with stress-ng. Both are caused by improper filtering
of opcodes.

The first bug can be triggered by a floating point store with a no-fault
ASI, for instance "sta %f0, [%g0] #ASI_PNF", opcode C1A01040.

The code first tests op3[5] (0x100), which denotes a floating
point instruction, and then tests op3[2] (0x20), which denotes a
store instruction. But these bits are not mutually exclusive, and the
above mentioned opcode has both bits set. The intent is to filter out
stores, so the test for stores must be done first in order to have
any effect.

The second bug can be triggered by a floating point load with one of
the invalid ASI values 0x8e or 0x8f, which pass this check in
is_no_fault_exception():
 if ((asi & 0xf2) == ASI_PNF)

An example instruction is "ldqa [%l7 + %o7] #ASI 0x8f, %f38",
opcode CF95D1EF. Asi values greater than 0x8b (ASI_SNFL) are fatal
in handle_ldf_stq(), and is_no_fault_exception() must not allow these
invalid asi values to make it that far.

In both of these cases, handle_ldf_stq() reacts by calling
sun4v_data_access_exception() or spitfire_data_access_exception(),
which call is_no_fault_exception() and results in an infinite
recursion.

Signed-off-by: Rob Gardner 
Tested-by: Anatoly Pugachev 

Can you repull to get them, thanks.

Re: [GIT] SPARC

[David Miller]

From: Linus Torvalds 
Date: Tue, 9 Mar 2021 11:27:41 -0800

> On Tue, Mar 9, 2021 at 11:08 AM David Miller  wrote:
> 
> (And yes, I prefer lore.kernel.org over marc, although for single
> patches it doesn't make much of a difference. For patch series, I find
> 'b4' so convenient that I definitely want the patch to show up on
> lore.kernel.org).

Sadly, lore does not archive sparcli...@vger.kernel.org, so there
isn't much choice in this case.
> 
> I'll await your pull request or 'I have nothing else, take it from
> xyz', this thread is otherwise archived for me as "done".

I added Rob's fix to the tree, here is a new pull request, thanks!

The following changes since commit 062c84fccc805738d76a2699c4d3c95184ec:

  Merge tag 'rproc-v5.12' of 
git://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc (2021-02-24 
11:30:13 -0800)

are available in the Git repository at:

  git://git.kernel.org:/pub/scm/linux/kernel/git/davem/sparc.git 

for you to fetch changes up to 69264b4a43aff7307283e2bae29e9305ab6b7d47:

  sparc: sparc64_defconfig: remove duplicate CONFIGs (2021-03-09 16:22:40 -0800)


Al Viro (10):
  sparc32: don't bother with lookup_fault() in __bzero()
  sparc32: kill lookup_fault()
  sparc32: switch __bzero() away from range exception table entries
  sparc32: get rid of range exception table entries in checksum_32.S
  sparc32: switch copy_user.S away from range exception table entries
  sparc32: switch to generic extables
  Merge remote-tracking branch 'sparc/master' into work.sparc32
  sparc64: get rid of fake_swapper_regs
  sparc32: get rid of fake_swapper_regs
  sparc32: take ->thread.flags out

Corentin Labbe (1):
  sparc: sparc64_defconfig: remove duplicate CONFIGs

David S. Miller (2):
  Merge branch 'work.sparc' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
  Merge branch 'work.sparc32' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs

Rob Gardner (1):
  sparc64: Fix opcode filtering in handling of no fault loads

 arch/sparc/configs/sparc64_defconfig   |   4 +-
 arch/sparc/include/asm/elf_64.h|   1 -
 arch/sparc/include/asm/{extable_64.h => extable.h} |   4 +-
 arch/sparc/include/asm/processor_32.h  |   6 +-
 arch/sparc/include/asm/thread_info_64.h|   1 +
 arch/sparc/include/asm/uaccess.h   |   3 +
 arch/sparc/include/asm/uaccess_32.h|  38 --
 arch/sparc/include/asm/uaccess_64.h|   1 -
 arch/sparc/kernel/head_32.S|   2 +-
 arch/sparc/kernel/head_64.S|   2 +-
 arch/sparc/kernel/process_32.c |  12 
 arch/sparc/kernel/setup_32.c   |   3 -
 arch/sparc/kernel/setup_64.c   |   4 --
 arch/sparc/kernel/traps_64.c   |  13 ++--
 arch/sparc/kernel/unaligned_32.c   | 106 
++-
 arch/sparc/lib/checksum_32.S   |  64 +++--
 arch/sparc/lib/copy_user.S | 315 
+
 arch/sparc/lib/memset.S|  87 
+--
 arch/sparc/mm/Makefile |   2 +-
 arch/sparc/mm/extable.c| 107 

 arch/sparc/mm/fault_32.c   |  80 +++--
 arch/sparc/mm/mm_32.h  |   2 -
 lib/extable.c  |   5 --
 23 files changed, 205 insertions(+), 657 deletions(-)
 rename arch/sparc/include/asm/{extable_64.h => extable.h} (92%)
 delete mode 100644 arch/sparc/mm/extable.c

Re: [GIT] SPARC

[Linus Torvalds]

On Tue, Mar 9, 2021 at 11:08 AM David Miller  wrote:
>
> I'll make sure that gets into my next pull req, thanks.

Note that it's obviously always easiest for me to just ignore
something like sparc entirely, but on the other hand, particularly for
low-volume trees it's also ok to just say "I don't have anything
pending, here's the link to lore.kernel.org, can you apply that one
patch directly".

(And yes, I prefer lore.kernel.org over marc, although for single
patches it doesn't make much of a difference. For patch series, I find
'b4' so convenient that I definitely want the patch to show up on
lore.kernel.org).

I'll await your pull request or 'I have nothing else, take it from
xyz', this thread is otherwise archived for me as "done".

  Linus

Re: [GIT] SPARC

[David Miller]

From: John Paul Adrian Glaubitz 
Date: Tue, 9 Mar 2021 01:19:05 +0100

> Hi Dave!
> 
> On 3/9/21 12:46 AM, David Miller wrote:
>> Just some more random bits from Al,  including a conversion over to generic 
>> exytables.
> 
> Is there a chance we could include this important fix by Rob Gardner for 5.12 
> as well?
> 
>> https://marc.info/?l=linux-sparc=161457847223456=2
> 
> It fixes a hard kernel crash under certain loads which we have seen in Debian 
> quite frequently.

I'll ake sure that gets into my next pull req, thanks.

Re: [GIT] SPARC

[John Paul Adrian Glaubitz]

Hi Dave!

On 3/9/21 12:46 AM, David Miller wrote:
> Just some more random bits from Al,  including a conversion over to generic 
> exytables.

Is there a chance we could include this important fix by Rob Gardner for 5.12 
as well?

> https://marc.info/?l=linux-sparc=161457847223456=2

It fixes a hard kernel crash under certain loads which we have seen in Debian 
quite frequently.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [GIT] Sparc

[pr-tracker-bot]

The pull request you sent on Tue, 23 Feb 2021 13:21:26 -0800 (PST):

> git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git 
> refs/heads/master

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6dd580b93da8de5cab4ac1f24f343086318b664e

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT] Sparc

[pr-tracker-bot]

The pull request you sent on Sun, 07 Jun 2020 17:16:18 -0700 (PDT):

> git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next 
> refs/heads/master

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/52e0ad262cd76696e8cd8510944b0bfdc0c140a9

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT] Sparc

[pr-tracker-bot]

The pull request you sent on Fri, 12 Jul 2019 23:17:42 -0700 (PDT):

> git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git 
> refs/heads/master

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ec9249752465b87b5b26d03f476eebaf872ebd12

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT] Sparc

[pr-tracker-bot]

The pull request you sent on Sun, 02 Jun 2019 22:21:07 -0700 (PDT):

> git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git 
> refs/heads/master

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/01e7a841b4346836f19b40677e1fef4657cc0d0d

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT] Sparc

[pr-tracker-bot]

The pull request you sent on Thu, 09 May 2019 14:35:31 -0700 (PDT):

> git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git 
> refs/heads/master

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9b6c9e96f941c5ab13dad7278a3622f58e5672fc

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT] Sparc

[pr-tracker-bot]

The pull request you sent on Sat, 22 Dec 2018 15:46:26 -0800 (PST):

> git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next.git master

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c2f1f3e0e17d94ab0c66d83e669492cb9e9a3698

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT] Sparc

[pr-tracker-bot]

The pull request you sent on Fri, 21 Dec 2018 12:42:43 -0800 (PST):

> git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git master

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6cafab50eea327e0d198cc9579a60440fc959756

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT] Sparc

[pr-tracker-bot]

The pull request you sent on Sun, 02 Dec 2018 21:33:11 -0800 (PST):

> git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git master

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9099ff769faf879b5cb6e24e04c7904a8352aef0

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT] Sparc

[pr-tracker-bot]

The pull request you sent on Sun, 02 Dec 2018 21:33:11 -0800 (PST):

> git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git master

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9099ff769faf879b5cb6e24e04c7904a8352aef0

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT] Sparc

[Linus Torvalds]

On Wed, Oct 31, 2018 at 6:44 PM David Miller  wrote:
>
> Two small fixes, please pull.

Pulled,

Linus

Re: [GIT] Sparc

[Linus Torvalds]

On Wed, Oct 31, 2018 at 6:44 PM David Miller  wrote:
>
> Two small fixes, please pull.

Pulled,

Linus

Re: [GIT] Sparc

[Linus Torvalds]

On Fri, Oct 26, 2018 at 4:08 PM David Miller  wrote:
>
> Some more sparc fixups, mostly aimed at getting the allmodconfig build
> up and clean again.

Pulled,

  Linus

Re: [GIT] Sparc

[Linus Torvalds]

On Fri, Oct 26, 2018 at 4:08 PM David Miller  wrote:
>
> Some more sparc fixups, mostly aimed at getting the allmodconfig build
> up and clean again.

Pulled,

  Linus

Re: [GIT] Sparc

[Linus Torvalds]

On Thu, Oct 25, 2018 at 11:28 AM David Miller  wrote:
>
> Please pull to get this build regression fix.

Pulled,

  Linus

Re: [GIT] Sparc

[Linus Torvalds]

On Thu, Oct 25, 2018 at 11:28 AM David Miller  wrote:
>
> Please pull to get this build regression fix.

Pulled,

  Linus

Re: [GIT] Sparc

[Linus Torvalds]

On Wed, Oct 24, 2018 at 4:31 AM David Miller  wrote:
>
> Mostly VDSO cleanups and optimizations.

Pulled,

  Linus

Re: [GIT] Sparc

[Linus Torvalds]

On Wed, Oct 24, 2018 at 4:31 AM David Miller  wrote:
>
> Mostly VDSO cleanups and optimizations.

Pulled,

  Linus

Re: [GIT] Sparc

[Greg KH]

On Thu, Oct 18, 2018 at 04:33:23PM -0700, David Miller wrote:
> 
> The main bit here is fixing how fallback system calls are handled in
> the sparc vDSO.
> 
> Unfortunately, I fat fingered the commit and some perf debugging hacks
> slipped into the vDSO fix, which I revert in the very next commit.
> 
> Please pull, thanks a lot!
> 
> The following changes since commit c343db455eb3105f11bb5ac290d77ab2006b0209:
> 
>   Merge branch 'parisc-4.19-3' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux (2018-10-17 
> 14:01:00 +0200)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git 

Now merged, thanks.

greg k-h

Re: [GIT] Sparc

[Greg KH]

On Thu, Oct 18, 2018 at 04:33:23PM -0700, David Miller wrote:
> 
> The main bit here is fixing how fallback system calls are handled in
> the sparc vDSO.
> 
> Unfortunately, I fat fingered the commit and some perf debugging hacks
> slipped into the vDSO fix, which I revert in the very next commit.
> 
> Please pull, thanks a lot!
> 
> The following changes since commit c343db455eb3105f11bb5ac290d77ab2006b0209:
> 
>   Merge branch 'parisc-4.19-3' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux (2018-10-17 
> 14:01:00 +0200)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git 

Now merged, thanks.

greg k-h

Re: [GIT] Sparc

[Greg KH]

On Mon, Oct 15, 2018 at 07:39:45PM -0700, David Miller wrote:
> 
> 1) Revert the %pOF change, it causes regressions.
> 
> 2) Wire up io_pgetevents().
> 
> 3) Fix perf events on single-PCR sparc64 cpus.
> 
> 4) Do proper perf event throttling like arm and x86.
> 
> Please pull, thanks a lot!
> 
> The following changes since commit 0854ba5ff5c938307cd783e996b62c83f1ce923b:
> 
>   Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc (2018-10-08 
> 16:25:01 +0200)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git 

Now merged, thanks.

greg k-h

Re: [GIT] Sparc

[Greg KH]

On Mon, Oct 15, 2018 at 07:39:45PM -0700, David Miller wrote:
> 
> 1) Revert the %pOF change, it causes regressions.
> 
> 2) Wire up io_pgetevents().
> 
> 3) Fix perf events on single-PCR sparc64 cpus.
> 
> 4) Do proper perf event throttling like arm and x86.
> 
> Please pull, thanks a lot!
> 
> The following changes since commit 0854ba5ff5c938307cd783e996b62c83f1ce923b:
> 
>   Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc (2018-10-08 
> 16:25:01 +0200)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git 

Now merged, thanks.

greg k-h

Re: [GIT] Sparc

[Greg KH]

On Sun, Oct 07, 2018 at 11:48:32PM -0700, David Miller wrote:
> 
> I've been moving so haven't had access to my Sparc boxes during this
> time.  That's been resolved, and now I can get the patches flowing
> again.
> 
> 1) Minor fallthru comment tweaks from Gustavo A. R. Silva.
> 
> 2) VLA removal from Kees Cook.
> 
> 3) Make sparc vdso Makefile match x86, from Masahiro Yamada.
> 
> 4) Fix clock divider programming in mach64 driver, from Mikulas
>Patocka.
> 
> Please pull, thanks a lot!
> 
> The following changes since commit c1d84a1b42ef70d8ae601df9cadedc7ed4f1beb1:
> 
>   Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2018-10-06 
> 02:11:30 -0700)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git 

Now merged, thanks.

greg k-h

Re: [GIT] Sparc

[Greg KH]

On Sun, Oct 07, 2018 at 11:48:32PM -0700, David Miller wrote:
> 
> I've been moving so haven't had access to my Sparc boxes during this
> time.  That's been resolved, and now I can get the patches flowing
> again.
> 
> 1) Minor fallthru comment tweaks from Gustavo A. R. Silva.
> 
> 2) VLA removal from Kees Cook.
> 
> 3) Make sparc vdso Makefile match x86, from Masahiro Yamada.
> 
> 4) Fix clock divider programming in mach64 driver, from Mikulas
>Patocka.
> 
> Please pull, thanks a lot!
> 
> The following changes since commit c1d84a1b42ef70d8ae601df9cadedc7ed4f1beb1:
> 
>   Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2018-10-06 
> 02:11:30 -0700)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git 

Now merged, thanks.

greg k-h

Re: [GIT] Sparc

[David Miller]

Of course this should have been "[GIT] Networking", sigh...

Re: [GIT] Sparc

[David Miller]

Of course this should have been "[GIT] Networking", sigh...

Re: [GIT] Sparc

[Julia Lawall]

On Sat, 7 Nov 2015, Julian Calaby wrote:

> Hi Julia,
> 
> On Fri, Nov 6, 2015 at 5:44 PM, Julia Lawall  wrote:
> > On Fri, 6 Nov 2015, Julian Calaby wrote:
> >
> >> Hi Linus,
> >>
> >> On Fri, Nov 6, 2015 at 11:56 AM, Linus Torvalds
> >>  wrote:
> >> > On Thu, Nov 5, 2015 at 4:43 PM, Linus Torvalds
> >> >  wrote:
> >> >>
> >> >> Not that this *matters*, but it's a bit odd to have to cast constants
> >> >> to perfectly regular C types.
> >> >
> >> > Looking around with "git grep", there's a few more of these.
> >> >
> >> >  - btrfs seems to like "(unsigned long)-1"
> >> >
> >> >There's a few other users of that too, including more sparc uses.
> >> >
> >> >  - scsi/qla seems to like "(unsigned long)"
> >> >
> >> >  - fmdrv_common.h seems to like "((unsigned long)1< >> >
> >> > along with a smattering of random noise all over of "(unsigned long)
> >> > n" where 'n' is some integer.
> >> >
> >> > Apparently people aren't as aware of the normal "ul" postfix syntax as
> >> > I would have expected. That said, it's a hundred-odd cases in all of
> >> > the kernel, so it's still fairly rare.
> >>
> >> Maybe this is something the kernel-janitors team should look at? (CC'd)
> >
> > Do you have some concrete examples of the code that is undesirable?
> 
> Joe Perches produced a patch for checkpatch to check for this [1]
> 
> Linus was complaining [2] about people producing constants with casts
> to basic C types in them. For instance:
> 
> #define IOMMU_ERROR_CODE (~(unsigned long) 0)
> 
> This could be replaced with
> 
> #define IOMMU_ERROR_CODE (~0ul)
> 
> or potentially
> 
> #define IOMMU_ERROR_CODE (-1ul)
> 
> It's not overly common, but it looks wrong.

Thanks.  The checkpatch solution indeed looks fine in this case.

julia

> Thanks,
> 
> Julian Calaby
> 
> [1] https://lkml.org/lkml/2015/11/6/48
> [2] https://lkml.org/lkml/2015/11/5/785
> 
> -- 
> Julian Calaby
> 
> Email: julian.cal...@gmail.com
> Profile: http://www.google.com/profiles/julian.calaby/
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Julian Calaby]

Hi Julia,

On Fri, Nov 6, 2015 at 5:44 PM, Julia Lawall  wrote:
> On Fri, 6 Nov 2015, Julian Calaby wrote:
>
>> Hi Linus,
>>
>> On Fri, Nov 6, 2015 at 11:56 AM, Linus Torvalds
>>  wrote:
>> > On Thu, Nov 5, 2015 at 4:43 PM, Linus Torvalds
>> >  wrote:
>> >>
>> >> Not that this *matters*, but it's a bit odd to have to cast constants
>> >> to perfectly regular C types.
>> >
>> > Looking around with "git grep", there's a few more of these.
>> >
>> >  - btrfs seems to like "(unsigned long)-1"
>> >
>> >There's a few other users of that too, including more sparc uses.
>> >
>> >  - scsi/qla seems to like "(unsigned long)"
>> >
>> >  - fmdrv_common.h seems to like "((unsigned long)1<> >
>> > along with a smattering of random noise all over of "(unsigned long)
>> > n" where 'n' is some integer.
>> >
>> > Apparently people aren't as aware of the normal "ul" postfix syntax as
>> > I would have expected. That said, it's a hundred-odd cases in all of
>> > the kernel, so it's still fairly rare.
>>
>> Maybe this is something the kernel-janitors team should look at? (CC'd)
>
> Do you have some concrete examples of the code that is undesirable?

Joe Perches produced a patch for checkpatch to check for this [1]

Linus was complaining [2] about people producing constants with casts
to basic C types in them. For instance:

#define IOMMU_ERROR_CODE (~(unsigned long) 0)

This could be replaced with

#define IOMMU_ERROR_CODE (~0ul)

or potentially

#define IOMMU_ERROR_CODE (-1ul)

It's not overly common, but it looks wrong.

Thanks,

Julian Calaby

[1] https://lkml.org/lkml/2015/11/6/48
[2] https://lkml.org/lkml/2015/11/5/785

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Julian Calaby]

Hi Julia,

On Fri, Nov 6, 2015 at 5:44 PM, Julia Lawall  wrote:
> On Fri, 6 Nov 2015, Julian Calaby wrote:
>
>> Hi Linus,
>>
>> On Fri, Nov 6, 2015 at 11:56 AM, Linus Torvalds
>>  wrote:
>> > On Thu, Nov 5, 2015 at 4:43 PM, Linus Torvalds
>> >  wrote:
>> >>
>> >> Not that this *matters*, but it's a bit odd to have to cast constants
>> >> to perfectly regular C types.
>> >
>> > Looking around with "git grep", there's a few more of these.
>> >
>> >  - btrfs seems to like "(unsigned long)-1"
>> >
>> >There's a few other users of that too, including more sparc uses.
>> >
>> >  - scsi/qla seems to like "(unsigned long)"
>> >
>> >  - fmdrv_common.h seems to like "((unsigned long)1<> >
>> > along with a smattering of random noise all over of "(unsigned long)
>> > n" where 'n' is some integer.
>> >
>> > Apparently people aren't as aware of the normal "ul" postfix syntax as
>> > I would have expected. That said, it's a hundred-odd cases in all of
>> > the kernel, so it's still fairly rare.
>>
>> Maybe this is something the kernel-janitors team should look at? (CC'd)
>
> Do you have some concrete examples of the code that is undesirable?

Joe Perches produced a patch for checkpatch to check for this [1]

Linus was complaining [2] about people producing constants with casts
to basic C types in them. For instance:

#define IOMMU_ERROR_CODE (~(unsigned long) 0)

This could be replaced with

#define IOMMU_ERROR_CODE (~0ul)

or potentially

#define IOMMU_ERROR_CODE (-1ul)

It's not overly common, but it looks wrong.

Thanks,

Julian Calaby

[1] https://lkml.org/lkml/2015/11/6/48
[2] https://lkml.org/lkml/2015/11/5/785

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Julia Lawall]

On Sat, 7 Nov 2015, Julian Calaby wrote:

> Hi Julia,
> 
> On Fri, Nov 6, 2015 at 5:44 PM, Julia Lawall  wrote:
> > On Fri, 6 Nov 2015, Julian Calaby wrote:
> >
> >> Hi Linus,
> >>
> >> On Fri, Nov 6, 2015 at 11:56 AM, Linus Torvalds
> >>  wrote:
> >> > On Thu, Nov 5, 2015 at 4:43 PM, Linus Torvalds
> >> >  wrote:
> >> >>
> >> >> Not that this *matters*, but it's a bit odd to have to cast constants
> >> >> to perfectly regular C types.
> >> >
> >> > Looking around with "git grep", there's a few more of these.
> >> >
> >> >  - btrfs seems to like "(unsigned long)-1"
> >> >
> >> >There's a few other users of that too, including more sparc uses.
> >> >
> >> >  - scsi/qla seems to like "(unsigned long)"
> >> >
> >> >  - fmdrv_common.h seems to like "((unsigned long)1< >> >
> >> > along with a smattering of random noise all over of "(unsigned long)
> >> > n" where 'n' is some integer.
> >> >
> >> > Apparently people aren't as aware of the normal "ul" postfix syntax as
> >> > I would have expected. That said, it's a hundred-odd cases in all of
> >> > the kernel, so it's still fairly rare.
> >>
> >> Maybe this is something the kernel-janitors team should look at? (CC'd)
> >
> > Do you have some concrete examples of the code that is undesirable?
> 
> Joe Perches produced a patch for checkpatch to check for this [1]
> 
> Linus was complaining [2] about people producing constants with casts
> to basic C types in them. For instance:
> 
> #define IOMMU_ERROR_CODE (~(unsigned long) 0)
> 
> This could be replaced with
> 
> #define IOMMU_ERROR_CODE (~0ul)
> 
> or potentially
> 
> #define IOMMU_ERROR_CODE (-1ul)
> 
> It's not overly common, but it looks wrong.

Thanks.  The checkpatch solution indeed looks fine in this case.

julia

> Thanks,
> 
> Julian Calaby
> 
> [1] https://lkml.org/lkml/2015/11/6/48
> [2] https://lkml.org/lkml/2015/11/5/785
> 
> -- 
> Julian Calaby
> 
> Email: julian.cal...@gmail.com
> Profile: http://www.google.com/profiles/julian.calaby/
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Julia Lawall]

On Fri, 6 Nov 2015, Julian Calaby wrote:

> Hi Linus,
> 
> On Fri, Nov 6, 2015 at 11:56 AM, Linus Torvalds
>  wrote:
> > On Thu, Nov 5, 2015 at 4:43 PM, Linus Torvalds
> >  wrote:
> >>
> >> Not that this *matters*, but it's a bit odd to have to cast constants
> >> to perfectly regular C types.
> >
> > Looking around with "git grep", there's a few more of these.
> >
> >  - btrfs seems to like "(unsigned long)-1"
> >
> >There's a few other users of that too, including more sparc uses.
> >
> >  - scsi/qla seems to like "(unsigned long)"
> >
> >  - fmdrv_common.h seems to like "((unsigned long)1< >
> > along with a smattering of random noise all over of "(unsigned long)
> > n" where 'n' is some integer.
> >
> > Apparently people aren't as aware of the normal "ul" postfix syntax as
> > I would have expected. That said, it's a hundred-odd cases in all of
> > the kernel, so it's still fairly rare.
> 
> Maybe this is something the kernel-janitors team should look at? (CC'd)

Do you have some concrete examples of the code that is undesirable?

thanks,
julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[David Miller]

From: Linus Torvalds 
Date: Thu, 5 Nov 2015 16:43:52 -0800

> On Thu, Nov 5, 2015 at 1:39 PM, David Miller  wrote:
>>
>> 5) Fix iommu-common code so it doesn't emit rediculous warnings
>>on some architectures, particularly ARM.
> 
> Heh. So looking at that patch, I can't but help to react that this:
> 
>   #define IOMMU_ERROR_CODE   (~(unsigned long) 0)
> 
> is still pretty ridiculous.  Maybe just (-1ul), or for those people
> who don't understand C unsigned long arithmetic and think that a
> negative unsigned long looks odd, (~0ul)?

Yeah I struggled with this, believe it or not.

The expression causing the problem was (~(dma_addr_t) 0) (AKA
DMA_ERROR_CODE) being used as the return value.

So I just replicated that expression.  A neuron did fire saying "hey
pinhead, why not just use ~0UL" but I did not listen to the little
voice in my head this time.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Julian Calaby]

Hi Linus,

On Fri, Nov 6, 2015 at 11:56 AM, Linus Torvalds
 wrote:
> On Thu, Nov 5, 2015 at 4:43 PM, Linus Torvalds
>  wrote:
>>
>> Not that this *matters*, but it's a bit odd to have to cast constants
>> to perfectly regular C types.
>
> Looking around with "git grep", there's a few more of these.
>
>  - btrfs seems to like "(unsigned long)-1"
>
>There's a few other users of that too, including more sparc uses.
>
>  - scsi/qla seems to like "(unsigned long)"
>
>  - fmdrv_common.h seems to like "((unsigned long)1<
> along with a smattering of random noise all over of "(unsigned long)
> n" where 'n' is some integer.
>
> Apparently people aren't as aware of the normal "ul" postfix syntax as
> I would have expected. That said, it's a hundred-odd cases in all of
> the kernel, so it's still fairly rare.

Maybe this is something the kernel-janitors team should look at? (CC'd)

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Linus Torvalds]

On Thu, Nov 5, 2015 at 4:43 PM, Linus Torvalds
 wrote:
>
> Not that this *matters*, but it's a bit odd to have to cast constants
> to perfectly regular C types.

Looking around with "git grep", there's a few more of these.

 - btrfs seems to like "(unsigned long)-1"

   There's a few other users of that too, including more sparc uses.

 - scsi/qla seems to like "(unsigned long)"

 - fmdrv_common.h seems to like "((unsigned long)1

Re: [GIT] Sparc

[Linus Torvalds]

On Thu, Nov 5, 2015 at 1:39 PM, David Miller  wrote:
>
> 5) Fix iommu-common code so it doesn't emit rediculous warnings
>on some architectures, particularly ARM.

Heh. So looking at that patch, I can't but help to react that this:

  #define IOMMU_ERROR_CODE   (~(unsigned long) 0)

is still pretty ridiculous.  Maybe just (-1ul), or for those people
who don't understand C unsigned long arithmetic and think that a
negative unsigned long looks odd, (~0ul)?

Not that this *matters*, but it's a bit odd to have to cast constants
to perfectly regular C types.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Linus Torvalds]

On Thu, Nov 5, 2015 at 1:39 PM, David Miller  wrote:
>
> 5) Fix iommu-common code so it doesn't emit rediculous warnings
>on some architectures, particularly ARM.

Heh. So looking at that patch, I can't but help to react that this:

  #define IOMMU_ERROR_CODE   (~(unsigned long) 0)

is still pretty ridiculous.  Maybe just (-1ul), or for those people
who don't understand C unsigned long arithmetic and think that a
negative unsigned long looks odd, (~0ul)?

Not that this *matters*, but it's a bit odd to have to cast constants
to perfectly regular C types.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[David Miller]

From: Linus Torvalds 
Date: Thu, 5 Nov 2015 16:43:52 -0800

> On Thu, Nov 5, 2015 at 1:39 PM, David Miller  wrote:
>>
>> 5) Fix iommu-common code so it doesn't emit rediculous warnings
>>on some architectures, particularly ARM.
> 
> Heh. So looking at that patch, I can't but help to react that this:
> 
>   #define IOMMU_ERROR_CODE   (~(unsigned long) 0)
> 
> is still pretty ridiculous.  Maybe just (-1ul), or for those people
> who don't understand C unsigned long arithmetic and think that a
> negative unsigned long looks odd, (~0ul)?

Yeah I struggled with this, believe it or not.

The expression causing the problem was (~(dma_addr_t) 0) (AKA
DMA_ERROR_CODE) being used as the return value.

So I just replicated that expression.  A neuron did fire saying "hey
pinhead, why not just use ~0UL" but I did not listen to the little
voice in my head this time.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Julian Calaby]

Hi Linus,

On Fri, Nov 6, 2015 at 11:56 AM, Linus Torvalds
 wrote:
> On Thu, Nov 5, 2015 at 4:43 PM, Linus Torvalds
>  wrote:
>>
>> Not that this *matters*, but it's a bit odd to have to cast constants
>> to perfectly regular C types.
>
> Looking around with "git grep", there's a few more of these.
>
>  - btrfs seems to like "(unsigned long)-1"
>
>There's a few other users of that too, including more sparc uses.
>
>  - scsi/qla seems to like "(unsigned long)"
>
>  - fmdrv_common.h seems to like "((unsigned long)1<
> along with a smattering of random noise all over of "(unsigned long)
> n" where 'n' is some integer.
>
> Apparently people aren't as aware of the normal "ul" postfix syntax as
> I would have expected. That said, it's a hundred-odd cases in all of
> the kernel, so it's still fairly rare.

Maybe this is something the kernel-janitors team should look at? (CC'd)

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Julia Lawall]

On Fri, 6 Nov 2015, Julian Calaby wrote:

> Hi Linus,
> 
> On Fri, Nov 6, 2015 at 11:56 AM, Linus Torvalds
>  wrote:
> > On Thu, Nov 5, 2015 at 4:43 PM, Linus Torvalds
> >  wrote:
> >>
> >> Not that this *matters*, but it's a bit odd to have to cast constants
> >> to perfectly regular C types.
> >
> > Looking around with "git grep", there's a few more of these.
> >
> >  - btrfs seems to like "(unsigned long)-1"
> >
> >There's a few other users of that too, including more sparc uses.
> >
> >  - scsi/qla seems to like "(unsigned long)"
> >
> >  - fmdrv_common.h seems to like "((unsigned long)1< >
> > along with a smattering of random noise all over of "(unsigned long)
> > n" where 'n' is some integer.
> >
> > Apparently people aren't as aware of the normal "ul" postfix syntax as
> > I would have expected. That said, it's a hundred-odd cases in all of
> > the kernel, so it's still fairly rare.
> 
> Maybe this is something the kernel-janitors team should look at? (CC'd)

Do you have some concrete examples of the code that is undesirable?

thanks,
julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Linus Torvalds]

On Thu, Nov 5, 2015 at 4:43 PM, Linus Torvalds
 wrote:
>
> Not that this *matters*, but it's a bit odd to have to cast constants
> to perfectly regular C types.

Looking around with "git grep", there's a few more of these.

 - btrfs seems to like "(unsigned long)-1"

   There's a few other users of that too, including more sparc uses.

 - scsi/qla seems to like "(unsigned long)"

 - fmdrv_common.h seems to like "((unsigned long)1<

Re: [GIT] Sparc

[David Miller]

From: Linus Torvalds 
Date: Mon, 23 Mar 2015 10:12:30 -0700

> Oh well. I'm actually somewhat surprised this didn't hit anything
> else. Doesn't networking also end up doing overlapping memmove() on
> the skb data occasionally?

The only case I can think of is when {en,de}capsulating VLANs in
software.

But those are really small header sized copies, and would never
trigger the unrolled loop which requires len >= 128.

A quick grep shows something similar for wireless WEP/WPA, but not
only are these small copies too but I don't have any wireless on
any of my sparc boxes :-)

It really is just SLAB/SLUB with large NR_CPU configurations.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[David Miller]

From: Linus Torvalds 
Date: Mon, 23 Mar 2015 10:05:10 -0700

> On Mon, Mar 23, 2015 at 9:55 AM, David Miller  wrote:
>>
>> Some perf bug fixes from David Ahern, and the fix for that nasty
>> memmove() bug.
> 
> That doesn't seem to be marked for stable? Or do you do the same thing
> as for networking, and just collect stable patches manually?

Yes, I do sparc stuff manually and queue it up at:

http://patchwork.ozlabs.org/bundle/davem/stable/?state=*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Linus Torvalds]

On Mon, Mar 23, 2015 at 10:05 AM, Linus Torvalds
 wrote:
> On Mon, Mar 23, 2015 at 9:55 AM, David Miller  wrote:
>>
>> Some perf bug fixes from David Ahern, and the fix for that nasty
>> memmove() bug.
>
> That doesn't seem to be marked for stable? Or do you do the same thing
> as for networking, and just collect stable patches manually?

Side note: the memmove commit message is a bit misleading. The old
code handled zero-length calls fine, even if it wasn't explicit: it
always called memmove() for that case.

The condition "dst <= src || src + len <= dst" ends up being always
true when len is zero (because it obviously ends up being "dst <= src
|| src <= dst").

So there was just one bug - the 64-byte overlap with the cacheline
establish for the destination. Even that cacheline establish would
have been ok if all the loads for the 64-byte block had been done
up-front.

Oh well. I'm actually somewhat surprised this didn't hit anything
else. Doesn't networking also end up doing overlapping memmove() on
the skb data occasionally?

   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Linus Torvalds]

On Mon, Mar 23, 2015 at 9:55 AM, David Miller  wrote:
>
> Some perf bug fixes from David Ahern, and the fix for that nasty
> memmove() bug.

That doesn't seem to be marked for stable? Or do you do the same thing
as for networking, and just collect stable patches manually?

Pulled,

   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[David Miller]

From: Linus Torvalds torva...@linux-foundation.org
Date: Mon, 23 Mar 2015 10:12:30 -0700

 Oh well. I'm actually somewhat surprised this didn't hit anything
 else. Doesn't networking also end up doing overlapping memmove() on
 the skb data occasionally?

The only case I can think of is when {en,de}capsulating VLANs in
software.

But those are really small header sized copies, and would never
trigger the unrolled loop which requires len = 128.

A quick grep shows something similar for wireless WEP/WPA, but not
only are these small copies too but I don't have any wireless on
any of my sparc boxes :-)

It really is just SLAB/SLUB with large NR_CPU configurations.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[David Miller]

From: Linus Torvalds torva...@linux-foundation.org
Date: Mon, 23 Mar 2015 10:05:10 -0700

 On Mon, Mar 23, 2015 at 9:55 AM, David Miller da...@davemloft.net wrote:

 Some perf bug fixes from David Ahern, and the fix for that nasty
 memmove() bug.
 
 That doesn't seem to be marked for stable? Or do you do the same thing
 as for networking, and just collect stable patches manually?

Yes, I do sparc stuff manually and queue it up at:

http://patchwork.ozlabs.org/bundle/davem/stable/?state=*
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Linus Torvalds]

On Mon, Mar 23, 2015 at 9:55 AM, David Miller da...@davemloft.net wrote:

 Some perf bug fixes from David Ahern, and the fix for that nasty
 memmove() bug.

That doesn't seem to be marked for stable? Or do you do the same thing
as for networking, and just collect stable patches manually?

Pulled,

   Linus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Linus Torvalds]

On Mon, Mar 23, 2015 at 10:05 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
 On Mon, Mar 23, 2015 at 9:55 AM, David Miller da...@davemloft.net wrote:

 Some perf bug fixes from David Ahern, and the fix for that nasty
 memmove() bug.

 That doesn't seem to be marked for stable? Or do you do the same thing
 as for networking, and just collect stable patches manually?

Side note: the memmove commit message is a bit misleading. The old
code handled zero-length calls fine, even if it wasn't explicit: it
always called memmove() for that case.

The condition dst = src || src + len = dst ends up being always
true when len is zero (because it obviously ends up being dst = src
|| src = dst).

So there was just one bug - the 64-byte overlap with the cacheline
establish for the destination. Even that cacheline establish would
have been ok if all the loads for the 64-byte block had been done
up-front.

Oh well. I'm actually somewhat surprised this didn't hit anything
else. Doesn't networking also end up doing overlapping memmove() on
the skb data occasionally?

   Linus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Steve Capper]

On Mon, Oct 27, 2014 at 06:43:27PM -0400, David Miller wrote:
> From: Andrew Morton 
> Date: Mon, 27 Oct 2014 14:09:38 -0700
> 
> > Perhaps sparc should be defining CONFIG_HAVE_GENERIC_RCU_GUP.
> > 
> > We really should switch x86 to the generic version - from a quick read
> > it looks like it will work without needing any changes.
> > 
> > Steve, thoughts?
> 
> We need to add the necessary hooks to the generic code so that x86
> doesn't so specualtive gets and instead do direct increments,
> otherwise it's a performance regression, and then sparc can make use
> of that as well.

Agreed, I think x86 may require a helper to read 64-bit ptes (as it
can't do that atomically). Also I think there's some subtlety in the
way access_ok works that should be checked.

The overall structure of the code looks the same to me, and I think it
would be beneficial to extend then use the generic version for x86.

Cheers,
-- 
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Steve Capper]

On Mon, Oct 27, 2014 at 06:43:27PM -0400, David Miller wrote:
 From: Andrew Morton a...@linux-foundation.org
 Date: Mon, 27 Oct 2014 14:09:38 -0700
 
  Perhaps sparc should be defining CONFIG_HAVE_GENERIC_RCU_GUP.
  
  We really should switch x86 to the generic version - from a quick read
  it looks like it will work without needing any changes.
  
  Steve, thoughts?
 
 We need to add the necessary hooks to the generic code so that x86
 doesn't so specualtive gets and instead do direct increments,
 otherwise it's a performance regression, and then sparc can make use
 of that as well.

Agreed, I think x86 may require a helper to read 64-bit ptes (as it
can't do that atomically). Also I think there's some subtlety in the
way access_ok works that should be checked.

The overall structure of the code looks the same to me, and I think it
would be beneficial to extend then use the generic version for x86.

Cheers,
-- 
Steve
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[David Miller]

From: Andrew Morton 
Date: Mon, 27 Oct 2014 14:09:38 -0700

> Perhaps sparc should be defining CONFIG_HAVE_GENERIC_RCU_GUP.
> 
> We really should switch x86 to the generic version - from a quick read
> it looks like it will work without needing any changes.
> 
> Steve, thoughts?

We need to add the necessary hooks to the generic code so that x86
doesn't so specualtive gets and instead do direct increments,
otherwise it's a performance regression, and then sparc can make use
of that as well.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Andrew Morton]

On Fri, 24 Oct 2014 12:47:48 -0700 Linus Torvalds 
 wrote:

> On Fri, Oct 24, 2014 at 10:32 AM, David Miller  wrote:
> >
> >It's really idiotic to have a weak symbolled fallback that just
> >returns zero, and causes this kind of bug.  There should be no
> >backup implementation and the link should fail if the architecture
> >fails to provide __get_user_pages_fast() and supports transparent
> >hugepages.
> 
> Agreed. I think the weak fallback is for the "no hugepages support"
> case, but that does sound very annoying and fragile.
> 

Yup.  I'm thinking the get_user_pages_fast() and
__get_user_pages_fast() in mm/util.c should be made non-weak and moved
to mm/nommu.c.

With that change, MMU architctures will need to either define
CONFIG_HAVE_GENERIC_RCU_GUP or implement their own versions.

Perhaps sparc should be defining CONFIG_HAVE_GENERIC_RCU_GUP.

We really should switch x86 to the generic version - from a quick read
it looks like it will work without needing any changes.

Steve, thoughts?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Andrew Morton]

On Fri, 24 Oct 2014 12:47:48 -0700 Linus Torvalds 
torva...@linux-foundation.org wrote:

 On Fri, Oct 24, 2014 at 10:32 AM, David Miller da...@davemloft.net wrote:
 
 It's really idiotic to have a weak symbolled fallback that just
 returns zero, and causes this kind of bug.  There should be no
 backup implementation and the link should fail if the architecture
 fails to provide __get_user_pages_fast() and supports transparent
 hugepages.
 
 Agreed. I think the weak fallback is for the no hugepages support
 case, but that does sound very annoying and fragile.
 

Yup.  I'm thinking the get_user_pages_fast() and
__get_user_pages_fast() in mm/util.c should be made non-weak and moved
to mm/nommu.c.

With that change, MMU architctures will need to either define
CONFIG_HAVE_GENERIC_RCU_GUP or implement their own versions.

Perhaps sparc should be defining CONFIG_HAVE_GENERIC_RCU_GUP.

We really should switch x86 to the generic version - from a quick read
it looks like it will work without needing any changes.

Steve, thoughts?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[David Miller]

From: Andrew Morton a...@linux-foundation.org
Date: Mon, 27 Oct 2014 14:09:38 -0700

 Perhaps sparc should be defining CONFIG_HAVE_GENERIC_RCU_GUP.
 
 We really should switch x86 to the generic version - from a quick read
 it looks like it will work without needing any changes.
 
 Steve, thoughts?

We need to add the necessary hooks to the generic code so that x86
doesn't so specualtive gets and instead do direct increments,
otherwise it's a performance regression, and then sparc can make use
of that as well.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Linus Torvalds]

On Fri, Oct 24, 2014 at 10:32 AM, David Miller  wrote:
>
>It's really idiotic to have a weak symbolled fallback that just
>returns zero, and causes this kind of bug.  There should be no
>backup implementation and the link should fail if the architecture
>fails to provide __get_user_pages_fast() and supports transparent
>hugepages.

Agreed. I think the weak fallback is for the "no hugepages support"
case, but that does sound very annoying and fragile.

   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Linus Torvalds]

On Fri, Oct 24, 2014 at 10:32 AM, David Miller da...@davemloft.net wrote:

It's really idiotic to have a weak symbolled fallback that just
returns zero, and causes this kind of bug.  There should be no
backup implementation and the link should fail if the architecture
fails to provide __get_user_pages_fast() and supports transparent
hugepages.

Agreed. I think the weak fallback is for the no hugepages support
case, but that does sound very annoying and fragile.

   Linus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[David Miller]

From: Dave Jones 
Date: Tue, 6 May 2014 12:29:46 -0400

> It seems like forever you go you sent me patches to trinity to make it
> work on sparc. I'm curious if you've tried running it again more
> recently ?   Given the work I've done it to do more creative things with
> VM related syscalls, I wouldn't be surprised if it also found some sparc
> specific bugs in thp.
> 
> It should now also scale up to run a lot more child processes than the older
> version, with the -c option, which could be interesting on some of the
> bigger sparc machines.
> 
> (It's entirely possible I've broken the compile on non-x86 in
>  current git, but it shouldn't be much work to fix up).
> 
> git://github.com/kernelslacker/trinity is where it lives now.

Thanks Dave, I'll take a look and get back to you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Dave Jones]

On Tue, May 06, 2014 at 11:30:31AM -0400, David Miller wrote:
 > 
 > I've been auditing the THP support on sparc64 and found several bugs,
 > hopefully most of which are fixed completely here.
 
Hi Dave,

It seems like forever you go you sent me patches to trinity to make it
work on sparc. I'm curious if you've tried running it again more
recently ?   Given the work I've done it to do more creative things with
VM related syscalls, I wouldn't be surprised if it also found some sparc
specific bugs in thp.

It should now also scale up to run a lot more child processes than the older
version, with the -c option, which could be interesting on some of the
bigger sparc machines.

(It's entirely possible I've broken the compile on non-x86 in
 current git, but it shouldn't be much work to fix up).

git://github.com/kernelslacker/trinity is where it lives now.

Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Dave Jones]

On Tue, May 06, 2014 at 11:30:31AM -0400, David Miller wrote:
  
  I've been auditing the THP support on sparc64 and found several bugs,
  hopefully most of which are fixed completely here.
 
Hi Dave,

It seems like forever you go you sent me patches to trinity to make it
work on sparc. I'm curious if you've tried running it again more
recently ?   Given the work I've done it to do more creative things with
VM related syscalls, I wouldn't be surprised if it also found some sparc
specific bugs in thp.

It should now also scale up to run a lot more child processes than the older
version, with the -c option, which could be interesting on some of the
bigger sparc machines.

(It's entirely possible I've broken the compile on non-x86 in
 current git, but it shouldn't be much work to fix up).

git://github.com/kernelslacker/trinity is where it lives now.

Dave

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[David Miller]

From: Dave Jones da...@redhat.com
Date: Tue, 6 May 2014 12:29:46 -0400

 It seems like forever you go you sent me patches to trinity to make it
 work on sparc. I'm curious if you've tried running it again more
 recently ?   Given the work I've done it to do more creative things with
 VM related syscalls, I wouldn't be surprised if it also found some sparc
 specific bugs in thp.
 
 It should now also scale up to run a lot more child processes than the older
 version, with the -c option, which could be interesting on some of the
 bigger sparc machines.
 
 (It's entirely possible I've broken the compile on non-x86 in
  current git, but it shouldn't be much work to fix up).
 
 git://github.com/kernelslacker/trinity is where it lives now.

Thanks Dave, I'll take a look and get back to you.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[David Miller]

From: Sergei Shtylyov 
Date: Fri, 06 Sep 2013 02:32:51 +0400

> Hello.
> 
> On 09/06/2013 12:44 AM, David Miller wrote:
> 
>> Several bug fixes (from Kirill Tkhai, Geery Uytterhoeven, and Alexey
>> Dobriyan) and some support for Fujitsu sparc64x chips (from Allen
>> Pais).
> 
>> Please pull, thanks a lot!
> 
>You meant that for 'linux-sparc', not 'linux-ide', right? :-)

Yes, sparclinux is the intended destination, and I forwarded it there
once I realized my mistake :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Sergei Shtylyov]

Hello.

On 09/06/2013 12:44 AM, David Miller wrote:


Several bug fixes (from Kirill Tkhai, Geery Uytterhoeven, and Alexey
Dobriyan) and some support for Fujitsu sparc64x chips (from Allen
Pais).



Please pull, thanks a lot!


   You meant that for 'linux-sparc', not 'linux-ide', right? :-)

WBR, Sergei


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Sergei Shtylyov]

Hello.

On 09/06/2013 12:44 AM, David Miller wrote:


Several bug fixes (from Kirill Tkhai, Geery Uytterhoeven, and Alexey
Dobriyan) and some support for Fujitsu sparc64x chips (from Allen
Pais).



Please pull, thanks a lot!


   You meant that for 'linux-sparc', not 'linux-ide', right? :-)

WBR, Sergei


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[David Miller]

From: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Date: Fri, 06 Sep 2013 02:32:51 +0400

 Hello.
 
 On 09/06/2013 12:44 AM, David Miller wrote:
 
 Several bug fixes (from Kirill Tkhai, Geery Uytterhoeven, and Alexey
 Dobriyan) and some support for Fujitsu sparc64x chips (from Allen
 Pais).
 
 Please pull, thanks a lot!
 
You meant that for 'linux-sparc', not 'linux-ide', right? :-)

Yes, sparclinux is the intended destination, and I forwarded it there
once I realized my mistake :-)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[David Miller]

From: Al Viro 
Date: Wed, 10 Oct 2012 06:11:10 +0100

> sparc64: fix ptrace interaction with force_successful_syscall_return()
> 
> we want syscall_trace_leave() called on exit from any syscall;
> skipping its call in case we'd done force_successful_syscall_return()
> is broken...
> 
> Signed-off-by: Al Viro 

My eyes say this one is good, I'm testing it now and will push to
Linus if I don't hit any problems.

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[David Miller]

From: Al Viro v...@zeniv.linux.org.uk
Date: Wed, 10 Oct 2012 06:11:10 +0100

 sparc64: fix ptrace interaction with force_successful_syscall_return()
 
 we want syscall_trace_leave() called on exit from any syscall;
 skipping its call in case we'd done force_successful_syscall_return()
 is broken...
 
 Signed-off-by: Al Viro v...@zeniv.linux.org.uk

My eyes say this one is good, I'm testing it now and will push to
Linus if I don't hit any problems.

Thanks!
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Al Viro]

On Mon, Oct 08, 2012 at 04:18:06PM -0400, David Miller wrote:
> 
> There is an attempt to fix a bad interaction between syscall tracing
> and force_successful_syscall() from Al Viro, but it needs to be redone
> as it introduced regressions and thus had to be reverted for now.
> 
> Al is working on an updated version.

See below.  Just in case: Linus, please DO NOT APPLY unless it goes through
sparc tree - this is modulo approval by davem.

sparc64: fix ptrace interaction with force_successful_syscall_return()

we want syscall_trace_leave() called on exit from any syscall;
skipping its call in case we'd done force_successful_syscall_return()
is broken...

Signed-off-by: Al Viro 

diff --git a/arch/sparc/kernel/syscalls.S b/arch/sparc/kernel/syscalls.S
index 1d7e274..7f5f65d 100644
--- a/arch/sparc/kernel/syscalls.S
+++ b/arch/sparc/kernel/syscalls.S
@@ -212,24 +212,20 @@ linux_sparc_syscall:
 3: stx %o0, [%sp + PTREGS_OFF + PT_V9_I0]
 ret_sys_call:
ldx [%sp + PTREGS_OFF + PT_V9_TSTATE], %g3
-   ldx [%sp + PTREGS_OFF + PT_V9_TNPC], %l1 ! pc = npc
sra %o0, 0, %o0
mov %ulo(TSTATE_XCARRY | TSTATE_ICARRY), %g2
sllx%g2, 32, %g2
 
-   /* Check if force_successful_syscall_return()
-* was invoked.
-*/
-   ldub[%g6 + TI_SYS_NOERROR], %l2
-   brnz,a,pn %l2, 80f
-stb%g0, [%g6 + TI_SYS_NOERROR]
-
cmp %o0, -ERESTART_RESTARTBLOCK
bgeu,pn %xcc, 1f
-andcc  %l0, 
(_TIF_SYSCALL_TRACE|_TIF_SECCOMP|_TIF_SYSCALL_AUDIT|_TIF_SYSCALL_TRACEPOINT), 
%l6
-80:
+andcc  %l0, 
(_TIF_SYSCALL_TRACE|_TIF_SECCOMP|_TIF_SYSCALL_AUDIT|_TIF_SYSCALL_TRACEPOINT), 
%g0
+   ldx [%sp + PTREGS_OFF + PT_V9_TNPC], %l1 ! pc = npc
+
+2:
+   stb %g0, [%g6 + TI_SYS_NOERROR]
/* System call success, clear Carry condition code. */
andn%g3, %g2, %g3
+3:
stx %g3, [%sp + PTREGS_OFF + PT_V9_TSTATE]  
bne,pn  %icc, linux_syscall_trace2
 add%l1, 0x4, %l2   ! npc = npc+4
@@ -238,20 +234,20 @@ ret_sys_call:
 stx%l2, [%sp + PTREGS_OFF + PT_V9_TNPC]
 
 1:
+   /* Check if force_successful_syscall_return()
+* was invoked.
+*/
+   ldub[%g6 + TI_SYS_NOERROR], %l2
+   brnz,pn %l2, 2b
+ldx[%sp + PTREGS_OFF + PT_V9_TNPC], %l1 ! pc = npc
/* System call failure, set Carry condition code.
 * Also, get abs(errno) to return to the process.
 */
-   andcc   %l0, 
(_TIF_SYSCALL_TRACE|_TIF_SECCOMP|_TIF_SYSCALL_AUDIT|_TIF_SYSCALL_TRACEPOINT), 
%l6  
sub %g0, %o0, %o0
-   or  %g3, %g2, %g3
stx %o0, [%sp + PTREGS_OFF + PT_V9_I0]
-   stx %g3, [%sp + PTREGS_OFF + PT_V9_TSTATE]
-   bne,pn  %icc, linux_syscall_trace2
-add%l1, 0x4, %l2   ! npc = npc+4
-   stx %l1, [%sp + PTREGS_OFF + PT_V9_TPC]
+   ba,pt   %xcc, 3b
+or %g3, %g2, %g3
 
-   b,pt%xcc, rtrap
-stx%l2, [%sp + PTREGS_OFF + PT_V9_TNPC]
 linux_syscall_trace2:
callsyscall_trace_leave
 add%sp, PTREGS_OFF, %o0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT] Sparc

[Al Viro]

On Mon, Oct 08, 2012 at 04:18:06PM -0400, David Miller wrote:
 
 There is an attempt to fix a bad interaction between syscall tracing
 and force_successful_syscall() from Al Viro, but it needs to be redone
 as it introduced regressions and thus had to be reverted for now.
 
 Al is working on an updated version.

See below.  Just in case: Linus, please DO NOT APPLY unless it goes through
sparc tree - this is modulo approval by davem.

sparc64: fix ptrace interaction with force_successful_syscall_return()

we want syscall_trace_leave() called on exit from any syscall;
skipping its call in case we'd done force_successful_syscall_return()
is broken...

Signed-off-by: Al Viro v...@zeniv.linux.org.uk

diff --git a/arch/sparc/kernel/syscalls.S b/arch/sparc/kernel/syscalls.S
index 1d7e274..7f5f65d 100644
--- a/arch/sparc/kernel/syscalls.S
+++ b/arch/sparc/kernel/syscalls.S
@@ -212,24 +212,20 @@ linux_sparc_syscall:
 3: stx %o0, [%sp + PTREGS_OFF + PT_V9_I0]
 ret_sys_call:
ldx [%sp + PTREGS_OFF + PT_V9_TSTATE], %g3
-   ldx [%sp + PTREGS_OFF + PT_V9_TNPC], %l1 ! pc = npc
sra %o0, 0, %o0
mov %ulo(TSTATE_XCARRY | TSTATE_ICARRY), %g2
sllx%g2, 32, %g2
 
-   /* Check if force_successful_syscall_return()
-* was invoked.
-*/
-   ldub[%g6 + TI_SYS_NOERROR], %l2
-   brnz,a,pn %l2, 80f
-stb%g0, [%g6 + TI_SYS_NOERROR]
-
cmp %o0, -ERESTART_RESTARTBLOCK
bgeu,pn %xcc, 1f
-andcc  %l0, 
(_TIF_SYSCALL_TRACE|_TIF_SECCOMP|_TIF_SYSCALL_AUDIT|_TIF_SYSCALL_TRACEPOINT), 
%l6
-80:
+andcc  %l0, 
(_TIF_SYSCALL_TRACE|_TIF_SECCOMP|_TIF_SYSCALL_AUDIT|_TIF_SYSCALL_TRACEPOINT), 
%g0
+   ldx [%sp + PTREGS_OFF + PT_V9_TNPC], %l1 ! pc = npc
+
+2:
+   stb %g0, [%g6 + TI_SYS_NOERROR]
/* System call success, clear Carry condition code. */
andn%g3, %g2, %g3
+3:
stx %g3, [%sp + PTREGS_OFF + PT_V9_TSTATE]  
bne,pn  %icc, linux_syscall_trace2
 add%l1, 0x4, %l2   ! npc = npc+4
@@ -238,20 +234,20 @@ ret_sys_call:
 stx%l2, [%sp + PTREGS_OFF + PT_V9_TNPC]
 
 1:
+   /* Check if force_successful_syscall_return()
+* was invoked.
+*/
+   ldub[%g6 + TI_SYS_NOERROR], %l2
+   brnz,pn %l2, 2b
+ldx[%sp + PTREGS_OFF + PT_V9_TNPC], %l1 ! pc = npc
/* System call failure, set Carry condition code.
 * Also, get abs(errno) to return to the process.
 */
-   andcc   %l0, 
(_TIF_SYSCALL_TRACE|_TIF_SECCOMP|_TIF_SYSCALL_AUDIT|_TIF_SYSCALL_TRACEPOINT), 
%l6  
sub %g0, %o0, %o0
-   or  %g3, %g2, %g3
stx %o0, [%sp + PTREGS_OFF + PT_V9_I0]
-   stx %g3, [%sp + PTREGS_OFF + PT_V9_TSTATE]
-   bne,pn  %icc, linux_syscall_trace2
-add%l1, 0x4, %l2   ! npc = npc+4
-   stx %l1, [%sp + PTREGS_OFF + PT_V9_TPC]
+   ba,pt   %xcc, 3b
+or %g3, %g2, %g3
 
-   b,pt%xcc, rtrap
-stx%l2, [%sp + PTREGS_OFF + PT_V9_TNPC]
 linux_syscall_trace2:
callsyscall_trace_leave
 add%sp, PTREGS_OFF, %o0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/