We'll just fall into the same local delivery block under the
'if (m->m_flags & M_FASTFWD_OURS)'.
Suggested by: ae
Differential Revision: https://reviews.freebsd.org/D2225
Approved by: gnn (mentor)
In cases where we scrub (fragment reassemble) on both input and output
we risk ending up in infinite loops when forwarding packets.
Fragmented packets come in and get collected until we can defragment. At
that point the defragmented packet is handed back to the ip stack (at
the pfil point in ip6_input(). Normal processing continues.
Eventually we figure out that the packet has to be forwarded and we end
up at the pfil hook in ip6_forward(). After doing the inspection on the
defragmented packet we see that the packet has been defragmented and
because we're forwarding we have to refragment it.
In pf_refragment6() we split the packet up again and then ip6_forward()
the individual fragments. Those fragments hit the pfil hook on the way
out, so they're collected until we can reconstruct the full packet, at
which point we're right back where we left off and things continue until
we run out of stack.
Break that loop by marking the fragments generated by pf_refragment6()
as M_SKIP_FIREWALL. There's no point in processing those packets in the
firewall anyway. We've already filtered on the full packet.
Differential Revision: https://reviews.freebsd.org/D2197
Reviewed by: glebius, gnn
Approved by: gnn (mentor)
under bootverbose. Every example I've seen to date has been due to
an ACPI system resource device reserving a range that overlaps with
system memory (which ram0 attempts to reserve) or a local or I/O APIC
(which apic0 attempts to reserve). These are always harmless but look
scary to users.
MFC after: 1 week
no need for them to be this strong, we only need to provide one or the
other.
While here replace atomic_load_acq_* and atomic_store_rel_* with a single
instruction version, and fix the definition of atomic_clear_* to point to
the correct functions.
Sponsored by: The FreeBSD Foundation
ASIZE() was never used, and min() stopped being used in r207812.
Differential Revision: https://reviews.freebsd.org/D2230
Reviewed by: emax
Approved by: emax
MFC after: 1 week
The `nonnull' attribute specifies that some function parameters should be
non-null pointers. This is very useful as it helps the compiler generate
warnings on suspicious code and can also enable some small optimizations.
Also start using 'alloc_size' attribute in the allocator functions.
This is an initial step to better integrate our libc with the compiler:
these attributes are fully supported by clang and they are also useful
for the static analyzer.
Note that due to some bogus internal procedure in the way gcc ports
are built they may require updating if they were built before r280801.
Relnotes: yes
Hinted by: Android's bionic libc
Differential Revision: https://reviews.freebsd.org/D2107
I .. stupidly added code to return HAL_ANI_STATS to HAL_DIAG_ANI_STATS.
I discovered this in a noisy environment when the returned values were
enough to .. well, make everything terrible.
So - restore functionality.
Tested:
* AR5416 (uses the AR5212 HAL), in a /very/ noisy 2GHz environment.
Enough to trigger ANI to get upset and generate useful data.
The MAC addresses were totally wrong. They're like the DIR-625C1 - at
0x1ffe0004 and 0x1ffe0018. They're however stored as text strings.
The ath0 MAC address is also not set, even though the calibration
partition is valid.
So, pick the board address / first MAC as the ath0 MAC, and derive
arge0/arge1 from that. That way they're hopefully unique enough
for people with multiple devices.
Tested:
* DIR-655A1
TODO:
* Do the same for the DIR-625A1 and DIR-625C1.
So far, we were always using HID_USAGE() to determine the Usage ID of a
certain HID report input item. This does not work as intended if a field
is an array and the allowed usages are specified with a usage range, as
HID_USAGE() will return 0. We need to use the field value as an index in
the usage range list in this case instead.
This makes the volume keys in a Microsoft Bluetooth Mobile Keyboard
5000 be properly recognized. The relevant part of the HID report looks
like this:
0xA1, 0x01, // Collection (Application)
0x85, 0x07, // Report ID (7)
0x05, 0x0C, // Usage Page (Consumer)
0x19, 0x00, // Usage Minimum (Unassigned)
0x2A, 0xFF, 0x03, // Usage Maximum (0x03FF)
0x95, 0x01, // Report Count (1)
0x75, 0x10, // Report Size (16)
0x15, 0x00, // Logical Minimum (0)
0x27, 0xFF, 0x03, 0x00, 0x00, // Logical Maximum (1023)
0x81, 0x00, // Input (Data,Array,Abs,No Wrap,Linear,Preferred
// State,No Null Position)
When a key such as "volume down" is pressed, the following data is
transferred through Interrupt In:
0x07 0xEA 0x00
Differential Revision: https://reviews.freebsd.org/D2229
Reviewed by: emax
Approved by: emax
MFC after: 1 week
- Remove extranious echo that breaks puppet
- Handle restarts of multiple pflog devices correctly
- Add the ability to perform actions on specific pflog devices.
PR: 199150
Submitted by: jason.unovitch@gmail.com
MFC after: 3 days
This is only an interim fix; MIPS should be using the MI code instead,
which does not have this issue.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D661
unroll the loop in ENTRY(pagezero)
acc' to the submitter this results in a reproducible 1% perf
improvement under buildworld like workload
I validated correctness and run-testing, but not performance impact
Submitted by: lidl@pix.net
Reviewed by: adrian
PR: 199151
MFC After: 1 month
