Properly speaking, this is part of POSIX and not of the Be-style
"kits", and so it should live in system/ alongside libroot.
No functional change intended.
Change-Id: I0fcf78a09c76e220ad4f1719d147978ef4a3bc52
Reviewed-on: https://review.haiku-os.org/726
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This allows Clang builds (linked with our cross binutils) to
at least start runtime_loader and then try to load launch_daemon.
That fails with an infinite loop somewhere...
Clang doesn't support -maccumulate-outgoing-args, -nostartfiles
is not needed in LDFLAGS (and lld doesn't know about it anyway),
and Clang uses .dynstr so we need to copy it also.
Previously this protection was possible via the opt-in B_KERNEL_AREA flag,
however, almost nothing used that, so in practice these protections were
rarely enforced.
Userland can still access kernel areas according to the protection flags
(and due to SMAP, these have been refined and reduced as appopriate)
and clone them (according to B_USER_CLONEABLE_AREA flag, which has
been required since August of this year), but they can no longer
resize them (something no in-tree application does on any shared area),
set protections (otherwise they could add B_USER_CLONEABLE_AREA...),
unmap them, or essentially do anything else besides get their
information (and even that we should restrict to uid 0, in the future.)
From my testing, this does not introduce any issues, and no applications
nor drivers should have been relying on the previous behavior (unlike
SMAP or the clone-area changes, which did affect applications.)
As the TODO said, we now have good userland debugging facilities, so
this isn't needed (and has been if 0'd out for almost a decade now.)
The dprintf on page faults may still be useful under rare circumstances,
but we already have a "TRACE_FAULTS" configuration for this file,
so guard it behind that.
Fixes part of #14360.
We won't need the mailbox for most chipsets except bcm2835
to determine the framebuffer base address.
(especially at this early boot stage)
This simplifies things by making the mailbox usage limited
to boot_arch_arm and not spreading it all thoughout the
platform u-boot code... however we keep the mailbox driver
as-is since it would make a good kernel driver someday.
mmu_man mentioned us "finding" the fb base from the mailbox
and modifying the FDT to let it know the base reg of the
framebuffer... that's beyond 'just getting things building'
though :-)
Change-Id: Ic2772b85dff004f9d21447ea5958b5ae9776d526
It seems GCC2 occasionally will inline a call to memcpy with
a count of 0, which this function did not previously expect
and would result in a "Divide Error Exception."
Hopefully fixes#14613.
Previously, there were a number of circumstances where these were
not getting reset properly, leading to some destroyed mutexes having
holders of the last thread which locked them, and some with "-1",
which meant that the next call to "mutex_lock" just behaved as if
the lock was still valid (!), and so the unlucky caller would deadlock
forever.
Now we properly reset these fields, which means from now on attempts to
lock or unlock destroyed mutexes will lead to "PANIC: uninitialized mutex"
on KDEBUG kernels, and (as before) an infinite deadlock on non-KDEBUG
kernels (perhaps we should store the thread_id of the locker on non-KDEBUG
kernels also?).
As the next commits will show, this already uncovered a number of bugs,
and there are of course potentially more strange deadlocks caused by this.
* Move MMU image to a real image define vs being crammed into
the u-boot bootloader Jamfile
* ARM not working yet, but better!
* x86 still builds
Change-Id: I3fb873dbac06fe2db893915b667bf3ce1df44686
* haiku_loader is the hpkg name in system/packages and not the
loader name.
* bios_ia32 stage1 assumes the bios_ia32 loader is the first
file in haiku_loader.hpkg. This isn't ideal.. but space in
stage1 is *limited*
From mmlr's analysis in #13370 comment:22: "We actually do ignore a missing
routing in case the interrupt line is 0. In this case it isn't 0 but 0xff,
which is invalid and generally treated the same as 0 in the rest of the code.
Ignoring the missing routing on 0xff seems like the way to go here."
Indeed, I managed to locate a footnote in the PCI 3.0 specification which
confirms that this is the case on x86, and a commit in the Linux kernel
which essentially does the same thing this change does:
https://github.com/torvalds/linux/commit/e237a5518425155faa508a087f2826
Interestingly, that commit is only from 2016, while PCI 3.0 is from 2004.
This probably fixes#13370 ("Haiku doesn't MBR boot on Ryzen"), and potentially
other interrupt-routing-related boot failures.
Change-Id: I88129f6507c62d24cb50cf5c78597ca7bd7872d7
Reviewed-on: https://review.haiku-os.org/590
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The action vm_page_fault takes should depend on whether the iframe to be
handled is a user iframe or not. The check for the user flag in the
error code does however only check if the fault happend in user or
kernel space. Use IFRAME_IS_USER() instead which checks the privilege
level of the iframe. Under 32 bit x86 this also handles vm86
compatibility mode properly.
This is the same logic as used on FreeBSD (TRAPF_USERMODE).
Fixes#13930.
Change-Id: I9c348b6ab4c60daaaaa2c0fe33bcc3336aa29f7b
Reviewed-on: https://review.haiku-os.org/560
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
BFS does this as part of journal management, but not as part of block
cache synchronization (which makes sense, as flushing it then would
defeat the purpose of the drive's write cache.) No other file system
seems to touch it at all, so we should do it as part of an explicit sync.
This may help with some of the filesystem corruption issues, as it seems
that on slow disks, the drive might not have enough time to flush the cache
before it is powered off (or on some SATA/AHCI based disks, it is not flushed
before close at all), so triggering it here and, as the ioctl is supposed to be
synchronous, waiting for it also, seems to make sense.
Change-Id: I7d9992c21ca4b59c839711dcc96c973b4b8df052
Reviewed-on: https://review.haiku-os.org/530
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The kernel's handling of SIGABRT is just to terminate the application
immediately without doing anything else (it only notifies the debugger if
there's one installed for this application already.) More serious faults
(e.g. SIGSEGV) originate in the kernel and handle this logic before they
even invoke the signal handler.
So the correct solution is to do the same here in libroot. This incurs
a very, very slight performance penalty of the syscall time for sigaction(),
though I expect whatever applications are causing SIGABRT to be invoked more
than once a second will call raise() directly instead of abort()...
It seems the old one was just broken (see mailing list discussion.)
This new one was built from the generic one, but it was done using
a trunk build of Clang 8 with tuned optimization flags, and is
smaller (101 instructions) than GCC 8's (134 instructions) and
the old hand-optimized one (~125 instructions?) as well as being
targeted for ARMv7 instead of ARMv6 like the old one was.
In the future, we may want to look at newlib's ARM memcpy, which
is probably much more hand-optmized than this one is, but this
is at least better than what we had before.
* Realized we already had a function which iterates over
an fdt node and maps it's memory regs. Make it work for
physical mappings or identity mappings.
Change-Id: I0e3e323798bc2dfcead1accc1d403b30a8ab188f
GCC provides these but Clang does not; these come from the ones Clang
was going to provide, but decided against it in favor of letting libc vendors
distribute them instead, hence the license headers.
For now, they are only enabled when building with Clang, as we still use GCC's
versions otherwise. But I've tested them with apps built with GCC 7 (as Clang
builds are still too broken at present) and they seem to work just fine. (They
will not build with GCC 2 of course, due to how they use __attribute__.)
To indicate this is a menu you can enter to select a previous
state to boot. Also rename "Latest version" to "Latest state" as
that is more correct.
Thanks waddlesplash for pointers.
Fixes#14362
Spotted while reading through the VM code while thinking about how to
implement vfork().
When axeld disabled this in 2005 (!), Haiku's kernel was still young,
BeOS drivers were still "a thing," and there was no distinction in this
function from being called by the kernel / not by the kernel.
Now, it's 2018, we manage all drivers ourselves, have SMAP enabled by
default when available, and as axeld recently noted on the mailing lists,
"there's not much reason we still use GCC2 for the kernel anyway." So we
probably don't care about any BeOS drivers that may be broken by this
(are there any still around?)
Besides the usual fixes to get this 13-year-old chunk to work again, there
are two functional changes:
1) Allow the kernel to clone whatever it likes into the user's address space.
It seems that this is often done legitimately (e.g. team creation), and
so attempting to distinguish those cases seems more work than it may be
worth right now.
The disadvantage is that drivers without proper checks may be "tricked"
into cloning areas they shouldn't; but I'm guessing if that's the case,
then something else is probably broken and the driver should be fixed.
It seems the reverse case (cloning a userland area into the kernel)
is much more common (in fact, it looks like all 4 of the 4 places
where clone_area is used in kernel-space outside the kernel itself
are doing this.)
2) At KDEBUG_LEVEL 2 and higher, throw a panic when attempting to clone
an area that does not have the protection flag set. This should make
finding any bugs exposed by this change much easier than "hardware doesn't
work" / "black screen on boot" / etc., as well as any potential future
bugs introduced in the process of driver development.
* Consolidate all fdt code into fdt bus_manager
* Build boot and kernel static libraries
Change-Id: I2a69cd7e1f1276999a80734ff12918fd49b599e5
Reviewed-on: https://review.haiku-os.org/440
Reviewed-by: Alexander von Gluck IV <kallisti5@unixzen.com>
* This fixes booting Haiku on Raspberry Pi and qemu (-M raspi2)
* Makes several assumptions which need corrected.
/axi is broadcom only
size is fixed
* The final solution will be "probing" each simple-bus device
from the fdt. A lot of fdt support code needs written though
for "finding" compatible devices and determining the full size
of the devices in memory.
Change-Id: Ifd5fbab7490c8456247115f5aada618909f1bb9e
1. SDHCI PCI Bus: Discovering SDHC device from the PCI bus
and registers a child node(MMC bus) to which slots
are attached. SDHC registers are mapped by MMUIO,
they are binded in a structure(struct* registers).
A pin based interrupt handler is also installed,
which triggers the handler function and interrupts
are being taken care of. Added API's to set-up and
the clock for SD/MMC card, change frequency and
reset the registers.
2. Device Manager: Currently, busses subdir lists are har-
dcoded and in order to load the driver. We hard
coded the bus dir under PCI devices.
3. MMC Disk Driver: In order to register the slots under
/dev/disk/mmc and hence data transfer and other
operations can be done.
4. MMC Bus Manager: Setted up a bus manager to create an object
to do a particular for eg certain data transfer and
get freed until another operation is requested.
Change-Id: I369354da6b79adc6b6dfb08fe160334af1392a34
Reviewed-on: https://review.haiku-os.org/318
Reviewed-by: Alexander von Gluck IV <kallisti5@unixzen.com>
memset uses rep stosb on x86 during boot, with memory
not set to write-combining, which makes it slow.
Instead we do aligned writes of 2 x four bytes at once.
Only clear the minimum of size and width * height * 4
UEFI framebuffer size can be huge, upto 512MB here,
and rep stosb seems to be around 25-30MB/s
This is written as generic as possible to work on
old compilers and different platforms, without
expecting boot memset to be optimized.
This makes it almost unnoticable compared to not
clearing.
It will probably be just stubs for the significant future, but,
here it is anyway.
Regarding the naming: Yes, the official name is "aarch64." However,
Linux, FreeBSD, and Zircon all call it "arm64", and so we will do the same.
I've configured it initially to be a Clang-only port, making no
changes to GCC buildtools whatsoever here. We'll see if that sticks,
however.
It seems not all of the kernel includes this, but some use new/delete
anyway. Further, operator delete[] was not implemented at all.
Possibly fixes the ARM build.
Clang's equivalent of .tfloat is .x86_fp80, but apparently that
is not enabled for Haiku. So for now, use .double instead.
This is the same thing MinGW does.
Writes to videomem is slow without memory remapping
Can't do the mapping without leaving UEFI, so skipping
the clear. Afaict it should always be cleared by UEFI
This saves ~10 seconds of booting on my machine
(1920*1080*4 bytes)
EFI video mode (should have been it's own commit)
* Only do strcmp if there are enough params
* break when found
* <x86_gcc2>runtime_loader can also handle x86 binaries.
* At the moment the x86_64 kernel will execute the x86 runtime_loader
when it sees x86 and x86_gcc2 binaries. The reason is checking the GCC
version of a binary in the kernel seems cumbersome, the kernel should
just fallback using the x86_gcc2 runtime_loader when the x86 one is missing.
* gcc 7.x defines __arm__ and __ARM__ (and others)
* clang defines __arm__ and __arm
* cleanup a few related ifdef vs if macros
Change-Id: I5da4bafac590f6fa3e10e543688001c2449f840d
Before hrev46809, the "thread->priority = priority" line was below this
check, and so all was well. But that commit moved the line to its present
location, which means ever since then, the following code which updates
CPU entries, scheduler listeners, etc. has never been run.
On my VMware instance (which is probably pretty affected by the host system
and thus not the greatest performance test), "time jam -j2 HaikuDepot" decreased
from 46.0s real to 43.3s real, 52.3s user to 48.1s user, 12.1s sys to 12.2s sys.
So this seems to make some sort of impact.
Spotted by Fishpond in #10454 and confirmed by korli, but somehow neither of
them followed up on that in the 4.5 years since...
As Rene pointed out on the mailing list, if this is NULL after the file system
mount call occurs, then something has gone very wrong and we should treat it
as an error.
I got a reproducible KDL that upon close inspection seems to have been
a NULL dereference of this, thanks to GCC's mix-source-and-assembly
functionality.
Unfortunately, I deleted my mount_server settings before I fully understood
what was going on, and afterwards it no longer reproduced, so it seems to
have been related to that. I'm confident enough this is the correct fix to
commit it anyway.
6ad3d25212 changed the timezoneOffset type from
time_t to int32 without adjusting the user_memcpy size. Harmless as the
function is hardly used with a non-null argument.
instead of user_memcpy().
* fix#14204: the NTFS filesystem kernel addon uses the fcntl system call to
lock the underlying device. The user_memcpy replacement in the x86 compat
branch adds range checks for the user pointer, which exposes such problems.
The user iframe and associated data that the syscall entry pushes to the
stack directly were causing the stack to be mis-aligned by 8 bytes. Since
we re-aligned %rsp afterwards, for most usecases this wasn't a problem.
However, since we stored the pre-realinged %rsp in %rbp (as we need it to
access the iframe data), this also meant that anything which depended on
%rbp being 16-byte-aligned would run into serious problems.
As it turned out, GCC 7 assumed that %rbp was indeed 16-byte-aligned, and
so optimized certain accesses to use SSE instructions that depended on this
alignment. Since inside any callstack begining with a syscall this was not
the case, a "General Protection Exception" resulted (see #14160 for an example)
at the first usage of such an instruction. I wasn't really sure what was going
on when it first came up, and so "fixed" it by disabling the GCC optimization
that used such instructions. Replacing the -fdisable... with -mstackrealign thus
also "fixes" the problem, as I discovered earlier today, as it forces GCC to
realign the stack in function prologues.
So instead of rounding %rsp down to the nearest aligned address after the
pushes are complete, we offset %rsp by the amount the pushes are not,
thus fixing both %rsp and %rbp in syscall handling routines. This of course
depends on syscall_rsp being already aligned, which it is.
Thanks to PulkoMandy and js for the advice and guidance (and PulkoMandy
for the ASCII art), as this is essentially my first time working with
kernel assembly.
This reverts commit c558f9c8fe.
This reverts commit 44f24718b1.
This reverts commit a69cb33030.
This reverts commit 951182620e.
There have been multiple reports that these changes break mounting NTFS partitions
(on all systems, see #14204), and shutting down (on certain systems, see #12405.)
Until they can be fixed, they are being backed out.
* define compat_thread_info, compat_rlim_t, compat_rlimit and
compat_thread_creation_attributes to be used when applicable in compatibility
mode.
* handle 32-bit types in _user_spawn_thread(), _user_get_thread_info(),
_user_get_next_thread_info(), _user_getrlimit(), _user_setrlimit(),
other syscalls are compatible as is.
* init TLS for compatibility mode threads.
Change-Id: I483ba95e6198ddac9d240671bcb56fcd2ad831d2
* in load_image_internal(), elf32_load_user_image checks whether the binary
format requires the compatibility mode.
* we then set up the flag THREAD_FLAGS_COMPAT_MODE and the address space size.
* the compatibility mode runtime_loader is hardcoded with x86/runtime_loader.
* if needed, the 64-bit flat_args structure is converted in-place to its 32-bit
layout.
* a 32-bit flat_args isn't handled yet (a 32-bit team execs a 64-bit binary).
Change-Id: Ia6a066bde8d1774d85de29b48dc500e27ae9668f
* define compat_area_info to be used when applicable in
compatibility mode.
* handle 32-bit types in _user_reserve_address_range(), _user_get_area_info(),
_user_get_next_area_info(), _user_transfer_area(), _user_clone_area(),
_user_create_area(), _user_map_file(), other syscalls are compatible as is.
* _get_next_area_info() doesn't work well with a 32-bit address cookie (address
could be in 64-bit range). Instead use _compat_get_next_area_info() which uses
the area id as cookie, though the areas are not ordered by address any more.
Change-Id: Ic7519ca8824aa2d534b0f03ea75a1bf6ae321535
* handle 32-bit types in _user_send_signal(), _user_sigaction(), _user_sigwait(),
_user_set_signal_stack(), _user_restore_signal_frame(), other syscalls are
compatible as is.
Change-Id: I4c8dc47bfa80f36e363d444d2a5a7be6c621606d
* define compat_image_info, compat_extended_image_info
to be used for respective 32-bit types of syscalls in compatibility mode.
* handle 32-bit types in _user_register_image, _user_get_image_info,
_user_get_next_image_info, other syscalls are compatible as is.
Change-Id: Ibbd33e6796208dfa70d869e36bf745bc3e18d330
* define compat_flock, compat_timespec, compat_stat, compat_attr_info,
compat_fs_info, compat_fd_info to be used for respective 32-bit types
of syscalls in compatibility mode.
* handle 32-bit types in common_fcntl(), _user_read_stat(), _user_stat_attr(),
_user_read_index_stat, _user_read_fs_info, _user_write_fs_info,
_user_get_next_fd_info, other syscalls are compatible as is.
Change-Id: I5b372169fe142f67b81fd6c27e0627d5119ba687
* With the previous commit, we can now move functions that require
calling mmu_map_physical_memory to where they should have been
originally. This also allows the SMP safe mode menu entries to
be properly generated, now that smp_init is called prior to
main().
Change-Id: I05ddca5273b11cb4846021664c1ea2cf8ba723b7
* mmu_map_physical_address will get called prior to calling main()
which leaves us without a heap, malloc, and new. Instead, use
the kernel args physical allocated range array, and then
convert to our allocated memory region type on-demand.
Change-Id: I265fd165ef7143681e8e40c3686fda1a583c20dc
The call to smp_... is not working since it relies on gKernelArgs being
fully initialized, which it isn't at this stage in the EFI loader. Jessica
says that in order to have that happen, the heap would also need to be
initialized early, which it also is not.
At least you can now force a safe videomode, which is enough for me to
be able to test video drivers.
* install syscall handlers in compatibility mode.
* copy the syscall entry in the compatibility commpage, ATM only for Intel
SYSENTER.
* copy the thread exit handler in the compatibility commpage.
Change-Id: Ic350799938815194377d8a4560cb106fe7366cc6
* File locks created by flock should only apply for the file descriptor
that was used to lock the file. Another fd on the same file should then
be denied access (calling flock should fail).
* fcntl based locks, however, are in a separate namespace and are global
to a team.
* This issue was found when running webkitpy test suite, and should close
ticket #13795.
* Don't use session or team as comparison in release_advisory_lock(), as
that information might not be available anymore (e.g. when called from
Team::~Team()). This fixes#14121.
Change-Id: I9efb96cfcefe7e72b0060220c635a665e7e643cc
Co-authored-by: Axel Dörfler <axeld@pinc-software.de>
* This gives us a solid automatic entry point to u-boot
* A uEnv.txt specifies the fdt file name
* This should work on any modern u-boot for most architectures
* Non-mmc targets will likely need some work
Change-Id: I9a00316a213a15e85d3f2e18574d64920d9bdb76
* x86_64_signal_handler_compat is a dump of x86 x86_signal_frame_function().
* the x86 compiler should be used to produce this code, which ends up in the
commpage.
Change-Id: I03da02c376f67ff83dbaba9bcb144da726463996
* x86 uses a commpage with 32-bit addresses, incompatible with the one used for
x86_64. For this reason, a compatibility commpage is needed to support a 32-bit
userland on x86_64.
* define ADDRESS_TYPE as a macro for addr_t (default) or uint32 (for the 32-bit
commpage).
* team_create_thread_start_internal() will use clone_commpage_area() with
KERNEL_USER_DATA_BASE or clone_commpage_compat_area() with
KERNEL_USER32_DATA_BASE, to setup the correct commpage.
* real_time_clock (in compatibility mode) also updates the compatibility
commpage with real time data.
Change-Id: I61605077ce0beabab4439ef54edd1eae26f26fd2
* define ELF32_COMPAT to enable ELF32 macros.
* add a flag ELF_LOAD_USER_IMAGE_TEST_EXECUTABLE to only check the format.
It will be used by load_image_internal() to check which mode to use when
loading an image.
* in arch_elf_relocate_rel(), switch to elf_addr instead of addr_t, which
would be the wrong size for elf32 on x86_64.
* the ELF compat loader reuses the relevant parts of elf.cpp and arch_elf.cpp,
excluding for instance load_kernel_add_on() or dump functions.
Change-Id: Ifa47334e5adefd45405a823a3accbd12eee5b116
* only for Intel sysenter/sysexit.
* the entry function processes stack arguments as follows:
we look up the syscall in the table, find the number of arguments.
reserve place on the stack for the arguments.
copy arguments on the stack
pop register arguments
call the syscall function
place the return value in ax and dx registers.
* TODO: we need to store the arguments somewhere for the post-syscall tracing.
* the thread exit stub is 32-bit, for the time being use hexadecimal instructions.
Change-Id: Ie5c502eb596d4fa7613d238de80643566bc19ed8
* also adjust BOOT_GDT_SEGMENT_COUNT for x86, the definition is used by the
boot loader.
* add some 32-bit definitions.
* add a UserTLSDescriptor class, this will be used by 32-bit threads.
Change-Id: I5b1d978969a1ce97091a16c9ec2ad7c0ca831656
the x86_64 compat syscall entry needs size and offset of parameters to
handle them correctly to the syscall function. struct extended_syscall_info
and struct syscall_parameter_info provide parameter count, size and offsets.
Change-Id: I7e5c7b6e19e757b28b43c3b3419b7071fae321f8
use x86 as default sSearchPathSubDir in compatibility mode.
use the generic memset/memcpy when x86_64 is the primary arch.
Change-Id: Ib464c308ff97f7ae2482ef4c037de1b1bb2bf61b
the standard x86 implementation uses the commpage, which is difficult to setup. we could
also use the C++11 version instead.
Change-Id: I4be7e3466082ff2c91bc32bef377a664ce65f3fc
* A Node/Partition cannot be member of two lists at once. This
resolves an issue where a partition cannot be found later
due to corruption of a NodeList.
* The kernel's advisory locking implemenation must not be used if the
file system has its own (ie. network file systems).
* Added ASSERT to free_vnode() that assures there is no locking left;
I recently had a lot of them around.
Since wait_for_objects can wait on sems, threads and ports in addition
to FDs, limiting to RLIMIT_NOFILES as in the select/poll case does not
work. Since space is allocated for the wait objects in kernel memory,
limiting their number to a valid range is still desireable.
The limit is now placed at the sum of max sem, thread and port count
plus RLIMIT_NOFILES.
This also fixes a signed vs. unsigned comparison warning in
check_max_fds introduced in hrev51866.
It was limited to a uint32 and could for example be overflown by the
slab MemoryManager that uses size_t on a 64 bit system.
This aligns the signature with create_area() that already uses size_t
for the size argument.
Note that the function is currently private, so the impact should be
limited.
* Show old page table location and provide more feedback
* 16 int32 * 0x10000000 > sizeof(int32), fix to uint32
Change-Id: Ib68c34f5d3c6bfa1da53241e6586c07e4e494750
Output-only events (B_EVENT_ERROR, B_EVENT_DISCONNECTED and
B_EVENT_INVALID, with B_EVENT_INVALID masked out before passing down
events) are used to indicate error, so they should not be notified if
the vnode does not have select().
Bug: 13965
Output-only events (B_EVENT_ERROR, B_EVENT_DISCONNECTED and
B_EVENT_INVALID, with B_EVENT_INVALID masked out before passing down
events) are used to indicate error, so they should not be notified if
the device does not have Select().
Bug: 13965
Output-only events (B_EVENT_ERROR, B_EVENT_DISCONNECTED and
B_EVENT_INVALID, with B_EVENT_INVALID masked out before passing down
events) are used to indicate error, so they should not be notified if
the filesystem does not explicitly provide an fd_select() override.
Bug: 13965
