According to UEFI spec,
for the Messaging Device Path with USB Class SubType, some paras
are optional in the text device path.
Take UsbClass(VID,PID,Class,SubClass,Protocol) for example,
The VID is an integer between 0 and 65535 and is optional. The
default value is 0xFFFF.
The PID is an integer between 0 and 65535 and is optional. The
default value is 0xFFFF.
The Class is an integer between 0 and 255 and is optional. The
default value is 0xFF.
The SubClass is an integer between 0 and 255 and is optional. The
default value is 0xFF.
The Protocol is an integer between 0 and 255 and is optional. The
default value is 0xFF.
So if any the optional para is not specified in the text device,
we should set related para in the node structure to default value.
This commit is to do the enhancement for USB Class device path
when optional para is not specified.
Upstream Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=1243
Obtained from: 3874108034
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
When converting DebugPort device path from text,
current code use VENDOR_DEFINED_MESSAGING_DEVICE_PATH structure
for Debug port device node.
typedef struct {
EFI_DEVICE_PATH_PROTOCOL Header;
EFI_GUID Guid;
UINT8 VendorDefinedData[1];
} VENDOR_DEFINED_MESSAGING_DEVICE_PATH;
And Debugport Device Path is a vendor-defined messaging
device path with no data, only a GUID. So it's better to
use VENDOR_DEVICE_PATH to create the Debug port device node.
typedef struct {
EFI_DEVICE_PATH_PROTOCOL Header;
EFI_GUID Guid;
} VENDOR_DEVICE_PATH;
Upstream Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=1229
Obtained from: 9343d0a1cd
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
According to UEFI spec,for ACPI Expanded Device Path
when HID=PNP0A03 or CID=PNP0A03 and HID != PNP0A08,
the device path node can be displayed as: PciRoot(UID|UIDSTR)
When HID=PNP0A08 or CID=PNP0A08, the device path node can be
displayed as: PcieRoot(UID|UIDSTR). But current code miss the
code logic.
This commit is to do the enhancement.
Upstream Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=1228
Obtained from: 78af0984b4
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
According to UEFI Spec, for ACPI Expanded Device Path,
when HIDSTR=empty, CIDSTR=empty, UID STR!=empty,
the ACPI Expanded Device Path node can be displayed as
AcpiExp(HID,CID,UIDSTR) format.
And if UID is 0 and UIDSTR is empty, then use AcpiEx format.
This patch is to correct the condition check to follow UEFI
Spec when convert the device path node to the AcpiExp text
format.
Upstream Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=1226
Obtained from: fb4bea551e
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
1. Do not use tab characters
2. No trailing white space in one line
3. All files must end with CRLF
Adapted according to FreeBSD-update instructions, with the sole purpose
of reducing the differences with upstream sources.
Obtained from: 9095d37b8f
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
Per UEFI spec, iSCSI.Lun is a 8-byte array with byte #0 in the left.
It means "0102030405060708" should be converted to:
UINT8[8] = {01, 02, 03, 04, 05, 06, 07, 08}
or UINT64 = {0807060504030201}
Today's implementation wrongly uses the reversed order.
Obtained from: d0196be1e3
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
For the following two functions:
DevPathFromTextBluetooth()
DevPathToTextBluetooth()
The Bluetooth device address "UINT8 Address[6]" is displayed with the
order from Address[5] to Address[0]. This commit reverses the order.
Obtained from: 4fc8277133
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
For current iSCSI protocol parsing, UINT16 truncation may be happened. Since
the Spec already have declaimed that 0 is TCP Protocol and 1+ is reserved, the
parsing can be refined as below:
if (StrCmp (ProtocolStr, L"TCP") == 0) {
ISCSIDevPath->NetworkProtocol = 0;
} else {
//
// Undefined and reserved.
//
ISCSIDevPath->NetworkProtocol = 1;
}
Obtained from: 7571a1c191
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
UefiDevicePathLibConvertTextToDevicePath correctly detects when it
has hit a ',' splicing together multiple paths. However, the code
that tries to cope with it:
{code}
if (IsInstanceEnd) {
DeviceNode = (EFI_DEVICE_PATH_PROTOCOL *) AllocatePool (
END_DEVICE_PATH_LENGTH);
ASSERT (DeviceNode != NULL);
SetDevicePathEndNode (DeviceNode);
NewDevicePath = AppendDevicePathNode (DevicePath, DeviceNode);
FreePool (DevicePath);
FreePool (DeviceNode);
DevicePath = NewDevicePath;
}
{code}
causes a problem. The END node that's appended it the node for the
entire list. So when the node is appended in AppendDevicePathNode,
it winds up disappearing. This leads to the path
'PciRoot(0x0),PciRoot(0x0)' parsing as if 'PciRoot(0x0)/PciRoot(0x0)'
were specified. These are two very different things.
NOTE:
This fix was already committed. It has been included with the sole
intention of reducing diffs with upstream.
Upstream Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=419
Obtained from: 647636e175
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
Network interface type should be checked before the conversion between
text device path node and MAC device path. Otherwise, the MAC text string
can't be converted to the representation of a device node, which leads to
the series failure of network HII configuration(e.g. IP, VLAN, HTTP Boot
configuration in Network Device List).
Obtained from: 2d67f2bae3
Pull Request: https://github.com/freebsd/freebsd-src/pull/581
Merge commit f457863ae345 from llvm git (by Fangrui Song):
[ELF] Support REL-format R_AARCH64_NONE relocation
-fprofile-use=/-fprofile-sample-use= compiles may produce REL-format
.rel.llvm.call-graph-profile even if the prevailing format is RELA on AArch64.
Add R_AARCH64_NONE to getImplicitAddend to fix this linker error:
```
ld.lld: error: internal linker error: cannot read addend for relocation R_AARCH64_NONE
PLEASE submit a bug report to https://crbug.com and run tools/clang/scripts/process_crashreports.py (only works inside Google) which will upload a report and include the crash backtrace.
```
Merge commit 53fc5d9b9a01 from llvm git (by Fangrui Song):
[ELF] Support R_PPC_NONE/R_PPC64_NONE in getImplicitAddend
Similar to f457863ae345d2635026501f5383e0e625869639
Merge commit 767e64fc11d7 from llvm git (by Fangrui Song):
[ELF] Support some absolute/PC-relative relocation types for REL format
ctfconvert seems to use REL-format `.rel.SUNW_dof` for 32-bit architectures.
```
Binary file usr/ports/lang/perl5.32/work/perl-5.32.1/dtrace_mini.o matches
[alfredo.junior@dell-a ~/tmp/llvm-bug]$ readelf -r dtrace_mini.o
Relocation section (.rel.SUNW_dof):
r_offset r_info r_type st_value st_name
00000184 0000281a R_PPC_REL32 00000000 $dtrace1772974259.Perl_dtrace_probe_load
```
Support R_PPC_REL32 to fix `ld.lld: error: drti.c:(.SUNW_dof+0x4E4): internal linker error: cannot read addend for relocation R_PPC_REL32`.
While here, add some common relocation types for AArch64, PPC, and PPC64.
We perform minimum tests.
Reviewed By: adalava, arichardson
Differential Revision: https://reviews.llvm.org/D120535
Requested by: alfredo
MFC after: 3 days
something similar a while back, and there are devices in the wild
that otherwise won't attach. This patch is temporary until the
PHY code is further cleared up.
Obtained from: grehan
but was missed. Mark it for gone_in 14.0. The hardware hasn't been
produced or supported in over 20 years, and even back then it was
known to be electrically unreliable and prone to catastrophic failure.
physical/absolute address in FreeBSD, but it looks like the calling
code might be somewhat portable to other OS's that do require this.
Therefore, set the variables to __unused instead of removing the code
entirely.
The OID "kern.iscsi.login_timeout" references an integer and
not a string.
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D34380
While coalescing all ECN-related code into new common source files,
the flag to deal with SACK retransmissions was skipped. This leads
to non-compliant ECT-marking of SACK retransmissions, as well as
the premature sending of other TCP ECN flags (CWR).
Reviewed By: rrs, #transport
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D34376
Use get_pcpu() instead of an open-coded pcpu_find(td->td_oncpu). This
eliminates some memory accesses and results in a shorter instruction
sequence. Note that get_pcpu() didn't exist when rmlocks were added.
Reviewed by: jah, mjg
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34377
Due to misplaced braces, an error from vfs_uninit() in the VFCF_SBDRY
case was ignored.
Reported by: Anton Rang <rang@acm.org>
Reviewed by: Anton Rang <rang@acm.org>, markj
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D34375
The result of fstat() was not checked. Furthermore, there was a
redundant check of st.st_size. Fix both.
Reported by: Coverity
MFC after: 1 week
Sponsored by: Dell EMC Isilon
The result of read() was stored in an unsigned variable, so the
test for a negative value would never work.
While I'm here, print a better error message for an empty file,
omitting the misleading errno message.
Reported by: Coverity
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Since commit 04e9edb544, rtsold has leaked the memory for the
argument vector of every script it runs.
Reported by: Coverity
Reviewed by: markj
Fixes: 04e9edb544
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D34355
Set errno to EINVAL if the name overflows the buffer, as was done
before commit ecce515d54.
Reviewed by: dab, markj
Fixes: ecce515d54
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D34354
ler@, markj@ reported a use after free in nfscl_cleanupkext().
They also provided two possible causes:
- In nfscl_cleanup_common(), "own" is the owner string
owp->nfsow_owner. If we free that particular
owner structure, than in subsequent comparisons
"own" will point to freed memory.
- nfscl_cleanup_common() can free more than one owner, so the use
of LIST_FOREACH_SAFE() in nfscl_cleanupkext() is not sufficient.
I also believe there is a 3rd:
- If nfscl_freeopenowner() or nfscl_freelockowner() is called
without the NFSCLSTATE mutex held, this could race with
nfscl_cleanupkext().
This could happen when the exclusive lock is held
on the client, such as when delegations are being returned
or when recovering from NFSERR_EXPIRED.
This patch fixes them as follows:
1 - Copy the owner string to a local variable before the
nfscl_cleanup_common() call.
2 - Modify nfscl_cleanup_common() so that it will never free more
than the first matching element. Normally there should only
be one element in each list with a matching open/lock owner
anyhow (but there might be a bug that results in a duplicate).
This should guarantee that the FOREACH_SAFE loops in
nfscl_cleanupkext() are adequate.
3 - Acquire the NFSCLSTATE mutex in nfscl_freeopenowner()
and nfscl_freelockowner(), if it is not already held.
This serializes all of these calls with the ones done in
nfscl_cleanup_common().
Reported by: ler
Reviewed by: markj
Tested by: cy
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D34334
Add per-Session configurable ping (SCSI NOP) and login timeouts.
Remove the torn down, old iSCSI session quickly, when performing a reconnect.
Reviewed By: trasz
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D34198
Require the newly opened file descriptor to be good, instead of
re-requiring the one that was required three lines earlier.
Thankfully, opening /dev/null is really unlikely to fail.
Reported by: Coverity
MFC after: 1 week
Sponsored by: Dell EMC Isilon
