include/statfs_magic: use macro rather than type for f_type

Signed-off-by: Karel Zak <kzak@redhat.com>
tests: simplify and update swaplabel test

Signed-off-by: Karel Zak <kzak@redhat.com>
libfdisk: fdisk_read_firstsector should seek to offset 0

The current offset of cxt->dev_fd may not be still 0, notably when
blkdev_get_size has to resort to using blkdev_find_size

Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org
libfdisk: (gpt) make mode more readable

* use check_ prefix for checking functions
* use plural in function names where we work with more partitions than one
* always use "ents" when when we work with gpt entries array

Signed-off-by: Karel Zak <kzak@redhat.com>
libfdisk: (gpt) don't offer first sector before the first partion

The GPT first usable LBA is usually aligned to grain (1MiB), but for small
(<=4MiB) devices we strictly follow sector sizes.

In this case there is a small space in front of the aligned begin of
the first partition. This useless space should not be offered for the
next partitions.

	Sector size (logical/physical): 512 bytes / 4096 bytes
	I/O size (minimum/optimal): 4096 bytes / 32768 bytes
	Disklabel type: gpt
	Disk identifier: 041E2D54-AD0C-4C7E-A50D-363D23058D47

	Device    Start          End Size Type
	/dev/sdb1    40         2087   1M Linux filesystem

	Command (m for help): n
	Partition number (2-128, default 2):
	First sector (34-8158, default 2088):
                      ^^

first usable LBA is 34, but first aligned (recommended) LBA is 40, we
use it for the first partition. All this is correct, but the space
before the first partition should be ignored. Fixed version:

        Command (m for help): n
	Partition number (2-128, default 2):
	First sector (2088-8158, default 2088):
                      ^^^^

Note this problem does not exist for "normal" (large) devices where
first usable LBA is aligned to grain.

Reported-by: Boaz Harrosh <boaz@plexistor.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
build-sys: make scanf_cv_alloc_modifier to work [LeakSanitizer]

The tests failed with following message in config.log

ERROR: LeakSanitizer: detected memory leaks

Direct leak of 2 byte(s) in 1 object(s) allocated from:
    #0 0x49a40e in realloc (/home/src/util-linux/conftest+0x49a40e)
    #1 0x7fbe48633e69 in __GI__IO_vfscanf (/usr/lib/libc.so.6+0x56e69)
    #2 0x7fbe48649786 in _IO_vsscanf (/usr/lib/libc.so.6+0x6c786)

which knocked out libmount from build, and commands depending on it.

The reason this change makes sense is that AddressSanitizer seems like a
good addition to set of tools that util-linux package can use, when and
if needed.

Reference: https://code.google.com/p/address-sanitizer/wiki/AddressSanitizer
Reviewed-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
tests: fix memory leak [AddressSanitizer]

Signed-off-by: Sami Kerola <kerolasa@iki.fi>
libmount: fix memory overflow [AddressSanitizer]

==10918==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffd795b680 at pc 0x0000004447c6 bp 0x7fffd795b3e0 sp 0x7fffd795ab78
WRITE of size 129 at 0x7fffd795b680 thread T0
    #0 0x4447c5 in scanf_common(void*, int, bool, char const*, __va_list_tag*) (/home/src/util-linux/.libs/lt-mount+0x4447c5)
    #1 0x445892 in sscanf (/home/src/util-linux/.libs/lt-mount+0x445892)
    #2 0x7fe78709a3d3 in get_filesystems /home/src/util-linux/libmount/src/utils.c:581:7
    #3 0x7fe78709a1ba in mnt_get_filesystems /home/src/util-linux/libmount/src/utils.c:622:7
    #4 0x7fe7870aa78f in do_mount_by_pattern /home/src/util-linux/libmount/src/context_mount.c:833:7
    #5 0x7fe7870a9534 in mnt_context_do_mount /home/src/util-linux/libmount/src/context_mount.c:951:9
    #6 0x7fe7870aab2b in mnt_context_mount /home/src/util-linux/libmount/src/context_mount.c:1051:8
    #7 0x4ba9f5 in main /home/src/util-linux/sys-utils/mount.c:1107:7
    #8 0x7fe785caa03f in __libc_start_main (/usr/lib/libc.so.6+0x2003f)
    #9 0x4b9f9c in _start (/home/src/util-linux/.libs/lt-mount+0x4b9f9c)

Signed-off-by: Sami Kerola <kerolasa@iki.fi>
tests: skip kill -SEGV test when running AddressSanitizer

Sending signal indicating invalid memory reference makes AddressSanitizer
to report false positive test failure.

Signed-off-by: Sami Kerola <kerolasa@iki.fi>
tests: mark python libmount tests known to fail with AddressSanitizer

The tests fail with an error similar to this.

Traceback (most recent call last):
  File "/home/src/util-linux/libmount/python/test_mount_tab_update.py", line 7, in <module>
    import pylibmount as mnt
ImportError: /home/src/util-linux/.libs/libuuid.so.1: undefined symbol: __asan_option_detect_stack_use_after_return

It might be possible to build ASAN-DSO and set LD_PRELOAD, but this
solution is not officially supported.  See the reference for details.

Reference: https://code.google.com/p/address-sanitizer/wiki/AsanAsDso
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
mkswap: remove memory leaks [LeakSanitizer] [valgrind]

==18922==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 8 byte(s) in 1 object(s) allocated from:
    #0 0x49d12b in __interceptor_malloc (/home/src/util-linux/.libs/lt-mkswap+0x49d12b)
    #1 0x7faf2a5069c9 in __GI___strdup (/usr/lib/libc.so.6+0x819c9)
    #2 0xffff96e7e33 (<unknown module>)

SUMMARY: AddressSanitizer: 8 byte(s) leaked in 1 allocation(s).

And another one that valgrind found.

==6316== 8 bytes in 1 blocks are definitely lost in loss record 1 of 1
==6316==    at 0x4C29F90: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6316==    by 0x5E3F9C9: strdup (in /usr/lib/libc-2.20.so)
==6316==    by 0x43A25F: size_to_human_string (strutils.c:495)
==6316==    by 0x42B35C: main (mkswap.c:488)

Signed-off-by: Sami Kerola <kerolasa@iki.fi>