| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
Support for this type of PTY was removed in the 2.1.115 kernel. Just
use __LINUX_KERNEL_VERSION to determine when we can drop the compat code.
|
|
|
|
grantpt was performing two consecutive calls to stat with the same
file name. Avoid this by creating a special version of the ptsname
function which allows to pass the stat result back to the caller.
|
|
The pt_chown program is completely transparently called. It might
not be able to live with the various file descriptors the program
has open at the time of the call (e.g., under SELinux). Close all
but the needed descriptor and connect stdin, stdout, and stderr
with /dev/null. pt_chown shouldn't print anything when called to
do real work.
|
|
This is a minor optimization. The tty group mustn't change so a
successful call to getgrnam will always return the same information.
Cache it and reuse it.
|
|
Before the change they crash on startup. Perform IREL relocations
earlier to prevent this.
|
|
POSIX.1-2008 made stat.st_[acm]tim mandatory.
|
|
|
|
Programs forking and using RPC in the forks would use the same XIDs.
|
|
The ntp_gettime implementation of NTP exports the tai field the kernel
now produces. This requires an ABI change since the ntptimeval structure
changed. Upstream kept the same name, there is nothing to do. This
patch changes the ntptimeval structure but keeps the old ntp_gettime
definition. A new ntp_gettimex function which is transparently invoked
through the old name is introduced. This has the advantage that even
object files can remain compatible. This wouldn't be the case if
symbol versioning would be used to overload the name ntp_gettime.
|
|
|
|
|
|
|
|
|
|
But maintain compatiblity for 2.11.
|
|
|
|
I've noticed that sync_file_range is a stub on ppc/ppc64.
The kernel on these arches provides sync_file_range2 syscall with swapped
parameters.
The following completely untested patch ought to fix this.
|
|
This is another bug in computing the fastmap. It was reported by a user
of sed because it usually does not happen with !_LIBC. However, it is
there in that case too.
The bug is that whenever we have a range at the beginning of the regex,
the regex must be tested on any possible multibyte character. The reason
why _LIBC masks it, is that in general there is a collation symbol for
each possible multibyte-character lead byte, so all the lead bytes are
in general already part of the fastmap.
The tests use cyrillic characters as an example. With _LIBC, they pass
without the patch too, but you can make them fail by removing collation
symbols handling.
|
|
|
|
|
|
|
|
When data is shorter than software pipeline, recovery may fail. This
patch avoids it by using a simple loop on data shorter than software
pipeline.
|
|
|
|
|
|
|
|
|
|
|
|
With big DNS answers like the one you get for goodtimesdot.com you can
get a truncated address list if IPv6 mapping is enabled. Instead tell
the caller to resize the buffer.
|
|
|
|
|
|
|
|
do_sym should use DL_FIXUP_VALUE_XXX macros to call IFUNC function.
Otherwise, it won't compile on ia64. This patch fixes it and adds
a test.
|
|
Due to alignment of 64bit parameters there is a dummy second argument.
But other than that the syscall arguments are directly mapped to the
function arguments.
|
|
I've just committed STT_GNU_IFUNC ppc/ppc64 support into prelink,
and this patch is needed on the glibc side. Without it ld.so segfaults,
as in dl-conflict.c sym_map is always NULL. While dl-machine.h could use
RESOLVE_CONFLICT_FIND_MAP macro to compute it, it doesn't make sense,
because with prelink we know it is already properly relocated (all relative
relocations are applied by prelink).
|
|
As reported in http://bugzilla.redhat.com/533063 , preadv/pwritev prototypes
are wrong on 32-bit arches with -D_FILE_OFFSET_BITS=64 and as I've just
found, fallocate is wrong too.
The problem is that only off_t is remapped to the 64-bit type transparently,
__off_t is not.
|
|
|
|
This code is only used when MALLOC_CHECK_ is used. Then some bogus
crashes and/or assert could result from the locking changes. The code
ain't fast.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
