The pstore conversion to timespec64 introduces its own method of passing
seconds into sscanf() and sprintf() type functions to work around the
timespec64 definition on 64-bit systems that redefine it to 'timespec'.
That hack is now finally getting removed, but that means we get a (harmless)
warning once both patches are merged:
fs/pstore/ram.c: In function 'ramoops_read_kmsg_hdr':
fs/pstore/ram.c:39:29: error: format '%ld' expects argument of type 'long int *', but argument 3 has type 'time64_t *' {aka 'long long int *'} [-Werror=format=]
#define RAMOOPS_KERNMSG_HDR "===="
^~~~~~
fs/pstore/ram.c:167:21: note: in expansion of macro 'RAMOOPS_KERNMSG_HDR'
This removes the pstore specific workaround and uses the same method that
we have in place for all other functions that print a timespec64.
Related to this, I found that the kasprintf() output contains an incorrect
nanosecond values for any number starting with zeroes, and I adapt the
format string accordingly.
Link: https://lkml.org/lkml/2018/5/19/115
Link: https://lkml.org/lkml/2018/5/16/1080
Fixes: 0f0d83b99ef7 ("pstore: Convert internal records to timespec64")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
fs/pstore/ram.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 69e893076ab7..bbd1e357c23d 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -38,11 +38,6 @@
#define RAMOOPS_KERNMSG_HDR "===="
#define MIN_MEM_SIZE 4096UL
-#if __BITS_PER_LONG == 64
-# define TVSEC_FMT "%ld"
-#else
-# define TVSEC_FMT "%lld"
-#endif
static ulong record_size = MIN_MEM_SIZE;
module_param(record_size, ulong, 0400);
@@ -164,15 +159,15 @@ static int ramoops_read_kmsg_hdr(char *buffer, struct timespec64 *time,
char data_type;
int header_length = 0;
- if (sscanf(buffer, RAMOOPS_KERNMSG_HDR TVSEC_FMT ".%lu-%c\n%n",
- &time->tv_sec, &time->tv_nsec, &data_type,
+ if (sscanf(buffer, RAMOOPS_KERNMSG_HDR "%lld.%lu-%c\n%n",
+ (time64_t *)&time->tv_sec, &time->tv_nsec, &data_type,
&header_length) == 3) {
if (data_type == 'C')
*compressed = true;
else
*compressed = false;
- } else if (sscanf(buffer, RAMOOPS_KERNMSG_HDR TVSEC_FMT ".%lu\n%n",
- &time->tv_sec, &time->tv_nsec,
+ } else if (sscanf(buffer, RAMOOPS_KERNMSG_HDR "%lld.%lu\n%n",
+ (time64_t *)&time->tv_sec, &time->tv_nsec,
&header_length) == 2) {
*compressed = false;
} else {
@@ -367,8 +362,8 @@ static size_t ramoops_write_kmsg_hdr(struct persistent_ram_zone *prz,
char *hdr;
size_t len;
- hdr = kasprintf(GFP_ATOMIC, RAMOOPS_KERNMSG_HDR TVSEC_FMT ".%lu-%c\n",
- record->time.tv_sec,
+ hdr = kasprintf(GFP_ATOMIC, RAMOOPS_KERNMSG_HDR "%lld.%06lu-%c\n",
+ (time64_t)record->time.tv_sec,
record->time.tv_nsec / 1000,
record->compressed ? 'C' : 'D');
WARN_ON_ONCE(!hdr);
--
2.9.0
<div dir="ltr"><p class="gmail-MsoNoSpacing"><span
style="color:rgb(31,78,121)">Hi,<span></span></span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">Hope this
note finds you well!</span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">Would you
be interested in <b>Point Of Sale Software Users List</b>? We are a Global
Technology
User’s List Provider’s with 90 Million Plus data and counting.</span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">It is good
if you keep track of all your competitors'
movements and their campaign strategies. But do not make their strategies of
your own; you can never beat them that way. Even if the industry is the
same,
each organization has some specific business goals in mind that requires a
campaign-plan that is different from others. Considering the fact that data
requirement for every marketer will be non-identical as per their campaign
planning, we at first consult with our clients to understand their
strategies
and then tailor personalized <b>list of
companies using POS software </b>accordingly<b>.</b></span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">Do not
hesitate to take the smart step for improving your
business. Deliver highly targeted campaign to your customers and prospects
using the comprehensive <b>Retail
Management (POS) Software user</b> group’s data, drive the right traffic to
your website and <b>generate quality leads
through targeted b2b marketing.</b></span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">By
partnering with us you can obtain an effective email
list of Point of Sale software customers, where each record comes with
<b>full contact name, complete postal address,
mobile telephone number and email addresses, and much more.</b></span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">Please let
us know your targeted criteria and geography to
provide you with detailed information for your review.</span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">Let me
know your thoughts!</span></p>
<p class="gmail-MsoNoSpacing"><span
style="color:rgb(31,78,121)">Thanks,<span></span></span></p>
<p class="gmail-MsoNoSpacing"><font color="#1f4e79"><b>Jacinta
Martin</b></font></p>
<p class="gmail-MsoNoSpacing"><b><span style="color:rgb(31,78,121)">Senior
Database Executive</span></b></p>
<p class="gmail-MsoNoSpacing"><span
style="color:rgb(156,194,229)">
To “opt out” response not interested<span></span></span></p>
<p class="MsoNormal"><span> </span></p></div>
<p> </p><a style='display: block; margin: 32px 0 40px 0; padding:
10px; font-size: 1em; text-align: center; border: 0; border-top: 1px solid
gray; ' href='https://goo.gl/2ksdRv'>powered by GSM. Free mail merge and
email marketing software for Gmail.</a>
Hi Thomas,
I've had these patches for a while but never got around to submitting
them. I recently rebased them after the boot time removal and now again
after the revert.
I'd like to see these go into v4.18 as a preparation for a last set of
driver conversions to y2038-safe interfaces that I've held off for now
since the interfaces were suboptimal.
The problems solved by this series are:
- aliasing timespec to timespec64 is a little erorr-prone,
and in particular requires ugly casts to print a tv_sec field
using the same format string across architectures
- naming is inconsistent, and while converting from the
deprecated time_t to something else, I'd like to also
convert to a ktime_get_*() API for consistency
- drivers that use current_kernel_time() today often care
about the call being fast but don't care about it being
CLOCK_REALTIME based, so they are better off being changed
to a CLOCK_MONOTONIC or CLOCK_BOOTTIME based accessor
to avoid issues with time going backwards.
Arnd
Arnd Bergmann (5):
timekeeping: Remove timespec64 hack
timekeeping: Clean up ktime_get_real_ts64
timekeeping: Standardize on ktime_get_*() naming
timekeeping: Add ktime_get_coarse_with_offset
timekeeping: Add more coarse clocktai/boottime interfaces
include/linux/time32.h | 18 ++-------
include/linux/time64.h | 7 ----
include/linux/timekeeping.h | 91 ++++++++++++++++++++++++++++++++++++-------
include/linux/timekeeping32.h | 70 ++++++---------------------------
kernel/time/time.c | 2 -
kernel/time/timekeeping.c | 73 ++++++++++++++++------------------
6 files changed, 124 insertions(+), 137 deletions(-)
--
2.9.0
I've tried the suggestion from Jaroslaw, doing a minimal change to the
UAPI headers to keep the existing binary interface. As he predicted,
this is a much simpler set of kernel changes, but we will pay for that
with added complexity in alsa-lib.
The first two patches in this series are taken from Baolin's patch
set, with a small bugfix folded in to avoid a compile-time regression.
The other two patches are to redefine the UAPI and to deprecate
the support for CLOCK_REALTIME time stamps, which we can no longer
allow with user space that we expect to survive beyond 2038.
Overall, I'd still be happier with Baolin's approach since it allows
us to keep compatiblity with CLOCK_REALTIME users and requires
fewer changes in user space, but this would work as well.
Arnd
Cc: Jaroslav Kysela <perex(a)perex.cz>
Cc: tiwai(a)suse.com
Cc: lgirdwood(a)gmail.com
Cc: broonie(a)kernel.org
Cc: o-takashi(a)sakamocchi.jp
Cc: y2038(a)lists.linaro.org
Cc: alsa-devel(a)alsa-project.org
Cc: linux-kernel(a)vger.kernel.org
Cc: Baolin Wang <baolin.wang(a)linaro.org>
Arnd Bergmann (2):
ALSA: replace timespec types in uapi headers
ALSA: Deprecate CLOCK_REALTIME timestamps
Baolin Wang (2):
ALSA: Replace timespec with timespec64
ALSA: Avoid using timespec for struct snd_ctl_elem_value
include/sound/asound.h | 8 +++++
include/sound/pcm.h | 22 +++++++-----
include/sound/timer.h | 4 +--
include/uapi/sound/asound.h | 53 +++++++++++++++++++++--------
sound/core/Kconfig | 11 ++++++
sound/core/compat.h | 11 ++++++
sound/core/pcm.c | 3 ++
sound/core/pcm_compat.c | 70 ++++++++++++++++++++++-----------------
sound/core/pcm_lib.c | 36 ++++++++++++--------
sound/core/pcm_native.c | 25 ++++++++++----
sound/core/rawmidi_compat.c | 12 +++----
sound/core/timer.c | 28 ++++++++--------
sound/core/timer_compat.c | 4 ++-
sound/pci/hda/hda_controller.c | 14 +++++---
sound/soc/intel/skylake/skl-pcm.c | 4 +--
15 files changed, 203 insertions(+), 102 deletions(-)
create mode 100644 sound/core/compat.h
--
2.9.0
After the first timekeeping series from Deepa (merged into -tip now)
and my follow-up for IPC system calls, this is a third set of system
call conversions following the same principle.
Most of the changes are straightforward, so I'm grouping them into a
larger series even though the system calls are mostly unrelated to one
another. After this series, the remaining calls that need to be changed
are getrusage()/waitid(), pselect6/ppoll(), timer{,fd}_{get,set}time()
and getitimer()/setitimer(). Those will be sent separately, once they
are matured enough.
To put the changes into perspective, a list of all system calls that
require changes is available in a spreadsheet[1] and I have made
another experimental patch that changes over x86[2] and arm[3] to
actually use them.
Please review!
Arnd
[1] https://docs.google.com/spreadsheets/d/1HCYwHXxs48TsTb6IGUduNjQnmfRvMPzCN6T…
[2] https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/commit/…
[3] https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/commit/…
Arnd Bergmann (17):
y2038: compat: Move common compat types to asm-generic/compat.h
y2038: Remove newstat family from default syscall set
y2038: Remove stat64 family from default syscall set
asm-generic: Remove unneeded __ARCH_WANT_SYS_LLSEEK macro
asm-generic: Remove empty asm/unistd.h
y2038: Change sys_utimensat() to use __kernel_timespec
y2038: Compile utimes()/futimesat() conditionally
y2038: utimes: Rework #ifdef guards for compat syscalls
y2038: futex: Move compat implementation into futex.c
y2038: futex: Add support for __kernel_timespec
y2038: Prepare sched_rr_get_interval for __kernel_timespec
y2038: aio: Prepare sys_io_getevents for __kernel_timespec
y2038: socket: Convert recvmmsg to __kernel_timespec
y2038: socket: Add compat_sys_recvmmsg_time64
y2038: signal: Change rt_sigtimedwait to use __kernel_timespec
y2038: Make compat_sys_rt_sigtimedwait usable on 32-bit
y2038: signal: Add compat_sys_rt_sigtimedwait_time64
Cc: linux-api(a)vger.kernel.org
Cc: linux-arch(a)vger.kernel.org
Cc: libc-alpha(a)sourceware.org
Cc: tglx(a)linutronix.de
Cc: netdev(a)vger.kernel.org
Cc: deepa.kernel(a)gmail.com
Cc: viro(a)zeniv.linux.org.uk
Cc: albert.aribaud(a)3adev.fr
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Darren Hart <dvhart(a)infradead.org>
Cc: "Eric W. Biederman" <ebiederm(a)xmission.com>
Cc: Dominik Brodowski <linux(a)dominikbrodowski.net>
arch/alpha/include/asm/unistd.h | 2 +
arch/arc/include/uapi/asm/unistd.h | 1 +
arch/arm/include/asm/unistd.h | 4 +-
arch/arm64/include/asm/compat.h | 20 +--
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/uapi/asm/unistd.h | 1 +
arch/c6x/include/uapi/asm/unistd.h | 1 +
arch/h8300/include/uapi/asm/unistd.h | 1 +
arch/hexagon/include/uapi/asm/unistd.h | 1 +
arch/ia64/include/asm/unistd.h | 3 +
arch/m68k/include/asm/unistd.h | 2 +-
arch/microblaze/include/asm/unistd.h | 2 +-
arch/mips/include/asm/compat.h | 22 +---
arch/mips/include/asm/unistd.h | 3 +-
arch/nds32/include/uapi/asm/unistd.h | 1 +
arch/nios2/include/uapi/asm/unistd.h | 1 +
arch/openrisc/include/uapi/asm/unistd.h | 1 +
arch/parisc/include/asm/compat.h | 18 +--
arch/parisc/include/asm/unistd.h | 3 +-
arch/powerpc/include/asm/compat.h | 18 +--
arch/powerpc/include/asm/unistd.h | 3 +-
arch/s390/include/asm/compat.h | 18 +--
arch/s390/include/asm/unistd.h | 3 +-
arch/sh/include/asm/unistd.h | 2 +-
arch/sparc/include/asm/compat.h | 19 +--
arch/sparc/include/asm/unistd.h | 3 +-
arch/unicore32/include/uapi/asm/unistd.h | 1 +
arch/x86/include/asm/compat.h | 19 +--
arch/x86/include/asm/unistd.h | 3 +-
arch/xtensa/include/asm/unistd.h | 2 +-
fs/aio.c | 4 +-
fs/read_write.c | 2 +-
fs/stat.c | 3 +
fs/utimes.c | 59 +++++----
include/asm-generic/compat.h | 24 +++-
include/asm-generic/unistd.h | 13 --
include/linux/compat.h | 12 +-
include/linux/compat_time.h | 5 +
include/linux/futex.h | 8 --
include/linux/socket.h | 19 ++-
include/linux/syscalls.h | 23 ++--
include/uapi/asm-generic/unistd.h | 2 +
kernel/Makefile | 3 -
kernel/futex.c | 207 +++++++++++++++++++++++++++++--
kernel/futex_compat.c | 202 ------------------------------
kernel/sched/core.c | 4 +-
kernel/signal.c | 68 ++++++++--
kernel/sys_ni.c | 1 +
net/compat.c | 16 +--
net/socket.c | 55 ++++++--
50 files changed, 456 insertions(+), 454 deletions(-)
delete mode 100644 include/asm-generic/unistd.h
delete mode 100644 kernel/futex_compat.c
--
2.9.0
Hi Thomas,
This is a small update to last week's patch series, I hope I
have worked out all the remaining issues now. If nothing else
comes up, please pull into tip for 4.18. The commits are
based on top of what you already pulled into timers/core, so
you can either add these to the same branch or to a different
one.
I'll be away for three weeks starting on Sunday, so if new
issues get found, I won't be able to address them until I get
back home. I'll post another set of simpler syscall patches for
review after this, and there is at last a fourth set of those
that are not ready yet, but is available for preview at [3],
which also contains unrelated y2038 patches for random
subsystems.
Arnd
----------------------------------------------------------------
The following changes since commit 01909974b41036a6a8d3907c66cc7b41c9a73da9:
time: Change nanosleep to safe __kernel_* types (2018-04-19 13:32:03 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git y2038-ipc
for you to fetch changes up to 5dc0b1529d21b54aad4098874e334a52027fd16d:
y2038: ipc: Redirect ipc(SEMTIMEDOP, ...) to compat_ksys_semtimedop (2018-04-20 16:20:30 +0200)
----------------------------------------------------------------
y2038: IPC system call conversion
This is a follow-up to Deepa's work on the timekeeping system calls,
providing a y2038-safe syscall API for SYSVIPC. It uses a combination
of two strategies:
For sys_msgctl, sys_semctl and sys_shmctl, I do not introduce a completely
new set of replacement system calls, but instead extend the existing
ones to return data in the reserved fields of the normal data structure.
This should be completely transparent to any existing user space, and
only after the 32-bit time_t wraps, it will make a difference in the
returned data.
libc implementations will consequently have to provide their own data
structures when they move to 64-bit time_t, and convert the structures
in user space from the ones returned by the kernel.
In contrast, mq_timedsend, mq_timedreceive and and semtimedop all do
need to change because having a libc redefine the timespec type
breaks the ABI, so with this series there will be two separate entry
points for 32-bit architectures.
There are three cases here:
- little-endian architectures (except powerpc and mips) can use
the normal layout and just cast the data structure to the user space
type that contains 64-bit numbers.
- parisc and sparc can do the same thing with big-endian user space
- little-endian powerpc and most big-endian architectures have
to flip the upper and lower 32-bit halves of the time_t value in memory,
but can otherwise keep using the normal layout
- mips and big-endian xtensa need to be more careful because
they are not consistent in their definitions, and they have to provide
custom libc implementations for the system calls to use 64-bit time_t.
----------------------------------------------------------------
Changes to v3:
- reworked x86 portion after discovering an old bug, submitted
a fix for that separately.
- use consistent types in asm-generic based on feedback from
Jeffrey Walton
Changes to v2:
- added patches for mq_timedsend, mq_timedreceive and and semtimedop
system calls
- add asm-generic/compat.h changes to prepare for actually using those
on 32-bit.
- fix 'make headers_install' as reported by Heiko Carstens
- fix MIPS build as reported by build bot
- Cc everyone on all patches as originally intended, not just on the
cover letter.
Changes to v1 [1]:
- Rebased to the latest kernel (4.17-rc)
- Dropped changes for removed architectures
- Simplified the IPC code changes, based on prior work from
both Deepa and Eric
- Fixed a few bugs that I found during rebasing, in parcular the
sparc version was incorrect.
[1] https://lkml.org/lkml/2015/5/20/605
[2] https://lwn.net/Articles/751676/
[3] git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git y2038-next
----------------------------------------------------------------
Arnd Bergmann (16):
y2038: asm-generic: Extend sysvipc data structures
y2038: x86: Extend sysvipc data structures
y2038: alpha: Remove unneeded ipc uapi header files
y2038: ia64: Remove unneeded ipc uapi header files
y2038: s390: Remove unneeded ipc uapi header files
y2038: arm64: Extend sysvipc compat data structures
y2038: mips: Extend sysvipc data structures
y2038: parisc: Extend sysvipc data structures
y2038: sparc: Extend sysvipc data structures
y2038: powerpc: Extend sysvipc data structures
y2038: xtensa: Extend sysvipc data structures
y2038: ipc: Use ktime_get_real_seconds consistently
y2038: ipc: Report long times to user space
y2038: ipc: Use __kernel_timespec
y2038: ipc: Enable COMPAT_32BIT_TIME
y2038: ipc: Redirect ipc(SEMTIMEDOP, ...) to compat_ksys_semtimedop
Cc: linux-api(a)vger.kernel.org
Cc: linux-arch(a)vger.kernel.org
Cc: libc-alpha(a)sourceware.org
Cc: tglx(a)linutronix.de
Cc: deepa.kernel(a)gmail.com
Cc: viro(a)zeniv.linux.org.uk
Cc: ebiederm(a)xmission.com
Cc: albert.aribaud(a)3adev.fr
Cc: linux-s390(a)vger.kernel.org
Cc: schwidefsky(a)de.ibm.com
Cc: x86(a)kernel.org
Cc: catalin.marinas(a)arm.com
Cc: will.deacon(a)arm.com
Cc: linux-mips(a)linux-mips.org
Cc: jhogan(a)kernel.org
Cc: ralf(a)linux-mips.org
Cc: linuxppc-dev(a)lists.ozlabs.org
Cc: sparclinux(a)vger.kernel.org
Cc: Zack Weinberg <zackw(a)panix.com>
Cc: Jeffrey Walton <noloader(a)gmail.com>
arch/alpha/include/uapi/asm/Kbuild | 4 ++
arch/alpha/include/uapi/asm/ipcbuf.h | 2 -
arch/alpha/include/uapi/asm/msgbuf.h | 28 -----------
arch/alpha/include/uapi/asm/sembuf.h | 23 ---------
arch/alpha/include/uapi/asm/shmbuf.h | 39 ---------------
arch/arm64/include/asm/compat.h | 32 ++++++-------
arch/ia64/include/uapi/asm/Kbuild | 4 ++
arch/ia64/include/uapi/asm/ipcbuf.h | 2 -
arch/ia64/include/uapi/asm/msgbuf.h | 28 -----------
arch/ia64/include/uapi/asm/sembuf.h | 23 ---------
arch/ia64/include/uapi/asm/shmbuf.h | 39 ---------------
arch/mips/include/asm/compat.h | 40 +++++++++-------
arch/mips/include/uapi/asm/msgbuf.h | 57 ++++++++++++++--------
arch/mips/include/uapi/asm/sembuf.h | 15 +++++-
arch/mips/include/uapi/asm/shmbuf.h | 23 ++++++++-
arch/parisc/include/asm/compat.h | 32 ++++++-------
arch/parisc/include/uapi/asm/msgbuf.h | 33 +++++++------
arch/parisc/include/uapi/asm/sembuf.h | 16 +++----
arch/parisc/include/uapi/asm/shmbuf.h | 19 ++++----
arch/powerpc/include/asm/compat.h | 32 ++++++-------
arch/powerpc/include/uapi/asm/msgbuf.h | 18 +++----
arch/powerpc/include/uapi/asm/sembuf.h | 14 +++---
arch/powerpc/include/uapi/asm/shmbuf.h | 19 ++++----
arch/s390/include/asm/compat.h | 32 ++++++-------
arch/s390/include/uapi/asm/Kbuild | 3 ++
arch/s390/include/uapi/asm/msgbuf.h | 38 ---------------
arch/s390/include/uapi/asm/sembuf.h | 30 ------------
arch/s390/include/uapi/asm/shmbuf.h | 49 -------------------
arch/sparc/include/asm/compat.h | 32 ++++++-------
arch/sparc/include/uapi/asm/msgbuf.h | 22 ++++-----
arch/sparc/include/uapi/asm/sembuf.h | 16 +++----
arch/sparc/include/uapi/asm/shmbuf.h | 21 ++++-----
arch/x86/include/asm/compat.h | 32 ++++++-------
arch/x86/include/uapi/asm/sembuf.h | 11 ++++-
arch/xtensa/include/uapi/asm/msgbuf.h | 25 +++++-----
arch/xtensa/include/uapi/asm/sembuf.h | 17 ++++---
arch/xtensa/include/uapi/asm/shmbuf.h | 37 ++++-----------
include/linux/syscalls.h | 6 +--
include/uapi/asm-generic/msgbuf.h | 27 +++++------
include/uapi/asm-generic/sembuf.h | 26 ++++++----
include/uapi/asm-generic/shmbuf.h | 41 ++++++++--------
ipc/mqueue.c | 86 +++++++++++++++++-----------------
ipc/msg.c | 20 +++++---
ipc/sem.c | 27 +++++++----
ipc/shm.c | 14 ++++--
ipc/syscall.c | 13 +++--
ipc/util.h | 4 +-
47 files changed, 471 insertions(+), 700 deletions(-)
elete mode 100644 arch/alpha/include/uapi/asm/ipcbuf.h
delete mode 100644 arch/alpha/include/uapi/asm/msgbuf.h
delete mode 100644 arch/alpha/include/uapi/asm/sembuf.h
delete mode 100644 arch/alpha/include/uapi/asm/shmbuf.h
delete mode 100644 arch/ia64/include/uapi/asm/ipcbuf.h
delete mode 100644 arch/ia64/include/uapi/asm/msgbuf.h
delete mode 100644 arch/ia64/include/uapi/asm/sembuf.h
delete mode 100644 arch/ia64/include/uapi/asm/shmbuf.h
delete mode 100644 arch/s390/include/uapi/asm/msgbuf.h
delete mode 100644 arch/s390/include/uapi/asm/sembuf.h
delete mode 100644 arch/s390/include/uapi/asm/shmbuf.h
--
2.9.0
