| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
When e.g. looking up a socket with O_DIRECTORY, we should return ENOTDIR
rather than EACCESS.
|
|
|
|
| |
The implementation is shared with IPv4
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a four-player problem (here for diskfs):
- One runs sync, which calls diskfs_S_file_syncfs, which triggers
fsys_syncfs on all active translators, while keeping the
translator_ihash_lock lock.
- One of the active translators is hung, for some reason
- Another ext2fs thread is trying to call fshelp_set_active_translator from
dir_lookup. It is stuck on trying to acquire translator_ihash_lock, and it
holds the np.
- The ext2fs thread running diskfs_sync_everything tries to lock that
np, while holding the nodecache_lock.
In the end everything is locked. While diskfs_S_file_syncfs can as well just
atomically get the list of active translators, and then call fsys_syncfs
without keeping translator_ihash_lock held.
|
|
|
|
| |
In network terms, long is 32bit, i.e. an int for us.
|
|
|
|
| |
To get mach_msg_type_number_t everywhere
|
| |
|
| |
|
|
|
|
| |
Shifting unsigned 32bit right by 32 bits is undefined, so avoid this.
|
|
|
|
|
| |
Shifting signed integers left by 31 bits is not representable, so better
make sure to use unsigned integers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes netfs_[gs]et_translator use mach_msg_type_number_t like
the RPC and diskfs. This also makes the fshelp_fetch_root_callback1_t
for fshelp_fetch_root use mach_msg_type_number_t.
This also makes procfs_get_translator and the get_translator proc method
use mach_msg_type_number_t.
This makes diskfs_get_directs use mach_msg_type_number_t like the
dir_readdir RPC
Also get rid of u_int.
This notably fixes _diskfs_translator_callback1_fn's bogus cast of
size_t *argz_len into (u_int *).
|
|
|
|
|
|
|
| |
* pci-arbiter/netfs_impl.c:
* get_filemap_region(): Return MACH_PORT_NULL and set errno to EOPNOTSUPP
when the client tries to map a IO region file.
Message-Id: <20230705193812.6384-2-jlledom@mailfence.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The existing code mapped the first PT_LOAD segment using anywhere=1,
letting Mach pick an arbitrary location, and then uses anywhere=0 for
all the remaining segments to place them next to the first one, as
expected by the program.
This, however, runs into many issues, primarily because of conflicts
between interpreter and executable mappings. Some of those the existing
code tried to work around. Instead, do it the way it's implemented in
glibc: calculate upfront how much space the overall mapping will need,
and ask Mach to preallocate this much address space. Then we deallocate
it back, and instead map the program segments onto this very same place.
Message-Id: <20230625231137.403096-4-bugaevc@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a second binary target to compile in
the rump USB stack instead of SATA/IDE using conditional
ifdefs to mostly share the code between the two translators.
This can be tested by running qemu with a USB3 controller as follows:
-drive if=none,id=usbstick,format=raw,file=/path/to/disk.img \
-device qemu-xhci \
-device usb-storage,drive=usbstick \
NB: /path/to/disk.img can be a block device on the host.
Then call grub module rumpusbdisk.static instead of rumpdisk.static
and pass ' root=part:X:device:sd0 noide' as gnumach parameters,
where X is the partition number of / within the disk/image.
Caveats: netdde seems to exhibit a bug when running 'ifdown /dev/eth0'
simultaneously to running the rumpusbdisk translator, due to
the two devices sharing the same IRQ.
Message-Id: <20230703101815.925760-1-damien@zamaudio.com>
|
|
|
|
|
|
|
|
|
|
| |
We want to map the whole lower 4 GB of address space inaccessible to
catch accidental pointer truncation. We can only do this when the
executable (as well as the interpreter, if any) is compiled as PIC/PIE,
since otherwise we would violate the ABI requirement. Fortunately most
distributions have already switched to using PIE by default, so this
should not be an issue.
Message-Id: <20230625231137.403096-3-bugaevc@gmail.com>
|
|
|
|
|
|
|
|
|
|
| |
The code already ignores proc_mark_important failing with EPERM; do the
same for opening /servers/startup and startup_request_notification. All
of these calls will fail for unprivileged mounts.
Also plug a port leak: we want to deallocate the "init" port whether the
RPC succeeds or not.
Message-Id: <20230625231137.403096-1-bugaevc@gmail.com>
|
|
|
|
|
| |
AC_CHECK_LIB does not work when -lpciaccess is also required.
Message-Id: <20230629105620.809091-1-damien@zamaudio.com>
|
|
|
|
| |
acpica will need it to access PCI configurations.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to little-endianness of x86, this resulted in a 64-bit pointers that
pointed to the lower 4 GB of the address space being treated as a 32-bit
pointer followed by NULL, which manifested as only the first program arg
(the argv[0]) being visible in ps output. When a pointer pointed outside
of the lower 4 GB, this resulted in both halves being treated as invalid
pointers, causing proc_getprocargs () to fail with KERN_INVALID_ADDRESS,
which manifested as ps displaying COMMAND for the affected process as ?.
Found by placing all memory above the 4 GB limit, which made it apparent
that something about fetching process command lines is seriously broken.
Before:
USER PID PPID TTY TIME COMMAND
0 1 1 - 0:00.00 /hurd/init
0 2 1 - 0:00.05 /hurd/startup
0 3 2 ? 0:02.80 ?
0 4 2 ? 0:00.00 /hurd/proc
0 5 2 - 0:00.08 ?
0 6 5 - 0:00.02 ?
0 7 2 - 0:00.00 /hurd/auth
0 9 1 - 0:00.01 /hurd/term
0 13 1 - 0:00.11 /hurd/mach-defpager
0 15 1 - 0:00.00 /bin/bash
0 16 5 - 0:00.00 /hurd/pflocal
0 18 15 - 0:00.00 /bin/sh
0 20 18 - 0:00.00 ps-hurd
After:
USER PID PPID TTY TIME COMMAND
0 1 1 - 0:00.01 /hurd/init -a
0 2 1 - 0:00.03 /hurd/startup --kernel-task=1 console=com0
0 3 2 ? 0:01.36 gnumach --kernel-task=1 console=com0
0 4 2 ? 0:00.00 /hurd/proc --kernel-task=1
0 5 2 - 0:00.06 ext2fs --multiboot-command-line=console=com0
0 6 5 - 0:00.00 /hurd/exec --device-master-port=1
0 7 2 - 0:00.02 /hurd/auth
0 9 1 - 0:00.00 /hurd/term /dev/console device console
0 13 1 - 0:00.09 /hurd/mach-defpager
0 15 1 - 0:00.00 /bin/bash /usr/libexec/runsystem.hurd
0 16 5 - 0:00.00 /hurd/pflocal
0 18 15 - 0:00.00 /bin/sh
0 19 18 - 0:00.01 ps-hurd -ef
Message-Id: <20230621105638.1045306-1-bugaevc@gmail.com>
|
| |
|
|
|
|
|
| |
msgh_kind is deprecated and is an alias to msgh_seqno.
Message-Id: <ZIfy1sJwuhEtKSPH@jupiter.lan>
|
|
|
|
|
|
|
|
| |
access/modification times
libtrivfs/nfsd/fakeroot can now make the call to the underlying
translators.
Message-Id: <ZIlK1ow9VFolIbga@jupiter.lan>
|
| |
|
|
|
|
|
|
| |
This reverts commit 19558c940e81d405dbda0ea1dd29549f34b5aa2a.
It now builds fine.
|
| |
|
| |
|
|
|
|
| |
When ports_create_port returns an error there is no reference to release.
|
| |
|
| |
|
|
|
|
| |
proc_getprocargs and proc_getprocenv read their size value
|
| |
|
|
|
|
| |
Message-Id: <20230518165719.90745-2-bugaevc@gmail.com>
|
|
|
|
|
|
|
| |
This enables me to run 'fsysopts /dev/mach-console' and get:
/hurd/streamio --writable console
Message-Id: <20230518165719.90745-1-bugaevc@gmail.com>
|
|
|
|
|
| |
We will more and more default to using rumpdisk and thus need the whole
stack with static link.
|
|
|
|
| |
Message-Id: <20230515073600.1350072-4-bugaevc@gmail.com>
|
|
|
|
|
|
|
|
| |
Normally glibc does not buffer tty output, but a devstream backed by
the Mach console device cannot be isatty'ed. So we need to ask glibc
explicitly to not buffer it. This is what the startup and mach-defpager
do already.
Message-Id: <20230515073600.1350072-3-bugaevc@gmail.com>
|
|
|
|
|
|
|
|
|
| |
Since we don't support mixing i386 and x86_64 binaries on the same
system (as running them requires different build-time gnumach
configurations), the exec server can simply require the binary being
loaded to have been built for the same architecture as the exec server
itself.
Message-Id: <20230515073600.1350072-1-bugaevc@gmail.com>
|
|
|
|
|
|
|
|
|
|
| |
Also fixed the implementation of default_pager_paging_storage_new in proxy
def pager to call into default_pager_paging_storage_new.
We can fast track the simplification of the RPC ABI for x86_64 if we don't have
MACH_MSG_TYPE_STRING used in RPCs which forces msgt_size to use more than 8
bits.
Message-Id: <ZFsk/W+slpAZyTG1@jupiter.tail36e24.ts.net>
|
| |
|
|
|
|
|
|
|
|
| |
GCC was complaining about the mismatch in types between the 'fn' pointer
and the function pointers assigned to it. Since fn is meant to be used
with different function types, represent it as a 'void *' and not a
pointer to any particular function type.
Message-Id: <20230508213136.608575-13-bugaevc@gmail.com>
|
| |
|
|
|
|
| |
Message-Id: <20230508213136.608575-42-bugaevc@gmail.com>
|
|
|
|
| |
Message-Id: <20230508213136.608575-41-bugaevc@gmail.com>
|
|
|
|
|
| |
There's no mach/i386/ on x8_64.
Message-Id: <20230508213136.608575-40-bugaevc@gmail.com>
|
| |
|
|
|
|
| |
Message-Id: <20230508213136.608575-39-bugaevc@gmail.com>
|
|
|
|
| |
Message-Id: <20230508213136.608575-38-bugaevc@gmail.com>
|
|
|
|
| |
Message-Id: <20230508213136.608575-37-bugaevc@gmail.com>
|
|
|
|
| |
Message-Id: <20230508213136.608575-36-bugaevc@gmail.com>
|
|
|
|
| |
Message-Id: <20230508213136.608575-35-bugaevc@gmail.com>
|
|
|
|
| |
Message-Id: <20230508213136.608575-34-bugaevc@gmail.com>
|