travis-ci: import travis yaml controller

.travis.yml is used for automatic builds on travis build farm
(https://travis-ci.org/) if the travis service hook is enabled for the
repo on github.

This inital yaml controller will run 2 different compilers (gcc, clang).
The test suite currently fails, that's why we don't abort yet.
docs: refresh TODO

Signed-off-by: Karel Zak <kzak@redhat.com>
umount: don't use mountinfo if possible

The umount(8) always parses /proc/self/mountinfo to get fstype and to
merge kernel mount options with userspace mount options from
/run/mount/utab. This behavior is overkill in many cases and it's
pretty expensive as kernel has to always compose *whole* mountinfo.
This performance disadvantage is visible for crazy use-cases with huge
number of mountpoints and frequently called umount(8).

It seems that we can bypass /proc/self/mountinfo by statfs() to get
filesystem type (statfs.f_type magic) and analyze /run/mount/utab
before we parse mountinfo.

This optimization is not used when:

 * umount(8) executed by non-root (as user= in utab is expected)
 * umount --lazy / --force (target is probably unreachable NFS, then
   use statfs() is pretty bad idea)
 * target is not a directory (e.g. umount /dev/sda1)
 * there is (deprecated) writeable mtab

Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Karel Zak <kzak@redhat.com>
libmount: cgroup magic already defined

Signed-off-by: Karel Zak <kzak@redhat.com>
partx: make dirent d_type usage more robust

Signed-off-by: Karel Zak <kzak@redhat.com>
lib/sysfs: make dirent d_type usage more robust

Signed-off-by: Karel Zak <kzak@redhat.com>
switch_root: make dirent d_type usage more robust

Signed-off-by: Karel Zak <kzak@redhat.com>
lscpu: don't assume filesystem supports d_type when searching for NUMA nodes

Not all file systems support the d_type field and simply checking for
d_type == DT_DIR in is_node_dirent would cause the test suite to fail
if run on (for example) XFS.

The simple fix is to check for DT_DIR or DT_UNKNOWN in is_node_dirent.

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
lscpu: read_hypervisor_dmi: only fallback to memory scan on x86/x86_64

As the comment in the code says, this method is really only valid
on x86 and x86_64, so add a #ifdef for those architectures around
that code block.

This was causing "Program lscpu tried to access /dev/mem between f0000->100000."
warnings on some ppc64 machines.

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
hexdump: color unit may now be longer than the corresponding format unit

Signed-off-by: Ondrej Oprala <ooprala@redhat.com>
logger: allow user to send structured journald messages

This feature is hopefully mostly used to give MESSAGE_ID labels for
messages coming from scripts, making search of messages easy.  The
logger(1) manual page update should give enough information how to use
--journald option.

[kzak@redhat.com: - add missing #ifdefs
                  - use xalloc.h]

Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Signed-off-by: Karel Zak <kzak@redhat.com>
docs: fix two command representations in the man page of more

The previous-file command is not :P but :p, and the back-to-where
command is not an acute accent but an apostrophe.  Also condense
some of the descriptions and remove some useless comments.

Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
Merge branch 'master' of https://github.com/rudimeier/util-linux

* 'master' of https://github.com/rudimeier/util-linux:
  travis-ci: import travis yaml controller
build-sys: don't connect _DEPENDENCIES and _LIBADD

The _DEPENDENCIES has to be used for dependencies on another in-tree
files, but _LIBADD is to specify additional libs (including external
libs).

Reported-by: oleid <notifications@github.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
chcpu: cleanup return codes

The code currently always return EXIT_SUCCESS, that's strange. It
seems better to return 0 on success, 1 on complete failure and 64 on
partial success.

Signed-off-by: Karel Zak <kzak@redhat.com>
chcpu: cleanup stdout/stderr usage

Signed-off-by: Karel Zak <kzak@redhat.com>
libmount: define BTRFS_TEST_MAGIC if missing

* libmount/src/utils.c (BTRFS_TEST_MAGIC): Conditionally add define
which is used since commit v2.24-243-g6a52473.

Signed-off-by: Bernhard Voelker <mail@bernhard-voelker.de>
hwclock: fix possible hang and other set_hardware_clock_exact() issues

In sys-utils/hwclock.c, set_hardware_clock_exact() has some problems when the
process gets pre-empted (for more than 100ms) before reaching the time for
which it waits:

1. The "continue" statement causes execution to skip the final tdiff
assignment at the end of the do...while loop, leading to the while condition
using the wrong value of tdiff, and thus always exiting the loop once
newhwtime != sethwtime (e.g., after 1 second).  This masks bug # 2, below.

2. The previously-existing bug is that because it starts over waiting for the
desired time whenever two successive calls to gettimeofday() return values >
100ms apart, the loop will never terminate unless the process holds the CPU
(without losing it for more than 100ms) for at least 500ms.  This can happen
on a heavily loaded machine or on a virtual machine (or on a heavily loaded
virtual machine).  This has been observed to occur, preventing a machine from
completing the shutdown or reboot process due to a "hwclock --systohc" call in
a shutdown script.

The new implementation presented in this patch takes a somewhat different
approach, intended to accomplish the same goals:

It computes the desired target system time (at which the requested hardware
clock time will be applied to the hardware clock), and waits for that time to
arrive.  If it misses the time (such as due to being pre-empted for too long),
it recalculates the target time, and increases the tolerance (how late it can
be relative to the target time, and still be "close enough".  Thus, if all is
well, the time will be set *very* precisely.  On a machine where the hwclock
process is repeatedly pre-empted, it will set the time as precisely as is
possible under the conditions present on that particular machine.  In any
case, it will always terminate eventually (and pretty quickly); it will never
hang forever.

[kzak@redhat.com: - tiny coding style changes]

Signed-off-by: Chris MacGregor <chrismacgregor@google.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
build-sys: remove deprecated-mount/

Signed-off-by: Karel Zak <kzak@redhat.com>
libmount: add statfs_magic.h

Signed-off-by: Karel Zak <kzak@redhat.com>