assuming them to be inflight write buffers. This is not always the case.
bufdaemon might hold the buffer lock and give up writing the buffer due to it
having dependencies, the file system being suspended or the vnode lock being
held by another thread. When bufdaemon decides to write the buffer there is
still a window before bufobj_wref() has been called, allowing other threads to
believe that the vnode has no dirty buffers or inflight writes.
Try harder to flush first block of new subdirectory to get rid of MKDIR_BODY
dependency.
o Introduce -r and -w keys which allow to load and save a worklist.
o Replace README by man page.
PR: bin/96677
Submitted by: Ulrich Spoerlein
Approved by: phk
MFC after: 1 month
for signicantly optimized UDP socket I/O when using a single UDP
socket from many threads or processes that share it, by avoiding
significant locking and other overhead in the general sosend()
path that isn't necessary for simple datagram sockets. Specifically,
this change results in a significant performance improvement for
threaded name service in BIND9 under load.
Suggested by: Jinmei_Tatsuya at isc dot org
Add back in a scheme to emulate old type major/minor numbers via hooks into
stat, linprocfs to return major/minors that Linux app's expect. Currently
only /dev/null is always registered. Drivers can register via the Linux
type shim similar to the ioctl shim but by using
linux_device_register_handler/linux_device_unregister_handler functions.
The structure is:
struct linux_device_handler {
char *bsd_driver_name;
char *linux_driver_name;
char *bsd_device_name;
char *linux_device_name;
int linux_major;
int linux_minor;
int linux_char_device;
};
Linprocfs uses this to display the major number of the driver. The
soon to be available linsysfs will use it to fill in the driver name.
Linux_stat uses it to translate the major/minor into Linux type values.
Note major numbers are dynamically assigned via passing in a -1 for
the major number so we don't need to keep track of them.
This is somewhat needed due to us switching to our devfs. MegaCli
will not run until I add in the linsysfs and mfi Linux compat changes.
Sponsored by: IronPort Systems
after ipsec4_output processing else KAME IPSec using the handbook
configuration with gif(4) will panic the kernel.
Problem reported by: t. patterson <tp lot.org>
Tested by: t. patterson <tp lot.org>
return NULL. In principle this shouldn't change the behavior, but
avoids returning a potentially invalid/inappropriate pointer to
the caller.
Found with: Coverity Prevent (tm)
Submitted by: pjd
MFC after: 3 months
case). Can be useful for recovering in some cases;
o use SBLOCK_UFS2 instead of SBLOCK_UFS1 to calculate likely start of the UFS2
partition from the beginning of disk.
functions not yet asserting it but working on global ip6_forward_rt
route cache which is not locked and perhaps should go away in the
future though cache hit/miss ration wasn't bad.
It's #if 0ed in frag6 because the code working on ip6_forward_rt is.
destination. These checks are needed so we do not install
a route looking like this:
(0) 192.0.2.200 UH tun0 =>
When removing this route the kernel will start to walk
the address space which looks like a hang on 64bit platforms
because it'll take ages while on 32bit you should see a panic
when kernel debugging options are turned on.
The problem is in rtrequest1:
if (netmask) {
rt_maskedcopy(dst, ndst, netmask);
} else
bcopy(dst, ndst, dst->sa_len);
In both cases the len might be 0 if the application forgot to
set it. If so ndst will be all-zero leading to above
mentioned strange routes.
This is an application error but we must not fail/hang/panic
because of this.
Looks ok: gnn
No objections: net@ (silence)
MFC after: 8 weeks
two places where g_io_request() is called. g_io_request() can free bio
structure so we can't reference it after and G_RAID3_FOREACH_BIO() macro
was doing this.
Found by: Coverity Prevent analysis tool (with my new models)
MFC after: 1 day
and displays entries from the administrative database specified by
database, using the lookup order specified in nsswitch.conf(5).
PR: bin/79903, bin/88460, bin/96536
Submitted by: Julien Gabel, Dan Nelson, Daniel J. O'Connor
Obtained from: NetBSD
Discussed with: ume, soc-bushman
MFC after: 1 month
- Fix bfe_encap so that it will pass the address of the mbuf back up to its
caller if/when it modifies it, as it does when doing a m_defrag on a mbuf chain.
- Make sure to unload the dmamap for ALL fragments of a packet, not just the first
- Use BUS_DMA_NOWAIT for all bus_dmamap_load calls so that the allocation of the
map is not delayed - this driver is not set up to handle such delays.
- Reduce the number of RX and TX buffers bfe uses so that it does not use more
bounce buffers than busdma is willing to allow it to use
With these changes, the driver now works properly for a user with a 2GB system,
and it also works on my system when the acceptable address range is lowered to 128MB.
Previously, both of these setups would act up after a few minutes of activity.
so that it can be more easily unbroken and extended.
Try to use `static', `const' (as appropriate), prototypes declared together,
and parameter names in prototypes for all private functions, not just the
new one.
interact very nicely with HTTP proxies: Since proxies do not know
that all the files on portsnap1.freebsd.org are identical to the
files with the same names on portsnap2.freebsd.org, said proxies end
up downloading and storing files in duplicate.
This commit uses the HTTP_PROXY environment variable, if set, to
generate a random number seed for use in selecting a mirror. This
means that if several systems all have the same HTTP_PROXY value set,
they will ask the proxy to fetch files from the same mirror (unless
that mirror fails, in which case all the systems will use the same
second choice, et cetera).
Portsnap still doesn't interact very well with "transparent" HTTP
proxies, but there's nothing I can do about those.
Requested by: simon
Sponsored by: FreeBSD security development fundraiser
track of which mirrors we have tried and try a different mirror if we
fail when trying to download the SSL public key or the snapshot
signature.
Failures later in the download process will not result in switching to
a different mirror, for two reasons:
1. If is very unlikely that a mirror will fail partway through the
process of downloading updates.
2. If we switched from a more recently updated mirror to a less
recently updated mirror partway through the download process, we would
end up failing anyway because we would be trying to fetch files which
the second mirror didn't have yet.
PR: bin/96288
Requested by: lots of people
Sponsored by: FreeBSD security development fundraiser
