Description: capability adjust
Team:OTHERS
Feature or Bugfix:Feature
Binary Source:No
PrivateCode(Yes/No):No

Change-Id: I17eb186a7f7e15ea534085b096ecc442675b66cd
Reviewed-on: http://mgit-tm.rnd.huawei.com/10642475Tested-by: Npublic jenkins <public_jenkins@notesmail.huawei.com>
Reviewed-by: Nchencheng 00349400 <chencheng16@huawei.com>
Reviewed-by: Nzhaopeng 00380337 <zhaopeng22@huawei.com>
(cherry picked from commit 7804cd9ff30011074a834c4d77feeb748503e8d6)
Reviewed-on: http://mgit-tm.rnd.huawei.com/10643283

Description:userspace musl code

Team:OTHERS
Feature or Bugfix:Feature
Binary Source:NA
PrivateCode(Yes/No):No

Change-Id: I1d445ef7d16285be98b1857f4c01b94c9759daea
Reviewed-on: http://mgit-tm.rnd.huawei.com/10274931Reviewed-by: Ncaoruihong 00546070 <crh.cao@huawei.com>
Tested-by: Npublic jenkins <public_jenkins@notesmail.huawei.com>
Reviewed-by: Nshenwei 00579521 <denny.shenwei@huawei.com>

_POSIX_VDISABLE is only visible if unistd.h has already been included,
so conditional use of it here makes no sense. the value is always 0
anyway; it does not vary.

This macro exists since Linux 2.6.25 and is defined in glibc since 2011.

this change was discussed on the mailing list thread for the linux
uapi v5.3 patches, and submitted as a v2 patch, but overlooked when I
applied the patches much later.

revert commit f291c09e and apply the
v2 as submitted; the net change is just padding.

notes by Szabolcs Nagy follow:

compared to the linux uapi (and glibc) a padding is used instead of
aligned attribute for keeping the layout the same across targets, this
means the alignment of the struct may be different on some targets
(e.g. m68k where uint64_t is 2 byte aligned) but that should not affect
syscalls and this way the abi does not depend on nonstandard extensions.

allows waiting on a pidfd, in the future it might allow retrieving the
exit status by a non-parent process, see

  linux commit 3695eae5fee0605f316fbaad0b9e3de791d7dfaf
  pidfd: add P_PIDFD to waitid()

per thread prctl commands to relax the syscall abi such that top bits
of user pointers are ignored in the kernel. this allows the use of
those bits by hwasan or by mte to color pointers and memory on aarch64:

  linux commit 63f0c60379650d82250f22e4cf4137ef3dc4f43d
  arm64: Introduce prctl() options to control the tagged user addresses ABI

These were mainly introduced so android can optimize the memory usage
of unused apps.

MADV_COLD hints that the memory range is currently not needed (unlike
with MADV_FREE the content is not garbage, it needs to be swapped):

  linux commit 9c276cc65a58faf98be8e56962745ec99ab87636
  mm: introduce MADV_COLD

MADV_PAGEOUT hints that the memory range is not needed for a long time
so it can be reclaimed immediately independently of memory pressure
(unlike with MADV_DONTNEED the content is not garbage):

  linux commit 1a4e58cce84ee88129d5d49c064bd2852b481357
  mm: introduce MADV_PAGEOUT

ptrace API to get details of the syscall the tracee is blocked in, see

  linux commit 201766a20e30f982ccfe36bebfad9602c3ff574a
  ptrace: add PTRACE_GET_SYSCALL_INFO request

the align attribute was used to keep the layout the same across targets
e.g. on m68k uint32_t is 2 byte aligned, this helps with compat ptrace.

see

  linux commit 99f3a064bc2e4bd5fe50218646c5be342f2ad18c
  bpf: net: Add SO_DETACH_REUSEPORT_BPF

the elf_prstatus structure is used in core dumps, and the timeval
structures in it are longs matching the elf class, *not* the kernel
"old timeval" for the arch. this means using timeval here for x32 was
always wrong, despite kernel uapi headers and glibc also exposing it
this way, and of course it's wrong for any arch with 64-bit time_t.

rather than just changing the type on affected archs, use a tagless
struct containing long tv_sec and tv_usec members in place of the
timevals. this intentionally breaks use of them as timevals (e.g.
assignment, passing address, etc.) on 64-bit archs as well so that any
usage unsafe for 32-bit archs is caught even in software that only
gets tested on 64-bit archs. from what I could gather, there is not
any software using these members anyway. the only reason they need to
be fixed to begin with is that the only members which are commonly
used, the saved registers, follow the time members and have the wrong
offset if the time members are sized incorrectly.

commit b60fdf13 broke the
SIOCGSTAMP[NS] ioctl fallbacks introduced in commit
2e554617, as well as use of these
ioctls, by creating a situation where bits/ioctl.h could be included
without __LONG_MAX being visible.

now that all 32-bit archs have 64-bit time types, the values for the
time-related socket option macros can be treated as universal for
32-bit archs. the sys/socket.h mechanism for this predates
arch/generic and is instead in the top-level header.

x32, which does not use the new time64 values of the macros, already
has its own overrides, so this commit does not affect it.

these structures can now be defined generically in terms of endianness
and long size. previously, the 32-bit archs all shared a common
definition from the generic bits header, and each 64-bit arch had to
repeat the 64-bit version, with endian conditionals if the arch had
variants of each endianness.

I would prefer getting rid of the preprocessor conditionals for
padding and instead using unnamed bitfield members, like commit
9b2921be did for struct timespec.
however, at present sendmsg, recvmsg, and recvmmsg need access to the
padding members by name to zero them. this could perhaps be cleaned up
in the future.

SO_RCVTIMEO and SO_SNDTIMEO already were, but only in aggregate with
SO_DEBUG and all of the other low/traditional options that varied per
arch. SO_TIMESTAMP* are newly overridable. the two groups have to be
done separately since mips64 and powerpc64 will override the former
but not the latter.

at some point this should be cleaned up to use bits headers more
idiomatically.

a _REDIR_TIME64 macro is introduced, which the arch's alltypes.h is
expected to define, to control redirection of symbol names for
interfaces that involve time_t and derived types. this ensures that
object files will only be linked to libc interfaces matching the ABI
whose headers they were compiled against.

along with time32 compat shims, which will be introduced separately,
the redirection also makes it possible for a single libc (static or
shared) to be used with object files produced with either the old
(32-bit time_t) headers or the new ones after 64-bit time_t switchover
takes place. mixing of such object files (or shared libraries) in the
same program will also be possible, but must be done with care; ABI
between libc and a consumer of the libc interfaces is guaranteed to
match by the the symbol name redirection, but pairwise ABI between
consumers of libc that define interfaces between each other in terms
of time_t is not guaranteed to match.

this change adds a dependency on an additional "GNU C" feature to the
public headers for existing 32-bit archs, which is generally
undesirable; however, the feature is one which glibc has depended on
for a long time, and thus which any viable alternative compiler is
going to need to provide. 64-bit archs are not affected, nor will
future 32-bit archs be, regardless of whether they are "new" on the
kernel side (e.g. riscv32) or just newly-added (e.g. a new sparc or
xtensa port). the same applies to newly-added ABIs for existing
machine-level archs.

building on commit 97d35a55,
__BYTE_ORDER is now available wherever alltypes.h is included.
endian.h should not be used since, in the future, it will expose
identifiers that are not in the reserved namespace for the headers
which were previously using it.

otherwise, 32-bit archs that could otherwise share the generic
bits/ipc.h would need to duplicate the struct ipc_perm definition,
obscuring the fact that it's the same. sysvipc is not widely used and
these headers are not commonly included, so there is no performance
gain to be had by limiting the number of indirectly included files
here.

files with the existing time32 definition of IPC_STAT are added to all
current 32-bit archs now, so that when it's changed the change will
show up as a change rather than addition of a new file where it's less
obvious that the value is changing vs the generic one that was used
before.

to make use of {sem,shm,msg}ctl IPC_STAT functionality to provide
64-bit time_t on 32-bit archs, IPC_STAT and related macros must be
defined with bit 8 (0x100) set. allow archs to define IPC_STAT in
bits/ipc.h, and define the other macros in terms of it so that they
all get the same value of the time64 bit.

SO_BINDTOIFINDEX behaves similar to SO_BINDTODEVICE, but takes a
network interface index as argument, rather than the network
interface name. see

  linux commit f5dd3d0c9638a9d9a02b5964c4ad636f06cf7e2c
  net: introduce SO_BINDTOIFINDEX sockopt

allows specifying that the speculative store bypass disable bit should
be cleared on exec. see

  linux commit 71368af9027f18fe5d1c6f372cfdff7e4bde8b48
  x86/speculation: Add PR_SPEC_DISABLE_NOEXEC

includes changes from linux v5.1

  linux commit 235328d1fa4251c6dcb32351219bb553a58838d2
  fanotify: add support for create/attrib/move/delete events

  linux commit 5e469c830fdb5a1ebaa69b375b87f583326fd296
  fanotify: copy event fid info to user

  linux commit e9e0c8903009477b630e37a8b6364b26a00720da
  fanotify: encode file identifier for FAN_REPORT_FID

as well as earlier changes that were missed.

sys/statfs.h is included for fsid_t.

this reverts commit f552c792, which
exposed the sysmacros.h macros (device major/minor calculations) for
BSD and GNU profiles to mimic an unintentional glibc behavior some
code depended on. glibc has deprecated and since removed them as the
resolution to bug #19239, so it makes no sense for us to keep this
behavior. affected code should all have been fixed by now, and if it's
not yet fixed it needs to be for use with modern glibc anyway.

aarch64 pointer authentication code related prctl that allows
reinitializing the key for the thread, added in linux commit
ba830885656414101b2f8ca88786524d4bb5e8c1

prctls to allow per task control of indirect branch speculation on x86.

added in linux commit 9137bb27e60e554dab694eafa4cca241fa3a694f

aarch64 supports 32MB and 512MB hugetlb page sizes too.
added in linux commit 20916d4636a9b3c1bf562b305f91d126771edaf9

inotify_add_watch flag to prevent modifying existing watch descriptors,
when used on an already watched inode it fails with EEXIST.
added in linux commit 4d97f7d53da7dc830dbf416a3d2a6778d267ae68

added in linux commit 80b14dee2bea128928537d61c333f24cb8cbb62f

the motivation for this change is twofold. first, it gets the fallback
logic out of the dynamic linker, improving code readability and
organization. second, it provides application code that wants to use
the membarrier syscall, which depends on preregistration of intent
before the process becomes multithreaded unless unbounded latency is
acceptable, with a symbol that, when linked, ensures that this
registration happens.

new in linux commit 76b7f670730e87974f71df9f6129811e2769666e

in struct signalfd_siginfo the pad member is changed to __pad to keep
the namespace clean, it's not part of the public api.

new address family and related macros were added in linux commit
68e8b849b221b37a78a110a0307717d45e3593a0

maintainer's note: while musl does not use the linux kernel headers,
it does provide these three sys/* headers which do nothing but include
the corresponding linux/* headers, since the sys/* versions are the
ones documented for application use (and they arguably provide
interfaces that are not linux-specific but common to other unices).
these headers should probably not be provided by libc (rather by a
separate package), but as long as they are, use the bits header
framework as an aid to out-of-tree ports of musl for non-linux systems
that want to implement them in some other way.

maintainer's note: at some point, probably long before linux separated
the uapi headers, it was the case, or at least I believed it was the
case, that linux/types.h was unsafe to include from userspace. thus,
the inclusion guard macro _LINUX_TYPES_H was defined in sys/kd.h to
prevent linux/kd.h from including linux/types.h (which it spuriously
includes but does not use). as far as I can tell, whatever problem
this was meant to solve does not seem to have been present for a long
time, and the hack was not done correctly anyway, so removing it is
the right thing to do.

sys/ptrace.h is target specific, use bits/ptrace.h to add target
specific macro definitions.

these macros are kept in the generic sys/ptrace.h even though some
targets don't support them:

PTRACE_GETREGS
PTRACE_SETREGS
PTRACE_GETFPREGS
PTRACE_SETFPREGS
PTRACE_GETFPXREGS
PTRACE_SETFPXREGS

so no macro definition got removed in this patch on any target. only
s390x has a numerically conflicting macro definition (PTRACE_SINGLEBLOCK).

the PT_ aliases follow glibc headers, otherwise the definitions come
from linux uapi headers except ones that are skipped in glibc and
there is no real kernel support (s390x PTRACE_*_AREA) or need special
type definitions (mips PTRACE_*_WATCH_*) or only relevant for linux
2.4 compatibility (PTRACE_OLDSETOPTIONS).

new in linux v3.1 commit 3544d72a0e10d0aa1c1bd59ed77a53a59cdc12f7
changed in linux v3.4 commit 5cdf389aee90109e2e3d88085dea4dd5508a3be7

A tracer recieves this event in the waitpid status of a PTRACED_SEIZED
process.