IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
src/readahead/readahead-common.c:55:17: warning: format ‘%zu’ expects argument of type ‘size_t’, but argument 7 has type ‘__off64_t’ [-Wformat=]
log_debug("Not preloading file %s with size out of bounds %zu", fn, st->st_size);
^
Cases where name_to_handle_at is used allocated the full struct to be
MAX_HANDLE_SZ, and assigned this size to handle_bytes. This is wrong
since handle_bytes should describe the length of the flexible array
member and not the whole struct.
Define a union type which includes sufficient padding to allow
assignment of MAX_HANDLE_SZ to be correct.
safe_close() automatically becomes a NOP when a negative fd is passed,
and returns -1 unconditionally. This makes it easy to write lines like
this:
fd = safe_close(fd);
Which will close an fd if it is open, and reset the fd variable
correctly.
By making use of this new scheme we can drop a > 200 lines of code that
was required to test for non-negative fds or to reset the closed fd
variable afterwards.
In trying to track down a stupid linker bug, I noticed a bunch of
memset() calls that should be using memzero() to make it more "obvious"
that the options are correct (i.e. 0 is not the length, but the data to
set). So fix up all current calls to memset(foo, 0, length) to
memzero(foo, length).
This extends 62678ded 'efi: never call qsort on potentially
NULL arrays' to all other places where qsort is used and it
is not obvious that the count is non-zero.
systemd-readahead reports "Failed to create shared memory segment:
No such file or directory", but it's unclear how it can happen. Be
more verbose about failures.
This reverts commit 4826f0b7b5.
Because statfs.t_type can be int on some architecures, we have to cast
the const magic to the type, otherwise the compiler warns about
signed/unsigned comparison, because the magic can be 32 bit unsigned.
statfs(2) man page is also wrong on some systems, because
f_type is not __SWORD_TYPE on some architecures.
The following program:
int main(int argc, char**argv)
{
struct statfs s;
statfs(argv[1], &s);
printf("sizeof(f_type) = %d\n", sizeof(s.f_type));
printf("sizeof(__SWORD_TYPE) = %d\n", sizeof(__SWORD_TYPE));
printf("sizeof(long) = %d\n", sizeof(long));
printf("sizeof(int) = %d\n", sizeof(int));
if (sizeof(s.f_type) == sizeof(int)) {
printf("f_type = 0x%x\n", s.f_type);
} else {
printf("f_type = 0x%lx\n", s.f_type);
}
return 0;
}
executed on s390x gives for a btrfs:
sizeof(f_type) = 4
sizeof(__SWORD_TYPE) = 8
sizeof(long) = 8
sizeof(int) = 4
f_type = 0x9123683e
This reverts commit a858b64ddd.
This reverts commit aea275c431.
This reverts commit fc6e6d245e.
This reverts commit c4073a27c5.
This reverts commit cddf148028.
This reverts commit 8c68a70170.
The constants are now casted to __SWORD_TYPE, which should resolve the
compiler warnings about signed vs unsigned.
After talking to Kay, we concluded:
This should be fixed in the kernel, not worked around in userspace tools.
Architectures cannot use int and expect magic constants lager than INT_MAX
to work correctly. The kernel header needs to be fixed.
Even coreutils cannot handle it:
#define RAMFS_MAGIC 0x858458f6
# stat -f -c%t /
ffffffff858458f6
#define BTRFS_SUPER_MAGIC 0x9123683E
# stat -f -c%t /mnt
ffffffff9123683e
Although I found the perfect working macro to fix the thing :)
__extension__ ({ \
bool _ret = false; \
switch(f) { case c: _ret=true; }; \
( _ret ); \
})
On some architectures (like s390x) the kernel has the type int for
f_type, but long in userspace.
Assigning the 32 bit magic constants from linux/magic.h to the 31 bit
signed f_type in the kernel, causes f_type to be negative for some
constants.
glibc extends the int to long for those architecures in 64 bit mode, so
the negative int becomes a negative long, which cannot be simply
compared to the original magic constant, because the compiler would
automatically cast the constant to long.
To workaround this issue, we also compare to the (int)MAGIC value in a
macro. Of course, we could do #ifdef with the architecure, but it has to
be maintained, and the magic constants are 32 bit anyway.
Someday, when the int is unsigned or long for all architectures, we can
remove this macro again. Until then, keep it as simple as it can be.
Instead of making a type up, just use __SWORD_TYPE, after reading
statfs(2).
Too bad, this does not fix s390x because __SWORD_TYPE is (long int) and
the kernel uses (int) to fill in the field!!!!!!
statfs.f_type is signed but the filesystem magics are unsigned.
Casting the magics to signed will not make the signed.
Problem seen on big-endian 64bit s390x with __fsword_t 8 bytes.
Casting statfs.f_type to unsigned on the other hand will get us what we
need.
https://bugzilla.redhat.com/show_bug.cgi?id=953217
Make sure we compare errno against positive error codes.
The ones in hwclock.c and install.c can have an impact, the
rest are unlikely to be hit or in code that isn't widely
used.
Also check that errno > 0, to help gcc know that we are
returning a negative error code.
Before, we would initialize many fields twice: first
by filling the structure with zeros, and then a second
time with the real values. We can let the compiler do
the job for us, avoiding one copy.
A downside of this patch is that text gets slightly
bigger. This is because all zero() calls are effectively
inlined:
$ size build/.libs/systemd
text data bss dec hex filename
before 897737 107300 2560 1007597 f5fed build/.libs/systemd
after 897873 107300 2560 1007733 f6075 build/.libs/systemd
… actually less than 1‰.
A few asserts that the parameter is not null had to be removed. I
don't think this changes much, because first, it is quite unlikely
for the assert to fail, and second, an immediate SEGV is almost as
good as an assert.
Internally we store all time values in usec_t, however parse_usec()
actually was used mostly to parse values in seconds (unless explicit
units were specified to define a different unit). Hence, be clear about
this and name the function about what we pass into it, not what we get
out of it.
Readahead has all sorts of bad side effects depending on your
storage media. On rotating disks, it may be degrading startup
performance if enough requests are queued spanning linearly
over all blocks early at boot, and mount, blkid and friends
want to insert reads to the start of these block devices after.
The end result is that on spinning disks with ext3/4 that udev
and mounts take a very long time, and nothing really happens until
readahead is completely finished.
This has the net effect that the CPU is almost entirely idle
for the entire period that readahead is working. We could have
finished starting up quite a lot of services in this time if
we were smarter at how we do readahead.
This patch sorts all requests into 2 second "chunks" and sub-sorts
each chunk by block. This adds a single cross-drive seek per "chunk"
but has the benefit that we will have a lot of the blocks we need
early on in the boot sequence loaded into memory faster.
For a comparison of how before/after bootcharts look (ext4 on a
mobile 5400rpm 250GB drive) please look at:
http://foo-projects.org/~sofar/blocked-tests/
There are bootcharts in the "before" and "after" folders where you
should be able to see that many low-level services finish 5-7
seconds earlier with the patch applied (after).
It is only needed in files designed to be usable in standalone
compilation. In those files the #ifdefinery is indented. When
compiling in-tree, GNU_SOURCE is always defined, so remove one
definition.
[zj: Reworded message s/to watch/to add watch on/ to make it clear
that it was the watch init action that failed, and not the
"process of watching". I think this way it'll be clearer to
people who don't know what inotify does.]
also a number of minor fixups and bug fixes: spelling, oom errors
that didn't print errors, not properly forwarding error codes,
few more consistency issues, et cetera
