-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add CONFIG_NETFILTER_XT_MATCH_RECENT=y (5.4.y) #199
Add CONFIG_NETFILTER_XT_MATCH_RECENT=y (5.4.y) #199
Conversation
Adds xt_recent module, needed for iptables -m recent ..., used by Kubernetes kube-proxy to implement Services with sessionAffinity: ClientIP
I also added this to my PR. Thanks for bringing this up. |
Thank you for your contribution. The WSL team has discussed and decided that the WSL 2 Linux kernel GitHub repo is not taking pull requests. The WSL 2 Linux kernel repo was always intended to provide the additional infrastructure necessary to build and release the kernel component of WSL 2. It was never designed to replace the current existing community and feedback channels for WSL, especially through https://github.com/microsoft/WSL. This is why we are not accepting issues or pull requests through this repository. We understand that this should have been better communicated and implemented from the beginning. While we understand that it is frustrating to have a PR closed, it is never our intention to ignore feedback or stifle community discussions. We are taking this opportunity to increase transparency on how we work with the WSL community and ensure all members are routed to the appropriate resources. If you would like contribute to, discuss, or report an issue relating to WSL, or the WSL 2 Linux kernel configuration, please do so at the WSL GitHub. The team is actively monitoring and responding to user feedback there: https://github.com/microsoft/WSL. The WSL 2 Linux kernel is based on the Linux version from https://www.kernel.org/. If you would like to contribute to or report an issue on the Linux kernel in general, please do so on the upstream Linux GitHub: https://www.kernel.org/doc/html/latest/process/submitting-patches.html. |
When the PHY fails on calibration we were previously skipping the ddi initialization. However the driver is not really prepared for that, ultimately leading to a NULL pointer dereference: [ 75.748348] i915 0000:03:00.0: [drm:intel_modeset_init_nogem [i915]] SNPS PHY A failed to calibrate; output will not be used. ... [ 75.750336] i915 0000:03:00.0: [drm:intel_modeset_setup_hw_state [i915]] [CRTC:80:pipe A] hw state readout: enabled ... ( no DDI A/PHY A ) [ 75.753080] i915 0000:03:00.0: [drm:intel_modeset_setup_hw_state [i915]] [ENCODER:235:DDI B/PHY B] hw state readout: disabled, pipe A [ 75.753164] i915 0000:03:00.0: [drm:intel_modeset_setup_hw_state [i915]] [ENCODER:245:DDI C/PHY C] hw state readout: disabled, pipe A ... [ 75.754425] i915 0000:03:00.0: [drm] *ERROR* crtc 80: Can't calculate constants, dotclock = 0! [ 75.765558] i915 0000:03:00.0: drm_WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev)) [ 75.765569] WARNING: CPU: 5 PID: 1759 at drivers/gpu/drm/drm_vblank.c:728 drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x347/0x360 ... [ 75.781230] BUG: kernel NULL pointer dereference, address: 000000000000007c [ 75.788198] #PF: supervisor read access in kernel mode [ 75.793347] #PF: error_code(0x0000) - not-present page [ 75.798480] PGD 0 P4D 0 [ 75.801019] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 75.805377] CPU: 5 PID: 1759 Comm: modprobe Tainted: G W 5.18.0-rc1-demarchi+ microsoft#199 [ 75.827613] RIP: 0010:icl_aux_power_well_disable+0x3b/0x200 [i915] [ 75.833890] Code: 83 ec 30 65 48 8b 04 25 28 00 00 00 48 89 44 24 28 48 8b 06 0f b6 70 1c f6 40 20 04 8d 56 fa 0f 45 f2 e8 88 bd ff ff 48 89 ef <8b> 70 7c e8 ed 67 ff ff 48 89 ef 89 c6 e8 73 67 ff ff 84 c0 75 0a [ 75.852629] RSP: 0018:ffffc90003a7fb30 EFLAGS: 00010246 [ 75.857852] RAX: 0000000000000000 RBX: ffff8881145e8f10 RCX: 0000000000000000 [ 75.864978] RDX: ffff888115220840 RSI: 0000000000000000 RDI: ffff888115220000 [ 75.872106] RBP: ffff888115220000 R08: ffff88888effffe8 R09: 00000000fffdffff [ 75.879234] R10: ffff88888e200000 R11: ffff88888ed00000 R12: ffff8881145e8f10 [ 75.886363] R13: 0000000000000001 R14: ffff888115223240 R15: 0000000000000000 [ 75.893490] FS: 00007ff6e753a740(0000) GS:ffff88888f680000(0000) knlGS:0000000000000000 [ 75.901573] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 75.907313] CR2: 000000000000007c CR3: 00000001216a6001 CR4: 0000000000770ee0 [ 75.914446] PKRU: 55555554 [ 75.917153] Call Trace: [ 75.919603] <TASK> [ 75.921709] intel_power_domains_sanitize_state+0x88/0xb0 [i915] [ 75.927814] intel_modeset_init_nogem+0x317/0xef0 [i915] [ 75.933205] i915_driver_probe+0x5f6/0xdf0 [i915] [ 75.937976] i915_pci_probe+0x51/0x1d0 [i915] We skip the initialization of PHY A, but later we try to find out what is the phy for that power well and dereference dig_port, which is NULL. Failing the PHY calibration could be left as a warning or error, like it was before commit b4eb76d ("drm/i915/dg2: Skip output init on PHY calibration failure"). However that often fails for outputs not being used, which would make the warning/error appear on systems that have no visible issues. Anyway, there is still a need to fix those failures, but that is left for later. Signed-off-by: Lucas De Marchi <[email protected]> Reviewed-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
commit 560840a upstream. If a file consists of an inline extent followed by a regular or prealloc extent, then a legitimate attempt to resolve a logical address in the non-inline region will result in add_all_parents reading the invalid offset field of the inline extent. If the inline extent item is placed in the leaf eb s.t. it is the first item, attempting to access the offset field will not only be meaningless, it will go past the end of the eb and cause this panic: [17.626048] BTRFS warning (device dm-2): bad eb member end: ptr 0x3fd4 start 30834688 member offset 16377 size 8 [17.631693] general protection fault, probably for non-canonical address 0x5088000000000: 0000 [#1] SMP PTI [17.635041] CPU: 2 PID: 1267 Comm: btrfs Not tainted 5.12.0-07246-g75175d5adc74-dirty microsoft#199 [17.637969] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [17.641995] RIP: 0010:btrfs_get_64+0xe7/0x110 [17.649890] RSP: 0018:ffffc90001f73a08 EFLAGS: 00010202 [17.651652] RAX: 0000000000000001 RBX: ffff88810c42d000 RCX: 0000000000000000 [17.653921] RDX: 0005088000000000 RSI: ffffc90001f73a0f RDI: 0000000000000001 [17.656174] RBP: 0000000000000ff9 R08: 0000000000000007 R09: c0000000fffeffff [17.658441] R10: ffffc90001f73790 R11: ffffc90001f73788 R12: ffff888106afe918 [17.661070] R13: 0000000000003fd4 R14: 0000000000003f6f R15: cdcdcdcdcdcdcdcd [17.663617] FS: 00007f64e7627d80(0000) GS:ffff888237c80000(0000) knlGS:0000000000000000 [17.666525] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [17.668664] CR2: 000055d4a39152e8 CR3: 000000010c596002 CR4: 0000000000770ee0 [17.671253] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [17.673634] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [17.676034] PKRU: 55555554 [17.677004] Call Trace: [17.677877] add_all_parents+0x276/0x480 [17.679325] find_parent_nodes+0xfae/0x1590 [17.680771] btrfs_find_all_leafs+0x5e/0xa0 [17.682217] iterate_extent_inodes+0xce/0x260 [17.683809] ? btrfs_inode_flags_to_xflags+0x50/0x50 [17.685597] ? iterate_inodes_from_logical+0xa1/0xd0 [17.687404] iterate_inodes_from_logical+0xa1/0xd0 [17.689121] ? btrfs_inode_flags_to_xflags+0x50/0x50 [17.691010] btrfs_ioctl_logical_to_ino+0x131/0x190 [17.692946] btrfs_ioctl+0x104a/0x2f60 [17.694384] ? selinux_file_ioctl+0x182/0x220 [17.695995] ? __x64_sys_ioctl+0x84/0xc0 [17.697394] __x64_sys_ioctl+0x84/0xc0 [17.698697] do_syscall_64+0x33/0x40 [17.700017] entry_SYSCALL_64_after_hwframe+0x44/0xae [17.701753] RIP: 0033:0x7f64e72761b7 [17.709355] RSP: 002b:00007ffefb067f58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [17.712088] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f64e72761b7 [17.714667] RDX: 00007ffefb067fb0 RSI: 00000000c0389424 RDI: 0000000000000003 [17.717386] RBP: 00007ffefb06d188 R08: 000055d4a390d2b0 R09: 00007f64e7340a60 [17.719938] R10: 0000000000000231 R11: 0000000000000246 R12: 0000000000000001 [17.722383] R13: 0000000000000000 R14: 00000000c0389424 R15: 000055d4a38fd2a0 [17.724839] Modules linked in: Fix the bug by detecting the inline extent item in add_all_parents and skipping to the next extent item. CC: [email protected] # 4.9+ Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Boris Burkov <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
[ Upstream commit e1ba7f6 ] We're observing test flakiness on an arm64 platform which might not have timestamps as precise as x86. The test log looks like: test_time_tai:PASS:tai_open 0 nsec test_time_tai:PASS:test_run 0 nsec test_time_tai:PASS:tai_ts1 0 nsec test_time_tai:PASS:tai_ts2 0 nsec test_time_tai:FAIL:tai_forward unexpected tai_forward: actual 1702348135471494160 <= expected 1702348135471494160 test_time_tai:PASS:tai_gettime 0 nsec test_time_tai:PASS:tai_future_ts1 0 nsec test_time_tai:PASS:tai_future_ts2 0 nsec test_time_tai:PASS:tai_range_ts1 0 nsec test_time_tai:PASS:tai_range_ts2 0 nsec microsoft#199 time_tai:FAIL This patch changes ASSERT_GT to ASSERT_GE in the tai_forward assertion so that equal timestamps are permitted. Fixes: 64e1582 ("selftests/bpf: Add BPF-helper test for CLOCK_TAI access") Signed-off-by: YiFei Zhu <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Adds
xt_recent
module, needed foriptables -m recent ...
, used by Kubernetes kube-proxy to implement Services withsessionAffinity: ClientIP
Edit: also included in #176