In our implementation and most others, a break or continue in a dot script
can break or continue a loop outside the dot script. This should cause all
further commands in the dot script to be skipped. However, cmdloop() did not
know about this and continued to parse and execute commands from the dot
script.
As described in the man page, a return in a dot script in a function returns
from the function, not only from the dot script. There was a similar issue
as with break and continue. In various other shells, the return appears to
return from the dot script, but POSIX seems not very clear about this.
a very bad one, since the shift does not actually overflow. This is
a better example (assuming uint64_t = unsigned long long):
~0LLU >> 9 = 0x7fffffffffffffLLU
~0LLU >> 9 << 10 = 0xfffffffffffffc00LLU
~0LLU >> 9 << 10 >> 10 = 0x3fffffffffffffLLU
path MTU discovery and the tcp_minmss limiter for very small MTU's.
When the MTU suggested by the gateway via ICMP, or if there isn't
any the next smaller step from ip_next_mtu(), is lower than the
floor enforced by net.inet.tcp.minmss (default 216) the value is
ignored and the default MSS (512) is used instead. However the
DF flag in the IP header is still set in tcp_output() preventing
fragmentation by the gateway.
Fix this by using tcp_minmss as the MSS and clear the DF flag if
the suggested MTU is too low. This turns off path MTU dissovery
for the remainder of the session and allows fragmentation to be
done by the gateway.
Only MTU's smaller than 256 are affected. The smallest official
MTU specified is for AX.25 packet radio at 256 octets.
PR: kern/146628
Tested by: Matthew Luckie <mjl-at-luckie org nz>
MFC after: 1 week
report when a new socket couldn't be created because one of
in_pcbinshash(), in6_pcbconnect() or in_pcbconnect() failed.
Logging is conditional on net.inet.tcp.log_debug being enabled.
MFC after: 1 week
bug in the config file was long, and merged to stable, we have to bump
the version here so that stable/8 kernels can have their required
version number bumped to make sure the right config is used.
MFC after: 3 days
fatal condition. While it works out really well for diagnosing the
case where you want it, but don't have it, it works really badly for
the case where you don't have it and don't want it. Remove the printf
and exit pair. Replate it with simple return to silently ignore this
condition.
This is needed to fix the COMPAT_IA32 being required in options.* in
stable, but we need to run this change through -current first...
MFC after: 3 days
and we loop back to 'again'. If the remainder is less or equal
to one full segment, the TSO flag was not cleared even though
it isn't necessary anymore. Enabling the TSO flag on a segment
that doesn't require any offloaded segmentation by the NIC may
cause confusion in the driver or hardware.
Reset the internal tso flag in tcp_output() on every iteration
of sendalot.
PR: kern/132832
Submitted by: Renaud Lienhart <renaud-at-vmware com>
MFC after: 1 week
a kernel printf to a log output with the priority of LOG_NOTICE.
This way the messages still show up in /var/log/messages but no
longer spam the console every other second on busy servers that
are port scanned:
"Limiting open port RST response from 114 to 100 packets/sec"
PR: kern/147352
Submitted by: Eugene Grosbein <eugen-at-eg sd rdtc ru>
MFC after: 1 week
It was experimental and interferes with the normal congestion control
algorithms by instating a separate, possibly lower, ceiling for the
amount of data that is in flight to the remote host. With high speed
internet connections the inflight limit frequently has been estimated
too low due to the noisy nature of the RTT measurements.
This code gives way for the upcoming pluggable congestion control
framework. It is the task of the congestion control algorithm to
set the congestion window and amount of inflight data without external
interference.
Reviewed by: lstewart
MFC after: 1 week
Removal after: 1 month
switch. Since expand_number() does not accept negative numbers, switch
from int64_t to uint64_t; this makes it easier to check for overflow.
MFC after: 3 weeks
and go to the next iteration early if multicast filtering would decide that
this socket shall not receive the data.
Unlock the pcb in that case or we leak the read lock and next time trying
to get a write lock, would hang forever.
PR: kern/149608
Submitted by: Chris Luke (chrisy flirble.org)
MFC after: 3 days
It is more appropriate in this context because TSC MSR is reset to zero
when the CPU is restarted from S3 and above. Move acpi_resync_clock() back
to where it was before r211202. It does not make a difference any more.
unless it is the current timer. When we have resumed successfully, restore
the previous timecounter hardware if it was changed earlier. Only the ACPI
timer is guaranteed to increase monotonically between S-state changes.