linux-stable.git/arch/m68k/include/uapi, branch linux-5.0.y

arch: unexport asm/shmparam.h for all architectures

2019-02-01T23:46:22+00:00

Most architectures do not export shmparam.h to user-space.

  $ find arch -name shmparam.h  | sort
  arch/alpha/include/asm/shmparam.h
  arch/arc/include/asm/shmparam.h
  arch/arm64/include/asm/shmparam.h
  arch/arm/include/asm/shmparam.h
  arch/csky/include/asm/shmparam.h
  arch/ia64/include/asm/shmparam.h
  arch/mips/include/asm/shmparam.h
  arch/nds32/include/asm/shmparam.h
  arch/nios2/include/asm/shmparam.h
  arch/parisc/include/asm/shmparam.h
  arch/powerpc/include/asm/shmparam.h
  arch/s390/include/asm/shmparam.h
  arch/sh/include/asm/shmparam.h
  arch/sparc/include/asm/shmparam.h
  arch/x86/include/asm/shmparam.h
  arch/xtensa/include/asm/shmparam.h

Strangely, some users of the asm-generic wrapper export shmparam.h

  $ git grep 'generic-y += shmparam.h'
  arch/c6x/include/uapi/asm/Kbuild:generic-y += shmparam.h
  arch/h8300/include/uapi/asm/Kbuild:generic-y += shmparam.h
  arch/hexagon/include/uapi/asm/Kbuild:generic-y += shmparam.h
  arch/m68k/include/uapi/asm/Kbuild:generic-y += shmparam.h
  arch/microblaze/include/uapi/asm/Kbuild:generic-y += shmparam.h
  arch/openrisc/include/uapi/asm/Kbuild:generic-y += shmparam.h
  arch/riscv/include/asm/Kbuild:generic-y += shmparam.h
  arch/unicore32/include/uapi/asm/Kbuild:generic-y += shmparam.h

The newly added riscv correctly creates the asm-generic wrapper
in the kernel space, but the others (c6x, h8300, hexagon, m68k,
microblaze, openrisc, unicore32) create the one in the uapi directory.

Digging into the git history, now I guess fcc8487d477a ("uapi:
export all headers under uapi directories") was the misconversion.
Prior to that commit, no architecture exported to shmparam.h
As its commit description said, that commit exported shmparam.h
for c6x, h8300, hexagon, m68k, openrisc, unicore32.

83f0124ad81e ("microblaze: remove asm-generic wrapper headers")
accidentally exported shmparam.h for microblaze.

This commit unexports shmparam.h for those architectures.

There is no more reason to export include/uapi/asm-generic/shmparam.h,
so it has been moved to include/asm-generic/shmparam.h

Link: http://lkml.kernel.org/r/1546904307-11124-1-git-send-email-yamada.masahiro@socionext.com
Signed-off-by: Masahiro Yamada 
Acked-by: Stafford Horne 
Cc: Geert Uytterhoeven 
Cc: Michal Simek 
Cc: Yoshinori Sato 
Cc: Richard Kuo 
Cc: Guan Xuetao 
Cc: Nicolas Dichtel 
Cc: Arnd Bergmann 
Cc: Aurelien Jacquiot 
Cc: Greentime Hu 
Cc: Guo Ren 
Cc: Palmer Dabbelt 
Cc: Stefan Kristiansson 
Cc: Mark Salter 
Cc: Albert Ou 
Cc: Jonas Bonn 
Cc: Vincent Chen 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

arch: restore generic-y += shmparam.h for some architectures

2019-01-07T02:16:11+00:00

For some reasons, I accidentally got rid of "generic-y += shmparam.h"
from some architectures.

Restore them to fix building c6x, h8300, hexagon, m68k, microblaze,
openrisc, and unicore32.

Fixes: d6e4b3e326d8 ("arch: remove redundant UAPI generic-y defines")
Signed-off-by: Masahiro Yamada 
Signed-off-by: Linus Torvalds

arch: remove redundant UAPI generic-y defines

2019-01-06T01:22:15+00:00

Now that Kbuild automatically creates asm-generic wrappers for missing
mandatory headers, it is redundant to list the same headers in
generic-y and mandatory-y.

Suggested-by: Sam Ravnborg 
Signed-off-by: Masahiro Yamada 
Acked-by: Sam Ravnborg

arch: remove stale comments "UAPI Header export list"

2019-01-06T00:46:51+00:00

These comments are leftovers of commit fcc8487d477a ("uapi: export all
headers under uapi directories").

Prior to that commit, exported headers must be explicitly added to
header-y. Now, all headers under the uapi/ directories are exported.

Signed-off-by: Masahiro Yamada

m68k: Generate uapi header and syscall table header files

2018-12-04T08:47:55+00:00

System call table generation script must be run to gener-
ate unistd_32.h and syscall_table.h files. This patch will
have changes which will invokes the script.

This patch will generate unistd_32.h and syscall_table.h
files by the syscall table generation script invoked by
m68k/Makefile and the generated files against the removed
files must be identical.

The generated uapi header file will be included in uapi/-
asm/unistd.h and generated system call table header file
will be included by kernel/syscalltable.S file.

Signed-off-by: Firoz Khan 
Signed-off-by: Geert Uytterhoeven

m68k: Add __NR_syscalls along with NR_syscalls

2018-12-04T08:47:48+00:00

NR_syscalls macro holds the number of system call
exist in m68k architecture. We have to change the
value of NR_syscalls, if we add or delete a system
call.

One of the patch in this patch series has a script
which will generate a uapi header based on syscall-
.tbl file. The syscall.tbl file contains the total
number of system calls information. So we have two
option to update NR_syscalls value.

1. Update NR_syscalls in asm/unistd.h manually by
   counting the no.of system calls. No need to up-
   date NR_syscalls until we either add a new sys-
   tem call or delete existing system call.

2. We can keep this feature it above mentioned sc-
   ript, that will count the number of syscalls and
   keep it in a generated file. In this case we
   don't need to explicitly update NR_syscalls in
   asm/unistd.h file.

The 2nd option will be the recommended one. For that,
I added the __NR_syscalls macro in uapi/asm/unistd.h
along with NR_syscalls asm/unistd.h. The macro __NR-
_syscalls also added for making the name convention
same across all architecture. While __NR_syscalls
isn't strictly part of the uapi, having it as part
of the generated header to simplifies the implement-
ation. We also need to enclose this macro with #ifdef
__KERNEL__ to avoid side effects.

Signed-off-by: Firoz Khan 
Signed-off-by: Geert Uytterhoeven

unify {de,}mangle_poll(), get rid of kernel-side POLL...

2018-02-11T22:37:22+00:00

except, again, POLLFREE and POLL_BUSY_LOOP.

With this, we finally get to the promised end result:

 - POLL{IN,OUT,...} are plain integers and *not* in __poll_t, so any
   stray instances of ->poll() still using those will be caught by
   sparse.

 - eventpoll.c and select.c warning-free wrt __poll_t

 - no more kernel-side definitions of POLL... - userland ones are
   visible through the entire kernel (and used pretty much only for
   mangle/demangle)

 - same behavior as after the first series (i.e. sparc et.al. epoll(2)
   working correctly).

Signed-off-by: Al Viro 
Signed-off-by: Linus Torvalds

Merge branch 'misc.poll' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs

2018-01-31T01:58:07+00:00

Pull poll annotations from Al Viro:
 "This introduces a __bitwise type for POLL### bitmap, and propagates
  the annotations through the tree. Most of that stuff is as simple as
  'make ->poll() instances return __poll_t and do the same to local
  variables used to hold the future return value'.

  Some of the obvious brainos found in process are fixed (e.g. POLLIN
  misspelled as POLL_IN). At that point the amount of sparse warnings is
  low and most of them are for genuine bugs - e.g. ->poll() instance
  deciding to return -EINVAL instead of a bitmap. I hadn't touched those
  in this series - it's large enough as it is.

  Another problem it has caught was eventpoll() ABI mess; select.c and
  eventpoll.c assumed that corresponding POLL### and EPOLL### were
  equal. That's true for some, but not all of them - EPOLL### are
  arch-independent, but POLL### are not.

  The last commit in this series separates userland POLL### values from
  the (now arch-independent) kernel-side ones, converting between them
  in the few places where they are copied to/from userland. AFAICS, this
  is the least disruptive fix preserving poll(2) ABI and making epoll()
  work on all architectures.

  As it is, it's simply broken on sparc - try to give it EPOLLWRNORM and
  it will trigger only on what would've triggered EPOLLWRBAND on other
  architectures. EPOLLWRBAND and EPOLLRDHUP, OTOH, are never triggered
  at all on sparc. With this patch they should work consistently on all
  architectures"

* 'misc.poll' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (37 commits)
  make kernel-side POLL... arch-independent
  eventpoll: no need to mask the result of epi_item_poll() again
  eventpoll: constify struct epoll_event pointers
  debugging printk in sg_poll() uses %x to print POLL... bitmap
  annotate poll(2) guts
  9p: untangle ->poll() mess
  ->si_band gets POLL... bitmap stored into a user-visible long field
  ring_buffer_poll_wait() return value used as return value of ->poll()
  the rest of drivers/*: annotate ->poll() instances
  media: annotate ->poll() instances
  fs: annotate ->poll() instances
  ipc, kernel, mm: annotate ->poll() instances
  net: annotate ->poll() instances
  apparmor: annotate ->poll() instances
  tomoyo: annotate ->poll() instances
  sound: annotate ->poll() instances
  acpi: annotate ->poll() instances
  crypto: annotate ->poll() instances
  block: annotate ->poll() instances
  x86: annotate ->poll() instances
  ...

bpf: correct broken uapi for BPF_PROG_TYPE_PERF_EVENT program type

2017-12-05T14:02:40+00:00

Commit 0515e5999a466dfe ("bpf: introduce BPF_PROG_TYPE_PERF_EVENT
program type") introduced the bpf_perf_event_data structure which
exports the pt_regs structure.  This is OK for multiple architectures
but fail for s390 and arm64 which do not export pt_regs.  Programs
using them, for example, the bpf selftest fail to compile on these
architectures.

For s390, exporting the pt_regs is not an option because s390 wants
to allow changes to it.  For arm64, there is a user_pt_regs structure
that covers parts of the pt_regs structure for use by user space.

To solve the broken uapi for s390 and arm64, introduce an abstract
type for pt_regs and add an asm/bpf_perf_event.h file that concretes
the type.  An asm-generic header file covers the architectures that
export pt_regs today.

The arch-specific enablement for s390 and arm64 follows in separate
commits.

Reported-by: Thomas Richter 
Fixes: 0515e5999a466dfe ("bpf: introduce BPF_PROG_TYPE_PERF_EVENT program type")
Signed-off-by: Hendrik Brueckner 
Reviewed-and-tested-by: Thomas Richter 
Acked-by: Alexei Starovoitov 
Cc: Arnaldo Carvalho de Melo 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Arnd Bergmann 
Cc: Daniel Borkmann 
Signed-off-by: Daniel Borkmann

make kernel-side POLL... arch-independent

2017-11-30T00:00:41+00:00

mangle/demangle on the way to/from userland

Signed-off-by: Al Viro