This adds 21 new system calls on each ABI that has 32-bit time_t
today. All of these have the exact same semantics as their existing
counterparts, and the new ones all have macro names that end in 'time64'
for clarification.
This gets us to the point of being able to safely use a C library
that
All architectures should implement these two, so assign numbers
and hook them up on ia64.
Signed-off-by: Arnd Bergmann
---
arch/ia64/kernel/syscalls/syscall.tbl | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/ia64/kernel/syscalls/syscall.tbl
b/arch/ia64/kernel/syscalls/syscall.tbl
statx is available on almost all other architectures but
got missed on sh, so add it now.
Signed-off-by: Arnd Bergmann
---
arch/sh/kernel/syscalls/syscall.tbl | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/sh/kernel/syscalls/syscall.tbl
b/arch/sh/kernel/syscalls/syscall.tbl
index
A couple of architectures including arm64 already implement the
kexec_file_load system call, on many others we have assigned a system
call number for it, but not implemented it yet.
Adding the number in arch/arm/ lets us use the system call on arm64
systems in compat mode, and also reduces the
From: Deepa Dinamani
struct timex is not y2038 safe.
Replace all uses of timex with y2038 safe __kernel_timex.
Note that struct __kernel_timex is an ABI interface definition.
We could define a new structure based on __kernel_timex that
is only available internally instead. Right now, there
The migrate_pages system call has an assigned number on all architectures
except ARM. When it got added initially in commit d80ade7b3231 ("ARM:
Fix warning: #warning syscall migrate_pages not implemented"), it was
intentionally left out based on the observation that there are no 32-bit
ARM NUMA
The time, stime, utime, utimes, and futimesat system calls are only
used on older architectures, and we do not provide y2038 safe variants
of them, as they are replaced by clock_gettime64, clock_settime64,
and utimensat_time64.
However, for consistency it seems better to have the 32-bit
sparc64 is the only architecture on Linux that has a 'timeval'
definition with a 32-bit tv_usec but a 64-bit tv_sec. This causes
problems for sparc32 compat mode when we convert it to use the
new __kernel_timex type that has the same layout as all other
64-bit architectures.
To avoid adding
Most architectures have assigned numbers for both seccomp and
perf_event_open, even when they do not implement either.
ia64 is an exception here, so for consistency lets add numbers for both
of them. Unless CONFIG_PERF_EVENTS and CONFIG_SECCOMP are implemented,
the system calls just return
From: Deepa Dinamani
struct timex is not y2038 safe.
Switch all the syscall apis to use y2038 safe __kernel_timex.
Note that sys_adjtimex() does not have a y2038 safe solution. C libraries
can implement it by calling clock_adjtime(CLOCK_REALTIME, ...).
Signed-off-by: Deepa Dinamani
The io_pgetevents system call was added in linux-4.18 but has
no entry for alpha:
warning: #warning syscall io_pgetevents not implemented [-Wcpp]
Assign a the next system call number here.
Cc: sta...@vger.kernel.org
Signed-off-by: Arnd Bergmann
---
arch/alpha/kernel/syscalls/syscall.tbl | 1 +
On Fri, Jan 18, 2019 at 5:57 PM Dennis Clarke wrote:
>
> On 1/18/19 11:18 AM, Arnd Bergmann wrote:
> > This is a minor update of the patches I posted last week, I
> > would like to add this into linux-next now, but would still do
> > changes if there are concerns about the contents. The first
> >
On 1/18/19 12:14 PM, Arnd Bergmann wrote:
On Fri, Jan 18, 2019 at 5:57 PM Dennis Clarke wrote:
On 1/18/19 11:18 AM, Arnd Bergmann wrote:
This is a minor update of the patches I posted last week, I
would like to add this into linux-next now, but would still do
changes if there are concerns
We want to reuse the compat_timex handling on 32-bit architectures the
same way we are using the compat handling for timespec when moving to
64-bit time_t.
Move all definitions related to compat_timex out of the compat code
into the normal timekeeping code, along with a rename to old_timex32,
This is the big flip, where all 32-bit architectures set COMPAT_32BIT_TIME
abd use the _time32 system calls from the former compat layer instead
of the system calls that take __kernel_timespec and similar arguments.
The temporary redirects for __kernel_timespec, __kernel_itimerspec
and
The behavior of these system calls is slightly different between
architectures, as determined by the CONFIG_ARCH_WANT_IPC_PARSE_VERSION
symbol. Most architectures that implement the split IPC syscalls don't set
that symbol and only get the modern version, but alpha, arm, microblaze,
mips-n32,
These are all for ignoring the lack of obsolete system calls,
which have been marked the same way in scripts/checksyscall.sh,
so these can be removed.
Signed-off-by: Arnd Bergmann
---
arch/mips/include/asm/unistd.h | 16
arch/parisc/include/asm/unistd.h | 3 ---
This is a minor update of the patches I posted last week, I
would like to add this into linux-next now, but would still do
changes if there are concerns about the contents. The first
version did not see a lot of replies, which could mean that
either everyone is happy with it, or that it was
x32 has always followed the time64 calling conventions of these
syscalls, which required a special hack in compat_get_timespec
aka get_old_timespec32 to continue working.
Since we now have the time64 syscalls, use those explicitly.
Signed-off-by: Arnd Bergmann
---
A small typo has crept into the y2038 conversion of the timer_settime
system call. So far this was completely harmless, but once we start
using the new version, this has to be fixed.
Fixes: 6ff847350702 ("time: Change types to new y2038 safe __kernel_itimerspec")
Signed-off-by: Arnd Bergmann
---
Other architectures commonly use __NR_umount2 for sys_umount,
only ia64 and alpha use __NR_umount here. In order to synchronize
the generated tables, use umount2 like everyone else, and add back
the old name from asm/unistd.h for compatibility.
For shmat, alpha uses the osf_shmat name, we can do
We now use 64-bit time_t on all architectures, so the __kernel_timex,
__kernel_timeval and __kernel_timespec redirects can be removed
after having served their purpose.
This makes it all much less confusing, as the __kernel_* types
now always refer to the same layout based on 64-bit time_t across
Most architectures have assigned a numbers for the seccomp syscall
even when they do not implement it.
m68k is an exception here, so for consistency lets add the number.
Unless CONFIG_SECCOMP is implemented, the system call just
returns -ENOSYS.
Signed-off-by: Arnd Bergmann
---
Most architectures define system call numbers for the rseq and pkey system
calls, even when they don't support the features, and perhaps never will.
Only a few architectures are missing these, so just define them anyway
for consistency. If we decide to add them later to one of these, the
system
Other architectures commonly use __NR_umount2 for sys_umount,
only ia64 and alpha use __NR_umount here. In order to synchronize
the generated tables, use umount2 like everyone else, and add back
the old name from asm/unistd.h for compatibility.
The __IGNORE_* lines are now all obsolete and can be
__kernel_timespec and timespec are currently the same type, but once
they are different, the type cast has to be changed here.
Signed-off-by: Arnd Bergmann
---
arch/sparc/kernel/sys_sparc_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/sparc/kernel/sys_sparc_64.c
From: Deepa Dinamani
struct timex uses struct timeval internally.
struct timeval is not y2038 safe.
Introduce a new UAPI type struct __kernel_timex
that is y2038 safe.
struct __kernel_timex uses a timeval type that is
similar to struct __kernel_timespec which preserves the
same structure size
Alpha has traditionally followed the OSF1 calling conventions
here, with its getxpid, getxuid, getxgid system calls returning
two different values in separate registers.
Following what glibc has done here, we can define getpid,
getuid and getgid to be aliases for getxpid, getxuid and getxgid
As Joseph Myers points out, alpha has never had a standard statfs64
interface and instead returns only 32-bit numbers here.
While there is an old osf_statfs64 system call that returns additional
data, this has some other quirks and does not get used in glibc.
I considered making the stat64
On 1/18/19 11:18 AM, Arnd Bergmann wrote:
This is a minor update of the patches I posted last week, I
would like to add this into linux-next now, but would still do
changes if there are concerns about the contents. The first
version did not see a lot of replies, which could mean that
either
Michael,
On Thu, 19 Apr 2018, Michael Schmitz wrote:
> --- /dev/null
> +++ b/drivers/net/phy/asix.c
> @@ -0,0 +1,63 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Driver for Asix PHYs
> + *
> + * Author: Michael Schmitz
> + *
> + * This program is free software; you can redistribute it and/or
On Fri, Jan 18, 2019 at 8:53 PM Andy Lutomirski wrote:
> I think we have two issues if we reuse those numbers for new syscalls.
> First, I'd really like to see new syscalls be numbered consistently
> everywhere, or at least on all x86 variants, and we can't on x32
> because they mean something
On Fri, Jan 18, 2019 at 7:50 PM Andy Lutomirski wrote:
> On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote:
> > - Once we get to 512, we clash with the x32 numbers (unless
> > we remove x32 support first), and probably have to skip
> > a few more. I also considered using the 512..547 space
On Fri, 2019-01-18 at 11:57 -0500, Dennis Clarke wrote:
> On 1/18/19 11:18 AM, Arnd Bergmann wrote:
> > This is a minor update of the patches I posted last week, I
> > would like to add this into linux-next now, but would still do
> > changes if there are concerns about the contents. The first
> >
On Fri, Jan 18, 2019 at 6:20 PM Gabriel Paubert wrote:
>
> On Fri, Jan 18, 2019 at 05:18:19PM +0100, Arnd Bergmann wrote:
> > The IPC system call handling is highly inconsistent across architectures,
> > some use sys_ipc, some use separate calls, and some use both. We also
> > have some
On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote:
>
> This adds 21 new system calls on each ABI that has 32-bit time_t
> today. All of these have the exact same semantics as their existing
> counterparts, and the new ones all have macro names that end in 'time64'
> for clarification.
>
> This
On Fri, Jan 18, 2019 at 11:33 AM Arnd Bergmann wrote:
>
> On Fri, Jan 18, 2019 at 7:50 PM Andy Lutomirski wrote:
> > On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote:
> > > - Once we get to 512, we clash with the x32 numbers (unless
> > > we remove x32 support first), and probably have to
On Fri, Jan 18, 2019 at 05:18:19PM +0100, Arnd Bergmann wrote:
> The IPC system call handling is highly inconsistent across architectures,
> some use sys_ipc, some use separate calls, and some use both. We also
> have some architectures that require passing IPC_64 in the flags, and
> others that
On Wed, Jan 16, 2019 at 03:44:19PM +0200, Mike Rapoport wrote:
> Add check for the return value of memblock_alloc*() functions and call
> panic() in case of error.
> The panic message repeats the one used by panicing memblock allocators with
> adjustment of parameters to include only relevant
On Wed, Jan 16, 2019 at 03:44:21PM +0200, Mike Rapoport wrote:
> As all the memblock allocation functions return NULL in case of error
> rather than panic(), the duplicates with _nopanic suffix can be removed.
>
> Signed-off-by: Mike Rapoport
> ---
> arch/arc/kernel/unwind.c | 3 +--
>
40 matches
Mail list logo
