Greetings from Ukraine,
Mr. Razumkov Mykhailo, an entrepreneur businessman from Odessa
Ukraine. Within a year plus some months now, more than 8.2 million
people around the cities of my country Ukraine have been evacuated to
a safe location and out of the country, most especially children with
their parents, nursing mothers and pregnant women, and those who have
been seriously wounded and need urgent medical attention. I was among
those that were able to evacuate to our neighbouring countries and I’m
now in the refugee camp of Ter Apel Groningen in the Netherlands.
I need a foreign partner to enable me to transport my investment
capital and then relocate with my family, honestly i wish I will
discuss more and get along. I need a partner because my investment
capital is in my international account. I’m interested in buying
properties, houses, building real estates, my capital for investment
is ($30 Million USD) . The financial institutions in my country
Ukraine are all shot down due to the crisis of this war on Ukraine
soil by the Russian forces. Meanwhile, if there is any profitable
investment that you have so much experience in your country, then we
can join together as partners since I’m a foreigner.
I came across your e-mail contact through private search while in need
of your assistance and I decided to contact you directly to ask you if
you know any lucrative business investment in your country i can
invest my money since my country Ukraine security and economic
independent has lost to the greatest lower level, and our culture has
lost including our happiness has been taken away from us. Our country
has been on fire for more than a year now.
If you are capable of handling this business partnership, contact me
for more details, I will appreciate it if you can contact me
immediately. You may as well tell me a little more about yourself.
Contact me urgently to enable us to proceed with the business. I will
be waiting for your response. My sincere apologies for the
inconvenience.
Thank you!
Mr. Razumkov Mykhailo.
From commit ebf7d1f508a73871 ("bpf, x64: rework pro/epilogue and tailcall
handling in JIT"), the tailcall on x64 works better than before.
From commit e411901c0b775a3a ("bpf: allow for tailcalls in BPF subprograms
for x64 JIT"), tailcall is able to run in BPF subprograms on x64.
From commit 5b92a28aae4dd0f8 ("bpf: Support attaching tracing BPF program
to other BPF programs"), BPF program is able to trace other BPF programs.
How about combining them all together?
1. FENTRY/FEXIT on a BPF subprogram.
2. A tailcall runs in the BPF subprogram.
3. The tailcall calls itself.
As a result, a tailcall infinite loop comes up. And the loop would halt
the machine.
As we know, in tail call context, the tail_call_cnt propagates by stack
and RAX register between BPF subprograms. So do it in FENTRY/FEXIT
trampolines.
How did I discover the bug?
From commit 7f6e4312e15a5c37 ("bpf: Limit caller's stack depth 256 for
subprogs with tailcalls"), the total stack size limits to around 8KiB.
Then, I write some bpf progs to validate the stack consuming, that are
tailcalls running in bpf2bpf and FENTRY/FEXIT tracing on bpf2bpf[1].
At that time, accidently, I made a tailcall loop. And then the loop halted
my VM. Without the loop, the bpf progs would consume over 8KiB stack size.
But the _stack-overflow_ did not halt my VM.
With bpf_printk(), I confirmed that the tailcall count limit did not work
expectedly. Next, read the code and fix it.
Finally, unfortunately, I only fix it on x64 but other arches. As a
result, CI tests failed because this bug hasn't been fixed on s390x.
Some helps are requested.
[1]: https://github.com/Asphaltt/learn-by-example/tree/main/ebpf/tailcall-stacko…
Leon Hwang (2):
bpf, x64: Fix tailcall infinite loop bug
selftests/bpf: Add testcases for tailcall infinite loop bug fixing
arch/x86/net/bpf_jit_comp.c | 23 ++-
include/linux/bpf.h | 6 +
kernel/bpf/trampoline.c | 5 +-
kernel/bpf/verifier.c | 9 +-
.../selftests/bpf/prog_tests/tailcalls.c | 194 +++++++++++++++++-
.../bpf/progs/tailcall_bpf2bpf_fentry.c | 18 ++
.../bpf/progs/tailcall_bpf2bpf_fexit.c | 18 ++
7 files changed, 264 insertions(+), 9 deletions(-)
create mode 100644 tools/testing/selftests/bpf/progs/tailcall_bpf2bpf_fentry.c
create mode 100644 tools/testing/selftests/bpf/progs/tailcall_bpf2bpf_fexit.c
base-commit: 9930e4af4b509bcf6f060b09b16884f26102d110
--
2.41.0
The hwcaps selftest currently relies on the assembler being able to
assemble the crc32w instruction but this is not in the base v8.0 so is not
accepted by the standard GCC configurations used by many distributions.
Switch to manually encoding to fix the build.
Fixes: 09d2e95a04ad ("kselftest/arm64: add crc32 feature to hwcap test")
Signed-off-by: Mark Brown <broonie(a)kernel.org>
---
tools/testing/selftests/arm64/abi/hwcap.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/arm64/abi/hwcap.c b/tools/testing/selftests/arm64/abi/hwcap.c
index 112b6a219382..3b26a3660292 100644
--- a/tools/testing/selftests/arm64/abi/hwcap.c
+++ b/tools/testing/selftests/arm64/abi/hwcap.c
@@ -42,7 +42,8 @@ static void atomics_sigill(void)
static void crc32_sigill(void)
{
- asm volatile("crc32w w0, w0, w1");
+ /* CRC32W W0, W0, W1 */
+ asm volatile(".inst 0x1ac14800" : : : );
}
static void cssc_sigill(void)
---
base-commit: 358b763ee64b11f45287c286e1f6145729ed49ab
change-id: 20230816-arm64-fix-crc32-build-9d4c94f2e60e
Best regards,
--
Mark Brown <broonie(a)kernel.org>
lwt xmit hook does not expect positive return values in function
ip_finish_output2 and ip6_finish_output. However, BPF programs can
directly return positive statuses such like NET_XMIT_DROP, NET_RX_DROP,
and etc to the caller. Such return values would make the kernel continue
processing already freed skbs and eventually panic.
This set fixes the return values from BPF ops to unexpected continue
processing, checks strictly on the correct continue condition for
future proof. In addition, add missing selftests for BPF redirect
and reroute cases for BPF-CI.
v5: https://lore.kernel.org/bpf/cover.1692153515.git.yan@cloudflare.com/
v4: https://lore.kernel.org/bpf/ZMD1sFTW8SFiex+x@debian.debian/T/
v3: https://lore.kernel.org/bpf/cover.1690255889.git.yan@cloudflare.com/
v2: https://lore.kernel.org/netdev/ZLdY6JkWRccunvu0@debian.debian/
v1: https://lore.kernel.org/bpf/ZLbYdpWC8zt9EJtq@debian.debian/
changes since v5:
* fix BPF-CI failures due to missing config and busybox ping issue
changes since v4:
* fixed same error on BPF_REROUTE path
* re-implemented selftests under BPF-CI requirement
changes since v3:
* minor change in commit message and changelogs
* tested by Jakub Sitnicki
changes since v2:
* subject name changed
* also covered redirect to ingress case
* added selftests
changes since v1:
* minor code style changes
Yan Zhai (4):
lwt: fix return values of BPF xmit ops
lwt: check LWTUNNEL_XMIT_CONTINUE strictly
selftests/bpf: add lwt_xmit tests for BPF_REDIRECT
selftests/bpf: add lwt_xmit tests for BPF_REROUTE
include/net/lwtunnel.h | 5 +-
net/core/lwt_bpf.c | 7 +-
net/ipv4/ip_output.c | 2 +-
net/ipv6/ip6_output.c | 2 +-
tools/testing/selftests/bpf/config | 2 +
.../selftests/bpf/prog_tests/lwt_helpers.h | 139 ++++++++
.../selftests/bpf/prog_tests/lwt_redirect.c | 330 ++++++++++++++++++
.../selftests/bpf/prog_tests/lwt_reroute.c | 262 ++++++++++++++
.../selftests/bpf/progs/test_lwt_redirect.c | 90 +++++
.../selftests/bpf/progs/test_lwt_reroute.c | 36 ++
10 files changed, 868 insertions(+), 7 deletions(-)
create mode 100644 tools/testing/selftests/bpf/prog_tests/lwt_helpers.h
create mode 100644 tools/testing/selftests/bpf/prog_tests/lwt_redirect.c
create mode 100644 tools/testing/selftests/bpf/prog_tests/lwt_reroute.c
create mode 100644 tools/testing/selftests/bpf/progs/test_lwt_redirect.c
create mode 100644 tools/testing/selftests/bpf/progs/test_lwt_reroute.c
--
2.30.2
iommufd gives userspace the capability to manipulate iommu subsytem.
e.g. DMA map/unmap etc. In the near future, it will support iommu nested
translation. Different platform vendors have different implementations for
the nested translation. For example, Intel VT-d supports using guest I/O
page table as the stage-1 translation table. This requires guest I/O page
table be compatible with hardware IOMMU. So before set up nested translation,
userspace needs to know the hardware iommu information to understand the
nested translation requirements.
This series reports the iommu hardware information for a given device
which has been bound to iommufd. It is preparation work for userspace to
allocate hwpt for given device. Like the nested translation support [1].
This series introduces an iommu op to report the iommu hardware info,
and an ioctl IOMMU_GET_HW_INFO is added to report such hardware info to
user. enum iommu_hw_info_type is defined to differentiate the iommu hardware
info reported to user hence user can decode them. This series adds the
framework for iommu hw info reporting, and adds the vtd implementation. The
complete code is available in [2].
[1] https://lore.kernel.org/linux-iommu/20230724110406.107212-1-yi.l.liu@intel.…
[2] https://github.com/yiliu1765/iommufd/tree/iommufd_hw_info-v9
Change log:
v9:
- Simplify kdoc and updated commit logs
- Minor changes in iommufd_get_hw_info() from Kevin's review comments
- Add a selftest coverage for passing in a smaller buffer
- Add Kevin's r-b to patch 02/03/05.
v8: https://lore.kernel.org/linux-iommu/20230816121349.104436-1-yi.l.liu@intel.…
- Updated the uAPI by allowing a 0 value at the input @data_len
- Changed to always report the kernel supported data length instead of the
length that kernel filled in the user space buffer
- Updated uAPI doc accordingly
- Add one more selftest for 0 value @data_len and also check the output @data_len
with the size kernel supports
- Fix the usage of clear_user()
- Rebase on top of Jason's for-next branch (base: 65aaca1 iommufd: Remove iommufd_ref_to_users())
- Include the vtd hw_info implementation from vtd nesting series
https://lore.kernel.org/r/20230724111335.107427-12-yi.l.liu@intel.com
v7: https://lore.kernel.org/linux-iommu/20230811071501.4126-1-yi.l.liu@intel.co…
- Use clear_user() (Jason)
- Add fail_nth for hw_ifo (Jason)
v6: https://lore.kernel.org/linux-iommu/20230808153510.4170-1-yi.l.liu@intel.co…
- Add Jingqi's comment on patch 02
- Add Baolu's r-b to patch 03
- Address Jason's comment on patch 03
v5: https://lore.kernel.org/linux-iommu/20230803143144.200945-1-yi.l.liu@intel.…
- Return hw_info_type in the .hw_info op, hence drop hw_info_type field in iommu_ops (Kevin)
- Add Jason's r-b for patch 01
- Address coding style comments from Jason and Kevin w.r.t. patch 02, 03 and 04
v4: https://lore.kernel.org/linux-iommu/20230724105936.107042-1-yi.l.liu@intel.…
- Rename ioctl to IOMMU_GET_HW_INFO and structure to iommu_hw_info
- Move the iommufd_get_hw_info handler to main.c
- Place iommu_hw_info prior to iommu_hwpt_alloc
- Update the function namings accordingly
- Update uapi kdocs
v3: https://lore.kernel.org/linux-iommu/20230511143024.19542-1-yi.l.liu@intel.c…
- Add r-b from Baolu
- Rename IOMMU_HW_INFO_TYPE_DEFAULT to be IOMMU_HW_INFO_TYPE_NONE to
better suit what it means
- Let IOMMU_DEVICE_GET_HW_INFO succeed even the underlying iommu driver
does not have driver-specific data to report per below remark.
https://lore.kernel.org/kvm/ZAcwJSK%2F9UVI9LXu@nvidia.com/
v2: https://lore.kernel.org/linux-iommu/20230309075358.571567-1-yi.l.liu@intel.…
- Drop patch 05 of v1 as it is already covered by other series
- Rename the capability info to be iommu hardware info
v1: https://lore.kernel.org/linux-iommu/20230209041642.9346-1-yi.l.liu@intel.co…
Regards,
Yi Liu
Lu Baolu (1):
iommu: Add new iommu op to get iommu hardware information
Nicolin Chen (1):
iommufd/selftest: Add coverage for IOMMU_GET_HW_INFO ioctl
Yi Liu (3):
iommu: Move dev_iommu_ops() to private header
iommufd: Add IOMMU_GET_HW_INFO
iommu/vt-d: Implement hw_info for iommu capability query
drivers/iommu/intel/iommu.c | 19 +++++
drivers/iommu/iommu-priv.h | 11 +++
drivers/iommu/iommufd/device.c | 73 +++++++++++++++++++
drivers/iommu/iommufd/iommufd_private.h | 1 +
drivers/iommu/iommufd/iommufd_test.h | 9 +++
drivers/iommu/iommufd/main.c | 3 +
drivers/iommu/iommufd/selftest.c | 16 ++++
include/linux/iommu.h | 16 ++--
include/uapi/linux/iommufd.h | 71 ++++++++++++++++++
tools/testing/selftests/iommu/iommufd.c | 38 +++++++++-
.../selftests/iommu/iommufd_fail_nth.c | 4 +
tools/testing/selftests/iommu/iommufd_utils.h | 62 ++++++++++++++++
12 files changed, 311 insertions(+), 12 deletions(-)
--
2.34.1
As is described in the "How to use MPTCP?" section in MPTCP wiki [1]:
"Your app should create sockets with IPPROTO_MPTCP as the proto:
( socket(AF_INET, SOCK_STREAM, IPPROTO_MPTCP); ). Legacy apps can be
forced to create and use MPTCP sockets instead of TCP ones via the
mptcpize command bundled with the mptcpd daemon."
But the mptcpize (LD_PRELOAD technique) command has some limitations
[2]:
- it doesn't work if the application is not using libc (e.g. GoLang
apps)
- in some envs, it might not be easy to set env vars / change the way
apps are launched, e.g. on Android
- mptcpize needs to be launched with all apps that want MPTCP: we could
have more control from BPF to enable MPTCP only for some apps or all the
ones of a netns or a cgroup, etc.
- it is not in BPF, we cannot talk about it at netdev conf.
So this patchset attempts to use BPF to implement functions similer to
mptcpize.
The main idea is to add a hook in sys_socket() to change the protocol id
from IPPROTO_TCP (or 0) to IPPROTO_MPTCP.
[1]
https://github.com/multipath-tcp/mptcp_net-next/wiki
[2]
https://github.com/multipath-tcp/mptcp_net-next/issues/79
v14:
- Use getsockopt(MPTCP_INFO) to verify mptcp protocol intead of using
nstat command.
v13:
- drop "Use random netns name for mptcp" patch.
v12:
- update diag_* log of update_socket_protocol.
- add 'ip netns show' after 'ip netns del' to check if there is
a test did not clean up its netns.
- return libbpf_get_error() instead of -EIO for the error from
open_and_load().
- Use getsockopt(SOL_PROTOCOL) to verify mptcp protocol intead of
using 'ss -tOni'.
v11:
- add comments about outputs of 'ss' and 'nstat'.
- use "err = verify_mptcpify()" instead of using =+.
v10:
- drop "#ifdef CONFIG_BPF_JIT".
- include vmlinux.h and bpf_tracing_net.h to avoid defining some
macros.
- drop unneeded checks for mptcp.
v9:
- update comment for 'update_socket_protocol'.
v8:
- drop the additional checks on the 'protocol' value after the
'update_socket_protocol()' call.
v7:
- add __weak and __diag_* for update_socket_protocol.
v6:
- add update_socket_protocol.
v5:
- add bpf_mptcpify helper.
v4:
- use lsm_cgroup/socket_create
v3:
- patch 8: char cmd[128]; -> char cmd[256];
v2:
- Fix build selftests errors reported by CI
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/79
Geliang Tang (4):
bpf: Add update_socket_protocol hook
selftests/bpf: Add two mptcp netns helpers
selftests/bpf: Fix error checks of mptcp open_and_load
selftests/bpf: Add mptcpify test
net/mptcp/bpf.c | 15 ++
net/socket.c | 26 ++-
.../testing/selftests/bpf/prog_tests/mptcp.c | 155 +++++++++++++++---
tools/testing/selftests/bpf/progs/mptcpify.c | 20 +++
4 files changed, 196 insertions(+), 20 deletions(-)
create mode 100644 tools/testing/selftests/bpf/progs/mptcpify.c
--
2.35.3
Dzień dobry,
Czy interesuje Państwa rozwiązanie umożliwiające monitorowanie samochodów firmowych oraz optymalizację kosztów ich utrzymania?
Pozdrawiam,
Jakub Lemczak
