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
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
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
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
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 +
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
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
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
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
On Fri, Jan 18, 2019 at 5:15 PM Jann Horn wrote:
>
> Multiple filesystems can already return EFSCORRUPTED errors to userspace;
> however, so far, definitions of EFSCORRUPTED were in filesystem-private
> headers.
>
> I wanted to use EUCLEAN to indicate data corruption in the VFS layer;
> Dave
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 set it implicitly.
For the additon of a y2083 safe semtimedop() system
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 Tue, Jan 15, 2019 at 1:01 AM Dave Chinner wrote:
> On Mon, Jan 14, 2019 at 07:23:17PM +0100, Jann Horn wrote:
> > When you e.g. run `find` on a directory for which getdents returns
> > "filenames" that contain slashes, `find` passes those "filenames" back to
> > the kernel, which then
When I merged this patch, the file was accidentally left intact
instead of being removed, which means any changes to syscall.tbl
have no effect.
Fixes: 2b3c5a99d5f3 ("sh: generate uapi header and syscall table header files")
Signed-off-by: Arnd Bergmann
---
arch/sh/include/uapi/asm/unistd_32.h
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,
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 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
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
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,
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
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
---
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
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
---
__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
Multiple filesystems can already return EFSCORRUPTED errors to userspace;
however, so far, definitions of EFSCORRUPTED were in filesystem-private
headers.
I wanted to use EUCLEAN to indicate data corruption in the VFS layer;
Dave Chinner says that I should instead hoist the definitions of
When you e.g. run `find` on a directory for which getdents returns
"filenames" that contain slashes, `find` passes those "filenames" back to
the kernel, which then interprets them as paths. That could conceivably
cause userspace to do something bad when accessing something like an
untrusted USB
As Al Viro pointed out, many filldir_t functions return error codes, but
all callers of filldir_t functions just check whether the return value is
non-zero (to determine whether to continue reading the directory); more
precise errors have to be signalled via struct dir_context.
Change all
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 +--
>
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 Fri, Jan 18, 2019 at 12:19:52AM +, Maciej W. Rozycki wrote:
> (much useful information set in the appropriate historical context)
Thank you for your thoughts.
The earlier reported problem with "/lib/systemd/systemd-udevd" evidently
requiring AF_UNIX socket support to be built-in rather
On Wed, 16 Jan 2019, Bob Tracy wrote:
> Odd thing about the disk partitioning scheme. The disk label definitely
> has to be "bsd" for SRM to be happy, but if Linux is the only OS on the
> disk, all the rest of the BSD partitioning conventions don't have to be
> observed as far as slice "c"
On Wed 2019-01-16 15:44:21, 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.
[...]
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index c4f0a41..ae65221 100644
On Wed, Jan 16, 2019 at 03:44:19PM +0200, Mike Rapoport wrote:
> arch/csky/mm/highmem.c| 5 +
...
> diff --git a/arch/csky/mm/highmem.c b/arch/csky/mm/highmem.c
> index 53b1bfa..3317b774 100644
> --- a/arch/csky/mm/highmem.c
> +++ b/arch/csky/mm/highmem.c
> @@ -141,6
On Wed, Jan 16, 2019 at 01:10:14AM -0600, Bob Tracy wrote:
> (initramfs / systemd / udevd issue)
I think I may have this one painted into a corner...
CONFIG_UNIX (at least) needs to be "y" instead of "m". This is a
relatively new dependency.
For userland applications used in the boot process
Mein Name ist Friedrich Mayrhofer, meine Frau und ich haben im Dezember 2015
eine Jackpot-Lotterie in Höhe von 50 Millionen Dollar gewonnen. Wir spenden die
Summe von 2.800.000 Millionen Euro an 5 glückliche Personen, von denen Sie
einer der Begünstigten sind. und wir spenden 2.800.000,00
From: Mike Rapoport
Date: Wed, 16 Jan 2019 15:44:15 +0200
> Add panic() calls if memblock_alloc*() returns NULL.
>
> Most of the changes are simply addition of
>
> if(!ptr)
> panic();
>
> statements after the calls to memblock_alloc*() variants.
>
> Exceptions are
On 16/01/2019 14:44, 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 ones.
>
> The
Hi,
Current memblock API is quite extensive and, which is more annoying,
duplicated. Except the low-level functions that allow searching for a free
memory region and marking it as reserved, memblock provides three (well,
two and a half) sets of functions to allocate memory. There are several
The memblock_phys_alloc_try_nid() function tries to allocate memory from
the requested node and then falls back to allocation from any node in the
system. The memblock_alloc_base() fallback used by this function panics if
the allocation fails.
Replace the memblock_alloc_base() fallback with the
The allocation of the page tables memory in openrics uses
memblock_phys_alloc() and then converts the returned physical address to
virtual one. Use memblock_alloc_raw() and add a panic() if the allocation
fails.
Signed-off-by: Mike Rapoport
---
arch/openrisc/mm/init.c | 5 -
1 file changed,
The last parameter of memblock_alloc_from() is the lower limit for the
memory allocation. When it is 0, the call is equivalent to
memblock_alloc().
Signed-off-by: Mike Rapoport
---
arch/alpha/kernel/core_cia.c | 2 +-
arch/alpha/kernel/pci_iommu.c | 4 ++--
arch/alpha/kernel/setup.c | 2
The __memblock_alloc_base() function tries to allocate a memory up to the
limit specified by its max_addr parameter. Depending on the value of this
parameter, the __memblock_alloc_base() can is replaced with the appropriate
memblock_phys_alloc*() variant.
Signed-off-by: Mike Rapoport
---
The memblock_alloc_base() function tries to allocate a memory up to the
limit specified by its max_addr parameter and panics if the allocation
fails. Replace its usage with memblock_phys_alloc_range() and make the
callers check the return value and panic in case of error.
Signed-off-by: Mike
Currently, memblock has several internal functions with overlapping
functionality. They all call memblock_find_in_range_node() to find free
memory and then reserve the allocated range and mark it with kmemleak.
However, there is difference in the allocation constraints and in fallback
strategies.
memblock_alloc() already clears the allocated memory, no point in doing it
twice.
Signed-off-by: Mike Rapoport
---
arch/c6x/mm/init.c | 1 -
arch/h8300/mm/init.c| 1 -
arch/ia64/kernel/mca.c | 2 --
arch/m68k/mm/mcfmmu.c | 1 -
arch/microblaze/mm/init.c | 6 ++
Add panic() calls if memblock_alloc*() returns NULL.
Most of the changes are simply addition of
if(!ptr)
panic();
statements after the calls to memblock_alloc*() variants.
Exceptions are pcpu_populate_pte() and kernel_map_range() that were
slightly refactored to
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 ones.
The replacement was mostly automated with semantic patches like the
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 +--
arch/sh/mm/init.c | 2 +-
arch/x86/kernel/setup_percpu.c | 10
Add panic() calls if memblock_alloc() returns NULL.
The panic() format duplicates the one used by memblock itself and in order
to avoid explosion with long parameters list replace open coded allocation
size calculations with a local variable.
Signed-off-by: Mike Rapoport
---
init/main.c | 26
Add panic() calls if memblock_alloc() returns NULL.
The panic() format duplicates the one used by memblock itself and in order
to avoid explosion with long parameters list replace open coded allocation
size calculations with a local variable.
Signed-off-by: Mike Rapoport
---
Add panic() calls if memblock_alloc() returns NULL.
The panic() format duplicates the one used by memblock itself and in order
to avoid explosion with long parameters list replace open coded allocation
size calculations with a local variable.
Signed-off-by: Mike Rapoport
---
mm/percpu.c | 73
As all the memblock_alloc*() users are now checking the return value and
panic() in case of error, the panic() call can be removed from the core
memblock allocator, namely memblock_alloc_try_nid().
Signed-off-by: Mike Rapoport
---
mm/memblock.c | 15 +--
1 file changed, 5
Add panic() calls if memblock_alloc*() returns NULL.
Most of the changes are simply addition of
if(!ptr)
panic();
statements after the calls to memblock_alloc*() variants.
Exceptions are create_mem_map_page_table() and ia64_log_init() that were
slightly refactored to
These functions are not used outside memblock. Make them static.
Signed-off-by: Mike Rapoport
---
include/linux/memblock.h | 4
mm/memblock.c| 4 ++--
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index
Make the memblock_phys_alloc() function an inline wrapper for
memblock_phys_alloc_range() and update the memblock_phys_alloc() callers to
check the returned value and panic in case of error.
Signed-off-by: Mike Rapoport
---
arch/arm/mm/init.c | 4
arch/arm64/mm/mmu.c
The memblock_alloc_base_nid() is a oneliner wrapper for
memblock_alloc_range_nid() without any side effect.
Replace it's usage by the direct calls to memblock_alloc_range_nid().
Signed-off-by: Mike Rapoport
---
include/linux/memblock.h | 3 ---
mm/memblock.c| 15 ---
2
The calls to memblock_alloc_base(size, align, MEMBLOCK_ALLOC_ANYWHERE) and
memblock_phys_alloc(size, align) are equivalent as both try to allocate
'size' bytes with 'align' alignment anywhere in the memory and panic if hte
allocation fails.
The conversion is done using the following semantic
Arnd Bergmann writes:
> On Mon, Jan 14, 2019 at 4:59 AM Michael Ellerman wrote:
>> Arnd Bergmann writes:
>> > arch/m68k/kernel/syscalls/syscall.tbl | 11 +++
>> > arch/mips/kernel/syscalls/syscall_o32.tbl | 11 +++
>> > arch/powerpc/kernel/syscalls/syscall.tbl | 12
Arnd Bergmann writes:
> On Tue, Jan 15, 2019 at 4:01 PM Arnd Bergmann wrote:
>>
>> On Mon, Jan 14, 2019 at 4:59 AM Michael Ellerman wrote:
>> > Arnd Bergmann writes:
>> > > arch/m68k/kernel/syscalls/syscall.tbl | 11 +++
>> > > arch/mips/kernel/syscalls/syscall_o32.tbl | 11
On Tue, Jan 15, 2019 at 5:36 PM Geert Uytterhoeven wrote:
> On Tue, Jan 15, 2019 at 4:19 PM Arnd Bergmann wrote:
> > On Tue, Jan 15, 2019 at 4:01 PM Arnd Bergmann wrote:
> > > On Mon, Jan 14, 2019 at 4:59 AM Michael Ellerman
> > > wrote:
> > > > Arnd Bergmann writes:
> > > > >
Hi Arnd,
On Tue, Jan 15, 2019 at 4:19 PM Arnd Bergmann wrote:
> On Tue, Jan 15, 2019 at 4:01 PM Arnd Bergmann wrote:
> > On Mon, Jan 14, 2019 at 4:59 AM Michael Ellerman
> > wrote:
> > > Arnd Bergmann writes:
> > > > arch/m68k/kernel/syscalls/syscall.tbl | 11 +++
> > > >
On Tue, Jan 15, 2019 at 4:01 PM Arnd Bergmann wrote:
>
> On Mon, Jan 14, 2019 at 4:59 AM Michael Ellerman wrote:
> > Arnd Bergmann writes:
> > > arch/m68k/kernel/syscalls/syscall.tbl | 11 +++
> > > arch/mips/kernel/syscalls/syscall_o32.tbl | 11 +++
> > >
On Mon, Jan 14, 2019 at 4:59 AM Michael Ellerman wrote:
> Arnd Bergmann writes:
> > arch/m68k/kernel/syscalls/syscall.tbl | 11 +++
> > arch/mips/kernel/syscalls/syscall_o32.tbl | 11 +++
> > arch/powerpc/kernel/syscalls/syscall.tbl | 12
>
> I have some changes
On Tue, Jan 15, 2019 at 12:52 PM Russell King - ARM Linux admin
wrote:
>
> On Thu, Jan 10, 2019 at 05:24:35PM +0100, Arnd Bergmann wrote:
> > 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.
>
On Thu, Jan 10, 2019 at 05:24:35PM +0100, Arnd Bergmann wrote:
> 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
On Mon, Jan 14, 2019 at 07:23:17PM +0100, Jann Horn wrote:
> When you e.g. run `find` on a directory for which getdents returns
> "filenames" that contain slashes, `find` passes those "filenames" back to
> the kernel, which then interprets them as paths. That could conceivably
> cause userspace to
When you e.g. run `find` on a directory for which getdents returns
"filenames" that contain slashes, `find` passes those "filenames" back to
the kernel, which then interprets them as paths. That could conceivably
cause userspace to do something bad when accessing something like an
untrusted USB
As Al Viro pointed out, many filldir_t functions return error codes, but
all callers of filldir_t functions just check whether the return value is
non-zero (to determine whether to continue reading the directory); more
precise errors have to be signalled via struct dir_context.
Change all
Michael Ellerman writes:
> Hi Arnd,
>
> Arnd Bergmann writes:
>> 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
On Fri, Jan 11, 2019 at 06:30:43PM +0100, Arnd Bergmann wrote:
> On Thu, Jan 10, 2019 at 9:36 PM Heiko Carstens
> wrote:
> > On Thu, Jan 10, 2019 at 05:24:35PM +0100, Arnd Bergmann wrote:
>
> > Since you only need/want the system call numbers, could you please
> > change these lines to:
> >
> >
Hi Arnd,
Arnd Bergmann writes:
> 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 set it implicitly.
>
> For the
Hi Arnd,
Arnd Bergmann writes:
> 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 set it implicitly.
>
> For the
On Thu, Jan 10, 2019 at 9:33 PM Heiko Carstens
wrote:
> On Thu, Jan 10, 2019 at 05:24:34PM +0100, Arnd Bergmann wrote:
> > diff --git a/arch/s390/kernel/syscalls/syscall.tbl
> > b/arch/s390/kernel/syscalls/syscall.tbl
> > index 022fc099b628..428cf512a757 100644
> > ---
On Thu, Jan 10, 2019 at 9:36 PM Heiko Carstens
wrote:
> On Thu, Jan 10, 2019 at 05:24:35PM +0100, Arnd Bergmann wrote:
> Since you only need/want the system call numbers, could you please
> change these lines to:
>
> > +384 common pkey_alloc - -
> >
Hi Arnd,
On Thu, Jan 10, 2019 at 11:43 PM Arnd Bergmann wrote:
> On Thu, Jan 10, 2019 at 7:11 PM Geert Uytterhoeven
> wrote:
> > On Thu, Jan 10, 2019 at 6:06 PM Arnd Bergmann wrote:
> > > On Thu, Jan 10, 2019 at 5:59 PM Geert Uytterhoeven
> > > wrote:
> > > > On Thu, Jan 10, 2019 at 5:26 PM
On Thu, Jan 10, 2019 at 11:42:32PM +0100, Arnd Bergmann wrote:
> On Thu, Jan 10, 2019 at 7:10 PM Joseph Myers wrote:
> >
> > On Thu, 10 Jan 2019, Arnd Bergmann wrote:
> >
> > > - Add system calls that have not yet been integrated into all
> > > architectures but that we definitely want there.
>
On Thu, Jan 10, 2019 at 7:11 PM Geert Uytterhoeven wrote:
> On Thu, Jan 10, 2019 at 6:06 PM Arnd Bergmann wrote:
> > On Thu, Jan 10, 2019 at 5:59 PM Geert Uytterhoeven
> > wrote:
> > > On Thu, Jan 10, 2019 at 5:26 PM Arnd Bergmann wrote:
> > > > The system call tables have diverged a bit over
On Thu, Jan 10, 2019 at 7:10 PM Joseph Myers wrote:
>
> On Thu, 10 Jan 2019, Arnd Bergmann wrote:
>
> > - Add system calls that have not yet been integrated into all
> > architectures but that we definitely want there.
>
> glibc has a note that alpha lacks statfs64, any plans for that?
Good
On Thu, Jan 10, 2019 at 06:22:12PM +0100, Arnd Bergmann wrote:
> diff --git a/arch/s390/kernel/syscalls/syscall.tbl
> b/arch/s390/kernel/syscalls/syscall.tbl
> index f84ea364a302..b3199a744731 100644
> --- a/arch/s390/kernel/syscalls/syscall.tbl
> +++ b/arch/s390/kernel/syscalls/syscall.tbl
> @@
On Thu, Jan 10, 2019 at 05:24:35PM +0100, Arnd Bergmann wrote:
> 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
On Thu, Jan 10, 2019 at 05:24:34PM +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
Hi Arnd,
On Thu, Jan 10, 2019 at 6:06 PM Arnd Bergmann wrote:
> On Thu, Jan 10, 2019 at 5:59 PM Geert Uytterhoeven
> wrote:
> > On Thu, Jan 10, 2019 at 5:26 PM Arnd Bergmann wrote:
> > > The system call tables have diverged a bit over the years, and a number
> > > of the recent additions
On Thu, 10 Jan 2019, Arnd Bergmann wrote:
> - Add system calls that have not yet been integrated into all
> architectures but that we definitely want there.
glibc has a note that alpha lacks statfs64, any plans for that?
--
Joseph S. Myers
jos...@codesourcery.com
This series finally gets us to the point of having system calls with
64-bit time_t on all architectures, after a long time of incremental
preparation patches.
There was actually one conversion that I missed during the summer,
i.e. Deepa's timex series, which I now updated based the 5.0-rc1
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
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
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
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
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
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
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
---
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
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,
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
On Thu, Jan 10, 2019 at 5:39 PM Will Deacon wrote:
>
> > diff --git a/arch/arm64/include/asm/unistd32.h
> > b/arch/arm64/include/asm/unistd32.h
> > index 355fe2bc035b..19f3f58b6146 100644
> > --- a/arch/arm64/include/asm/unistd32.h
> > +++ b/arch/arm64/include/asm/unistd32.h
> > @@ -823,6 +823,8
On Thu, Jan 10, 2019 at 5:32 PM Will Deacon wrote:
> > diff --git a/arch/arm64/include/asm/unistd32.h
> > b/arch/arm64/include/asm/unistd32.h
> > index 04ee190b90fe..355fe2bc035b 100644
> > --- a/arch/arm64/include/asm/unistd32.h
> > +++ b/arch/arm64/include/asm/unistd32.h
> > @@ -821,6 +821,8
On Thu, Jan 10, 2019 at 5:59 PM Geert Uytterhoeven wrote:
>
> Hi Arnd,
>
> On Thu, Jan 10, 2019 at 5:26 PM Arnd Bergmann wrote:
> > The system call tables have diverged a bit over the years, and a number
> > of the recent additions never made it into all architectures, for one
> > reason or
Hi Arnd,
On Thu, Jan 10, 2019 at 5:26 PM Arnd Bergmann wrote:
> The system call tables have diverged a bit over the years, and a number
> of the recent additions never made it into all architectures, for one
> reason or another.
>
> This is an attempt to clean it up as far as we can without
1001 - 1100 of 2609 matches
Mail list logo
